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
We take a look at the way you connect to the database in Metastorm BPM version 9. There are new Business Objects that allow you to define a read-only or editable query. There are also the system created Business Objects for acceding and editing Folder and Process data.
The overall architecture is:
* Business Object
* Business Object instance
* Field or grid column.
The Connection is the database or LDAP connection. In this discussion we concentrate on the database Business Objects. These can employ the default connection to the Metastorm database, or an external database Connection.
There are several different ways a Business Object may be employed. Unfortunately these are not clearly described in the documentation, and no small amount of confusion is possible. The ways a Business Object may be employed are as follows:
* Editable table
* Single editable record
* Single read-only record
* List of records
* Filtered list of records
It could be argued that these last two are identical, but we differentiate because they tend to be used very differently. A filtered list will typically have one or more filters that can be changed at run-time to filter the return list. A list of records will typically be a static list. This will not need updating during use. The difference in usage is the need to set the instance as 'always refresh' for those instances where the result may change.
Similarly, on can use the same Business Object for a single editable record and a single read-only record. The difference here is that an editable record required a Primary Key, and a single table, whereas a read-only record does not. You can easily use an editable Business Object as a read-only Business Object, but not the other way around.
The main use of Business Objects is as a single editable recordset. The system generated Process Context and Process Data Business Objects are examples of these. These require a single table reference with a unique reference. In order to be editable, tables require a Primary Key.
For certain uses, the Business Object instance may be parsed and a single or column or a pair of columns extracted. These are for options lists such as (and we believe limited to) dropdown and listbox fields.
In grids, the entire recordset is displayed.
The documentation is not particularly clear on these different uses of Business Objects in general. It seems to limit the differences to Query and Table types, rather than the potential uses of the Business Object.
System Business Objects
System Business Objects are Process Data, Local (form) Data and Process Context. Each of these are like the 'Single Editable Record' custom Business Object type we describe above. Some variables in the Process Context are read-only, it should be noted.
Looking at a form, the system Business Objects are listed in the 'Default Business Objects' pane at the top of the Business Objects Explorer window.
For a Form these will consist of the Process Context and Local Business Objects. If any Form Segments have been added, the Business Object for that segment will also appear.
Note that there is no default 'Process Data' Business Object. This is because forms are no longer bound to Processes as they have been in previous versions.
Like all Business Objects these can be expanded. Variables may be dropped onto the form, from here as well. Variables that are not editable, such as ActionName and FolderOriginator will be set to Read Only and cannot be made editable.
Notice you cannot set any 'Parameter' for these Business Objects. We shall see that you can in Process and Custom Business Objects.
For a Process you have similar default Business Objects, but no Local type and you additionally have the Process Data Business Object. Interestingly yo are able to set the parameter of FolderId for this. We cannot see any situation at all where it would make any sense (indeed, where it would work) to use anything but the FolderId as this parameter. It may be that this is a bug and should not be editable. We suspect this is the case.
It is also interesting to note that added Sub-Process Business Objects do not get added here. This seems in direct contradiction to the way Forms behave. You are forced to add the Business Object for the Sub-Process manually. This may be an oversight, but we are not sure.
Custom Business Objects
Custom Business Objects available are Table, Query and LDAP Query. LDAP Business Objects require an LDAP connection, and will be examined separately. What we shall concentrate on here are the database Business Objects.
There are two main differences between the Table and Query Business Object types. Table Business Object is potentially editable, given certain conditions, and it can only consist of one table, and indeed all fields in that table. Query Business Objects are always read-only and may consist of any tables or views and any fields. They may also be based on stored procedures, which is a big step forward.
The only type of Business Object that may be used in an editable grid is a Table. This now effectively restricts editable grids from containing calculated and sub query fields and from using joined tables.
Moving to any Business Object component, takes you to all Business Objects listed in a grid. You may set the name, type, connection and behaviour (read-only or editable).
You may also set the default page size. This may be overridden in the grid using the Business Object, but it is not clear if there is some initial page size that may be reduced still further in the grid. An example would be having a default of 100, so only 100 rows are returned from the server at a time, but a display page of 25. In effect four pages would be cached locally at any time.
There is a 'requirement' in the documentation (which does not seem to be enforced) that the grid page size is a factor (divisor) of the default page size, and this implies this is the way it will work.
Looking at a Query Business Object type, you may enter any query you wish. This may be entered manually or using the built in Query Builder.
Even though I entered this query manually, it has been parsed correctly by the Query Builder.
There are a great many settings, as you can see.
While discussing the Query Builder, it is worth noting that this may be invoked from fields where an SQL statement may be used to provide an option list. These are dropdown and listbox fields alone, we believe. Invoking the Query Builder allows a full query to be built, including parameters, such as the above.
We shall examine the SQL Builder separately in a future article as it is very complex and powerful in its own right.
In the SQL we had parameters denoted by the '@' prefix. These are defined in the Parameters tab.
We can set the data type, a description and an optional default value. The default value is set when an instance of the Business Object is created for use in a Form or Process. This makes it easy to create easily reusable Business Objects, but configurable as the parameters can still be edited.
Here we set the default to "N" so that only 'active' records are displayed. This can be easily overridden and set to "Y" to allow all records to be displayed.
In the Variable Names tab you are able to view the table columns and set the 'variable name', which is similar to an alias. These Names may not contain spaces or symbols.
These variable names are used when binding a field or grid column to a Business Object instance.
Oddly, however, the table column names are employed when using the Business Object for options in a dropdown or listbox field. We are sure this is a bug and it should be the variable name displayed.
Finally, we can test the data returned by the query. Note that this may return no data should a parameter default not be set, or if set to any variable.
For a Table Business Object we have to select a Table from the list. This effectively excludes views and stored procedures.
To build the conditions for this table, you are forced to use the condition builder as shown. Frankly, we find this approach very difficult to understand quickly, and thus we only use the table Business Object type for read-only Business Objects when the conditions are extremely simple.
In the case of an editable Business Object we are forced to use it, however. For a 'child' table as shown here, only the FolderId needs to be passed in as a parameter.
The default parameter we pass in is, as expected, the FolderId. This allows us to employ the Business Object on a form without the need to set the parameter.
Note that when we try to Test the Business Object, no records are returned because of the variable used in the default parameter.
Using Business Objects
We can now add system generated and custom Business Objects to components in our Solutions.
As you can see, once you have a system of even moderate size, and you have included libraries with Business Objects it can get very complex. Given that every grid requires its own Business Object, they tend to get very numerous very quickly.
Some way to filter and / or group Business Objects would seem to be required to make this list manageable.
Business Objects may be added to certain components. This is managed by dragging and dropping the Business Object from the Toolbox onto the component. These components are:
* Form Segments
They will then become an 'instance' of the Business Object itself, and certain settings may be changed, depending on the Business Object properties. You may also add multiple instances of the same Business Object to a component. Each will be named by default as 1/2/3 etc, although they can be renamed.
Note that Roles that are associated with a Process will have access to all Business Object instances related to that Process.
In this example we have a simple form with two dropdown fields to filter values listed in a third. In fact, the first dropdown field filters the second as well.
In the Business Object explorer we have the default system Business Objects and the three dropdown option lists. We set local variables from each dropdown selection.
Notice that we have differentiated the type using our naming convention. The fact that the top two are prefixed with 'Filt' is an indicator that they are a filtered Business Object and will need to be set to 'always refresh', which has been done here (see below how).
When we expand the Business Objects we have added, you can see the parameters we have set. It should be reasonably clear how this should work. The selection of a Building filters the Floor list to show Floors in that building. Selecting a Floor will limit the Equipment list to Equipment located in that Building on that Floor.
We did try to set the variables to fields from the Business Objects, but that will not work since the field is not then 'editable'. The Designer will recognise when any selected variable is not editable, and makes the field read-only. Local editable variables are required.
You may now drag and drop variables to the component.
Dragging multiple fields gives you the option to create multiple controls or a grid.
Note that some fields cannot be created like this, and must be created manually and then the variable assigned. These are dropdown, radio group and listbox fields.
Here we show what we regard as a relatively simple form. There are several dropdown fields and a couple of referenced fields, it is true, but the number of Business Objects is still surprising.
Having said that, there is SQL as such used on the form itself.
Looking at one particular Business Object instance, we can see that we can set the parameters here.
We are also able to set the 'always refresh' property, and the page size, as well as the page size. This is also settable separately for any associated grid, as mentioned above.
We can also rename the instance to a more meaningful description.
This is especially useful if you have two instances of the same Business Object as we have here.