Thursday, June 16, 2011

REST Services with Lombardi

This article is a supplement of Lombardi on mobile, in which it was discussed to have Lombardi services exposed as REST API for enabling mobile communication. REST is a very sought after API for any product due to the fact that REST is capable of emitting JSON which can be easily consumed by Web 2.0 and mobile applications. Lombardi support provides a REST API which extensively uses Lombardi Web API which Lombardi does not recommend after TeamWorks version 6. The objective of this article is to outline an approach to expose RESTful services of Lombardi API without using Lombardi Web API.

This post outlines a methodology to expose RESTful services for some of the common tasks of Lombardi like, process initiation and adding comments to a process instance taking them as examples. Any API call from Lombardi which needs to be exposed as REST should be exposed as a SOAP Webservice, since Lombardi does not provide the capability to directly expose the API calls as RESTful service. If a BPD needs to be invoked, a general system service needs to be exposed as SOAP Webservice. The actual instantiation of the process should happen with the general system service.




For example, a BPD can be invoked using the following command, embedded in a Server script activity of general system service.

// to start a process var processInstance = tw.system.startProcessByName(processName, InputParameterMap); // to add comment to a process instance var processInstance = tw.system.findProcessInstanceByID(processId); processInstance.addComment("Hello!");

Lombardi provides a Webservice implementation component which can be used to expose general system service as SOAP Webservices. A stand alone service layer built on Spring3 framework would consume the SOAP Webservices and convert them to RESTful services using Spring3 REST support. Stand alone services can decouple the transformation logic from Lombardi. Also, deploying them as stand alone would mean that Lombardi product code is not tinkered and hence not endangering future product patches and also this helps fully leveraging Lombardi warranty support.

Below are the examples of code snippets of Spring controller which calls a SOAP Webservice (Lombardi API exposed as SOAP Webservice) and exposes the method as RESTful service which would emit XML or JSON.

// controller method to invoke a process @RequestMapping(method = RequestMethod.GET, value = "/startCalcGDPProcess", headers = "Accept=application/xml, application/json") public @ResponseBody String startCalcGDP() throws Exception { RunGDPPortTypeProxy proxy = new RunGDPPortTypeProxy(); String pi = proxy.startGDP(); return pi; } // controller method to add a comment to a process instance @RequestMapping(method = RequestMethod.POST, value = "/addCommentToGDP", headers = "Accept=application/xml, application/json") public ModelAndView addCommentToGDPProcess(@RequestBody String body) { Source source = new StreamSource(new StringReader(body)); ProcessInstance e = (ProcessInstance) jaxb2Mashaller.unmarshal(source); addCommentToGDPProcess.add(e); return new ModelAndView(XML_VIEW_NAME, "object", e); }
A sample Spring servlet configuration for REST based services.
<!-- To enable @RequestMapping process on type level and method level --> <bean class="org.springframework.web.servlet.mvc.annotation.DefaultAnnotationHandlerMapping" /> <bean class="org.springframework.web.servlet.mvc.annotation.AnnotationMethodHandlerAdapter"> <property name="messageConverters"> <list> <ref bean="marshallingConverter" /> <ref bean="atomConverter" /> <ref bean="jsonConverter" /> </list> </property> </bean> <!-- Client --> <bean id="restTemplate" class="org.springframework.web.client.RestTemplate"> <property name="messageConverters"> <list> <ref bean="marshallingConverter" /> <ref bean="atomConverter" /> <ref bean="jsonConverter" /> </list> </property> </bean> <bean id="jaxbMarshaller" class="org.springframework.oxm.jaxb.Jaxb2Marshaller"> <property name="classesToBeBound"> <list> <value>dw.spring3.rest.bean.ProcessInstance</value> </list> </property> </bean> <bean id="lombardiRestAPI" class="org.springframework.web.servlet.view.xml.MarshallingView"> <constructor-arg ref="jaxbMarshaller" /> </bean> <bean class="org.springframework.web.servlet.view.ContentNegotiatingViewResolver"> <property name="mediaTypes"> <map> <entry key="xml" value="application/xml" /> <entry key="html" value="text/html" /> </map> </property> <property name="viewResolvers"> <list> <bean class="org.springframework.web.servlet.view.BeanNameViewResolver" /> <bean id="viewResolver" class="org.springframework.web.servlet.view.UrlBasedViewResolver"> <property name="viewClass" value="org.springframework.web.servlet.view.JstlView" /> <property name="prefix" value="/WEB-INF/jsp/" /> <property name="suffix" value=".jsp" /> </bean> </list> </property> </bean> <bean id="marshallingConverter" class="org.springframework.http.converter.xml.MarshallingHttpMessageConverter"> <constructor-arg ref="jaxbMarshaller" /> <property name="supportedMediaTypes" value="application/xml" /> </bean> <bean id="atomConverter" class="org.springframework.http.converter.feed.AtomFeedHttpMessageConverter"> <property name="supportedMediaTypes" value="application/atom+xml" /> </bean> <bean id="jsonConverter" class="org.springframework.http.converter.json.MappingJacksonHttpMessageConverter"> <property name="supportedMediaTypes" value="application/json" /> </bean>

This approach might sound little bit awkward for having a RESTful service invoking a SOAP Webservice, however this methodology effectively decouples the Lombardi API calls from generating RESTful services.

Thursday, June 9, 2011

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.

Monday, June 6, 2011

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.

Friday, June 3, 2011

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.

Thursday, June 2, 2011

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?