Workflow Engines and ERP: current state of the discussion

[StephenOTT]

@bernd.korthaus

I am more familiar with “simple” data objects like projects, invoices, business_partners and persons.

Same idea of a case. Invoices are just a form of record that gets stored. How that invoice gets generated, reminders, workflow, business rules etc, that execute around the invoice can be orchestrated by one or many workflows working together or in complete separation.

@bernd.korthaus

In those cases there is often a 1:1-relationship between process (= invoicing) and data object (= Invoice).

The I like to really break down the objects into what is the container and what is the input/output. The container may be the request to generate a invoice. The input is the various data about what should go into the generated invoice, and the output is the actual invoice record/data object. I have found that this approach provides flexibility around how the business wants to operate and not have to conform to how the system has designed it data objects.

A project is very much like a case. A project has all sorts of processes that could be activated around that project in sequential, parallel, and ad hoc ways. The project itself is really just a collection of associations and raw data. How the data got done may be part of the WfMS, another system or other code in the ERP. So I would tend not to create a Project handling process. I would create many smaller processes that can be activated around the Project object. (this is the similar use case for using CMMN).

@bernd.korthaus

And I guess that all associated process instances and their related tasks will again be stored beneath the case object, which makes everything well documented and traceable.

In the camunda case, and the simple case example I gave you, the tasks and process instances solely live in Camunda. Anything that is generated by Camunda against the case is logged as attributes of the data object as a SourceSystem and the IDs relating back to the process instance.

Something to note: You may of noticed there is the concept of KPIs at the case level. While there can/is KPIs in the process, we found it better to allow a third-party source to capture KPI markers because KPIs could be generated by camunda, but also by many other systems and actors that are all part of the same case instance.

@bernd.korthaus

But again the case itself can be seen as a data object that stores the data and holds all relations.

Yes, but the case is part of a large system. So that large system has Users, business units, permissions, records, reports, related objects like invoices, and notifications. The case just represents a form of container to store a timeline and data and actions that occurred.