Moving from Metastorm BPM Version 7 to Version 9 - Process Design

http://www.processmapping.com.au/MBPMv7Tov9/ProcessDesign.html

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.

Styles
Models 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. 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. 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. This replaces the need to select the Stage and then select the Visual Script (see forthcoming section) from the properties box. 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. This is the Rectangle shape, The Rounded Rectangle shape, The Parallelogram shape, The Ellipse shape 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 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. 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 … or from the Design menu. Here the Direct style is used. This is the Rounded style, And the Straight Style 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. Imagine the scenario to the left. Not an uncommon one, we feel. 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. We feel that the Rounded and Straight styles suffer from serious flaws too. Take the fairly basic map to the left. 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. 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! 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. First we change the line styles to Direct. 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 Roles, as well as being employed in the same way as they used to be, can be added to the Process map as ‘Swimlanes’. You just drag and drop a Role onto the Process map, And a Swimlane is created. You can add as many as you wish in this way. The way Stages are assigned to lanes is to drag them to the lane. We notice that moving on the same lane works too. This adds the Role to the to-do list of the Stage. Dragging to a lane adds the Role that corresponds to that lane, and dragging off that lane removes it. 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. 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
Adding Sub-Processes 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. Sub-Processes are added from the Home menu. And appear in the selected or default Project. The map looks the same as we are used to, with no ‘start’ action. 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. You drag and drop this to the Process like any other Stage. You can see that the properties are the same as we are used to, And you can, in fact, select a different Sub-Process if one is available.
Sub-Process Data 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) 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. When data is entered … … 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

	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.
	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.
	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.
	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.
	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).
	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).
	Now we are going to add a linked process. I add another Process, ‘Process1’.
	We then add a Linked Process Stage (previously known as a ‘Sub-Procedure’ Stage), and select Process1 as the Linked Process.
	As we are used to, a Flag is created in the linked Process.
	Again, what we are not used to is the ability to add the Parent Process Business Object by dragging it to the Process map.
	Notice the default of the FolderId is set.
	We merely need to change that to the Folder Parent like so …
	… and we now reference the data from the Parent Process directly. SQL is no longer required.
	As an example, using the Formula Builder…
	… 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.

 

Naming Conventions
Naming Conventions You cannot have two Actions with the same name in the same Process, regardless of the Action they start at. 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 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 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 can be added as before by selecting the type, and clicking and dragging from one Stage to another. 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. This gives us ‘drag & drop’ action editing at last.
Unattached Actions Actions also no longer have to be ‘tethered’ to Stages at all times. 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. Deleting Stages with attached Actions will no longer delete the attached Actions. You are left with a ‘dangling’ Action. You select it and drag the end to a suitable Stage to redirect it.
Copy and Paste Copy and paste is somewhat different too. If we select an Action and copy from the Context Menu … … 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 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 Comments are now a little more fancy. As before you can change the font, but now you can also change the shape… … and alignment of the comment. Not that it always works as expected, mind you!
Element Alignment 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!
Zooming We can now zoom the map properly. There is a slider at the base of the process map …

 

Integrated Help

	One new property for all Stages and Actions is the Help URL.
	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.
	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.