Systems integration with WebSphere Lombardi Edition V7.2, Part 1: Architecture and solution overview

WebSphere® Lombardi Edition V7.2 provides an integrated platform upon which to build BPM solutions. While it has traditionally been strong within the area of human-centric workflows, this series focuses on Lombardi's integration capabilities, using web services, JMS, Ajax, JDBC and stored procedures to create a fictitious Order Handling process. Part 1 gives you an overview of Lombardi and its key components, and outlines the Order Handling solution.

Share:

Scott Glen (scott.glen@uk.ibm.com), Certified IT Architect, IBM

Scott Glen photoScott Glen is a Certified IT Architect with IBM's Business Performance and Service Optimization (BPSO) team. He has over 19 years of experience in the architecture, design, and development of object-oriented systems, providing consulting to the finance, government, telecommunications, and media sectors. With a particular interest in WebSphere, Java EE architectures, and associated design patterns, Scott now specializes in SOA and BPM, providing consulting and implementation services to clients across Europe, the Middle East, and Africa.



13 July 2011

Also available in Chinese

Introduction

IBM and Lombardi

In 2010, IBM acquired the Lombardi Software, and subsequently enhanced its business process management (BPM) portfolio of products with the introduction of IBM Blueworks Live and WebSphere Lombardi Edition. Blueworks Live is an evolution of the Lombardi Blueprint offering and provides a cloud-based high-level business modeling and collaboration capability. Lombardi is an integrated business modeling and solution assembly platform designed to enable the rapid development of BPM applications. It focuses primarily on human-centric workflow, but also provides a range of backend integration capabilities.

This three-part series focuses on building an Order Handling solution, specifically aimed at demonstrating the integration capabilities provided by WebSphere Lombardi Edition V7.2 (hereafter called Lombardi). Although the solution is fictitious, it is loosely based on a standards-aligned Telecoms Order Handling process, and has been specifically constructed in order to expose a variety different integration options, including web services, JMS, Ajax, JDBC and Stored Procedures. Although we have based this on WebSphere Lombardi Edition, the content is also applicable to IBM Business Process Manager V7.5, which is compatible with the Lombardi V7.2 environment.

This series is not intended to cover on all aspects of Lombardi. Instead it focuses specifically on its integration capabilities, introducing the various services and technologies that support communication with operational systems. Part 1 introduces the series, provides an overview of the Lombardi architecture and development environment, and creates the underlying resources (such as database tables) upon which the solution is built. Part 2 will focus on process anatomy, taking a more in-depth look at Lombardi’s development capabilities, and introduces the main BPM elements of the solution. Finally, Part 3 will examine the various integration techniques that are used by the Order Handling process.


Installation notes

Lombardi V7.2 is currently supported on 32- and 64-bit Windows®, Solaris®, AIX® and 32 and 64-bit Linux®. Two installation paths are provided by the installer: Simple and Custom. The Simple installer does everything for you, installing all dependent applications such as DB2® and the underlying WebSphere Application Server.

The Custom option is more flexible, allowing you to tailor the installation to use an existing DB2, Oracle® or SQL Server database. If you choose this option, be sure that you have the correct version of the dependant applications. For example, Lombardi V7.2 depends on DB2 V9.7 FP 1. If you have a different DB2 version installed, the installer may proceed without error, but the application will not function correctly. Refer to the release notes in the Resources section for more details.


Architecture

The Lombardi platform has traditionally been about collaboration, with business, management and technical staff working together to iteratively develop BPM solutions. This approach enables the rapid prototyping and deployment of applications, typically in a shorter timeframe than other BPM environments.

This approach is reflected in the architecture of the product itself, where the solution components are maintained in a central Process Center. All parties involved in the effort to define, model, implement, measure, and improve the process work from a common shared platform which encapsulates each element of the solution. This platform can be accessed through a variety of tools, which present various role-based perspectives of the centralized information.

Figure 1. Lombardi shared model
Lombardi shared model

In the following sections, we'll take a more in-depth look at the key elements of this architecture that are relevant to this article series, namely the Process Center, Authoring Environment and Process Portal.


Process Center: The central repository

The Process Center is at the core of the Lombardi architecture. It provides a central development environment and repository, supporting multiple process authors and developers. It is administered through a Process Center Console, which enables the management of applications, workspaces and snapshots contained within the Process Center. Aside from acting as a development repository it also contains two key components:

  • The Process Server, a runtime process engine responsible for executing the processes and services. It provides a Unit Test Environment (UTE) for the process authors and is administered through the Process Admin Console.
  • The Performance Data Warehouse is responsible for collecting and aggregating process data to enable the generation of performance reports. It is configured through the Performance Admin Console.

Authoring Environment: Process development

The Authoring Environment provides a single tool for all process authoring activities. It is the main tool that analysts and integration developers interact with on a daily basis, and enables process authors to model, integrate and simulate their processes. Each Authoring Environment is dedicated to a single Process Center. Although the Authoring Environment provides an Eclipse-based user interface, it is essentially a thin client, as the majority of functionality is implemented in the associated Process Center.

Business process definitions (BPD)

The Authoring Environment supports the BPMN notation, which allows processes to be modeled visually through an intuitive drag-and-drop interface. Business activities can be added to swimlanes on the canvas, wired together and implemented by subprocesses or services, as shown in Figure 2.

Figure 2. Lombardi Authoring Environment
Lombardi Authoring Environment

When we mention services in the context of Lombardi, we're not talking about SOA services. Lombardi services are internal Lombardi components, constructed similarly to the business processes, but which model a lower level of interaction. They can take many forms, but fall into three categories: user interface services, implementation services and business rules services.

User interface services

The UI services can be used to rapidly construct interfaces, enabling users to interact with processes. They fall into two categories:

  • Human services, which typically contain the interfaces screens (known as Coaches because they guide users through the application), as well as any components required to populate the interface.
  • Ajax services, which are used to retrieve information asynchronously from the server. These services can be used by the Human services to create a more dynamic user experience.

Implementation services

These services focus on connectivity to the outside world, and include a variety of options to access information and functionality contained in external applications:

  • General System services create a reusable business component that may be invoked by other processes or services.
  • Integration services are used to integrate with operational systems that support the execution of the business process. Lombardi supports web service or Java™-based integration components, as well as a range of pre-built integration options through the System Data Toolkit, which includes a number of SQL-based integrations.
  • Undercover Agents are used by other services to provide message-based asynchronous communications. They can be used to enable loosely-coupled processes to work cooperatively, or to respond to external JMS-based message events.
  • External activities provide a limited capability to integrate directly with external applications, such as those deployed on a Microsoft® .Net platform, which can then manipulate process data.
  • Web services are used to expose an existing Lombardi service as a web service, making it available to other Lombardi processes or external consumers.

Business rule services

Although business rules are not used in this series, it's worth mentioning their capabilities in Lombardi. There are three types of business rule services:

  • Rule services enable the encapsulation of simple if-then business rules, which can be wired into a business process and applied to the process data, causing appropriate actions to be executed. While separating business rules in this way is an architecturally sound practice, Lombardi offers only a fairly rudimentary rules capability. At an enterprise level, it may be better to utilize a dedicated rules engine, such as IBM WebSphere ILOG® JRules, which is supported in Lombardi V7.2, to act as a single repository for all business rules.
  • Key performance indicators (KPIs) are business measurements that Lombardi tracks at runtime, storing results that you can use to analyze process and task performance in the Optimizer. KPIs can be associated with any activity in a process.
  • Service Level Agreements (SLAs) are built on top of KPIs, aggregating the process measurements and enabling a triggering action to occur on defined conditions.

Process Portal: Operations

The Lombardi Process Portal is a web-based interface where users can start and stop processes, manage and run tasks for each process, and view the performance of individuals, teams, and processes. The interface is role-based, displaying only those processes and tasks that are associated with the group that the user belongs to.

Figure 3. Process Portal
Process Portal

The Process Portal enables users to complete the tasks that result from running processes on the Process Server. If a task is claimed by a user, the appropriate Coach is displayed in the portal, enabling the user to complete the task before returning control to the next stage in the process.

We have now introduced all the Lombardi elements that will be used in this series, so let’s take a look at the solution scenario itself.


Solution overview

Traditionally, the Lombardi product has been aimed at human-centric workflow, however, in this series, we want to explore some of Lombardi’s more technical integration options to see how well it handles a realistic process automation scenario. For that reason we've selected a simplified Order Handling process, loosely based around a standardized process from the telecommunications industry. In order to explore Lombardi’s capabilities, we've introduced a number of different integration techniques into the solution. We would not necessarily advocate using all of these in a real-world solution, but it enables us to demonstrate the different options that Lombardi provides.

Figure 4 shows the end-to-end process at an abstract level.

Figure 4. Abstract Order Handling process
Abstract Order Handling process

The Create Order and Update Order Status processes effectively mimic the capabilities of a basic customer relationship management (CRM) system, and hence appear in the CRM swimlane. The Create Order process captures order details and issues a customer order to the Handle Order process, which attempts to fulfill the order before sending the final status back to the CRM system, where it is received by the Update Order Status process.

Each step in the abstract process is implemented by a separate Lombardi business process. The Create Order process, shown in Figure 5, utilizes a series of screens to capture the customer and product details before storing the order in the CRM database and issuing it to the Order Handling process.

Figure 5. Create Order process
Create Order process

The order is issued asynchronously through a message queue, since a real telecommunications order may take several days to complete if it involves physically provisioning equipment at a network level. The process therefore uses a combination of Lombardi techniques, including Coaches, SQL, stored procedure invocation, Ajax updates and asynchronous messaging.

An instance of the Handle Order process is initiated once the order message is read from the message queue. The feasibility of the order is first checked and then the customer's credit rating is assessed (we are assuming this is an order for a service which is paid monthly in arrears). The order is then fulfilled and finally closed. A combination of web services, asynchronous messaging and Coaches for exception handling and escalation are used in this process.

Figure 6. Handle Order process
Handle Order process

When the Handle Order process completes, or if the order is unable to be fulfilled for any reason, an appropriate status message is asynchronously sent back to the CRM system and handled by the Update Order Status process.

Figure 7. Update Order Status
Update Order Status

This process first updates the CRM record in the database with the order status and then creates a human task to display the order. It uses asynchronous messaging, SQL updates and Coaches.


Database design

To support the solution, we have created a simple data model that provides the static product data to drive the process, and serves as a repository for completed orders. Figure 8 shows the Entity Relationship Diagram (ERD), created in InfoSphere® Data Architect V7.5.3:

Figure 8. Entity Relationship Diagram
Entity Relationship Diagram

The real-world complexities of these entities have not been modeled here, as this is not the focus of this article series. However, the information they contain, and their relationships to each other, will be used to drive the BPDs. The entities are outlined below:-

  • Product defines the core products that are provided by the company, such as ASDL, Land Line, and so on.
  • An Offering is a grouping of one of more products that are provided for sale to customers. This enables products to be bundled together to create offerings such as "Triple Play" (ASDL, Land Line, Mobile).
  • The Offering_Product_Mapping table implements the many-to-many relationship between Products and Offerings.
  • Customer models a customer.
  • Order associates a customer with an offering. The name of the related Offering (the Offering_Name field) has been de-normalized and included here for simplicity within the solution.

Scripts to create these tables in DB2® are provided in the Downloads section of this article. Further scripts to deploy the associated stored procedures (which will be described in a future part of this series) and to load sample Product data will be made available for download in future parts of this series. Please refer to the Resources section for further information on configuring data sources in Lombardi.


Conclusion

WebSphere Lombardi Edition V7.2 provides an integrated platform upon which to build BPM solutions. While it has traditionally been strong within the area of human-centric workflows, this series focuses on its integration capabilities, utilizing web services, JMS, Ajax, JDBC and stored procedures to create a fictitious Order Handling process.

This initial part of the tutorial provided an overview of Lombardi, introducing its architecture and outlining the Order Handling solution. In part 2 we will begin to build the processes and begin to introduce the various integration capabilities provided by Lombardi.


Download

DescriptionNameSize
Sample scriptOH_Script.zip1KB

Resources

Comments

developerWorks: Sign in

Required fields are indicated with an asterisk (*).


Need an IBM ID?
Forgot your IBM ID?


Forgot your password?
Change your password

By clicking Submit, you agree to the developerWorks terms of use.

 


The first time you sign into developerWorks, a profile is created for you. Information in your profile (your name, country/region, and company name) is displayed to the public and will accompany any content you post, unless you opt to hide your company name. You may update your IBM account at any time.

All information submitted is secure.

Choose your display name



The first time you sign in to developerWorks, a profile is created for you, so you need to choose a display name. Your display name accompanies the content you post on developerWorks.

Please choose a display name between 3-31 characters. Your display name must be unique in the developerWorks community and should not be your email address for privacy reasons.

Required fields are indicated with an asterisk (*).

(Must be between 3 – 31 characters.)

By clicking Submit, you agree to the developerWorks terms of use.

 


All information submitted is secure.

Dig deeper into Business process management on developerWorks


static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=1
Zone=Business process management, WebSphere
ArticleID=711079
ArticleTitle=Systems integration with WebSphere Lombardi Edition V7.2, Part 1: Architecture and solution overview
publish-date=07132011