Our first example is very simple. The point here is to show the basic mechanism.

After this workflow has been started, it automatically enters the first transition (which contains no conditions), then automatically enters the second transition (which also contains no conditions), and then simply terminates.

Import: (instructions)

Workflow_WF_automated_1.xml

After the workflow has been started, it is almost immediately finished and can be found in the logs.

Business and technical level

As you can easily see from this example, such a functionless workflow diagram can easily be created in a first step to map the general flow of your process. This can be done directly by a business department or in collaboration with it. In a further step, the workflow can then be filled with technical life by the IT department without having to burden the business department with it. Of course, further consultation may be necessary if some step is tricky to implement this way, but in general this separation works very well.

Our next example in itself is also trivial. We want to show how decisions can be made and that there can be several end states.

The respective upper transition generates a random number between 0 and 1. If the random number is greater than 0.5, the condition is considered to be fulfilled. The upper transition is always checked first because it has a higher priority. If the check is negative, the lower transition is checked and since it has no condition, it then always takes effect.

Start the workflow a few times and see the different end states that are reached. Also, look at the log messages. The upper transition logs every random number generated with function log workflow message(a).

Import: (instructions)

Workflow_WF_automated_2.xml

The following example shows a combination of the first two examples.

But we only use one transition in which a random number is generated (like the upper transitions in example 2). If this does not work at the first time, the cyclical transition check (via the waiting time in the states) starts further attempts until it works.

Start the workflow a few times and wait until the jobs are no longer visible. After that, take a look at the log messages.

Import: (instructions)

Workflow_WF_automated_3.xml

The cyclical retry via the waiting time is mainly intended for situations such as an unreachable system, i.e. we do not want to retry like crazy in high frequency, but after a reasonable (internally defined) waiting time. In our example, however, we can certainly proceed a bit more briskly, so we would like to show the following example, in which the workflow is practically also done immediately, even if the random number does not produce the result required in the conditions a few times. The transitions to the retry states each have a lower priority and therefore always take effect when the random number does not fulfil the conditions.

Import: (instructions)

Workflow_WF_automated_3_tuned.xml

Now we make it a bit more difficult for ourselves. Instead of generating a random number directly in a transition, we call a profile as an action in the first transition and generate the random number in this profile.

We then return the random number from the profile to the workflow variable VAR_RANDOM and use it in the conditions of Transition 2.

Start the workflow a few times and then view the log messages. You will find the started profile as an action in tab Log.

Import: (follow the instructions!)

Profile-Generate_random_number_for_WF.pak (import first)

Workflow_WF_automated_4.xml

If we want to have a retry here, we have to proceed somewhat differently than in the first example 3, because we can only execute the check after the executed action in the transition before. So we have to proceed basically like in the second example 3.

Import: (follow the instructions!)

Profile-Generate_random_number_for_WF_retry.pak (import first)

Workflow_WF_automated_4_retry.xml

This example is structured like example 4, but now we call the profile Vertical_integration, which in turn calls three sub profiles in its source structure (and to keep the example simple, we use the same sub profile for each of the three calls).

Each of these sub profiles generates a random number. We then generate an average value from these three random numbers and return it to the workflow.

We've abstracted a lot here to show the principle. The idea is that you get data from three sources (that can be documents or sensors or Kafka-KSQL queries (not yet available) or whatever). The data is then analysed and the result of this analysis decides the further course in the workflow. The sub-profiles used can thus be understood as dynamic, encapsulated self-service access to all kinds of distributed systems. Your sub-profile structure is the connecting fabric, the data fabric, as required.

Start the workflow and then view the log messages. You will find the started profile as an action in tab Log.

Import: (follow the instructions!)

Profile-Generate_random_number_for_WF_2.pak (import first)

Profile-Vertical_integration.pak (import second)

Workflow_WF_automated_5.xml

Here's a quick look at the integration profile. You can see the sub profile source structure and the target structure with the sub profile calls and the calculation of the average random number, which is then passed back to the workflow.

If we want to have a retry here, we have to proceed as in the second example 4.

Import: (follow the instructions!)

Profile-Generate_random_number_for_WF_2_retry.pak (import first)

Profile-Vertical_integration_retry.pak (import second)

Workflow_WF_automated_5_retry.xml

See section Cyclical Workflows.

See section Sub Workflows.