Process Mapping Logo

Process Mapping - Articles

A Process of Improvement. An Outcome of Excellence.

Moving from Metastorm BPM Version 7 to Version 9

Metastorm BPM has been evolving since its very early days as an Oracle application. It has been a strong leader in the BPM area for over 12 years. It was a market leader in the Web Client arena, and has consistently kept up with and taken advantage of the ever changing technological landscape as it has grown.

Throughout these changes the fundamental ease of use and 'descriptive' Process Design that has made it a favourite of many for many years has been maintained.

The latest incarnation as a fully .Net application and code generator is yet another almost complete makeover, possibly as significant as its transition from Oracle. We've waited a long time for this, but the real question is, are we going to enjoy the same ease of process design and overriding clarity that we have come to rely on, and has been the main strength of the product to date.

In this and the articles to follow over the next few weeks we shall try to give you all the information you will need to answer that question, and, we hope, many others.

Jerome Pearce

Jerome was one of the original development team of the Metastorm BPM product at Metastorm, and has been using it for over 12 years.

He has also written the Metastorm BPM Developer's Guide

Process Design

Process Design is the core of the Metastorm BPM product. This has, we are pleased to see, remained as it was, but with several major enhancements. Some are very useful indeed, whereas some, we feel, may not be.

Model Style

image
image
We have a couple of choices regarding the Process layout. One is the Model Style. This is a toggle between Enhanced and Basic.

The second is not a setting but a default for the line style of new lines. System-drawn lines ignore this, but that may be fixed later.

image
image
This is the default 'Basic' Model style. Analysts will typically use this as it is less cluttered. This is also the style we are used to.

Notice that the Action icons are now larger, which is a welcome reversion.

image
image
This is the 'Enhanced' style. The differences are that you have 'quick-launch' icons to jump to the Visual Scripts for Actions and Stages, and shapes for Stages.

image
image
This replaces the need to select the Stage and then select the Visual Script (see forthcoming section) from the properties box.

image
image
The shapes for Stages can be selected from the Design menu, or from the Context menu.

These Stages do not represent anything apart from the graphic.

We feel that as the 'Enhanced' style is really for Developers, and the 'Basic' style is more suited to Analysts, the inclusion of shapes in the 'Basic' style would be far more appropriate. Analysts will care about visual aspects, not code, and Developers will care about Code not visual aspects.

We also cannot see the 'Enhanced' style being employed for documentation as it is too 'busy'. Thus the shapes become useless in our view. Pretty, perhaps, but useless as they are.

What it really needs is the shapes to be used in the 'Basic' model, but allow 'None' to be selected as well (in case you don't like them). It is a good differentiator of Stages from Actions.

image
image
This is the Rectangle shape,

image
image
The Rounded Rectangle shape,

image
image
The Parallelogram shape,

image
image
The Ellipse shape

image
image
And finally the Diamond shape.

One puzzling omission is the lack of Shape selection from the Context menu. You can select a Line style from the Context menu for Actions (see below), but not a Shape style from the Context menu for Stages.

Line Styles

image
image
Lines also have a Style. We use the Curved style at all times for a number of reasons. Mostly because it is the only one that is unambiguous in all eventualities. The others may not be, as we shall see.

image
image
The Line style may be selected from the Context menu or Design menu. You can apply the same style to multiple lines by multi-selecting them and selecting a style from the Context menu ...

image
image

image
image
or from the Design menu.

image
image
Here the Direct style is used.

image
image
This is the Rounded style,

image
image
And the Straight Style

image
image
One nice feature of the Rounded and Square styles is that the lines 'jump' over each other when crossing. To the left is an extreme scenario.

Line Style flaws

Although these new line styles are attractive, in all but the Curved style (what we used to have) we get significant problems that will force us not to use them, unfortunately.

image
image
Imagine the scenario to the left. Not an uncommon one, we feel.

image
image
If the Straight style is selected for all these lines, look what happens.

One action has completely overshadowed the other, not even leaving an indication it is there. The Principle of Least Astonishment? is thus violated.

image
image
We feel that the Rounded and Straight styles suffer from serious flaws too.

Take the fairly basic map to the left.

image
image
When we change this to the rounded Line style, it becomes impossible to tell in which direction many of the Actions are set. This will definitely be a potential source of confusion, and we would not suggest using them.

image
image
The same is true of the Straight Line style.

A nice idea, but it will not work as is, I'm afraid. Back to bendy lines!

image
image
Although we feel the Direct style is flawed for general use, it does have one very nice ability. Starting with the layout on the left, we decide we want to move things around.

image
image

image
image
First we change the line styles to Direct.

image
image
Then we move the Stages around, before changing the line style back to Curved. Note that we never moved any of the Actions ourselves.

I think you can see that we have avoided the need from previous versions to move all the Actions around to align correctly with the new Stage layout, which is a big improvement.

Role Swimlanes

image
image
Roles, as well as being employed in the same way as they used to be, can be added to the Process map as 'Swimlanes'.

image
image
You just drag and drop a Role onto the Process map,

image
image
And a Swimlane is created.

image
image
You can add as many as you wish in this way.

image
image
The way Stages are assigned to lanes is to drag them to the lane.

image
image
We notice that moving on the same lane works too.

image
image
This adds the Role to the to-do list of the Stage.

image
image
Dragging to a lane adds the Role that corresponds to that lane,

image
image
and dragging off that lane removes it.

image
image
Notice that when dragging a Stage, the lane that will be used if you drop the Stage is highlighted while the others are dimmed.

You can also change the icon of the Swimlane, so you can represent different roles with suitable pictures, for example, should you wish.

image
image
System and Linked Process Stages do not change their To do list but their Watch list when being moved from lane to lane. This makes sense for a System Stage, although we are a bit dubious about the Linked Process Stage.

The most obvious problem we have found with the Swimlanes are that dropping a new Stage onto a Swimlane does not select the Role. In fact, the default To do list item of Originator is set, meaning you have to deselect it.

If that was fixed it would make the Swimlanes much more usable, but as it is you need to jump a few hoops to make it work as it really should, at least not to violate the Principle of Least Astonishment?, anyway.

Sub-Processes

image
image
The Stages and Actions you can add are identical to version 7, with one notable omission. This is the Sub-Process (formerly 'Sub-Map') Stage.

There is a very good reason for this.

Instead of adding a Sub- Process Stage and selecting the Sub-Process, you now can add all Sub-Process in the Project from the Process Toolbox.

image
image
Sub-Processes are added from the Home menu.

image
image
And appear in the selected or default Project.

image
image
The map looks the same as we are used to, with no 'start' action.

image
image
Going back to the Process, or another Sub-Process (not the same one, or you get an infinite loop), you can see the Sub-Process in the Toolbox.

image
image

image
image
You drag and drop this to the Process like any other Stage.

image
image
You can see that the properties are the same as we are used to,

image
image
And you can, in fact, select a different Sub-Process if one is available.

Sub-Process Data

image
image
If we set up a Process and Sub- Process as shown,

(note that we are developing a naming standard for objects in Metastorm Solutions, since there is no way to have two objects of the same name as far as we can tell)

image
image
Then add the Variables as shown. This is almost the same as previous versions, but with the additional ability to add descriptions for the variables, which is welcome.

Notice that you cannot have the same variables in the containing Process as the Sub- Process.

image
image
When data is entered ...

image
image
... the Containing Process table stores its data, and the Sub- Process table stores its data. Although the Sub-Process variables are added to the containing Process, like previous versions, but they are no longer populated.

This may make reporting from processes employing Sub-Process a little different. It does mean, however, that you can have common data properly stored for multiple Processes, such as for an approval or audit sub-process, because all Processes employing this Sub-Process will store their data in the same table.

Business Objects

image
image
Business Objects, which we shall cover in more detail later, are the mechanism for Processes are able to read and store data, among other things. Each Process and Sub-Process will have its own default Business Object created automatically. This corresponds to the table where variables are stored, named after the Process Name. This is essentially the same as previous versions.

image
image
What is different is that we can access any other Business Object merely by dragging it onto the Process map. In the case shown, we are adding the Sub-Process Business Object.

image
image
A new instance of the Business Object is created and you can refer to it from the 'Other Business Objects' pane. Here you can also set the parameter used to reference the data, although in many cases the default is sufficient.

image
image
What is more interesting still, is that the same approach can be taken for Sub-Processes. As the layer has been extracted, we can use it in many different ways.

image
image
Here, we add the Business Object for the containing Process (we have to decide what is valid, or the run-time Business Object will read and write nothing).

image
image
You can see here that we can now reference, ie read and write to, data from the containing Process. In the past, as we had no reference, this was impossible (we could in fact do it, but all validation would fail).

image
image
Now we are going to add a linked process. I add another Process, 'Process1'.

image
image
We then add a Linked Process Stage (previously known as a 'Sub-Procedure' Stage), and select Process1 as the Linked Process.

image
image
As we are used to, a Flag is created in the linked Process.

image
image
Again, what we are not used to is the ability to add the Parent Process Business Object by dragging it to the Process map.

image
image
Notice the default of the FolderId is set.

image
image
We merely need to change that to the Folder Parent like so ...

image
image

image
image
... and we now reference the data from the Parent Process directly. SQL is no longer required.

image
image
As an example, using the Formula Builder...

image
image
... we can set the child Folder's subject to Variable1 from the Parent Process.

image
image

This is something we could never do before without extensive SQL. This has been a major drawback in the previous 'Sub- Procedure' architecture that has caused difficulties for many versions.

What is fairly obvious is that you can also set these variables. What may not be clear is that this bypasses the standard Metastorm BPM transaction management. As such, there is a real possibility the data could be overwritten, or possibly you could create a deadlock.

Use wisely, and treat as a loaded gun, I would say. Having said that, it is enormously powerful, and especially useful when used safely to read variables.

What is not clear is what happens when multiple records are returned. We assume the first will be selected.

In our forthcoming section on Business Objects and Connectors, we shall demonstrate some real examples of design using concepts such as this to enhance functionality and make development easier and more robust.

Naming Conventions

Naming Limitations

image
image
You cannot have two Actions with the same name in the same Process, regardless of the Action they start at.

image
image
If you try, you will get an error message.

What is less obvious is that you cannot have a Stage named the same as any Action either. This is not intuitive.

You can, however, have any number of actions and Stages with the same Caption. The usability will not be affected at all, just the underlying names.

Process Properties

image
image
The Process properties are identical with our well-known Map, apart from one crucial difference. The 'Name' of the map has to follow the new object naming conventions, namely no spaces, alphanumeric and underscores only, and cannot start with a number.

We are now, however, allowed to name the Process Caption anything we want, even with quotes should we wish. This is what the users will see in the Client. The concept is similar to the field name and field caption that we are used to on forms.

The reason is that we can use different languages to name this and all elements of the Process. More on that later when we discuss the language options. For now it is great to know that we can have any name we like for a Process, regardless of the underlying table. This is something that we have needed, and been asking for, for quite some time, and it is very welcome.

Variable Types

image
image
One extremely important addition is the strong typing we get from the new architecture.

In previous versions there was a tendency to add a prefix such as 'txt' to the variable name to denote the variable type (as well as other odd and flawed conventions such as the field type). This was often useful as the Metastorm BPM system was not strongly typed.

Now, as we can see, you can both determine the type of a variable at any time, and the system will not allow invalid implicit conversion to be set. At last we can drop the prefix of variables, we feel, as it is now redundant.

Layout

Actions

image
image
Actions can be added as before by selecting the type, and clicking and dragging from one Stage to another.

image
image

image
image
What has been added is the ability to drag and drop the end of an Action, be it 'untethered' or attached, and drop it on another Stage.

image
image
This gives us 'drag & drop' action editing at last.

image
image

Unattached Actions

image
image
Actions also no longer have to be 'tethered' to Stages at all times.

image
image
You can, as shown, add an Action that is entirely separate.

It must be attached to a Stage or Stages before Deployment, however.

We think this ability will allow Analysts to add several Actions before any Stages when designing a Process with Business users. We find that many users are not as familiar with the concept of Stages as they are with Actions, since they mainly see Actions in isolation in systems.

Forcing the addition of Stages before linking them with Actions has always seemed artificial to us. This way constructs such as Activity Diagrams can be easily converted to Process maps in Metastorm BPM.

image
image
Deleting Stages with attached Actions will no longer delete the attached Actions.

image
image
You are left with a 'dangling' Action. You select it and drag the end to a suitable Stage to redirect it

Copy and Paste

image
image
Copy and paste is somewhat different too. If we select an Action and copy from the Context Menu ...

image
image
... we do not have a context menu on the map, but pressing Ctrl-V give us a new Action overlaying the original as shown.

Note that the Action is the same, which is good, but the Action Name has been changed to keep it unique as is required. Note also that it is unattached.

Stages behave in much the same way.

Note that for both Stages and Actions, if the Caption is the same as the Name, both get updated.

Changing Stage Type

image
image

One very common reason is to turn an Archive Stage into a system stage and add an Action to reintroduce Folders into the Process. This is no longer so easy. You will have to delete the Stage and add a new Stage with the same name (the Caption is not relevant) and an appropriate action.

Another is to replace a Conditional Action with a Timed Action for a number of reasons.

This is probably not too hard, but without the simple 'copy and paste' of 'code' (MetaScript as we like to call it), it becomes more complex to do.

We understand this is an issue, it is known and acknowledged, but the effort to add the functionality is quite significant. If enough customers request it, I am sure it will be included in some future release.

For the moment I feel we can live with it. At design time, when most changes would be made, there is little downside to adding one Stage and deleting another, especially as the associated Actions do not get removed as they did in previous versions. Once code has been added, it may be a different story.

No Default Form

image
image
Notice also that Forms do not get automatically selected when adding new Stages. This is probably because Forms are no longer associated directly with Processes as they used to be. This means you have to manually select the Form.

Comments

image
image
Comments are now a little more fancy.

image
image
As before you can change the font,

image
image
but now you can also change the shape...

image
image

image
image
... and alignment of the comment.

image
image
Not that it always works as expected, mind you!

Element Alignment

image
image
One extremely welcome addition is the comprehensive Layout menu. This allows any kind of alignment you may wish for. One very useful addition is the 'Increase' and 'Decrease' vertical and horizontal spacing. When inserting steps into a Process these will be invaluable!

image
image

Zooming

image
image
We can now zoom the map properly. There is a slider at the base of the process map ...

image
image

image
image

image
image

Integrated Help

image
image
One new property for all Stages and Actions is the Help URL.

image
image
This allows you to enter a literal or calculated URL that will appear as a "?" link in the Client.

While we like the idea in principle, We think it would be much better to have the ability to edit help text in the Designer.

image
image
It just seems like a complete departure from the assertion in the 'home page' of the Designer, which confidently reads:

"... it is all here in a single unified and tightly integrated environment. There is no reason you ever need to go to another tool because we make it easy for you to quickly create and deliver everything you might need in business processes."

Apart from the Help, it seems.