# Investigation of Microservice-Based Workflow Management Solutions for Industrial Automation
## 4 Strategies for Workflow Management in a Microservice Architecture
### Workflow Manager and Executor
Starting with the web service composition strategy, these systems control the workflow centrally, are driven by the internal state machines, and consume the services according to their logic. In addition, the information relevant to each workflow step is routed through the Executor, which is in stark contrast with a choreography web composition strategy. The trigger signal for a workflow comes from an external system that consumes the Workflow Manager services, while working in a smart factory environment, such a signal is expected to arrive from a decentralized system, such as a smart product. In other cases, the command will arrive from a centralized system, such as an MES or ERP. Figure 4: Workflow Manager and Executor service interactions. A few limitations of the capabilities of the process-task relation are imposed on the applications that use the Workflow Manager and Executor systems. The Workflow Executor is able to enact multiple workflows simultaneously. Each workflow executed is assigned an individual ID, which helps identify multiple workflows based upon the same underlying model, i.e., the same FSM. The ID is also communicated to the Workflow Manager to support the tracking of each workflow by third-party systems. During runtime, while a workflow is being executed, it is possible to act upon it to stop, modify, resume, or discard it as needed. Both systems are designed with concurrency in mind and are able to handle multiple service requests and consume several services simultaneously. Since internal workflows are represented as FSMs, each workflow can only be in a single state at any given time. This feature provides determinism, i.e., the behavior of the system can be known in advance if the inputs and initial state are known, but it also has some shortcomings. The analysis of parallel FSMs is complex and other workflow representations can be more suitable for illustrating the state or modeling parallel tasks. Synchronous and asynchronous communications are possible using this solution, with the only limitations being imposed by the Java programming language chosen for the current implementation. The Workflow Manager, which handles communications with third-party systems, can harness the advantage of asynchronous communications at all times. Meanwhile, the Workflow Executor is contingent on the logic of each workflow, choosing between synchronous and asynchronous messaging according to each state action code. Overall, the Workflow Manager and Executor provide a bare-bone and flexible solution to WFM. They provide workflow support without requiring major changes in infrastructure or being intrusive to other systems operating in the same environment. As they have been developed as research prototypes, the focus has been on functionality rather than reliability. Included are simple software constructions and a few dependencies to simplify future expansion, together with an open source license to promote community adoption. Nevertheless, they require one to be familiar with software programming to create the FSM and describe the state behavior. One of the main disadvantages of this solution occurs at the design phase of the workflow engineering lifecycle. The Workflow Manager and Executor systems do not explicitly support modeling state machines. However, once the state machine is modeled, it can be converted into software and added to the Workflow Executor through its web application programming interface (API).