In de volgende afbeelding is deze flow schematisch weergegeven:

Parameter

Je hebt één parameter tot je beschikking. Het bericht dat je stuurt/ontvangt dient van het datatype Text te zijn. Een enkelvoudige string als bericht is vaak niet zo’n probleem. Maar als je meer data en eventueel van verschillende datatypen wilt terug sturen, dan blijkt een enkele Text parameter niet zo handig.
Vaak krijg je dan ad hoc constructies waarin variabelen aan elkaar geregen worden met scheidingstekens. Zoiets als:

De action die de notify ontvangt wil je deze tekst weer ontleden. Hiervoor komt de system String_Split action om de hoek kijken:

De String_Split levert een lijst op met in dit geval drie rijen:

Wil je naar de inhoud verwijzen, dan ben je genoodzaakt om hard te verwijzen naar de rijen. Als je dit in een conditie gebruikt, komt dit de leesbaarheid en begrip niet ten goede:

Gelukkig is er ook een betere manier voor bovenstaande constructie. Om het retourneren te structuren en het gebruik van de data te vereenvoudigen, hebben we twee andere built-in actions tot onze beschikking, namelijk JSONSerialize en JSONDeserialize.

JSONSerialize en JSONDeserialize

Met JSONSerialize kun je een Record of List of Records datatypen converteren naar tekst. Dit kunnen bijvoorbeeld entiteiten/structures of lijsten hiervan zijn. Vervolgens gebruik je JSONDeserialize om de tekst weer terug te vertalen naar het oorspronkelijke data type.
Als we de vorige ad hoc constructie vervangen met een implementatie met de zojuist genoemde actions, zien we een duidelijk verschil. De notify bevat nu alleen de uitkomst van het serialiseren van een record variabele:

Hieronder zien we het resultaat van de JSONSerialize action:

De String_Split wordt vervangen door de JSONDeserialize, om de tekst weer om te zetten naar een record:

Herschrijven we de conditie van hierboven, dan krijgen we:

Een stuk duidelijker en geen harde verwijzingen naar posities in een lijst.

Is de JSONSerialize/Deserialize manier feilloos? Nee, je zal goed moeten opletten dat je in beide actions steeds hetzelfde datatype gebruikt. Anders kan het als nog runtime fouten opleveren. Als je bijvoorbeeld de inhoud van een text datatype naar een integer datatype serialiseert, dan levert dit een foutmelding op:

Als je geluk hebt levert het een foutmelding op, zodat je in ieder geval weet dat er iets fout gaat. In het slechtste geval levert het onverklaarbare functionele fouten op, als gevolg van onverwachte data.

Ik ben van mening dat deze manier meer voordelen dan nadelen heeft. Het is een goed gebruik om het elke keer toe te passen.