Revisit the scenario

Our scenario describes the evolution of two separate company policy systems to a consolidated eMerge policy system that handles the request and acceptance of car insurance quotes. The scenario is based on the merger of two insurance companies:

• Lord General Insurance (LGI), a traditional insurance company, is a large enterprise with over five million policy holders looking to boost its auto insurance business and requiring a quick entry to the e-business direct insurance market. LGI has a large legacy IT infrastructure based on IBM S/390® and CICS® systems.
• DirectCar.com (DC) is a modern dot.com auto insurance company that sells insurance through the Internet and has less than one million policy holders. It has an e-business-focused infrastructure based on WebSphere Application Server, Oracle databases, and IBM TXSeries® systems.

The scenario focuses on the merger and has the following requirements:

• Improve the company's profitability by reducing overall administration costs, with an immediate focus on claims administration for existing products.
• Create an automated claims system for the joint customer base that connects the existing external services.
• Satisfy service-level agreements as defined in customer requirements (for example, performance and security guidelines).

Back to top

Introduction

This series describes on demand business integration and focuses on a typical industry scenario of a merger of two insurance companies. The scenario is described in Part 1: Use business process management to create integrated solutions and highlights the business and technical factors of integrating two distinct companies. The scenario focuses on the merger and automation of the policy systems following the acquisition.

In this article, you'll learn how to model business processes with IBM WebSphere MQ Workflow (formerly IBM MQSeries® Workflow), especially those processes involving complicated logic, such as looping. If you are new to WebSphere MQ Workflow modeling, you'll find this article informative. We use WebSphere MQ Workflow Buildtime, the graphical process definition tool that is part of the WebSphere MQ Workflow product family.

WebSphere MQ Workflow, our process manager in the scenario, is part of the product portfolio that forms the process integration category of the IBM Business Integration solution. WebSphere MQ Workflow offers deep application connectivity to leverage WebSphere MQ, XML, Java™ programs, Web services, and WebSphere Business Integration software with rich support for human interactions on a wide range of operating systems. In combination with WebSphere Business Integration Monitor, it also lets you monitor real-time business processes, and as a result, improve business processes. While WebSphere Process Choreographer also offers the function of executing business processes, WebSphere MQ Workflow has its own strengths. To find out more information about WebSphere MQ Workflow and WebSphere Process Choreographer, read the developerWorks article, "Understanding how WebSphere MQ Workflow and WebSphere Application Server Enterprise Process Choreographer can work together."

Back to top

Understand workflow basic concepts

WebSphere MQ Workflow Buildtime lets you graphically define business processes and their activities for automation. WebSphere MQ Workflow Buildtime includes graphical support for declaring and documenting:

• Business rules on process navigation between steps
• Business rules for role-based work assignment
• "Need-to-know" constraints for process interactions, with data flows and data mapping
• Process interface definitions (data, programs, queues)

WebSphere MQ Workflow Buildtime lets you model a business process by defining activities and drawing connectors between them, according to the business logic. Three kinds of activities can be defined in a workflow process:

• Program activity
• Block activity
• Process activity

They have the same type of properties, such as staffing and notification.

Program activity

Program activity is an activity that encompasses one program interaction. This program can reside on any of the following platforms: IBM z/OS®, IBM OS/2®, IBM AIX®, HP-UX, Sun Solaris operating systems, Microsoft® Windows® 9x, and Windows NT (including Windows 2000 and Windows XP). This kind of activity is the elemental and basic component that exists within a business process. For the program activity, an application program and the relevent execution unit need to be defined. Three types of execution units are available:

Program execution agent (PEA)

Invokes and manages task-relevant application programs in attended or unattended mode [When the program is accessed through WebSphere MQ Workflow Web Client, no program is launched. Instead, a JavaServer Pages (JSP) script is launched with container access.]

Program execution server (PES)

Invokes programs running in subsystems of z/OS systems in unattended mode only

User-defined program execution server (UPES)

Integrates any type of application running on WebSphere MQ system-supported platforms with XML-based message format (Figures 1 and 2 show these elements in the properties of a program activity.)

Block activity

Block activity is an activity that contains one or more activities and is good practice for developing processes. Block activity can represent a subset of connected activities within a large process. This means the diagram of a large or complex process is simplified, making the process more easily readable and manageable. In a block activity, you can have a "do until" loop that contains a series of activities to be repeated as long as the exit condition is not met.

Process activity

If your process diagram is large or complex, you can use process activity to simplify its appearance. Although this sounds similar to block activity, a process activity contains a set of activities that can be reused in other processes, while a block activity is only visible to the hosting process. Creating a subprocess is a difficult operation that impacts the performance of WebSphere MQ Workflow Runtime. To reduce the performance impact, late binding for subprocesses is applied, whereas the existence of the process is checked only at run time.

Back to top

Use block activity

A business process often comprises complex logic that involves conditions and loops. Block activity is lightweight when compared with process activity and can also implement complex logic, which is why we are particularly interested in using it in this scenario. This section explains more about block activity.

Basic requirements

You need to place a source node for the block to receive external data and a sink node to pass the data out of the block if needed. Between the source node and sink node you can have any kind of activities and any number of activities. These activities are not accessible from outside of the block. For example, if you need to pass any data from an activity inside the block to an activity outside, you need to define a corresponding data member in the block's data structure and use the data connector between the activity and the block's sink node.

Controlling logic flow

In WebSphere MQ Workflow, control is decoupled from data. To control the logic flowing through activities, you need to use a control connector. There are two types:

• Control connector. Lets you specify the transition condition that makes the logic flow when it is met
• Default connector. Flows logic to the destination activity if the condition of any other control connector leaving the source activity is evaluated as false

Data flow

Whereas control connectors define the logic flow, data connectors (data connectors, data default connectors, and data loop connectors) identify the data flow. Default connectors are represented by dashed lines to differentiate them from control connectors, which are depicted as solid lines. Data connectors are the only ones that connect between different activities and source or sink nodes. The other two kinds of connectors are used for the same activity, with the data default connectors specifying the data from input to output container, and data loop connectors copying the data from output to input container when the exit condition evaluates to false.

Data mapping is a very powerful function in WebSphere MQ Workflow. Data mapping can be defined at all data connectors in a process diagram. With this ability, you can manipulate the value of any data member in a data structure, such as assigning a default value or taking the value from a data member in the source.

Restrictions

There are two restrictions in using block activity:

• The total number of block activities in a process cannot be greater than 32766.
• The maximum nesting level of blocks cannot be more than 100.

Back to top

See a modeling example

Take a look at an example from our scenario. In this example, a complex process (Claims) for an insurance claim process starts whenever a claim is raised by a customer. From a business point of view, as shown in Figure 3, the claims process comprises three stages:

• Validate
• Investigate
• Judge

Once a claim is validated, it enters the investigation stage, where certain reports can be requested. Finally, the claim is assessed and settled in the judge stage. (See Part 2: Understand the claims system for more details about the claims process.)

The top-level process is shown in Figure 3. It comprises one source node, three process activities, plus control and data connectors. No sink node is defined in the diagram since there is no need to pass the data when the process finishes. First, the validate activity accepts the input data from the source node and processes it. After it finishes, the output data is passed into the investigate activity. Finally, the data is passed to the judge activity. The direction of the data flow is indicated by the dashed-arrow lines. No transition conditions are defined for the control connectors.

Figure 4 shows the subprocess validate, which is called ClaimValidation. This process needs to accept input data and pass output data on, so a source node and a sink node are defined. Two types of activities are shown: the process activity and block activity, which are represented as two kinds of symbols. Because some of the process activities such as SetClaimInit, NotifyReg, AddClaimRes, and SetClaimStat are executed in asynchronous mode by a user-defined program execution server, data default connectors are used to flow the input data to the output of the same activities. For the block activity (InvalidLoop), a data loop connector is used.

Figure 5 shows how the block of InvalidLoop is constructed. As you can see, a number of program activities are defined. Two of them, LimitExceed and ClaimInvalid, require human interaction. This block activity, depending on conditions, can end in one of the four activities:

• GetClaimDetail_01
• LimitExceed
• ClaimInvalid
• UpdateClaim

Each of these activities maps their output data to the sink node, which is then evaluated according to the block exit condition to decide whether it should go to the next activity or go through InvalidLoop again.

The entire claim process is exported as a file in the form of flow-description language, which is then imported to WebSphere MQ Workflow Runtime for the process to run automatically.

Back to top

Summary

In this article, you learned the technical details for modeling a complex business process flow in WebSphere MQ Workflow. As a result, our merged company now has an automated claims process for its joint customer base, which will reduce overall administration costs. You can also gain the full benefit of J2EE technology-compliant applications in WebSphere MQ Workflow when used in conjunction with WebSphere Process Choreographer. And through WebSphere Business Integration Monitor, you are able to monitor the progress of individual claims and fine-tune your business process based on real business data.

Back to top

Next steps

Stay tuned for the upcoming tutorial, "Using SOAP/JMS as an alternative to SOAP/HTTP," which describes how you can create and deploy a SOAP/JMS Web service to communicate between LGI internal systems and an external assessor.

Resources

• "Understanding how WebSphere MQ Workflow and WebSphere Application Server Enterprise Process Choreographer can work together" (developerWorks, June 2003) gives you an overview of MQ Workflow and Process Choreographer and describes interoperability scenarios for both products.
  
  
• See IBM WebSphere MQ Workflow Started with Buildtime and IBM WebSphere MQ Workflow Concepts and Architecture, as well as other WebSphere MQ Workflow manuals.
  
  
• Read these IBM Redbooks™ for more information about WebSphere MQ Workflow and business process management:
  • MQSeries Workflow for Windows NT for Beginners
  • Intra-enterprise business process management
  
  
  

About the author

Jenny He works in the IBM Software Group Solution Test Center System House as a Solution Test Specialist. For the past two and half years, she has been actively involved in modeling and monitoring business processes. You can reach Jenny at hejen@uk.ibm.com.

Comments (Undergoing maintenance)

Back to top

Trademarks  |  My developerWorks terms and conditions

Table of contents

• Revisit the scenario
• Introduction
• Understand workflow basic concepts
• Use block activity
• See a modeling example
• Summary
• Next steps
• Resources
• About the author
• Comments

Next steps from IBM

• Try: WebSphere MQ
• Webcast: A smarter way to successful SOA - Information as a trusted strategic asset
• Briefing: WebSphere flexible business processes for a smarter planet
• Buy: WebSphere MQ

My developerWorks community