Automated workflows (examples)
Example 1 (Run without conditions)
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)
After the workflow has been started, it is almost immediately finished and can be found in the workflow 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.
Example 2 (Decision tree)
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().
Import: (instructions)
Example 3 (Run with conditions and retry) (and tuning variant)
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)
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.
Important note: Think well about such constructs in order to not burden the performance unnecessarily or even create a memory or hard disk overflow. We have built a wait function into the transitions back from the retry states, which is set to 0 seconds here, but if necessary, you can throttle the retries a bit here.
Import: (instructions)
Workflow_WF_automated_3_tuned.obj
Example 4 (Using profiles) (and retry variant)
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)
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.
Important note: Please note that you should think carefully about such constructs so you do not unnecessarily burden performance or even cause a memory or disk overflow. Always try looped profile calls on your test system first, and set the waiting time in the condition of transition retry out high enough so that you can't do too much damage if an infinite loop ever accidentally occurs. You will overload your system if there are hundreds or thousands of profile calls. If you do everything right, however, it's not a problem. Just a little caution please.
Note: See also section Cyclical Workflows (→ Linear Exit Point).
Note: Never use asynchronous profiles in such a construct, but only synchronous ones. So never set the checkbox Run in background.
Import: (follow the instructions!)
Profile-Generate_random_number_for_WF_retry.pak (import first)
Workflow_WF_automated_4_retry.obj
Example 5 (Vertical integration with sub profiles) (and retry variant)
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)
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.
Important note: Please note that you should think carefully about such constructs so you do not unnecessarily burden performance or even cause a memory or disk overflow. Always try looped profile calls on your test system first, and set the waiting time in the condition of transition retry out high enough so that you can't do too much damage if an infinite loop ever accidentally occurs. You will overload your system if there are hundreds or thousands of profile calls. If you do everything right, however, it's not a problem. Just a little caution please. Note: See also section Cyclical Workflows (→ Linear Exit Point). Note: Never use asynchronous profiles in such a construct, but only synchronous ones. So never set the checkbox Run in background.
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.obj
