communication between micro processor and the workflow engine

[rsoika]

Concept how the communication between micro processor and the workflow engine should work

• The workflow engine should accept commands to receive a process definition (BPMN xml), start the process, stop the process, accept external data that advances the execution of a task.
• use of peer-to-peer computing and mesh networking. remove internet and/or WAN dependency within the walls of the facility.

[gmillinger]

Addressing each point in separate comments.

-- Requirement: The workflow engine should accept commands to receive a process definition (BPMN xml), start the process, stop the process, accept external data that advances the execution of a task.

-- Explanation: This explanation reflects how I have done this in the past, I would expect there are better ways to do it. It is important to note the design constraints when thinking through this. The solution must be lightweight, minimum dependencies, run on computing resources such as Raspberry Pi, and so on. This rules out some of the heavyweight enterprise application infrastructures/platforms. Simplicity is the key concept.

This breaks down into an architectural description. Each software component is a stand-alone running program thought of as a service. For example, the workflow engine is a service that manages one or more running process definition instances that consumes and emits events using a publish-subscribe design pattern. The workflow engine is considered the hub which exposes a websocket for the exchange of the event messages. Other clients or services could make a secure connection to the engine and receive events and publish events to the engine. Examples of client-services are automation equipment and user interfaces such as a webpage. The event messages can be considered "commands" such as "load bpmn xml", "start process", "stop process", and so on. The event messages also publish state changes of the process and context data captured at the state change.

It may make more sense to do this locally with a type of plugin design pattern but there still exists the need to communicate more broadly with other workflow engines on the same network. This describes a decentralized approach with many workflow engines running on the same network on individual computers such as a Raspberry Pi acting as the workstation. The same requirement exists within a centralized application architecture design but is probably better using a different method of communication or an enterprise infrastructure.

The most important thing is meeting the requirement. Whatever technical solution meets requirements and constraints can be used.