State is transfered between controller and workers in a JSON object. This approach is very flexible and can basically contain any data, even binary. It's an easy to implement, generic, scalable, robust and meeting enterprise software design standards.
What is JSON?
{"label":"value"} > This is JSON ;-) JSON, or JavaScript Object Notation, is a minimal, readable format for structuring data. It is used primarily to transmit data between client and server or web services. So, we use it to exchange state in our different process steps.
How to design the Message Object(s)?
Design the message objects according to your scenario and business needs is key to success. Define them to be consumed in the most efficient way within Flow.
For a larger solution, you might ending up haveing multiple state objects for multiple controllers. So make sure to have an kind of a standard on how you stucture things.
A nested approach can you can avoid unnececary parsing actions in Flow and keep your solution architecture smart. Each level can represent one level of logic in the State Machine.
So for example Level 1 coud be approval type, where level 2 contains a nested JSON object containing more detailed instructions to the controller or a worker. This is how we implement it in our example here.
Schema & Values
So, that's how the nested JSON schema looks in bare metal:
{ "type": "object", "properties": { "messageType": { "type": "string" }, "messagePayload": { "type": "string" } } }
...and that's how it looks, when it's populated with data:
{ "messageType": "ParallelApproval", "messagePayload": "{"action":"start", "timestamp": "01.01.2020 22:00","initiator":"mail@mail.com","approvers": "user1@mail.com", "approvalDueDate": "01.01.2019", "approvalComment": "Sometest comment"}" }
Let's have a look at the detailed structure of the messagePayload object:
{ "type": "object", "properties": { "action": { "type": "string" }, "documentID": { "type": "string" }, "fileName": { "type": "string" }, "timestamp": { "type": "string" }, "initiator": { "type": "string" }, "approvers": { "type": "string" }, "dueDate": { "type": "string" }, "fileID": { "type": "string" } } }
...and populated with some sample content:
{ "action": "start", "documentID": "CASC18-2117562390-1996", "fileID": "1996", "fileName": "https://contoso.sharepoint.com/sites/123/Software/CNEXT-Approval-TEST.docx?d=wa67921c222bf4be5b118ee9dd7c5ce50", "timestamp": "2019-01-25T22:39:31Z", "initiator": "cnext.support@contoso.com", "approvers": "cnext.support@contoso.com", "dueDate": "2019-1-31" }
Very handy stuff!
Content Description
For our example scenario, we transfer the following content: messageType
This represents the first level of controller logic. In our case it's a global command if to call a parallel or a sequential approval.
messagePayload The messagePayload itself represents a nested JSON object with detailed instructions for the level two in the controller logic. In our case these are instructions for the Worker Flows.
Message State Transfer/Modification
During it's lifecycle a message object can be passed multiple times between the Controller and the Worker Flows.
For clearness in logic, workers always report back to the controller and don't call each other individually. So, we don't get hit by distributed controller logic. We can implement different Controllers, responsible to manage a group of workers, but always reporting state back to a certain Controller makes sense.
