Cookies op Tweakers

Tweakers maakt gebruik van cookies, onder andere om de website te analyseren, het gebruiksgemak te vergroten en advertenties te tonen. Door gebruik te maken van deze website, of door op 'Ga verder' te klikken, geef je toestemming voor het gebruik van cookies. Wil je meer informatie over cookies en hoe ze worden gebruikt, bekijk dan ons cookiebeleid.

Meer informatie

Google brengt api uit om taken in Docs te automatiseren

Google heeft de zogeheten Google Docs API uitgebracht, waarmee ontwikkelaars in staat zijn allerlei taken te automatiseren die nu nog handmatig in Docs-bestanden moeten worden ingevoerd.

Google meldt dat de api het mogelijk maakt om geautomatiseerd nieuwe documenten aan te maken, de inhoud van een specifiek document op te halen of op gezette tijden een update door te voeren in een specifiek document. De api ondersteunt ook de optie om tekst in een document in te voegen, te verwijderen, samen te voegen of de teksteigenschappen aan te passen. Verder maakt de api het mogelijk om een alinea om te vormen tot een puntenlijst.

De Google Docs API is sinds vorig jaar beschikbaar als preview en is nu uit voor alle ontwikkelaars. Bedrijven kunnen hier bijvoorbeeld gebruik van maken om dezelfde maandelijkse verstuurde factuur automatisch te genereren, op basis van een template. Onder meer Netflix heeft al gebruik van de api gemaakt, in de vorm van een interne tool om zijn technici te ondersteunen bij het vergaren van data.

Door Joris Jansen

Nieuwsredacteur

11-02-2019 • 21:11

40 Linkedin Google+

Reacties (40)

Wijzig sortering
Ik denk dat een beetje onduidelijk is voor de meeste wat er nu precies is toegevoegd. Er was inderdaad gewoon een API beschikbaar. Ik heb namelijk ook een 1 a 2 jaar geleden een applicatie gemaakt die Google Drive als basis gebruikt.
Wat er toen niet was; was een manier om documenten ook daadwerkelijk te editen. Om maar 1 ding te benoemen. Dus het uploaden/downloaden ging prima, net als basis functionaliteiten beheren in een document (bijv. read only voor een bepaalde groep).

De nu nieuwe API biedt de mogelijkheden om veel meer IN je documenten te doen.

Sowieso is het af en toe een wir-war met de diverse API's en de versies hiervan. Je hebt dus nu:

https://developers.google.com/drive/api/v3/about-sdk : Voor basic CRUD meuk en permissies.
https://developers.google.com/docs/api/reference/rest/ : Voor het spelen IN je documenten zelf.

Volgens mij doe je er ook goed aan om de drive API eerst te gebruiken gezien de mogelijkheden qua permissies die IMO de docs API mist. Nu heb ik er nog niet heel erg goed naar gekeken, maar toch :)
De Drive API gaat dus inderdaad over Drive, en niet over Docs, Sheets, Presentaties, Sites en 3rd party zaken, die hebben een eigen API :)
Bij dit soort API's van Google vraag ik mij altijd af, hoe lang blijven ze het ondersteunen?
Of wel,is het de moeite waard om er tijd in te steken,met het risico dat ze het over een paar jaar er weer stoppen.

Het idee is leuk en zie ook wel mogelijkheden.
Ik denk dat je twee zaken door elkaar haalt: consument spul en de zakelijke tak van Google.
Google sluit welk vaker experimenten die ze met consumenten hebben gedraaid en geen succes bleek.

De zakelijke (GSuite) onderdelen nemen ze echter behoorlijk serieus. Deze worden ook gewoon lang ondersteund. Om je een idee te geven GSuite komt uit 2006 en heeft een lange set van API's.
http://services.google.co...logs/g_suite_timeline.pdf
https://developers.google.com/gsuite/

Deze Docs API heeft lang geduurd maar er waren ook genoeg alternatieve zaken zoals Google scripts: https://www.google.com/script/start/ of gewoon sjablonen gebruiken.

En voordat iemand begint te schreeuwen dat MS het veel beter doet:
https://docs.microsoft.com/en-us/graph/overview
Word heeft (nog) geen open API
mmmm.... ik herinner mij een documentatie pakket met de naam 'Word' van een bedrijf met de naam 'Microsoft' waarin een duidelijke beschrijving stond van wat er allemaal wel (of niet) in de bestanden kon worden gedaan en hoe dat moest worden aangesproken, via de applicatie of direct in de bestanden.
Dat stond overigens op een plank met daarnaast ongeveer 4 keer zo dik de vergelijkbare documentatie van 'Word Perfect'...

Ergens in de jaren 1985, 1990 was er wel degelijk het een en ander mogelijk met programmeren en msWord. Al moet ik toegeven dat msWord toen nog erg beperkt was. WordPerfect was toen nog veruit superieur.
Naast VBA heeft word al lang een com interface API waarmee je heel geavanceerde zaken kunt programmeren inclusief mail merge met velden direct uit de database. Daarnaast hebben ze nu ook een JavaScript API.
Word perfect wow dan ben je de 40 wel gepasseerd ;)

Microsoft heeft (onder druk wel eens waar) de volledige specificatie van de Office suite bestanden vrijgegeven zodat jij, ik en iedereen gewoon alles volledig kan automatiseren. Als je echt via een API kan werken dan dat ook maar dan zit je vast aan de noodzaak om de juiste office executable te hebben draaien, dan wel via de (nog al afgrijselijk slechte) office 365 interface te werken.
De documentatie is zeer uitgebreid en voor veel mensen een flinke stap te ver wat betreft hun bereidheid om er iets mee te doen in een hobby setting. Denk aan honderden pagina's met zeer technische informatie over alleen al de outlook files
Uuhm, Microsoft heeft de volledige specificatie vrijgegeven, omdat ze wilden dat hun formaat (Office Open XML) als officiele standard werd erkend in plaats van ODF (Open Document Format).
Daar zat wel wat politieke druk achter vanuit het OASIS consortium en de OpenOffice groep, maar Microsoft heeft hiervoor zelf heel definitief gekozen en heeft zelfs wat vieze spelletjes gespeeld om hun standaard ook als standaard te laten worden erkend.
Dat was niet de eerste keer dat ze de msoffice documenten door de xml-molen hebben gehaald. Ik herinner mij rond office 2000 dat ze ook compleet aan de xml-standaard gingen voldoen... Ze hadden creatief gebruik gemaakt van het xml element "blob" (Binary Large OBject). Het was onder water gewoon het oude .doc formaat met een xml-header er voor en het oude binaire formaat in een blob element. En toen waren ze opeens compleet XML gespecificeerd. Maar niemand die er verder iets mee opschoot...
Je maakt een grapje?
De bestuursraad waar ik werk vond het leuk om een paar jaar geleden over te stappen op Gsuite.
Er was beloofd dat er nog veel functies bij gingen komen.
Ik kan je vertellen dat Gsuite vandaag nog steeds een schijntje is naast MS Office.

In Gmail kan je overigens nog niet eens een pdf openen in een degelijke viewer. (De ingebouwde crasht van zodra het wat moeilijk wordt, dan krijg je zo'n mooi wit scherm met "oops, something went wrong". Heel professioneel.)
Ik kan alleen maar hopen dat het veel goedkoper is, anders zijn we dubbel genaaid :)
In Gmail kan je overigens nog niet eens een pdf openen in een degelijke viewer. (De ingebouwde crasht van zodra het wat moeilijk wordt, dan krijg je zo'n mooi wit scherm met "oops, something went wrong". Heel professioneel.)
Ik kan alleen maar hopen dat het veel goedkoper is, anders zijn we dubbel genaaid :)
Dan zou ik echt jullie systemin nakijken. Want hier draait het gewoon prima. Ik heb PDF met soms wel 200 - 500 pagina's opent gewoon normaal.
Zoals je zelf schrijft; standaard documenten werken perfect.
Van zodra het formaat wat exotischer wordt dan A4 gaat het vaak minder perfect :)

Dat is dan ook mijn kritiek op Google: voor de standaard taken werkt het allemaal goed, van zodra het wat minder doorsnee is gaat het vaak de mist in. En dat is nu net waar MS een stuk sterker is.
Mijn baas vind Gsuite dan ook fantastisch, werkt perfect voor zijn taken, ik doe andere dingen.
Dat heet incompetente beheerders die de systemen onderhouden een zeer grote en complexe PDF openen is geen probleem maar ik gok dat je ook fijn met de onvolprezen Edge browser mag werken of misschien zelfs nog met IE (5.5?)

Ik gebruik zo wel de Office 365 als Gsuite oplossingen en om eerlijk te zijn is de Google oplossing een stuk prettiger om mee te werken. De Office 365 oplossing wil steeds maar weer een bestand openen in de lokale office en niet online bewerken, als je het bestand dan opent dan is het altijd in readonly mode en moet je eerst weer op een knop klikken om ook echt te kunnen editen.
Gsuite heeft dit vervelende gedrag niet maar heeft weer andere beperkingen, geen van beide zijn echt een volwaardige vervanging voor een lokale oplossing aan de andere kant voor de overgrote meerderheid van de mensen die dagelijks met Office werken is zo wel Gsuite als O365 voldoende. Maar prettig werken is met geen van beide echt het geval.
Nope, vectoriele pdf's, groot formaat, dat wel, in Chrome, laatste versie.
Van zodra je in Google applicaties de limieten opzoekt gaat het plat is mijn ervaring.
Ook zakelijk wordt je bij Gsuite zat door de keel geramd.

Ik ben wél met je eens dat alternatieven niet beter zijn maar van het design (mail bijv. hoeveel mensen wel niet ook zakelijk zo lang mogelijk naar classic wilden gaan) of Hangouts etc kan je stellen dat het wel degelijk veranderingen zijn die lang niet iedereen goed vallen, zonder keuze ook.
GSuite kent dit probleem ook, als ik in mijn mail box kijk, naar het aantal "ACTION REQUIRED" mails.
Daarnaast handteer Google in GSuite het heroine model. Eerst te gebruiken voor alle type accounts en langzaam moet je naar de duurdere, duurste accounts om bepaalde functies te kunnen gebruiken.
Sorry, dat is onzin. Nooit gebeurd.
Word heeft visual basic om alles te automatiseren, misschien iets lastiger, maar ook veel krachtiger.
Ik gebruik liever rest calls, dat is wat deze api betekend. Er zou met visual basic ge-automatiseert kunnen worden of python of C# of Java of whatever je hartje maar begeert en een request kan versturen.
Dat is wel gek, dat ze bij mij op het werk gewoon een programma heeft wat word taken automatiseerd.
Dit vraag ik me de laatste tijd ook wel af, nou ben ik niet echt op Google search een actieve Google gebruiker en hoor hier en daar best wel wat producten voorbij komen die erg goed klinken maar vrij snel gekilled worden.

We hadden in onze app de Firebase crash reporting ingebouwd, dat ging er uit, wij over naar Fabric, komt Fabric weer als Crashlytics naar Firebase, of ik heb ergens een stap gemist, maar elke keer die libraries inbouwen worden we ook een beetje zat
Helaas geldt dat zelfs voor elk product dat Google uitbrengt. Zakelijk zou ik er absoluut mijn geld niet op zetten. Vooral hoe kort van tevoren Google shutdowns vaak bekend maakt, maakt ze een erg onbetrouwbare zakenpartner, imho.
Voor zakelijk gebruik komt dat niet voor, of met sunsetperiodes van 2 jaar of meer (oude Google Sites)
Helemaal mee eens. Hun reputatie om lukraak dingen uit te zetten met vrij veel aggressie begint toch echt wel tegen ze te werken. Zelfs wanneer een nieuwe produkt van ze goed is, moet je bang zijn om er tijd en geld in te steken.
Was er niet al zoiets? Heb zelf een tijdje via IFTTT een aantal Google doc documenten laten updaten.
Ja, er waren al veel verschillende manieren om te interfacen met Docs maar een officiële API miste nog. Bij deze gefixed blijkbaar.
Zo, weer een stapje dichter bij VBA deprecation.
Is dit net zo krachtig als VBA dan?
Krachtiger.

Met VBA kun je ook tussen documenten werken, maar zit je met het probleem als bestanden van locatie of naam wisselen. Bij Google script kun je bestanden gewoon verplaatsen/hernoemen.

Google script doet alles via de browser (Android apps werken helaas niet met Google script). VBA werkt alleen in een lokale applicatie die 1 gebruiker. Google script werkt volgens realtime collaboration. Permissies zijn zo wel rol based als user based te gebruiken.

VBA is wel zonder limieten. Google script mag maar een bepaald aantal seconden per run iets doen. Aantal emails uitsturen is gelimiteerd.

Je hoeft geen programmeer expert te zijn om als iemand een vragenlijst invult via forms, de inhoud te verwerken in een document; uiteraard met complexere responses (als dan, value lookup, matrix berekeningen). Dit als pdf/word/PowerPoint attachment of bv comment only link terug te sturen per email naar deze persoon. Uiteraard met logging wanneer dit gebeurd is netjes in een spreadsheet inclusief link naar het verzonden document en de optie om het nog een keer te sturen. 5, 100, of met deelnemers is geen probleem.

Maar met professionele pakketten kun je meer. Mooiere en complexe vragenlijsten, complexere rapporten... Of het zelf creëren van een applicatie workflow met limesurvey en een programmeerbare rapportgenerator als basis component.

Allemaal gedaan/onderdeel van geweest. De afweging is geld, doorlooptijd, expertise, security risk, functionaliteit/complexiteit, imago.

Genoeg gelazer meegemaakt met limesurvey en pentesten. Maar ook de andere kant van het spectrum opmerkingen zoals: Google is toch niet professioneel.

Zelfs Google spreadsheet gebruikt zodat commercianten wat tabellen konden bijhouden dat als resultaat code opleverde die programmeurs copy/paste in de applicatie konden gebruiken; doorlooptijd van meer dan 2 weken naar max 2 dagen, van frustrerende itteraties naar 0 fouten.
Google Script kan triggeren onEdit, onOpen, of op een tijdtrigger (elk minuut, uur, dag etc)
Daarnaast kan Google Script via een HTTP call te bereiken zijn, dus dienst doen als API endpoint. Het wordt dan uitgevoerd als degene die het script aanroept (eerst inloggen!) of als degene die het script deployed. Het script is ook de 'user' op de rest van het platform.

"VBA is wel zonder limieten. Google script mag maar een bepaald aantal seconden per run iets doen. Aantal emails uitsturen is gelimiteerd.
"

Apps Script heeft een single-run van max 6 minuten en een daglimiet van 6 uur voor gratis gmailaccounts. Dit is 30 minuten / 6 uur voor G Suite accounts. Overigens kun je 1000 calls parallel doen,maar dan gelden dezelfde limieten. Je kunt vooralsnog niet betalen voor meer.

"Maar met professionele pakketten kun je meer. Mooiere en complexe vragenlijsten, complexere rapporten... Of het zelf creëren van een applicatie workflow met limesurvey en een programmeerbare rapportgenerator als basis component. "

Met Apps Script hebben we bijvoorbeeld deze app gebouwd, vergis je niet in de power van Apps Script
https://www.werf-en.nl/in...rganisatie-van-nederland/

Bovendien kan ik vertellen dat de ontwikkeling niet stil staat, met een nieuwe runtime binnenkort (zie Next ;18)

Disclamer: ik mag me Google Developer Expert noemen op Apps Script / G Suite API (waaronder ook Docs valt).
Je kunt het niet echt met VBA vergelijken lijkt me. VBA (Macro's) in Word draaien in het document zelf en deze API is om met het gehele platform te interfacen (inclusief de inhoud van documenten).
Als Marco tegenhanger heeft Google al lange tijd App script:
https://developers.google.com/apps-script/

Daarnaast had je al "screen recording" macro's:
https://techcrunch.com/2018/04/11/google-sheets-gets-macros/

Persoonlijk moet je altijd zo min mogelijk van dit soort "oplossingen" gebruiken. Allemaal maatwerk wat weer onderhoud nodig heeft.
Krachtiger qua taal eromheen. Wellicht is het document model minder uitgebreid (op dit moment).
Tegenwoordig kom je met Python en LibreOffice ook al een heel eind
Dit kan toch al jaar en dag via Google Apps Script? Ik zie niet meteen wat de toegevoegde waarde is? Of wat het verschil is?
Google App script is binnen de GSuite en API is extern te benaderen door bijv. Een Cloudapplicatie.
In theorie deed ik dat al met de Execution API, maar nu kan het direct.

De Apps Script methode is wat uitgebreider nog.
Deze nieuwe API lijkt precies te doen wat autoCrat al jaren deet in Google app's script.
Dat werkte ook volledig op google drive. Maar nu is het dus door Google gemaakt.
https://chrome.google.com...hfnlijoafjjkpoakpjjpdkgdj
Autocrat werkte op Google Apps Script en dat is er nog steeds ;)


Om te kunnen reageren moet je ingelogd zijn


Apple iPhone XS Red Dead Redemption 2 LG W7 Google Pixel 3 XL OnePlus 6T (6GB ram) FIFA 19 Samsung Galaxy S10 Google Pixel 3

Tweakers vormt samen met Tweakers Elect, Hardware.Info, Autotrack, Nationale Vacaturebank, Intermediair en Independer de Persgroep Online Services B.V.
Alle rechten voorbehouden © 1998 - 2019 Hosting door True