IBM Business Process Manager on Mobile

There is an increasing demand and need for BPM suites to extend its capabilities to Mobile platforms. IBM Business Process Manager does not provide out of the box features for Mobile applications; however IBM Business Process Manager does have a REST API which can be used for Mobile communication. The REST API provided by IBM Business Process Manager utilizes the Web API which has been discarded from TeamWorks 6. The REST API still exists and could prove to be useful too, but it is getting deprecated. Also, IBM Business Process Manager recommends all process data access through its JavaScript API from TeamWorks 7 and it extends for WebSphere editions too. This article aims at providing an approach for enabling mobile users communicate with IBM Business Process Manager.

Exposing IBM Business Process Manager API as RESTful services

Applications built on IBM Business Process Manager lives on intranet (corporate domain), which means a browser from a mobile phone with internet cannot be used to access IBM Business Process Manager portal on corporate domain. Even if an organization has exposed IBM Business Process Manager portal over internet, the usability feature of the portal will be hampered by the mobile browser. This boils down to the fact that dedicated mobile applications should be built for IBM Business Process Manager specific tasks. This article provides an approach to enable mobile app communication on platforms like Android, iOS and Symbian from IBM Business Process Manager and is not a tutorial to build the mobile application itself. A subsequent post would be published on building an Android application for IBM Business Process Manager tasks.

Some of the common activities users would wish to perform from their mobile application would be like, initiate a process, add comments to a process instance, complete a task, etc. One common protocol mobile apps use to perform for cross platform communication is Java Script Object Notation (JSON). Mobile application tool kits and SDK already have lot of libraries to write and read JSON. Choosing some other protocol other than JSON/HTTP would mean, that a lot of logic for mobile apps needs to written from scratch.

The activities required to be performed from a Mobile application needs to have corresponding services in IBM Business Process Manager which can throw JSON so that mobile apps can consume. So for instance, an activity like Create Bank Account process, if needs to be invoked from a mobile application, the mobile app would invoke a REST IBM Business Process Manager service (General System Service), which in turn would trigger the Create Bank Account process. IBM Business Process Manager has a JSON toolkit which has very limited capabilities and lot of other functions needs to be built to make it as a complete JSON toolkit. There are different approaches in which a IBM Business Process Manager service can be converted into a Restful service.

• Use JSON toolkit provided by IBM Business Process Manager support.
• Use REST API provided by IBM Business Process Manager support. REST API extensively uses Web API to access process data. As a word of caution, Web API is deprecated from TeamWorks6.
• Build a stand-alone REST services with Spring3, where the stand-alone REST services would be consumed by the Mobile apps and the REST services would invoke IBM Business Process Manager services via SOAP based Webservices.
• Another deviation from the 3rd option can be instead of REST services invoking IBM Business Process Manager services via SOAP based Webservices; REST services can invoke exposed URLs from IBM Business Process Manager. But, exposed URLs from IBM Business Process Manager are limited to executing a process and completing a task.

The 3rd option seems like a more reasonable and scalable option since, a lot of mobile app features can be incorporated in house. Moreover Spring3’s REST capabilities can be fully leveraged for JSON generation. The weird thing with this approach is that it uses REST services to invoke SOAP based services.



In real world, mobile apps are outside corporate domain network, it is imperative to expose the REST based services in internet. So a robust authentication mechanism is required to secure the REST based services over internet. Spring security and Spring Android security can be fully utilized with OAuth mechanism to fulfill any security constraints.

This article will be supplemented with two others posts, one for Developing Spring3 REST services which would expose IBM Business Process Manager Mobile API functions, and other post for building an Android app for IBM Business Process Manager tasks.

BPM Data Model Architecture

One of the primary assets of a BPM suite is how it manages the process data. Execution, monitoring and improving the process would heavily depend on the process data which the process engine manages. Process data in BPM suites are persisted as two flavors. Some suites store them as BLOBs and some products save the data in a relation data model. This article explores the two possible routes BPM vendors undertake.

A BPM suite when stores the process data using relational data model would give the technical users great insight and transparency into the process data. Also, users will have the ability to track the process data against each step of execution of the process. Tracking and reporting of historical process data would be a cake walk and the required data can be just pulled using a SQL query.

Having a relational data model for process data also means, that a third party Business Intelligence tool can be plugged into the process database for advanced BI activities. Also, versioning and in-flight instance management of process could be better handled by the BPM suite. The performance of the process engine itself would be greatly enhanced, since the engine is not required to parse the BLOBs to act on the process data, rather it has to just fetch from the database.

Typically, in relational data model, a process is represented as a database table. When a new process is created, a new database table will be created and would be associated with the process. So as the number of business processes keeps growing, so are the database tables, and so does the data model which also grows when the processes keeps increasing. Unlike, when the process data is stored as BLOBs a huge monolithic block of a single database table grows, with data model being frozen, highly impacting the database performance.

Moreover, the BPM product architecture would be highly scalable for the future demands of BPM features. For example, if a new or existing feature of a XPDL (XML Process Definition Language) schema needs to be implemented; having the process data in database instead of BLOBs would greatly enhance the ease of implementation.

Process data stored as BLOBs does not hold any significant advantage over relation data model. So, why some BPM suites went with this approach? It may be best answered by the BPM product vendors who choose to store process data as BLOBs.

Quest for Search functionality in BPM

It is quite often that we come across requirements in BPM/SOA projects to implement search functionality. Search is a ubiquitous functionality and is becoming an integral part of every software suite. A lot of product suites have in built search capabilities, but are limited, not customizable and extensible and quite cumbersome needing off the shelf implementation for the advanced search functionalities. Again implementing search functionality on a BPM SOA can be quite complex since the purview of such projects are not specific to single applications tied to specific platforms.

Traditionally, developers have implemented search functionalities using powerful APIs like Lucene, Compass etc. Venturing into search APIs for BPM SOA projects would quickly turn the implementation into nightmare. And on top of this the data to be searched might live on the bus or MOM.

What would ideally constitute good search functionality?

1. Should require less effort to implement and shouldn’t involve any core search APIs to be embedded in the applications. In other words, developers should not do any specific coding related to search functionality.
2. A stand alone search engine not tied to a specific system. The search engine itself should reside and function as a separate application.
3. Should be interoperable with other systems - RESTful, JSON, SOAP based queries for searching.
4. Should support XML search, Word/PDF handling and basic text search.
If your requirements sound similar to the above points, the Apache Solr might be your next search engine. Checkout Apache Solr.

Is it a right time for Federated BPM?

“BPM is an organization wide initiative” was the most famous premise a few years back. But for all practical reasons, organizations started BPM and SOA initiatives in pockets. Over the time, organizations ended up with few BPM domains with different governance models. There can be variety of compelling reasons for an organization to have different BPM domains, and some of the decisions might have happened without choice.

Mergers and Acquisitions (M&A) was one of the primary reasons for BPM selling like hot cakes. But with M&A came a different challenge, with merged or acquired organizations already having a BPM infrastructure, a choice was needed to be made for migration of the business processes into a single unified platform. This proved to be expensive and risky, and so without choice organizations settled for multiple BPM domains. Also, diversification of vendors had caused many organizations with diverse BPM domains, with different BPM product stacks.

Federated BPM is the need of the hour. With federated BPM, one of the existing BPM domains in the organization has to act as a master and rest of the BPM domains as dependent domains. Usually the domain with the most visible and top level business processes would be chosen as a master domain. All the top level business processes would be triggered from the master domain and subsequently routed to dependent domains.

Federated BPM is more of an enterprise architectural strategy which comes with a lot of challenges. Users might need a unified process portal platform, universal BAM and reporting capabilities, process metrics with KPIs and SLAs collated from different domains, uniform security implementation and many more. The challenges presented by Federated BPM architecture are many, but is it worth it, is it a right time for Federated BPM?

Advanced Reporting in Lombardi

Lombardi provides two flavors for Reporting. Adhoc Reporting let developers create quick charts and graphs in no time, without coding and with minimal configurations. The other flavor is custom reporting which is quite flexible with one or more SQL queries and data transformation logic with filtering of data.

Lombardi documentation provides enough information about creating Adhoc and custom reports. This article is aimed at creating better custom and advanced reports using Lombardi and this is not a tutorial or a guide to create reports. Please browse Lombardi documentation for user guides to create reports. Before getting into Lombardi custom reports, it is imperative for an analyst to understand the Lombardi Performance Data Warehouse Architecture and key concepts in performance reporting.

Basically, reports are just representation of business data, and Lombardi creates reports using business data which are tracked in the business process. Tracing business data is a key concept and in Lombardi business data can be either auto-tracked or it can be manually tracked with tracking events.



Tracking business data manually with tracking events offers several advantages. A tracking group needs to be created for manual tracking, which is used to group similar business data in a business process. From the business process, business data is fed into the tracking group using tracking events. Please see ‘Start tracking GDP’ as tracking event in the above business process diagram. So a tracking event essentially captures business data which needs to be tracked and sends it to the Performance Warehouse DB. In technical terms, a tracking group translates to a database view in Lombardi Performance Warehouse DB. The same is the case for auto-tracked business data, but Lombardi captures auto-tracked events during the start and end of each activity, deteriorating the overall performance of the BPM system. But in manual tracking, tracking events can be placed in business process exactly at an activity where tracking is essential, thereby reducing the round trips between Performance Warehouse server and Process server.

Lombardi comes with default tracking groups such as PROCESSFLOWS, SLASTATUS and SLATHRESHOLDTRAVERSALS. With default tracking groups, reports on SLA’s and violations can be easily created.

In custom reporting, a SQL query needs to be plugged into a chart as data source. The below link has variety of techniques to formulate an SQL query for analysis and reporting. http://download.oracle.com/docs/cd/B19306_01/server.102/b14223/analysis.htm The SQL query needs to be framed with aggregate functions for data columns with a GROUP BY clause as a must. Along with the query, data transformation logic has to be plugged into the data source as well. Lombardi provides around 7 in-house built report transformation services. Analysts can write their own data transformation logic by developing report transformation which parses the data which is fed from the SQL query and then inputs them to a Lombardi JavaScript function addDataToSeries(seriesValue, labelValue, displayValue).

Having created a data source, it’s time to build a chart. Lombardi comes to rescue with 9 default chart layouts defined in Lombardi system toolkit. The input for charts is data source. The data source along with its embedded report transformation logic converts the data into chart. Custom chart layouts can be defined using Chart Definition Language (CDL). Existing Lombardi chart layouts can be altered by replicating their CDL and altering the chart properties.

Finally, one or more charts can be embedded as pages (HTML) and can be published as scoreboards. Below are some of chart samples generated using Lombardi.





Adam Deane had an interesting point to make about business data being not used in BPM Reporting capabilities. Fortunately, Lombardi just does that. Lombardi captures process business data and generates reports out of it. Process business data is captured in performance DB as relational data unlike in process server where process data is persisted as CLOBs and BLOBs.