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 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 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.
imageWe 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.
imageThis 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.
imageThis 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.
imageThis replaces the need to select the Stage and then select the Visual Script (see forthcoming section) from the properties box.
imageThe 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.
imageThis is the Rectangle shape,
imageThe Rounded Rectangle shape,
imageThe Parallelogram shape,
imageThe Ellipse shape
imageAnd 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.
imageLines 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.
imageThe 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 ...
imageor from the Design menu.
imageHere the Direct style is used.
imageThis is the Rounded style,
imageAnd the Straight Style
imageOne 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.
imageImagine the scenario to the left. Not an uncommon one, we feel.
imageIf 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.
imageWe feel that the Rounded and Straight styles suffer from serious flaws too.
Take the fairly basic map to the left.
imageWhen 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.
imageThe 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!
imageAlthough 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.
imageFirst we change the line styles to Direct.
imageThen 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.
imageRoles, as well as being employed in the same way as they used to be, can be added to the Process map as 'Swimlanes'.
imageYou just drag and drop a Role onto the Process map,
imageAnd a Swimlane is created.
imageYou can add as many as you wish in this way.
imageThe way Stages are assigned to lanes is to drag them to the lane.
imageWe notice that moving on the same lane works too.
imageThis adds the Role to the to-do list of the Stage.
imageDragging to a lane adds the Role that corresponds to that lane,
imageand dragging off that lane removes it.
imageNotice 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.
imageSystem 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.
imageThe 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.
imageSub-Processes are added from the Home menu.
imageAnd appear in the selected or default Project.
imageThe map looks the same as we are used to, with no 'start' action.
imageGoing 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.
imageYou drag and drop this to the Process like any other Stage.
imageYou can see that the properties are the same as we are used to,
imageAnd you can, in fact, select a different Sub-Process if one is available.
imageIf 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)
imageThen 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.
imageWhen data is entered ...
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.
imageBusiness 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.
imageWhat 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.
imageA 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.
imageWhat 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.
imageHere, 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).
imageYou 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).
imageNow we are going to add a linked process. I add another Process, 'Process1'.
imageWe then add a Linked Process Stage (previously known as a 'Sub-Procedure' Stage), and select Process1 as the Linked Process.
imageAs we are used to, a Flag is created in the linked Process.
imageAgain, what we are not used to is the ability to add the Parent Process Business Object by dragging it to the Process map.
imageNotice the default of the FolderId is set.
imageWe merely need to change that to the Folder Parent like so ...
image... and we now reference the data from the Parent Process directly. SQL is no longer required.
imageAs an example, using the Formula Builder...
image... we can set the child Folder's subject to Variable1 from the Parent Process.
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.
imageYou cannot have two Actions with the same name in the same Process, regardless of the Action they start at.
imageIf 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.
imageThe 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.
imageOne 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.
imageActions can be added as before by selecting the type, and clicking and dragging from one Stage to another.
imageWhat 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.
imageThis gives us 'drag & drop' action editing at last.
imageActions also no longer have to be 'tethered' to Stages at all times.
imageYou 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.
imageDeleting Stages with attached Actions will no longer delete the attached Actions.
imageYou are left with a 'dangling' Action. You select it and drag the end to a suitable Stage to redirect it
Copy and Paste
imageCopy and paste is somewhat different too. If we select an Action and copy from the Context Menu ...
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
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
imageNotice 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.
imageComments are now a little more fancy.
imageAs before you can change the font,
imagebut now you can also change the shape...
image... and alignment of the comment.
imageNot that it always works as expected, mind you!
imageOne 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!
imageWe can now zoom the map properly. There is a slider at the base of the process map ...
imageOne new property for all Stages and Actions is the Help URL.
imageThis 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.
imageIt 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.