Metastorm BPM 9.0 SR2 review

 We are just looking at those things we have an immediate use for. There are more features that we are not showing yet

Status fields in grids

Most noticeably you have Status fields in grids now. This kind of thing is a very common requirement, so we are very pleased indeed.

Here we have set the properties, say for the Priority column in a folder list. We have also set a custom image:

 Here is the view in the grid. Note that the scroll bars are a bit more sensibly placed, and you can avoid the horizontal scroll bar which you could not in 9.0.1 if you had a vertical one. You must leave space for it (see above).

 There is a nice tooltip we have set, and the orientation of the label, which is optional, is settable.

Action button tooltips

Another addition is the tooltip for actions. We thought that was an obvious choice as soon as the description was added for blank forms, but have waited until now for it to happen:

Multiple sorts in grids

You now have the option to have multiple sort orders in grids, and an optional 'clear sort' button, which is mandatory, I feel. I would like to disable sorting as well, in fact, as some grids depend on the given sort.

 

 You cannot, however, tell what sort has been set from the icons, but I guess that is not a big deal.

Default colours for stage shapes

We like the options to set the default colours for the process shapes. Frankly we do not like or use these shapes, as they get in our way and mean less to us than the icons, although we appreciate others may feel differently. What we do like however, is the instant 'lightning bolt' icons to show if activities are set for stages and actions, and allow one-click access to them.

So we cheat a bit and set the shape colour to white, and the border to light grey (otherwise action lines 'hang' in mid-space):

 In this way we can get the best of both worlds, no shapes in the way, and still get activity icons:

Calculated labels

Probably the most useful addition is the calculated label, however. This will be used in lots of varying and ingenious ways, we can guarantee. At the minimum it will let us make many forms more readable by adding large descriptive titles and formatting block of text more nicely. Printing options become more varied too.

 Oddly the label in the Designer does not show the formula, which I think would have been nice. Perhaps it would be a bit messy, but I'd like to see what it contains.

In the client the text is wrapped, just like other labels. This means you may have to be careful with the width, or indeed, you can force wrapped blocks of text.

Business Object enhancements

We can now see, and jump to, objects using a Business Object. That makes it much easier to remove unused BO's, as we used to have to remove and then validate that no faults occur. This is neat.

 And you can also refresh table Business Objects with a button, and the associated bindings no longer get dropped.

Others

We have also noticed a few speed improvements, especially with the Assignment activity, but will have to try it out some more to see if that holds true when lots of BO's are being used.

All in all, we are very pleased!

Reasons to love Metastorm BPM version 9 (part 1)

OK, I know I give the product a hard time, but hey, if I don't, who will? The fact is, though, I really do like it, even if some bits could be improved. One aspect of Metastorm BPM that really lights my candle, and those of our customers, is the Visual Scripts. Not because they are easy to create (they are not, I'm afraid), but because the documentation they provide is stunning.

When I first saw the product now called Metastorm BPM, it was in its infancy, its first version on Windows (v3). I thought it was the most amazing way to develop systems I had ever seen. My view on that has not changed in the past 13 years. All that mucking about converting Data Flow Diagrams to code - why not make the diagram itself the code? It was so good a model, it actually remains fairly similar now, albeit with excellent and powerful enhancements such as Linked and Sub-Processes.

Well, now it is mainstream to do this. It is almost expected. Metastorm BPM (e-work in the day) was just the first of a new breed, long before BPM was even a TLA (Three Letter Acronym). The current challenge as far as I am concerned, is twofold. Fistly to integrate with Metastorm's other products, but more importantly for those at the coalface, to improve the development environment.

Well, in the Visual Scripting idea, I think they have done it (make it faster and it will be even better).

Here's why: Imagine I have a complex calculation that relies on a great many inputs and decisions. How would I typically manage this? Well, in the main, in previous versions, by writing a lot of code. In other development environments, such as Oracle BPM, I may use a nifty Business Rules generator. In Metastorm BPM you can always use a 3rd party Rules Engine.

But in version 9 we have Visual Scripting. It is not designed specifically to create Business Rules, but it does the job extemely well, for a number of reasons. Mostly this is because of the ease of communication, just like the Metastorm BPM process maps do, but to an additional level of detail. It is almost like looking at the Process Map, and then zooming in to a step to examine the decisions being made at that step. I do not have to explain the logic as I would have to with most Business Rules engines, it is extremely clear just as it is.

So, in this example, I have complex decisions  and calculations:

(Excuse the blurriness - it is deliberate to avoid giving away any proprietary information. The actual image is over twice as large and perfectly clear.)

I can discuss this with business owners and explain to them exactly what is happening at each step. The ability to expand and collapse groups at will makes this very easy to do 'live' rather than view the script as a whole. Each decision can be examined for validity, and in debugging, each output can be traced to determine accuracy. During development and testing, you can also disable any part of the script at will, and it and all contained activities will not be executed.

Here is a clip:

As you can see, the decisions tree is very clear. When descriptive titles and even comments (that appear as tool tips) are employed, the communication is massively greater than any code can be.

And yet, just as the Process Map that astounded me over a decade ago, this 'decision tree' is not merely documentation, it is the code!

In part two I shall discuss how we make this even better by creating full decision process tracing for primarily testing, and then auditing purposes.

Sydney BP Group Sundowner

http://metastorm.processmapping.com.au/calendar/eventdetail?date=2010-5-17&eventid=11021&calendarid=27303

The BP Group is pleased to announce the inaugural Sydney Sundowner, 17 May 2010.

If you have an interest in Business Process Management, Advanced Process Management and Outside-In or have previously attended one of the BP Group's Certified Process Professional courses, come join us for a couple of hours of meet, greet and discussion on how the BP Group might be able to help you with your business challenges.

Hosted by the BP Group and Outside In Consulting director David Mottershead, we will meet over a drink to discuss your Successful Outcomes.

With a ten minute overview and update from Steve Towers, VP & BP Group co-founder, the floor will be open to a facilitated discussion.

Is Process Simulation of any Value?

http://www.linkedin.com/groupAnswers?viewQuestionAndAnswers=&discussionID=12695928&gid=1062077

Steve Towers, BPM guru asks the same unthinkable (by most vendors) question that I have asked for many years.

Bits that I find very true:

It was very misleading and again over simplified the effort and knowledge required. In reality, process simulations are usually only useful when the process is repetitive and the resources are costly. Finding processing constraints usually does not require process simulation.

Could not agree more

I have seen bad simulation data can mislead managers and that make incorrect and costly assumptions.

I spend a lot of time as a consultant helping organizations recover these projects and training clients to be self sufficient.

Oh, yes!

In my own experience, there is very little connection between the simulation and reality. This in itself is probably the best argument against the usefulness of simulation. What we really need, and I think this is what Steve is referring to when he says "Finding processing constraints usually does not require process simulation." is to make the process better. Making it better, again in my experience, is reducing the effort required by users, increasing the accuracy, and improving the resulting information (not enabled by processes usually, but data). Accountability is another valuable point made in a comment by Brian Martin:

Even though I also have a geekish background, the greatest improvements that I have seen come with the socialization of the operations data, coaching people, and holding people accountable to operational targets. Some of the basic operations problems are a lack of coaching which is not related to simulation at all.

What simulation do we require? Well, in these cases, no simulation will help. What is we do is 'Prototype the Process'   to ensure it will work the way we want.

The Pomodoro Technique

I have come across a very interesting but simple answer to time management. It is called the Pomodoro Technique, after those nifty little kitchen timers shaped like tomatoes (Pomodoro is Italian for tomato).

http://www.pomodorotechnique.com/

Why mention it here? Because we spend our careers making people's work using our systems more effective and efficient (at least we hope we do). What some of us do not do is make our own anything like as efficient as we do with the BPM systems we write. It's "the cobblers children never have shoes" syndrome, I guess.

I happen to be the worst (or perhaps that's best) procrastinator in the world. I have so many tasks that my 'to-do' list is a legend in its own right. I actually think items on it breed. I wrote the book on procrastination. Well, I nearly did, but I put it off, of course.....

So how does this technique work? The idea, as I said, is a simple one. Break time into fixed chunks time. 25 minutes of work, and 5 minutes of 'down-time' to have a break. This does not have to be 25 minutes, but they have found it is best.

You work on a task until the 'Pomodoro' is ended (the timer rings). When it rings, you stop, even if there is only a few minutes of the task left. If you complete a task before the end of the Pomodoro, review it, improve on it etc until the end of the Pomodoro.

Do not let internal or external distractions stop the task. Internal ones, jot down, external ones explain and jot down, perhaps with a deadline if not today. You may add a Pomodoro just do deal with these queued up mini-tasks, too.

That is only a very simplistic overview, and you can get a lot more from the web site. There is also quite a bit you can do to develop the technique, especially regarding estimating time and recording and planning, that I will let you find out for yourself if it interests you.

I shall be working on a Metastorm BPM Pomodoro process shortly. It was actually my first 'parked' task I jotted down when working on my first Pomodoro!

Moving from Metastorm BPM Version 7 to Version 9 - Naming Conventions

http://www.processmapping.com.au/MBPMv7Tov9/NamingConventions%282%29.html

Metastorm BPM version 9 has significant new restrictions on naming of elements. This is based on the architecture employed, since the many elements will become properties or functions of the same C# class. There are basic limitations to all names, as well, that are linked to C# syntax.

On top of this, there is the new ability to provide ‘captions’ to many components and elements. These are often also changeable to support different languages supported by the user’s browser. Some we find are never used in the system at all, however.

There has also been a significant change in the way variables are referenced. Metastorm BPM is now strongly types, and the addition of Intellisense to all editing scenarios gives us the freedom to dispense with the awkward prefixes that abound in examples from earlier versions. We will certainly be very glad to see the back of these, although we are sure they will persist regardless in some quarters.

Because of these changes, we have developed a new set of naming conventions for Metastorm BPM. These conventions are designed to minimise the potential conflicts, and give us much greater ability to distinguish between items when no other indication is available (as it now is with variables).

These conventions are neither exhaustive or fixed in stone, they are merely what we have come across that needs a convention, or indeed, that needs one being dropped!

 

We no longer need to prefix our variables with the type. This was been very often misused due to ignorance in any case, and the field type is often used instead of the data type (eg %drpText1 and %rgpText2 and %txtText3 when all three are text variables).

Take the above example. We have three variables, each with a different type.

When we reference them in the Formula editor with the ‘%’ symbol, we have no way to tell what the variable type is. This can cause problems with erroneous conversions and the similar mistakes.

Now we move in to the (relatively) type-safe world of Metastorm BPM version 9.

When we try to assign values using the Formula Builder, we get a clear indication of the variable type.

When we select a value from any Business Object, we again have a clear indication of the variable type.

Even when we use Intellisense to find and select the variable, either in the Formula Builder or the C# editor, we get a clear indication of the variable type. We can lay the variable prefix to rest at last.

 

The naming of Processes has been the bane of many a Metastorm BPM developer. Firstly, once it is set, it is set for good. This is one reason we work very hard to get it right first time. Unfortunately the business owners rarely understand the significance of getting it wrong. They then ask, months later, “can we change the title of this process” (most often not in those words). Groans ensue. Well, it’s all over. All of it! We can name the process anything the users want, even with symbols in it! This is because we now have ‘Captions’ for our Processes. The upshot is that we can have what we have been requesting for a long time, namely a table name that is different from the Process Name. The facility has always been there, but never activated in the Designer. Look in the eMap table and you can see the eTableName field. This can be anything you like (we’ve hacked and it works).

What we now do is treat the Process name itself as a table name. Typically we group all tables for a particular system by prefixing the table with the initials of the system. When you have many systems on the same database, which we will always have, it makes it a great deal easier to see and select related tables. In Metastorm BPM version 9 we have decided to do exactly the same with our Process names.

This has the added advantage that the Process Data Business Objects are much easier to identify in what inevitably becomes a rather large list.

 

Solution Tables

When we define Solution Tables we employ the same naming conventions as we use in the Process Tables.

We do not, however, use the name eFolderId in Solution Tables that relate to Process tables using the Folder ID. If you do this, you end up with an extremely confusing schema that anyone who did not design the system cannot determine from the names alone. We use a convention of Id for these fields, so that it is clearly not a Process Table, and the related table is clearly identifiable. Given the same table prefix, this is rarely difficult to work out at a glance.

 

Roles

Roles are another area where naming is important to allow identification. All roles that relate to a specific Process are prefixed with the initials of the Process. This can be seen on the list above. In general these are dynamic Roles, although that is not always the case. If possible, Roles relating to the Process itself may be prefixed with the system prefix. If the Role may be used outside the system, which is common, we dispense with this convention, however. We arrange the roles in the following order: Default Metastorm Roles Process Specific Roles Other Roles We also add both a Caption and a Description, although generally both are set the same. This is because the Caption is seemingly never written to the database, although the Description is. We happen to think this is the wrong way around. Both can have different translations, but these are seemingly never written to the database.

As you can see, we show this description in our standard ‘Assign Users to Project Roles’ form that we can use in any Project.

We find this a great deal easier than the default approach that ignores both the Caption and Description. It also does not let you filter by Project, so making even a basic system a nightmare to administrate.

We find that generally the roles will then be easier to pick from the Toolbox. The few at the bottom are from Libraries, although not prefixed as such.

 

Forms

Now that forms are no longer associated with any particular Process, it is more important to find a naming convention that allows you to identify where they are used. We prefix the name with the initials of the Process they are associated with. Forms that are not associated with any specific Process have no prefix.

The exception is Forms in Libraries where we may prefix them with a numbering system. This is purely because there is no longer any way to set the order of Forms in Libraries, the are in alphabetical order by default. When we tend to add a large number of forms in one particular order, it saves a lot of time to ensure that the order is alphabetical.

 

Business Objects

Business Objects probably pose the most challenges when it comes to identification. As we have outlined elsewhere, there are a significant number of different usages for Business Objects. Each usage is potentially entirely different, and requires both different conditions and methods to employ the resulting Business Object. The different usages of Business Objects we have identified are: Editable table Single editable record Single read-only record List of records Filtered list of records Although some may appear to be very similar, they still need to be created differently and used differently. It is also possible for some types to be used as others, but there still remains these five unique possible different usages. Accordingly, we have created a prefix for each of these types. We list them here with a description of each: Usage PrefixConditionsCommentsEditable tableTablSingle Entire Table Primary Key Not read-only Can be used as a listSingle editable recordEditSingle Entire Table Primary Key Not read-only Unique Filter Can be used as a Single read-only recordSingle read-only recordDataUnique Filter Read-only List of recordsListGeneral or no Filter Read-only Will not change Filtered list of recordsFiltGeneral Filter Read-only Expected to change Can be used as a List

 

Admin Groups & Forms

There is little need to prefix Admin Form groups with anything. Nothing that the system creates will be relevant. Admin Form groups no longer even create a custom variable table.

If desired they can be prefixed with the system initials.

There also seems to be no real need to have any naming convention for Admin Forms.

In general, if naming conflicts occur a change of name is required. The Caption can remain as desired, of course.

 

Stages and Actions

There is a significant new restriction in the naming of Actions. No two Actions in the same Process can be the same. The restriction used to only apply to Actions from the same Stage.

However, the Caption can be anything you like, so this is not really a restriction that bothers us. In fact, you can now have three actions with exactly the same ‘name’ (Caption in reality) from the same Stage!

It is very important to make sure the name of Stages and Actions is edited, however. Most Process designers will happily edit the caption in place and ignore the actual name. This is not a good idea at all. As we have noted on our Forums, it can even lead to serious problems at a later date if they are renamed. If you leave the defaults, you will end up with Stage1/2/3 and UserAction1/2/3 in the eEvent table. No auditor would find that acceptable. You can link to the Caption in the eStage / eAction tables (and we do), but it is easier in the long term to avoid the necessity. Generally we try to keep the real name close to the Caption. To do this we enter the name without spaces or symbols, and then edit this in the Caption property to make it more friendly.

We do the same with Stages

 

Visual Script Activities

We deliberately do not change the naming of any Visual Script activity. We also leave the Container name as is, unless it causes a naming conflict (as described on our Forum). What we try to achieve is to ‘tell the story’ of what the code is doing. This is roughly equivalent to comments in code, althou vastly easier to read, typically. You can see fairly clearly in the above example what is occurring in the Visual Script, we feel.

If we have additional comments to make that do not fit on the Caption of the Activity, we add this to the description. This is not seen until you hover the mouse over the Activity, so is less likely to be seen. It is a very useful place to add notes that may be pertinent to developers maintaining the system, for example, but that do not add to the overall documentation. Oddly enough, this tooltip actually stays up until you move the mouse, unlike others that disappear after about five seconds. That means you can actually read this one!

 

Flags

Generally we name flags prefixed with the Project name. This allows us to more clearly identify their origin when examining the database or audit records, as well as during fault diagnosis.

 

Projects & Solutions

We do not have any naming conventions for Projects. They do not need a prefix, and as long as they are suitably descriptive, that is acceptable.

As Projects do not have any kind of ‘Caption’ that may be used for presentation, it is actually very important that the names of Projects are not garbled. It will not make the system more readable or understandable, and it can cause confusion.

Solutions can be named anything you like as long as it does not violate Windows file naming conventions, as far as we are aware. The Solution name is also not important like the Procedure name used to be in Version 7 and earlier. It is merely a container for the Project and Library files.

 

 

Metastorm BPM 9 Collaborative Training Course

Collaborative Training is the only way forward with Metastorm BPM 9, we think. 

See the details at:
http://metastorm.processmapping.com.au/post?id=4581397


Ours is a unique approach, we feel. The solution is built up in a series of stages by three collaborative parties - Analyst, Developer and Administrator. Each does separate work that is used by the others.

The more we look at the problems that are being faced by developers, and the problems that we know will be faced by developers in the future, the more we see how vital this complete separation of analyst and developer roles in Metatsorm BPM 9 will be. If we do not force the separation, we run the very real risk of putting the analyst in the ridiculous position of being forced to resolve C# issues, learn C#, or have nothing more to do with Metastorm BPM.

I think that would be costly for all Metastorm's existing customers in very many ways. Given the need for an almost complete rewrite of existing processes, to be documented in our Migrating to Metastorm BPM version 9 series, this poses some serious issues for the future of current Metastorm BPM systems.

It is clear to us that this either has not been foreseen by Metastorm, or they have chosen to ignore it. Either way could be ruinous for them in terms of the existing customer base.

Migration to Metastorm BPM 9 - 1 The Benefits of Metastorm BPM version 9

http://www.processmapping.com.au/MigrationToMBPMv9/TheBenefitsofMetastormBPMversion9.html

Firstly, let us look at what we stand to gain over version 7.

Processes Processes are the heart of the whole product. Are we going to get a great deal more in terms of functionality with these? We think there is little benefit in regards to process design per se, as it happens. Formatting is much nicer, however.
Swimlanes For those that like them, there are now Swimlanes. They are there for those that don’t like them too, of course, but they can be very easily ignored. As can be easily seen, they do add quite a bit to the attractiveness of the Process map. This is more pronounced when colours are employed. I am not certain I shall often use them myself, as it can make the process design awkward. Many analysts will love the idea, especially as a lot of specifications use the concept. Managers may well like the idea from a documentation perspective. The addition of meaningful icons, as we have here, makes them even more useful.
Process styles We now have the ability to set some options regarding the style of the Process map. Most important is probably the addition of ‘shapes’ for the Stages. These are potentially attractive if you wish to keep to a particular notation. You have the ability to change these from the default, but not to set the default shape for a Stage type. This could require a lot of maintenance if the defaults (as shown) do not conform to your needs. We find the addition of the Visual Script ‘arrows’ makes the diagram a bit ‘busy’, although they are extremely useful to portray the existence of scripts (solid arrows), and offer an easy way to edit them. Another potential useful option is the different line styles. You now have the option to use the standard ‘bendy’ lines, hard or rounded ‘square’ lines, or straight lines. Care does need to be taken to use each style effectively, but you can set the default and change each line individually to deal with any difficult positioning.
True parallel processing As we have demonstrated, it is now possible to have truly parallel processes. This was not really possible before, and any attempt would involve a significant amount of awkward and difficult to maintain code. http://www.processmapping.com.au/MBPMv9HnT/2010/01/index.html You can even now do this with no code or SQL at all, viewing and updating data from different processes, due to the new way forms and data have been dissociated from the process. This can result in far more elegant and easy to maintain systems, although care does need to be taken.
Formatting As well as the formatting options for fields, these are available in full for Process Maps as well. This can make laying maps out quite a bit easier.
Zooming Process Maps can now be zoomed in and out. This can make navigation of larger maps a great deal easier.

Forms
Field formatting As shown above for Process maps, we have full layout facilities for form fields. The size Equally option is especially welcome, and for me, the icons showing how centering works is great (I was always getting it the wrong way around). The Increase and Decrease spacing are welcome additions too. What is even neater, is the ‘snap to other fields’ feature. This is much better than a ‘snap to grid’ feature, we feel. The ability to resize multiple fields at once with the mouse is a great addition. It makes reorganising forms much less fiddly!
Drag & drop variables This is my favourite new feature: Drag fields from a Business Object to create fields for that variable. The only problem is you cannot get dropdown or listbox fields this way, but that is minor. And you get the option to create a grid if you drag multiple fields! The easiest and quickest way to create grids possible, I think.
Local Variables We’ve been after ‘temporary variables’ for a long time now. At last we have them in all forms. We also have them for form segments, so we can create really useful and functional reusable components to drag and drop onto a form. Obviously, once you delve into C# code you have the option to create as many local variables as you wish as well.
Field grouping There is a new ‘Tab Order’ feature that Metastorm are touting as fairly nifty. It is possibly clearer to use that the old way, although adding new fields can involve a lot of clicking about, which is a pain. What is neater, and I’m not sure Metastorm are really aware of it since it is not documented at all, is the ability to Group fields. This also gets set in the tab order, very usefully. There are some issues with display of grouped fields in the Designer, however.
Templates & defaults One of the most time-consuming tasks that are non-productive in Metastorm BPM is setting up forms to look the way you wish. It is possible to have a standard form and keep importing it, but in version 9 there are much easier ways. The approach is two-fold. Firstly you can set the colour of all new forms. We are not sure why you cannot set the font as well, as it would seem fairly simple. Better is the ability to save any form, admin form or form segment as a template. You can (and we do) even add segments to the template. Selecting the template you wish creates a copy of that form. There are so many uses for this, we will not attempt to exhaust them here, but will discuss in a forthcoming Metastorm BPM Hints & Tips episode. http://www.processmapping.com.au/MBPMv9HnT/

Code
Native C# code For the code monkeys among us, there is native C# code. All Metastorm code is now generated C# code, or Metastorm functions called from this code. You can also create as much of your own C# code as you wish, and import any DLL files you may wish to use, of course. You have a full C# editor here And many useful editing tools, including the all-important Script Validation.
Intellisense You also have Intellisense, as you would expect. What may not be expected, however, is the same facility in all areas where you can edit Metastorm code. In the Expression Builder you can use Intellisense at any time by pressing Ctrl-Space. Or it is automatically invoked at appropriate points. It is even available in the properties box fields where appropriate, making editing very swift indeed.
Easier code reuse One of the hindrances to code reuse has been the awkward scripting calls that are required in version 7 and before. This is now a thing of the past. all C# scripts can be promoted to the Expression Builder and Visual Scripts Toolbox. You can even add descriptive names for functions and parameters, as well as helpful hints for the Expression Builder. And in the Visual Script Toolbox Visual Scripts can also be promoted to the Visual Scripts Toolbox. And then used in any Visual Script.
Visual scripting Visual Scripts are a very nice way to write Metastorm code. Effectively they generate C# code by building the statements from Drag and Drop components. Here you can see the available components. And these are a set of components built into a script. You can see that certain components allow the nesting of others. You can even collapse containers of other activities to keep clutter to a minimum. And you can zoom in and out just like the Process Maps. When descriptive comments are added to the activities, the code is very nicely documented.
Conditionals & Looping As shown above, we now have looping within Metastorm code. This used to have to be handled by writing a script, or by means of conditional loopback actions. Looping if a basic do while loop. For each allows you to perform activities on a property of any Business Object. Although a list is accepted, it does not work with lists as far as we can tell, however. Conditional execution is an If – else if ... else format. Any Activity or container of Activities may be disabled by un- checking the ‘enabled’ checkbox. This is a neat way to disable code during development.

Data
Easier sharing of data In version 7 and earlier, you had to create the required SQL for every database call and grid. Now we have Business Objects that can be set up and shared among many components. This is a simple table BO which may be used for lists and read- only grids, or in an editable grid or recordset. You can also create a BO that uses any query you like, even employing views and stored procedures. These are always read- only. These Business Objects can be created and maintained in a library for use in any other Solution. This is a major potential time saver when tables are added or modified.
Data sources can be shared In version 7, if you wanted to access another database, you had to reference it each time it was used. In version 9 we now have Connectors. These may be created in a library and shared with other Solutions. This can make it a great easier to maintain separate connections for different environments. You could have a different set of connectors in different versions of a Library for Development, UAT and Production environments, for example. Ensuring the correct version is published to each database and retrieved on deployment would ensure the correct databases are used for that environment.

New Features
Multi-language support Metastorm are aiming at the larger corporate market. Many large corporations, even if only based in the US, will benefit from the new multi-language features. Forms can now be edited in as many languages as you like. The functionality remains the same, as well as the data, but the captions labels form names, and even field position, may be customised for each language. All of the process names, stages and Action names are likewise editable. These names are visible in different languages in the client, even for the same Folders.
Reports & graphs Most Metastorm BPM systems will have some kind of reporting needs. Now you can add your own reports into Metastorm BPM directly. Since these reports may well use the same Business Objects that you employ in your processes, much of the development work can potentially be reused.
Collaboration Metastorm BPM development has up until now mostly been a solo exercise. There are ways to share development responsibilities, but they are limited and awkward. Now the various components of a Metastorm BPM solution are in separate files. These can be easily shared using a source control system such as Visual Source Safe. Files that are not ‘checked out’ for editing are available and included in the Project, but not editable. This is also plainly demonstrated by the shading of the properties and toolbox.