Modular Process Building in OTRS.

Shawn Beasley18. Sep 2019 | Miscellaneous

BPMN 2.0 differentiates between an embedded subprocess and a call activity. From a conceptual point of view, both will initiate a subprocess when process execution arrives at the activity.

The difference is that the call activity references a process that is external to the process definition, whereas the subprocess is embedded within the original process definition. The main use case for a call activity is to have a reusable process definition that can be called from multiple other process definitions.

Although OTRS does not have a subprocess modeling capability as of OTRS 7 (or with upcoming OTRS 8), I will show you how to make a process modular.

Just gimme the core message.

In the above process, the “Approval” subprocess could be very detailed, and it could make designing an already detailed process more time consuming.

Approval process.

Subprocesses, like approvals, are often standardized processes that are needed in many areas of business from vacation requests, to hardware orders, to on-boarding tasks. Below we can see how the using a modular process called by a script task activity above can greatly increase readability in an already detailed process.

Hardware Order

To standardize this and make the subprocess of approval reusable, BPMN 2.0 defines a call activity. Because OTRS itself doesn’t have subprocesses or call activities, we will make use of the “magic” which makes a process ticket a process ticket — dynamic fields.

A process is identified by the ProcessID and the ActivityID. Without these, it’s YAT (yet another ticket). In order to spring from one process to another, just quickly rewrite the information via a script task activity and then you’re off to the call activity (or YAP – yet another process).

Script task activity: leaving a process for a call activity.

You will have to remember the old ProcessID and ActivityID by saving them to dynamic fields. Additionally, you should jump back into a dummy activity to prevent a loopback situation. Therefore you will need to know the next ActivityID before you leave your process for the modular process.

You may have as many activities in your modular process as needed, and then return by simply using the saved ProcessID and next ActivityID to return.

Script Task Activity: return from modular process

Note: Don’t forget to remember your decision. This will be automatically processed by the sequence action flow upon returning to your calling process.

All data saved during the process Hardware Order can be used in the Approval process, and all data saved in the Approval process can be used when returning to the Hardware Order process. This is the joy of saving the data to the ticket (also known as a business object record).

This works in a serialized fashion, meaning it’s not a parallel process. The approval process must be finished before continuing, which I guess is kinda the real-world situation anyhow.

ProTip: Set the Approval process to fadeaway so that it’s not callable and you don’t have to filter it per ACL. A fadeaway process will continue to work, but is not callable in the front end.

Summary (TL/DR)
Organizing your processes and making them more readable is easy when you use a script activity and dynamic field to move between processes. This especially makes sense when you have a reusable part of a process (a.k.a. a call activity).

((enjoy))

Best Wishes,

///shawn

“Instant gratification takes too long.”,

• 2