rsoika
commented
2 months ago Yes this is different in Imixs-Workflow. In your example the task is the place were something happens. And the worfklow engine does nothing else than executing one task after another until the process terminates with an end event. This is what I call a task-orientated processing concept.
In Imixs Workflow we have an event-orientated processing event. The difference is that in this concept the task defines a persistent unique state in the process flow. The workflow engine only reacts on events. If no event is fired the process status will not change.
You can see this in the wording. The task describes a fact like 'We received a new Invoice' or 'The invoice is ready for Approval'. But the task does not define what will happen. But if someone or something triggers the event 'Add Items' the workflow Engine will update the workitem status according to the process flow. So the action is the event like 'I add new items' or 'I approve the invoice'.
And from the coding perspective in your example the code (like adding items) is executed in a Task. So there is some code bound to the task that adds the items. In an event-orientated workflow engine this it different. If you want to add items you first need to fetch the process instance (workitem) from the persistence layer (data store). Now you can add data like items to the workitem and finally you call the event 'Add Items' to signal that now all is ready for the next step. The Workflow Engine coordinates this transition.
So from the coding it looks like this:
// fetch the workitem from the data base
workitem=database.load(id);
// change or add the payload
workitem.addItems();
// process the workitem
workflowEngine.process(workitem.event(100));The advantage is that you always have a clear definition of the state because this state is only be set by the workflow kernel. You can not tweak the status!
And I always wonder how in the task-orientated model the status is defined? When "Get Invoice" is finished and "Add Items" is started, what is if something goes wrong? In which status is the process instance? Is the process instance still in the "Add Items" task? Or is it now again in "Get invoice".
In Imixs-Workflow this is an transactional flow. If your process instance is in the status "New Invoice received" you are allowed to add items and fire the event "Add Items". If this is successful - and only than - the status will change to "Approval" and the status will be persisted. But if something goes wrong the transaction is rolled-back and the status is still "New Invoice received".
And this is the reason why we depend on Jakarta EE and the EJB Container that supports transactions.
gmillinger
Workflow example (start) -->[new ticket] --> (submit) --> [open] --> (end)
start, submit, end being events I am having trouble with sorting out events. Why is it required to have an event before a task?
This why I have trouble with this, in the past I have seen cases where tasks can flow one to another as they are completed. For example: (start) -->[Get Invoice] --> [Add Items] --> [Approve] --> (end)
"Get Invoice", "Add Items" are service tasks. Approve is a user task. Once Get Invoice retrieves the invoice data the task is complete and the workflow transitions to the Add Items task. The Invoice data is held in context and is used for input for the Add Items service task and it is executed and the workflow transitions to the Approve task. Finally the Approve task shows up in a task list and a human will look at the updated invoice and approve/disapprove it and the workflow ends.