Truly Parallel Processing
In this article we demonstrate how you can achieve truly parallel processing in Metastorm BPM for the first time, with Metastorm BPM version 9.
History of Linked Processes
In previous versions of Metastorm BPM (and e-work before that), we had the misnamed 'Sub-Procedure' Stages. They should have been called 'Sub-Map' stages, really. Although sub-procedure stages allowed a form of primitive parallel process design, the construct was rather limited and very clumsy to implement effectively. You needed to understand the Metastorm BPM database structure to some extent, as well as use a fair amount of SQL. In addition, to manage them in a robust manner, you needed to know how to implement flags and flagged actions properly and efficiently.
In Metastorm BPM 9 the mechanism seems identical. However now that we have a somewhat different architecture, we can potentially adapt this to manage parallel processes properly and more easily.
Demonstration
We are going to see how Metastorm BPM version 9 can now properly implement parallel process constructs, easily and in a robust fashion, with no SQL, flags, or any kind of coding at all.
Blank Form
We start with a blank form from the main 'parent' process
Enter three fields
We fill in the first three fields only as the rest are to be completed by the child processes
two child folders created
We end up with the two child folders on our to-do list as they are created by a 'linked process' stage
open the first child folder
When we open the first child folder we see the three variables filled from the main process although we have used no SQL or code
enter the second three fields
We enter the second set of fields in the same form in the child folder
open the parent folder
If we open the parent folder we can see that the data from the child folder's action is shown there
open the second child folder
When we then open the second child form we can see that the data from the first child's action is shown as well as the original here as well
ente rthe third set of three fields
We then fill in the third set of fields using the same form but from the second child folder
the parent folder has moved to the next stage
We see in the to-do list that the parent folder has now moved to the next stage
we can see all fields are filled in the parent folder
And on opening it we can see the data entered by all three folders
Explanation
So how do we manage this? There is absolutely no SQL involved, and no code at all.
Here we show you the Solution in the Designer:
Solution in the Designer
Solution in the Designer 2
You can see all the elements and where they are used. Essentially we have three processes and one form. The rest is completely unchanged apart from the addition of the 'Parent Originator' role to allow the child folders to be on the correct to- do list.
the main parent process
This is the main parent process
The first action has no code
The first action has no code and uses the parent form
The fields are set to read-only
The fields are set to read-only apart from the first set of three
linked process stage has two processes
The linked process stage has the two child processes selected
rendezvous action has both linked processes
And the rendezvous action has both linked processes selected and all to be completed
first child process
This is the first child process
no code at all in the first flagged action
As you can see there is no code at all in the first flagged action inserted automatically by the Designer
no code at the user stage
There is no code at the user stage which shows the parent form
no code during the complete action
And no code during the complete action which uses the parent form
second set of three variables is be filled
During this action the second set of three variables is set to be filled
second child process
This is the second child process
no code at all in the first flagged action
As you can see there is no code at all in the first flagged action inserted automatically by the Designer
no code at the user stage
There is no code at the user stage which shows the parent form
no code during the complete action
And no code during the complete action which uses the parent form
the third set of three variables is filled
During this action the third set of three variables is set to be filled
parent form
This is the parent form which is the only form used by all the processes and has no code
standard Business Objects
The form has the standard Business Objects of Process Context and the parent process data
So how does this work?
process data Business Object parameter
The trick is here in the process data Business Object parameter
you create a function
Looking at the parameter, instead of merely passing in the FolderId as is normal, you create a function that passes in the FolderId if this is the parent process, otherwise it passes in the Parent.
Conclusion
Although this is a very simple thing to do, look at what it achieves for us. We can now create limitless true parallel processes that require absolutely no SQL or creation of any flags, and no code. All of the parallel processes can use the same forms as the parent and sibling process too, thus significantly reducing any duplication of code or design. Even all the code associated with the form and fields will work perfectly well, regardless of the process employing it.
There are some caveats, however:
The parent folder should ideally stay at the Linked Process stage until all potential processing is complete and not have any updates possible until then.
It may not be wise to let two processes update the same data. This is purely in order to adhere to the Principle of Least Astonishment?.
There may be conflict if users update multiple child processes at exactly the same time. The window is milliseconds, so the chance very unlikely. We could not reproduce an error in our tests.
Data from sub-processes of child processes are not usable directly, although they may be used if required (we'll have a later episode on this).
Possible conflicts can be probably worked around. In a critical environment it may be worthwhile. The most obvious approach to try is to update the parent eFolder record by SQL with the username and time as the Engine would both on starting the action and submitting it. This can be managed in the form itself to reduce additional code.