In this short blog post I want to talk about the concept of workflow engines and what they are really good for. A workflow engine is the most misunderstood concept in modern software development. Many developers still believe a workflow engine is simply the description of steps to go for getting a work done => the Work-Flow.
From the example above it seems to be quite easy. We can implement a workflow engine by just storing the status within a data table:
Process Instance | Workflow Status ---------------------------------- cdbd825a-32ad | New Ticket a65cf0b1-9a2e | Open 19f97d5c-cd21 | Open 01fea8f2-b37f | Solved
Thus, we always know which process instance is in which state and we can change it at any time. Of course we can also extend our table to know when it happened and who was responsible:
Process Instance | Workflow Status | Date | UserID -------------------------------------------------------- cdbd825a-32ad | New Ticket |2022-01-01 | john a65cf0b1-9a2e | Open |2022-01-02 | john 19f97d5c-cd21 | Open |2022-01-02 | bob 01fea8f2-b37f | Solved |2022-01-09 | anna
But what we are doing here is just persisting the state of an object. This basic core concept is also known as a ‘State-Machine‘. If we go further and follow the modelling approach we can think about more complex workflow models containing also some decisions and business rules:
In this example a workflow engine decides if an order goes to the Management (>=100 EUR) or directly to the sales team (<100 EUR). The workflow engine is now evaluating a business rule based on the business data. We can still use the table model from before, but our engine is now more intelligent and controls the work-flow. This extended concept is also known as a ‘Rule-Engine‘.
What, How, ….Why?
But a workflow engine does a lot more than that. Until now we only answered
- the ‘what‘ = persisting the current state
- and the ‘how‘ = evaluating business rules
But what we did not answering is the ‘why’! If you think about more complex business applications the ‘why‘ is the most interesting question of a business process. It answers why a process has reached a certain state. For example if we have a complex “purchase requisition process” with a “4-eye approval process,” we’re likely have different persons involved at different times. We now may want to know why a specific order was approved or rejected, what happened during the processing live-cycle and when the process was finally completed.
All these steps happen at different times and are handled by different persons. To be able to re-vision such a business process we need a kind of protocol over the timeline telling us all the events happened during the business process. This is the only way to get an audit-proofed process flow.
And this is exactly what a Workflow Engine should be used for:
- controlling the status during the processing live-cycle
- evaluating different business rules
- logging every single event
- providing an audit-proofed process flow
As our business processes become more and more complex, these requirements are becoming more and more common. So if your next business application has these requirements, take a look at the Imixs-Workflow project . With its model-driven approach the project can improve your business workflows in a fast an very flexible way.