IBM Business Process Manager - Mastering Pitfalls

IBM Business Process Manager erstwhile Teamworks Lombardi is one of the top selling BPM suites in the market. IBM Business Process Manager has some excellent features and some innovative concepts which enhance BPM development. However it is imperative for an organization to know about its key features and some of the disadvantages it brings along with its features. These short comings can be easily overcome and one easiest way to do that is to become aware of the short coming itself.

Branching and Merging in IBM Business Process Manager

IBM Business Process Manager has a shared development model. Unlike the traditional software development, the IBM Business Process Manager code base is maintained in a Process Center environment. A Process Center environment is not a source control by itself; however the IBM Business Process Manager artifacts are stored in the Process Center. The code base for a process application is maintained in a Process Center.

The run-time instance (executable) of the process application (code base) is known as Snapshot. A Snapshot can be deployed into any of the IBM Business Process Manager run-time process servers. The code base for a process application cannot be branched nor merged. Although, branching can be done by creating a Workspace in IBM Business Process Manager, there is no way to merge the branches.

This important aspect of this short coming in IBM Business Process Manager is that the Agile projects have to be planned meticulously. If a project plan mandates parallel development for a same process application, then there is no way in IBM Business Process Manager to merge the parallel branches into a single trunk.

Process instance data cannot be modified

Long running process instances are vulnerable to failures. Some of the failed instances may be irrecoverable due to data issues. For example, a particular variable in a business process needs to be set to a certain value to take a certain path in the business process flow. The business process data due to system issues or code issues might have got a wrong set of data and it would become necessary to read and update the business process data when the process is active. IBM Business Process Manager has an API to read the data, unfortunately does not have a good way to update the data, since the process data is stored as BLOB.

To circumvent this problem, the usage of business process data has to be minimized. Only business key attributes or in layman terms, primary key attributes in the application data needs to be mapped to the business process data. By mapping the primary key data as business process data, a loose coupling between the business process and the application data is achieved, thereby the application data would have more freedom to change without the necessity of keeping the business process data in sync.  There is a huge debate on what needs to map to business process data and what has to go into the application data, which itself becomes a separate topic to explore and it is well outside the context of this article.

IBM Business Process Manager stores most of the process related data as BLOB's

A typical software application’s life cycle regions include Development (DEV), System Integration Test (SIT), User Acceptance Environment (UAT) and Production (PROD). After every release to production, a good practice is to mirror the entire PROD data into different regions. This is no exception for BPM applications, and IBM Business Process Manager presents itself another challenge to implement this setup. Since process data in IBM Business Process Manager are stored as BLOB’s, there is a challenge for DBA’s to replicate the BLOB’s in lower region databases.

Also if the application data model and the IBM Business Process Manager data model are two different schemas, then there is an additional challenge in maintenance of data states after the production refresh. It becomes imperative for DBA’s to understand the complete data model of the Process Manager to synchronize the tables required to reflect the state and to ignore the tables which represents the run-time dynamics.

Also refer, BPM Data Model Architecture.

Workspace cannot be deleted

The need for Workspace arises when the code needs to be branched out of a particular Snapshot. For example, if there is a defect in a production release and the current Development release has progressed into the next version of Snapshot, a branch of production Snapshot is required and Workspace comes for rescue. Any version of the Snapshot can be branched out to a Workspace, however it cannot be merged to another Workspace as discussed already. Workspace created cannot be deleted from Process Center leaving a scar for potential misuse. Multiple Workspace would lead to confusion and there is always a possibility of developer choosing a wrong Workspace.

Creation of Workspace cannot be avoided, but with proper naming convention and standards, a potential misuse or accidental usage of a wrong Workspace for a wrong version can be avoided.

Process applications in Process Center cannot be deleted

Process applications in Process Center cannot be purged. This is mostly a sanity related aspect of maintaining the code base in the Process Center. Over a period of time the Process applications tend to grow and there would be a need to purge some of the obsolete Process Applications which would be no longer required. Unfortunately there is no way in IBM Business Process Manager, a Process application can be purged. A better way to avoid this situation is to have tighter governance and strict privileges within the developer community on who can create a Process application.