IBM WEBSPHERE LOMBARDI

Overview WebSphere Lombardi Edition Version 7.1 (hereafter called Lombardi) provides a flexible platform for rapid delivery and improvement of your business process applications. Lombardi V7.1 is a comprehensive BPM offering that enables companies to continually improve their end-to-end business processes. With Lombardi, teams can build, manage, and optimize process applications that orchestrate human collaboration and system interactions. This article gives you an overview of the Lombardi product and architecture. Future articles in this series will cover basic and advanced process modeling, Coaches, monitoring and reporting, and simulation and optimization. We'll use a purchase order process as the scenario throughout the series.

Back to top Concepts A business process is a collection of activities designed to produce a specific output for a particular objective, involving both human and system interactions. A business process implies a strong emphasis on how the work is done within an organization, in contrast to a product's focus on what. A process is a specific ordering of work activities across time and place, with a beginning, an end, and clearly defined inputs and outputs: a structure for action. Business Process Modeling Notation (BPMN) is a diagramming standard for drawing business processes. Its a format that is understandable to business users because it looks like a flowchart - you dont need a lot of training to understand how to use it. And its also understandable to anybody in IT who might be involved in the process. The objective of BPMN is to support business process management (BPM) by both technical users and business users by providing a notation that is intuitive to business users but still able to represent complex process semantics. Lombardi V7.1 is one of the first BPM platforms to support BPMN. Lombardi V7.1 is compliant with all key BPM-related standards, and its design tools provide a BPMN-compliant process modeling environment.

Back to top Architecture Lombardi is an integrated set of Eclipse-based development tools, together with a webbased user portal and dashboards, and a common runtime platform. These technologies

provide design, simulation, rules definition, process execution and integration, monitoring and optimization functions. The main perspectives in Lombardi, which support all activities from design through simulation, deployment, monitoring and optimization, share a common repository, which called the Shared Model, as shown in Figure 1.

Figure 1. Shared Model

Lombardi includes the following components, as shown in Figure 2, which illustrates a typical Lombardi configuration. For different development and deployment phases, the Process Server and Performance Data Warehouse can be installed in multiple staging, test, and production environments, which are centrally controlled by the Process Center.

Process Center The Process Center provides a central development environment and repository for multiple process authors working in the Process Center Console and other interfaces in Lombardi Authoring Environment. It includes a Process Center Server and a Performance Data Warehouse, which enable you to build and run process applications and also store performance data for testing and playback purposes during development.

Process Server The Process Server executes the processes and services built in Lombardi Authoring Environment, stored in the Process Center repository, and then installed in a runtime environment.

Performance Data Warehouse The Performance Data Warehouse collects and aggregates process data according to tracking requirements established in Lombardi Authoring Environment.

Figure 2. Lombardi components

The following components make up the process modeling and management interface:

Authoring Environment Lombardi Authoring Environment consists of several interfaces that enable process authors to model, implement, simulate, and inspect business processes. Authoring Environment users can create process models, services, and other assets within process applications.

Process Center Console From the Process Center Console, you can create process applications and toolkits and grant other users access to them. The Process Center Console can help you manage and maintain the Lombardi repository, including managing process applications, workspaces, and snapshots. It also enables the installation of process applications on Process Servers in runtime environments.

Process Admin Console The Process Admin Console provides an interface that enables administrators to configure and maintain the Process Servers in any configured runtime environment, such as staging, test or production environments. It also enables administrators to configure and maintain the Process Center Server.

Performance Admin Console The Performance Admin Console provides an interface that enables administrators to configure and maintain Lombardi Performance Data Warehouses in any configured runtime environment, such as staging, test or production environments. It also enables administrators to configure and maintain the Performance Data Warehouse included in the Process Center.

Process Portal The Process Portal provides an interface that enables process participants to perform assigned tasks, view the history of tasks, and view the performance of their processes and teams. Using Process Portal, process participants can connect to the Process Center Server or a Process Server in any configured runtime environment, such as test or production environments.

Back to top Modeling your process using Authoring Environment Lombardi provides an Eclipse-based platform for process development. To get started using the authoring environment for business process modeling, do the following: 1. Start the server by selecting Start => IBM WebSphere Lombardi Edition 7 => Start Servers. To open the Authoring Environment, select Start => IBM WebSphere Lombardi Edition 7 => Lombardi Authoring Environment. The default login user account and password are both tw_admin. 2. The first time you start the authoring environment, it opens to the Process Center Console, which enables you to create and manage process applications, install snapshots on test and production servers, and perform other tasks. Click the Process Apps tab, and select Create New Process App, as shown in Figure 3. The acronym for a process application must be unique and is limited to seven characters. Lombardi uses the acronym as an identifier for the process application and the library items that it contains. For example, when manipulating the items within the process application using the Lombardi JavaScript API, you can use the acronym to specify the namespace of the items.

3. In the Create New Process App dialog, enter a name (for example, Purchase Order Process and an acronym (such as, POPROC) for your process application. You can also provide an optional description. You can view the description in the Process Center Console by clicking the question mark next to the process application name. Figure 3. Create a new process application in authoring environment

Part 2 of this series will describe in detail how to model a business process in the authoring environment. Creating a Business Process Definition (BPD) When you model a process in the authoring environment, you first create a Business Process Definition (BPD), as shown as Figure 4. A BPD is a reusable model of a process that defines what's common to all runtime instances of that process model.

Figure 4. Business Process Definition

Building Human services Build a Human service when you want a step in your BPD to create an interactive task that process participants can perform in a web-based user interface, as shown in Figure 5. When you build Human services, you include Coaches, which are the web-based forms that provide process-related data to users and collect input from those users. Coaches enable you to easily add standard fields and controls such as radio buttons, drop-down menus, and so on. The Ajax services that you build in Lombardi are subsequently bound to Coach controls to perform functions such as automatically populating drop-down lists and enabling type-ahead capability in input fields. You can use an Ajax service to pull data dynamically from a connected data source, such as a database.

Figure 5. Create a Human service

Building Integration services Build an Integration service when you want to integrate with an external system to complete a task, as shown in Figure 6. For example, you can build an integration service that calls a web service to do some business logic. Integration services are the only services that can include web service integration and Java integration components. Use General System services when you want to orchestrate other background services, manipulate variable data, generate HTML for a Coach, or perform other actions that don't require any integrations or business rules. General system services are likely to be called directly from a BPD or from a Human Service. General System services can

include only basic service components such as scripts and cannot contain Coaches or integration components (web service integration or Java integration). General System services can be nested within any other type of service. External activities enable you to create BPDs that include activities that are handled by systems outside of Lombardi. For example, you can build a custom application using the Lombardi web API to execute an activity, or step, in a BPD. An Undercover Agent (UCA) is started by an event that can either be triggered by a message or on a specific schedule. When a UCA is started, it invokes a Lombardi service in response to the event. When you include a message event in a BPD, you must attach a UCA to the event to call the specified service. For example, when a message event is received from an external system, a UCA is needed to invoke the appropriate service in response to the message. You can create and publish a web service to enable external applications to initiate a particular Lombardi service or set of services. Using the SOAP integration, external applications can also call the web service.

Figure 6. Create an Integration service

Building Rule services You can use a Rule service, shown in Figure 7, when you want a condition to determine what implementation is invoked. For example, when a certain condition evaluates to true, Lombardi implements a JavaScript expression that you provide. Rule services cannot include Java or web service integrations directly. You can call a Rule service from any other type of service and a Rule service can call other nested services. Key performance indicators (KPIs) are measurements that Lombardi tracks at process runtime, storing results that you can use to analyze process and task performance in the Optimizer. Service level agreements (SLAs) can be created based on standard and custom KPIs. SLAs enable you to establish a condition for one or more activities that triggers a consequence. When you run instances of your processes, SLA consequences do not trigger until the associated activity starts or completes.

Figure 7. Create a Rule service

Managing external files Lombardi supports adding external files to the process application, including images, style sheets, JAR files, and others. All these project assets are included in the Process Center repository. Adding these files to your process application ensures that all required assets are available and installed when your project is ready for testing or production.

Back to top Enabling re-use through Toolkits Toolkits are a collection of library items that can be used across multiple process applications in the Lombardi Authoring Environment. Lombardi enables process developers to re-use existing artifacts both within and across process applications through toolkits. For example, if you know several services already exist that include Coaches and other library items that other developers need, you can access and re-use those items by including them in a toolkit. Then, from your process application, you can add a dependency on the toolkit in which the library items reside. This enables you to pick one of the existing services when choosing the implementation for an activity. The items in the toolkit can also be used by other developers working in different process applications. Authoring Environment users can create dependencies on toolkits in order to re-use the items within. When Toolkit items are updated, existing dependencies show that updates are available. Library items in multiple toolkits can be shared across other toolkits, as well as process applications. Create toolkits To create a toolkit, do the following: 1. Click the Toolkits tab, and click Create New Toolkit, as shown in Figure 8.

Figure 8. Create a new toolkit

2. In the Create New Toolkit dialog, enter a name and an acronym for your toolkit. 3. To create library items in the toolkit or perform other edits, click Open in Designer. System Data toolkit During Lombardi installation, the System Data Toolkit is imported into the Process Center repository. Each process application and toolkit that you create automatically includes a System Data Toolkit dependency so that you have access to the assets that all Lombardi projects require, such as standard variable types, standard charts for reports, and so on. You cannot edit or change the library items in the System Data Toolkit, but you can open the toolkit and view the items in it.

Back to top Overview of the scenario In this series, we'll use a typical business scenario of a purchase order process to illustrate how to use Lombardi V7.1 to model and run the business process. As shown in Figure 9, the purchase order process is initiated by the buyer from the purchasing department according to the actual inventory and consumption. When the buyer enters the order, the process is triggered. When the process is started, the system sends a notification to the supplier who is responsible for confirming the order.

Figure 9. Purchase order process

The supplier can respond to the order through a web-based user interface as follows:

The supplier can directly accept the order without any change. In this situation, the buyer doesn't need to reconfirm the order. The supplier can accept the order with a change in the quantity and unit price of goods by filling out an "Order Change." In this case, the buyer needs to reconfirm this order before order generation. The supplier can reject the order because of price or because the item is out of stock. In this case, the order will be void and the system will send the notification to the buyer.

In the case of accepting the order, if the supplier raises the unit price of goods, the system needs to notify the buyer to reconfirm the updated order. The confirmation results in one of the following:

If the buyer accepts the updated order, the system automatically generates the final purchase order. If the buyer does not accept the updated order, the system sends the notification to the supplier and the purchase order process is halted.

Otherwise, the buyer does not need to confirm the order and the system automatically generates the formal purchase order. Generate Order subprocess The generation of the formal purchase order is a subprocess embedded in the main purchase order process, as shown in Figure 10. Upon receiving the final purchase order from the above purchase order process, the subprocess initiates the following tasks: 1. 2. 3. 4. Calculate the final total price of the goods for the order Select a shipper for the order. Schedule the shipment. Send notification to both the buyer and supplier.

Figure 10. Generate Order subprocess

Defining business data types Variables are used to capture the business data that is passed from step to step in a process. When you develop a Business Process Definition in Lombardi, you should spend time creating data models for the BPD during the design phase. In our Purchase Order scenario, one important data type, Order, is defined to describe the purchase order. The variable type Order includes two parameters: orderHead (the

cardinality is 1) and orderDetail (which is a List). The OrderHead and OrderDetail variable types and parameters are shown in Tables 1 and 2.

Table 1. Variable Type: OrderHead Parameter name Variable Description type orderId String The number of the current purchase order head orderName String The name of the current purchase order buyer String The buyer of the current purchase order orderDate Date The begin date of the current purchase order supplierName String The supplier name of the current purchase order supplierContactString The supplier contact info of the current purchase order orderCloseDate Date The closed date of the current purchase order status String The status of the purchase order, for example, Accepted by supplier, Rejected by supplier, and so on.

Is List False False False False False False False False

Table 2. Variable Type: OrderDetail Parameter name Variable typeDescription Is List orderItemId String The code of each purchase order detail False orderId String The number of the current purchase order headFalse shipDate Date Shipment date False productNumber String The product number False quantity Decimal The quantity of the product False unitPrice Decimal The unit price of the product False updatedQuantity Decimal The updated quantity of the product False updatedUnitPriceDecimal The updated unit price of the product False

Back to top Conclusion This article provided an overview of WebSphere Lombardi V7.1, including it's architecture, components, and features. In Part 2, you'll learn how use Lombardi to model a process using a purchase order scenario.