Introduction
Defining the runtime of a process based on conditions is a common use case. So far, SAP BPM supports this by offering an exclusive gateway. However, this gateway has a restriction: only the first sequence flow with a condition evaluated as true is taken.
But how do you model processes when several sequence flows with true-evaluated conditions should be run through? Would you like to follow several paths? Imagine a scenario where you would like to manage the business process: translating a text into several languages. Based on the text, you might want to translate it either to German only - or to German, Spanish and/or Italian.
Starting with SAP NetWeaver Developer Studio (NWDS) 750 SP1, there is now a possibility to model and run scenarios exactly like this: using the newly introduced inclusive gateway.
Modelling
Let’s have a look at the modelling in NWDS first. Again, we imagine a process where you might translate a text into several languages– an according process might look like this:
The first activity ‘Decide on translation language(s)’ does exactly this: its outcome is a list of languages to which the text should be translated. These languages are saved in the data object ‘TranslationLanguages’.
The following gateway is the newly introduced inclusive gateway. Like all other gateways, you can drag it from the palette or create it via the context menu. As you can see, four sequence flows exit the gateway.
All four sequence flows are named – in our case ‘NoTranslation’, ‘Italian’, ‘Spanish’ and ‘German’. These names are also used for defining the conditions of the inclusive gateway.
Looking at the properties of the inclusive gateway, you’ll see that you can provide it with a name and a description. Furthermore, it has a number of gates based on the number of sequence flows you have drawn out of the gateway. Thus, the inclusive gateway in our example has exactly four gates: ‘NoTranslation’, ‘Italian’, ‘Spanish’ and ‘German’. So far, the definition of the properties is the same as for exclusive gateways.
For each gate, you can define a condition based on the process context. You could define an order of the condition evaluation, but at runtime all non-default conditions are evaluated. In contrast to the exclusive gateway, the ordering of conditions is irrelevant, as all conditions are considered for evaluation.
One of these gates has to be marked as default gate. This default gate is taken if – and only if – none of the other conditions evaluate true. This ensures that the process has at least one path to continue. In our case, the default gate connects to a notification activity – a notification that no translation is necessary for the text. As in the exclusive gateway, the default gate is specifically marked in the process itself – see the little dash that is highlighted in the figure below:
As you can see, several process paths are merged again with an ‘Uncontrolled Merge’ gateway and the process continues from there.
Important to note: The uncontrolled merge is exactly what its name states – it is uncontrolled. Thus, at runtime the process does not wait at this gate until all process paths are executed. There is no synchronization. The uncontrolled merge directly triggers the continuation of the process when – at runtime – one process path reaches it. This can also happen multiple times. In our case, the activity ‘Start Rollout of translated text’ might be executed up to three times – depending on the number of conditions evaluated true at the inclusive choice gateway.
SAP BPM does not support the converging nature of the inclusive gateway: SAP BPM does not offer a merging gateway that would – at runtime – wait until all previously split process paths are completed before the process continues.
Runtime
When the process reaches an inclusive gateway at runtime, all non-default conditions are evaluated. For each condition that is true at runtime, a new split process path is created.
If no condition is true, the default gate will be triggered.
Let’s have a look at our example again – check the modelled conditions:
When the runtime reaches the inclusive gateway in the process, it will check whether the data object contains the values ‘IT’, ‘ES’ and ‘DE’. For each valid condition, a new parallel process path and the according activity is created. Here are concrete examples to make this clearer:
| Data Object | Result |
|---|---|
| {IT} | One process path is taken, one activity ‘Translate to Italian’ is created |
| {IT,DE} | Two parallel process paths are taken, two activities are created (‘Translate to Italian’ and ‘Translate to German’) |
| {IT,ES,DE} | Three parallel process paths are taken, three activities are created (‘Translate to Italian’, ’Translate to Spanish’ and ‘Translate to German’) |
| {EN, RU} | The default process path is taken, the activity ‘No Translation necessary’ is created |
As long as only one process path is taken, it is clear how the process continues along its modelled path. But what happens when parallel paths are taken? How will they be merged?
As SAP BPM does currently not support inclusive gateways for converging, the answer is simple: The parallel paths will never be merged. All three parallel paths continue to run until they reach the end of the process.
Take the third example from the table – three parallel process paths are created out of the inclusive gateway, and three activities are started. Now – after the activity ‘Translate to Italian’ is finished, the next activity ‘Start Rollout of translated text’ is started directly. There is no waiting for the finalization of the other parallel process paths. Instead, when the activity ‘Translate to Spanish’ is finished, another instance of the activity ‘Start Rollout of translated text’ is started. After finalizing the activity ‘Translate to German’, a third instance of the activity ‘Start Rollout of translated text’ is started. There are now three instances of the activity ‘Start Rollout of translated text’, thus it will be executed by the runtime three times.
Workflow Patterns
With the introduction of the inclusive gateway, SAP BPM can now support a few more workflow patterns, like the ones below:
The inclusive gateway splits up a process into parallel process paths that run into separate process end events.
The inclusive gateway splits up a process into parallel paths that are merged via an uncontrolled merge.
Important to note: As SAP BPM does not support the converging nature of the inclusive gateway, patterns like the workflow pattern no. 7 (shown below) - where the inclusive gateway merges paths -
cannot be supported:
Conclusion
You have now learned how to model SAP BPM processes with inclusive gateways and define conditions for them. You have also seen how the inclusive gateway behaves at runtime – and which workflow patterns can now be supported using it. Enjoy modeling your inclusive gateway!
- SAP Managed Tags:
1 Comment
