Process Mapping Logo

Process Mapping - Articles

A Process of Improvement. An Outcome of Excellence.

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
Blank Form

We start with a blank form from the main 'parent' process

Enter three fields
Enter three fields

We fill in the first three fields only as the rest are to be completed by the child processes

two cild folders
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

first child folder
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 three fields
enter the second three fields

We enter the second set of fields in the same form in the child folder

view parent 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

second child folder
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

enter the third three fields
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

parent folder has moved
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

all fields filled
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 1
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
the main parent process

This is the main parent process

The first action has no code
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

The fields are set to read-only apart from the first set of three

linked process stage has two processes
linked process stage has two processes

The linked process stage has the two child processes selected

rendezvous action has both linked processes
rendezvous action has both linked processes

And the rendezvous action has both linked processes selected and all to be completed

first child process
first child process

This is the first child process

no code at all in the first flagged action
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
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
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
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
second child process

This is the second child process

no code at all in the first flagged action
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
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
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
the third set of three variables is filled

During this action the third set of three variables is set to be filled

parent form
parent form

This is the parent form which is the only form used by all the processes and has no code

standard Business Objects
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
process data Business Object parameter

The trick is here in the process data Business Object parameter

you create a function
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.