How to model process that calls sub-processes/activities dynamically

[cbuchberger]

Hello,

we are trying to model a process that handles the order, deployment and a bit more IT services we are selling to our customers. That means one or more services are ordered (offer is a different process), order has to checked, service(s) have to be built and delivered, and so on.

The part of building the services is highly dynamic. For every product we sell (and that turns into a service) we define workplans that have to be processed. Those workplans have an order and we can re-use the workplans in all our products. It is important to know that every product has different workplans.

The workplans itself are processes that are deployed in camunda. Some are short and siimple with only a human task, others are complex.

Products, workplans (reference to process deployed in camunda), services and more related information are all stored in a central service management database

We are able to retrieve all workplans (and their order as a number) for every service that has to be built from our service management database.

We are now facing the question how to model a process that starts all required workplans (processes) in the right order ? I could imagine something like

1. Have a service task that gets all processes for service XYZ (input variable) with level 0 (input variable) and returns a collection of process-ids
2. Call Activities in paralell (if there are any) and then wait for all activities to complete
3. increase level by one and go back to 1. That gives the processes that have to be run next.

Is this the right approach ?
since we are just beginning with camunda (and bpmn ) any help is appreciated

We also have to think about the following

• How to identify the relation between the main process and the workplans (call activities) ? Should we use the same business key, or prefix the business key of the called activity with the business key of the main process. This is required for an overview/list in a portal-application (show all subordinate workplans and their current state)
• Called Activities might generate events that need to be handled in the main process
• Handling of cancellation of the main process needs some kind of compensation, e.g. all work that has been done so far must be undone. This is required both for currently running called activities and for those that have been executed already.

Thanks again & looking forward for some tips

[StephenOTT]

@cbuchberger we follow a similar example for dealing with “services” for governments.

In our case we have a Service that has Service Scenarios:

A Service is a parent grouping used as a generic item: Request a Server
A Scenario is a sub item that has the actual bpmn activation attached to it: Request 1 Server, Request Multiple Servers, Request Server - Priority

The reason for different scenarios is the ability to reuse BPMNs across scenarios as a “Generic” bpmn and the BPMN is injected full of variables.

So this leads to cases were we have many sub-processes that can activated based on the uniqueness of the client and their departments: similar to your IT services and your specific clients that have specific workplans, and workplans that are specific for certain services or groups of IT infra/tech.

A few assumptions i make based on your description:

1. The top level workplan order is executed in sequential order.
2. workplans may be a sudo-workplan that is actually a combination of other workplans

And you end up with something like this:

and you configure the call activity with sequential, so it’s in order (as per your workplan requirement).

And you config your call activity with a variable:

notice how the multi-instance is setup.

And now when you want to run parallel workplans, this is where the “sudo-workplans” come into play; your workplans can also just be a workplan that is executing other workplans in parallel:

Click on the image to see the full length

Where Plan ABC was just actually calling Plan 1 and 2. Therefore in the My Service, you dont need to actually have your Workplan list, have every workplan, just the packages or workplans, and the overall order. The overall order is that “Master” order i mentioned above.

You could also get into really interesting use cases of Signals and Messages from the child processes to the parent service process for things like client reporting of errors or failed deployments.

[cbuchberger]

Hi @StephenOTT - thanks a lot. That was quite useful.

[StephenOTT]

@cbuchberger did you end up building anything you can share your experience on?

[cbuchberger]

Well actually our approach wasn’t dynamic enough. he rquirement was to add (or remove if not started yet) workplans to the workorder on the fly. So we are going to use some kind of project management tool to define tasks. Those tasks can be Camunda processes. The plan is to be able to start processes from the the project management tool, or integrate it even more (status, assignment, etc,)