Overview of IBM Business Process Manager
Sample Monitor Solutions
Here we capture some sample monitor solutions.
Task Escalation alerts
Consider the notion of a human task. We may wish this task to be completed within a certain period of time. If it isn't, then we may wish to raise an alert to have it looked into. This is a good use case for Business Monitor.
When a BPD runs, a model is built of each of the steps performed by the process. This includes when the step starts and when it ends. Our design for the solution is broken into two phases. The first will be the determination that a task is late and the second on how an alert will be issued.
To determine if a task is late, we will create a new trigger that will fire:
An example trigger definition would be:
<trigger displayName="Task Overdue" id="Task_Overdue" isRepeatable="false"> <evaluationTime hours="0" minutes="2" /> <gatingCondition expression="bmon_Step_Name = 'Receive Claim' and fn:empty(bmon_EndTime)" /> </trigger>
with a corresponding outbound event definition off:
\<outboundEvent displayName="Task Escalation" id="Task\_Escalation" extensionName="ActionServicesEvent" rootElement="cbe:CommonBaseEvent"\> \<eventPart displayName="escalation" id="escalation" path="cbe:CommonBaseEvent/tns2:escalation" type="tns2:escalation"\>\</eventPart\> \<map\> \<trigger ref="Task\_Overdue"/\> \<outputValue\> \<assignments\> \<assignment leftValue="Task\_Escalation/extendedData/BusinessSituationName" rightValue="'Escalation'"/\> \<assignment leftValue="Task\_Escalation/escalation/tns2:processId" rightValue="../Process\_Instance\_ID "/\> \<assignment leftValue="Task\_Escalation/escalation/tns2:taskId" rightValue="Task\_ID "/\> \<assignment leftValue="Task\_Escalation/escalation/tns2:stepName" rightValue="bmon\_Step\_Name "/\> \<assignment leftValue="Task\_Escalation/escal# Overview of IBM Business Process Manager
IBM Business Process Manager (IBPM) provides a platform on which Business Processes can be described, implemented, executed and monitored.
History of IBM Business Process Manager
To truly understand IBM Business Process Manager (IBPM), one should first start with the path that IBM has traveled to get to where they are today. Without an understanding of the market and product evolutions, some aspects of IBPM may seem odd or strange. Let us start back in 2005 with the release of an IBM product called WebSphere Process Server (WPS). WPS was the preceding Business Process Management product from IBM. It was designed to answer all the needs of a customer from a BPM perspective. Its core design followed a Service Oriented Architecture paradigm. What this meant was that customers would have "business services" and those services could then be aggregated together to build "business solutions". In practical terms, a "business service" would be an application or coarse grained functional component that exposes itself as a reusable service. Commonly it would be exposed as a Web Service but almost any technology to execute such a service could be used. By building out a set of re-usable services, if we could now describe the rules that govern the execution of these services, we would have a solution.
Historically, such rules had been described in application code with the likes of programming languages such as Java or C#. By the time WPS came along, a new player in the story had arrived. This was an open and industry standard called Business Process Execution Language (BPEL). BPEL promised to be the core glue that would solve all Business Choreography needs. Without (yet) going into detail, think of BPEL as a language that described the order in which steps of a process would execute including branching, variable updates, and more. This language could be visualized in a flow chart style diagram. The WPS product provided IBM's implementation of BPEL. Coupling together WPS, its SOA integration capabilities, BPEL and a host of other functions, IBM brought a product to market that appeared to solve the majority of BPM problems.
Unfortunately, despite IBM's best efforts, WPS did not capture 100% of the market. Competitors arrived on the scene and market share became split between IBM and others. What also became apparent was that the expectations of customers was changing. IBM had seen BPM as being extremely closely married to SOA principles and that manifested itself in many aspects of WPS. Competitors were focusing much closer on the Business Users and not as deep on the technology users. WPS was arguably the most powerful SOA engine in the market but its leanings were distinctly technical. Business users could not sit down at its development tooling (a product called WebSphere Integration Developer (WID)) and describe/capture their business processes.
To counter this problem, IBM produced additional products such as IBM WebSphere Business Modeler (Modeler) which was aimed at business users. However, modeler, although awesome for describing business processes was distinct from WPS requiring migration work from the model through to WPS for execution. Changes reflected in the process made by technical staff in WID had challenges being brought back into Modeler. Something had to change.
A 3rd party company called Lombardi marketed a product called TeamWorks which was a stiff competitor to IBM's WPS. In 2010, IBM acquired Lombardi and the product previously known as TeamWorks was re-named as WebSphere Lombardi Edition (WLE) . The first release of this occurred in June 2010 with the 7.1 release. In December 2010, the WLE 7.2 version hit the streets. Although the transition from TeamWorks to WLE was quite transparent, on occasion the original name of the product showed through in a few places. For example, package names and variable names still begin with "
WLE continued to be extremely successful for IBM post acquisition and quickly became a staple of IBM's BPM products. However, it didn't take anyone long to realize that IBM had two BPM products in the market. These were, of course, WPS and WLE. Since prior to the acquisition, IBM and WLE had been rivals competing against each other for the same consumer projects, something further had to change.
The answer came in June 2011 with the release of the product called IBM Business Process Manager (IBPM). IBPM is a single product that brings together all the features and functions of both WPS and WLE in one environment. It needs to be immediately said that IBPM is not the two products known as WPS and WLE dumped into one box … far from it. IBPM is truly the integration of all the best parts of WPS and the best parts of WLE brought together in a single run-time environment, with identical models of development and deployment.
All this being said, despite the version of the product being labeled 7.5, this is the first release of IBPM to market. The core code built and tested by developers is extremely mature as its heritage are the mature WPS and WLE ancestor products. To maintain backwards compatibility for previous WPS customers and previous WLE customers, IBPM does surface many of the concepts that were found in WPS and WLE by themselves. Putting it another way, the nature of its heritage show up on occasion.
Business Processes usually exist in the minds and practices of staff in a business enterprise. Capturing them for automation in a BPM product is a relatively new endeavor (say within the last ten years). Business Analysts and BPM Analysts could spend extensive amounts of time studying the operation of a business before ever coming close to being able to translate that into automation design or implementation. One of the primary strengths of IBPM is to be able to considerably shorten the duration through a series of interactive sessions where the process is directly captured in IBPM as an intuitive diagram. After having captured the "flavor" of the process, the process can be "played back" to parties who understand its nature to validate that what has been captured is correct with respect to how the business operates today or how it should operate in the future. If parts are found to be in error or misunderstood, they can be changed in real-time and the solution played back again. This can be repeated until the process has been correctly captured. This interactive and real-time iterative walk-through capability is significant differentiator for IBPM compared to other products in the marketplace.
Modeling a process
One of the first parts of building an IBPM solution is to model the Business Process. Modeling the process is the notion of capturing the existing process or the new process that is desired to be created. This task is usually performed by a Business Analyst in conjunction with key individuals involved with the process who may know details about certain areas.
The outcome of this phase of activity is a model of a process.
During this period, we are interested in capturing the logical flow of steps in the process and the coarse grained nature of those steps themselves. What we are not interested in capturing (at this time) are the mechanics of how those steps are to be performed … that is vitally important information, but will come later.
IBPM allows us to capture the model of a process using a powerful drawing technique that is based upon the prevailing Business Process Model and Notation (BPMN) standard. This drawn diagram represents steps in the processes as "boxes" with lines drawn between them to describe the flow of work. Each box represents a step and is labeled with its description in the diagram.
By capturing a diagram of the process, the diagram can be discussed for accuracy with other people. It can be used as the basis of the important question "Is this how we work today?". During these discussions, it is common to catch errors or misconceptions that were made while the diagram was being originally drawn. It is a trivial matter to change the diagram at this stage as needed.
In other BPM products, the step of modeling the business process also occurs. Where IBPM differs is that the model captured here is exactly the model that will be refined in the future for implementation. There is no concept of exporting the model from one tool and importing into another. That is simply not needed. Because the model is shared between design and implementation, it is simply not possible for the two to diverge from each other. This eliminates the "round-trip" problems seen in other environments.
Integrating with IT Systems
Although many business processes involve only routing work from one user to another, the vast majority involve interacting with existing IT applications that may be located on a variety of remote systems. IBPM provides the ability to include these IT systems as part of the process. Integration can be achieved through Web Services or other communication calls.
When an alert is seen notifying someone that a task is overdue, we must now ask ourselves what should that alert contain? Options include:
ation/tns2:currentOwner" rightValue="bmon\_PerformerName "/\> \<assignment leftValue="Task\_Escalation/escalation/tns2:processName" rightValue="../Process\_Name "/\> \</assignments\> \</outputValue\> \</map\> \</outboundEvent\>
Of these, the Process Instance ID, the Task ID and the name of the process are not generated automatically by the BPM monitor model generation and need to be explicitly added.