Modeling

We will see here some rules/practices to improve the readability as well as the maintainability of your processes.

Note that there are circumstances in which we may decide to go against its good practices in order to achieve specific behaviour.

Use a “ sous-process interne ” to isolate a piece of process

The internal sub-processes are not only used to gather tasks to put border events. They can be beneficial for regrouping tasks and graphically support the user viewing the diagram.

Logical doors are always either closing or opening: both are avoided at the same time.

It is strongly recommended that a door not be both opening and closing at the same time. The BPMN model loses considerably in readability. Even if a duplicate door can in some cases avoid crossing flows.

Exception

Event doors are the only exceptions and can be closed and opened only if they lock on themselves.

Parallel Mails/Web Service

A good practice consists in extracting from the normal flow, the mails and some Web services, in order to avoid that the Workflow is blocked in case of error on the service. So, yes, it does complicate the design slightly, but the user experience comes first.

In this case, if an error occurs during the service, the flow is interrupted.
In this case, in the event of an error during the service, the flow is not interrupted.
In this case, if the service crashes: the process is stopped.
whereas in this model, the service is independent of the rest of the process.

Variable Depth

Unpiling consists in transforming a single execution into multiple executions by reading one by one the different elements of a variable. For example: On an order process, the requester will fill in a compound variable (his basket) and each line will individually launch the picking sub-process.

Example of a depil

To launch N times a sub-process at the same time and wait for the n endings before proceeding to the next of the processing you must use internal processes. Here’s an example:

here’s the script to put in dépil:

var json_content = JSON.parse(start_clientorder); //content
execution.setVariable("depil_maxLecture", json_content.length-1);
var _index = parseInt(format.replaceValueIfNull(execution, "depil_index", -1))+1; // (last index read or -1)+1
execution.setVariable("depil_index", _index);

var _index;
if (utils.hasValue(execution, "depil_index")){
  _index= depil_index+1;

execution.setVariable("depil_var1",_variable[index].var1);
execution.setVariable("depil_var2",_variable[index].var2);
Exception

The logic gate must be the result of a comparison between the read index and the read max.

Variable emails or two tasks?

We strongly advise against using the same task to send multiple emails.

As soon as the email is a little bit different, it becomes necessary for a better follow-up, to have one email per task.

Here is an example with the management of 2 reminder emails at 3 days and d-1.

Mismanagement of 2 reminder emails
Management of 2 reminder emails is recommended

Prefer BPMN to scripts

In order to improve the legibility of the process, we recommend always opting for a visually comprehensible solution if possible. A script task requires you to go and look at its configuration to understand what it does.

As an example, here are 2 processes that do the same thing, the first one with a script task that we replaced with a BPM element in the second one.

The Set True script task can be replaced by a simple XOR gate.
The process becomes much more readable.

Using edge timers on sub process

To further increase the readability of your processes, it is advisable to use internal sub-processes.

For example here are 2 processes that do the same thing, we placed the loop in a subProcess to make the process much more readable.

Very long life process

When a process has a life span of more than one year, it is best to split it into several shorter processes in order to benefit from improvements fairly quickly. To do this, it is better to use sub-processes called.

It is preferable to use a sub-process to itself rather than a loop at the start.

Processes with an infinite lifespan
Processes with a maximum lifetime of one year

In case of modification of the start, it will be necessary to think of taking into account (often by script) the cases where the mapping would not have been done correctly (processes already launched before evolution).

As far as possible, assignments to the launcher should also be avoided as it will never be possible to change it.

Updated on 13 November 2020

Was this article helpful?

Related Articles

Need Support?
Can't find the answer you're looking for?
Contact Support