FME Server use case (Track & Trace voor procesketens)

18 juni 2020

Wanneer we bij Vicrea zien dat één van onze medewerkers met iets bezig is dat ook voor anderen interessant kan zijn, delen we dat graag. Deze keer een artikel over het monitoren van de voortgang van een serie FME Server processen, die als een keten in elkaar grijpen. 

                                    
Helmoet de
Zwijger is één van Nederlands door Safe Software gecertificeerde FME trainers en geeft diverse FME Trainingen voor Vicrea. Daarnaast is hij voor verschillende klanten ingezet op een breed scala aan opdrachten. Helmoet: “Ik vind het altijd geweldig om te vertellen over de mogelijkheden van FME en FME Server. Ook bij opdrachtgevers laat ik graag zien op welke manier FME ingezet kan worden om een gebruikerswens eenvoudig te realiseren.“

 

 

Track and Trace in FME Server

Bij één van mijn opdrachtgevers draait een gecompliceerd proces, dat uitgesplitst is in een aantal deeltaken, gerealiseerd op het FME Server 2017 platform. Het proces bestaat uit 15 stappen, die aan elkaar verbonden zijn met notifications. Automations worden in deze versie FME Server nog niet ondersteund, en ondanks dat dit niet meer de typische oplossingsstrategie is, is het leerzaam de situatie te beschrijven. Als is het maar om te laten zien hoe eenvoudig FME Server integreert met de buitenwereld.

 

Tijdens de uitvoering van het proces kent iedere stap het risico te struikelen over onverwachte data of nieuw te testen functionaliteit, waardoor de opvolging van de deeltaken wordt verstoord en het proces halverwege blijft steken. De processen draaien onder het admin account en de eindgebruiker kan de jobs niet zien. Omdat de totale duur van het gehele proces twee dagen besloeg, was de frustratie bij onze productowner groot wanneer hij van de beheerder – meestal na een dag of twee – te horen kreeg dat éen en ander was fout gelopen. Veel tijd kan bespaard worden wanneer de productowner weet wanneer een stap klaar was, zodat hij onmiddellijk maatregelen kan nemen als er in die stap iets fout ging, bijvoorbeeld het de data corrigeren en een nieuwe run laten starten. Tijd om de real time en automation mogelijkheden van FME Server te laten zien!

 

Een FME Server oplossing voor het Track and Trace probleem

Het proces is gebouwd in FME Server 2017 en bestaat uit een opeenvolging van meerdere workspaces die geautomatiseerd, als een keten, na elkaar uitgevoerd worden.

Het Notification mechanisme in een notendop

De schakels van de keten kunnen aan elkaar vastgeknoopt worden met behulp van Notifications. Een Notification kan bestaan uit een Publication (de trigger), een Topic (een gebeurtenis) en een Subscription (de reactie). Deze Notifications kunnen naar believen met elkaar verbonden worden. Zo kan één Topic meerdere Subscriptions veroorzaken, die op hun beurt ook weer een Publication kunnen triggeren; alle mogelijke combinaties zijn denkbaar.

 

Workspaces en notifications

Een FME Workspace kan gepubliceerd worden tegen een FME Server Service. Bij het publiceren naar FME Server kan bij het configureren van deze service worden aangegeven welke Topics de workspace triggeren. Onderdelen van FME Server, bijvoorbeeld een mail subscription, die dat Topic interessant vinden, zullen hun acties dan uitvoeren wanneer de trigger af gaat. Maar de workspace kan zelf ook een topic triggeren, bijvoorbeeld de succes en failure topics of via een FMEServerNotifier transformer. Op deze manier kan een hele serie workspaces automatisch en gesynchroniseerd worden gestart. Wanneer dit b.v. met schedules wordt geprobeerd, ontstaat een timing probleem doordat workspaces niet altijd na dezelfde tijd klaar zijn.

 

 

Voorbeeld van een implementatie

In de workspace keten van onze opdrachtgever waren alle workspaces uit de keten als subscription aanwezig. De subscriptions reageerden ieder op een eigen topic. Nu is een bijkomend voordeel van het Notification mechanisme dat dit ook gebruikt kan worden om de voortgang van een keten van workspaces te monitoren. Het volstaat daarbij om één extra subscription te bouwen, die reageert op alle Topics uit de hele keten, en dat is een fluitje van een cent!

 

De subscription

FME Server heeft een naam voor de subscription nodig, en die is snel verzonnen. Verder moeten alle topics die van belang zijn in de monitoring van de voortgang van het proces als Topics Subscribed To worden opgegeven. Maar wat moet de subscription workspace eigenlijk precies gaan doen?

 

 

Het protocol achter de subscription: een workspace

FME Server kent een aantal standaard acties (“protocollen”) die gebruikt kunnen worden als respons op een topic. Voorbeelden zijn het versturen van een mail, het uploaden van een bestand via FTP of het sturen van een respons naar een webpagina. Maar het is ook mogelijk om een FME Workspace als actiehouder te benoemen, en daarmee staat alle functionaliteit van FME ter beschikking als reactie op een gebeurtenis in FME Server!

 

 

Een eigen ‘protocol’: Twitter

Voor de demo heb ik daarom een wat meer voor de hand liggend protocol gekozen om de voortgang van de procesketen te monitoren en wel Twitter. Met de Tweeter of de DirectTweeter transformers is het mogelijk om via een workspace Twitter berichten te versturen. De geïnteresseerde productowner of andere teamleden moeten dan wel een Twitter account hebben, waarmee zij de voortgangs-Tweets kunnen volgen.

De workspace voor het versturen van de Tweets is erg eenvoudig, en bestaat uit een Textfile Reader, een JSONFlattener, en een Tweeter. De Textfile Reader dient om de Topic Message uit te lezen. Dit is een bericht in JSON formaat dat FME Server intern tussen de elementen van de Notifications heen- en weer stuurt. Dit bericht kan naar de reader in de workspace worden gestuurd door bij de workspace parameter in de subscription het vinkje “Get Value from Topic Message” te zetten. Belangrijk is wel om bij de Textfile Reader als parameter op te geven dat de gehele tekst als één geheel gelezen moet

worden.

De Topic Message komt beschikbaar als JSON tekst, en om te kunnen beschikken over de tags en de values van de JSON tekst, gebruik ik een JSONFlattener. In de JSONFlattener kan aangegeven worden welke tags in de workspace als attributes beschikbaar gemaakt moeten worden (als ‘Attributes to Expose’). In dit geval zijn dat de naam van de workspace (die de topic aanraakt) en de status van de job die is afgerond.  

 

Vervolgens kan in de Tweeter de tekst worden opgegeven van het bericht dat naar Twitter moet worden gestuurd. Ook moet het account worden opgegeven, waarmee de tekst getwitterd zal worden. In dit geval wordt met mijn eigen Twitter account alleen de naam van de workspace en de statusmelding van de job getweet.

 

Resultaten

De productowner kwam bij me met zijn vraag, toen de procesketen op de testomgeving inmiddels was gestart. Maar dat was geen enkel probleem. Direct na het publiceren van de subscription, ging de aanpassing al ‘life’. Dat wil zeggen, met de eerst volgende job die door FME Server gereed gemeld werd na het implementeren, ging het topic voor de volgende stap af. En dus ook de nieuwe subscription. De Tweeter workspace las de naam van de workspace en het job resultaat uit de topic message en twitterde deze naar het aangegeven account, waar deze door alle volgers werd gezien:

 

 

Aandachtspunt: onmiddellijke in werkingtreding

Het nieuwe Track and Trace systeem begon dus midden in de keten al te werken! En de twitter workspace had niet meer dan een halve seconde nodig om zijn werk te doen. We  moeten hierbij natuurlijk wel in het oog moet houden, dat wanneer er geen engine beschikbaar is om de Track and Trace job uit te voeren, de Track and Trace taak misschien wel pas na de volgende job in de keten wordt uitgevoerd.

 

 

Aandachtspunt: Authenticatie van webservices

Iets anders om op te letten is dat ik om redenen van eenvoud hier mijn eigen Twitter account gebruikt heb. Bij het publiceren van de workspace is dat naar FME Server overgezet. In de praktijk zal een opdrachtgever daar een specifiek account voor willen gebruiken, en dat in FME Server zelf willen configureren. Ook zal in de praktijk vaker gekozen worden voor de DirectTweeter, omdat deze specifieke gebruikers kan adresseren, en niet het bericht voor de hele wereld zal willen versturen.

 

Aandachtspunt: Herhaalde twitter berichten

Iets waarin ik bij het testen achter kwam, is dat Twitter berichten niet herhaald mogen worden; wordt hetzelfde bericht te vaak herhaald, dan wordt het bericht geblokkeerd. Verder hebben Twitterberichten een beperkte lengte. Dus het doorgeven van de complete topic message lukt niet. Heel bescheiden meldt de Twitter website dan dat het bericht “iets” te lang is. Herhalende en/of te lange tweets zijn eenvoudig te voorkomen door slechts een beperkt deel van de topicmessage door te geven in de vorm van b.v. alleen de naam van de workspace, eventueel gevolgd door een volgnummer of timestamp.

 

De FME Server 2019 kijk op het Track and Trace probleem

FME Server is gebouwd rond drie kern taken: self-serve, real-time en automation. In versies tot en met FME 2018 werd het automation deel ingevuld met behulp van notifications. Dat werd in het bovenstaande voorbeeld ook toegepast. Vanaf FME Server 2019 zijn automations compleet anders ingericht en is het kinderspel geworden om een gecompliceerd proces automatisch uit te voeren: eenvoudig bouwstenen achter elkaar plakken in een drag- and drop-achtige interface.

Toevoegen van de Twitter bouwsteen

In het bovenstaande voorbeeld zou het volstaan hebben om een automation aan te maken met slechts één trigger en een (interne) actie. De trigger moet als type “FME Server Topic notified” geconfigureerd worden, en kan op dezelfde Topics reageren. Het aansluitende blokje is een Action van het type “Run a workspace”, waarin weer de workspace wordt aangeroepen die het resultaat twittert.

 

De workspace is echter iets anders. Waar de oude Notification de topic message naar een tekst bestand schreef, wordt in FME Server 2019 de gehele topic message via de command line verwerkt. Een textfile reader is dan niet meer nodig, maar alleen een creator. De JSONFlattener blijft staan, maar leest de workspace- en statusgegevens uit een published parameter.

Best practise bij kettingen van workspaces

Tenslotte wil ik de lezer nog wijzen op de best practises bij het bouwen van complexe processen die uit meerdere workspaces bestaan. Eerst en vooral de opmerking dat het niet echt nodig is om een workspace op te knippen in stukken omwille van de data die geschreven wordt, om die weer in een volgende stap uit te lezen en verder te verwerken. Met een FeatureWriter/FeatureReader combinatie kan vermeden worden dat de workspace wordt opgesplitst. Een tweede benadering zou zijn i.p.v. met Notifications, de “worker” workspaces aan elkaar te verbinden met FMEServerJobSubmitters in een “Parent” workspace. Dit is tegenwoordig goed mogelijk, ook in situaties met een Single Engine FME Server, waar de “worker” workspaces de “parent” in kunnen halen. Deze benadering maakt het ook mogelijk enige logica in het starten van workspaces in te bouwen, bijvoorbeeld onderscheid maken tussen Twitter gebruikers die een kort bericht ontvangen en mail gebruikers die een wat langer bericht kunnen ontvangen. Maar de mogelijkheden met FME Server 2020 zijn hier volop in ontwikkeling (met b.v. de Automation Writer om parameters binnen automations van workspace op workspace door te geven).

Slot

Dit artikel bedoelt inzicht te geven in de mogelijkheden van FME Server.  Het presenteert het probleem van de monitoring van hele procesketens die in FME Server zijn gebouwd met behulp van Notifications. Het blijkt mogelijk om relatief eenvoudig in te grijpen op de Topics met een nieuwe Subscription die b.v. via een Twitter bericht inzicht geven welke workspace met welke status is afgerond. De resultaten geven aan dat voor het versturen van een tweet niet meer dan een halve seconde nodig is; wel moet capaciteit op een andere engine beschikbaar zijn. Vanaf FME 2019 is dit nog eenvoudiger te realiseren met de nieuwe Automation interface.

 

 

Deel dit artikel