On demand business process life cycle, Part 1: Create the foundation for your on demand business processes

Introduction

This article series is based on our experience in a pilot project, Oneida-2. In this pilot, we implemented an on demand business transformation in a real supply chain scenario. We describe methods and techniques which you can use to build reusable assets, which support the rapid creation of on demand business processes.

In a supply chain, an Order to Manufacturing Processing System (OTMPS) typically sits between an order entry and a manufacturing support system (see Figure 1). You can use a generic OTMPS scenario and use cases to illustrate the application of the above methods.

In the Oneida-2 project, we implemented an on demand transformation of a legacy OTMPS. Our objective was to implement a prototype that would demonstrate how to address the following business requirements:

• Faster time-to-value solution -- shorter time of development, integration, and testing for functional updates
• Resilient processes -- manage IT risks and rapidly adapt and respond to opportunities and threats while continuing operations
• Adaptive business policies -- enable dynamic changes of policies without major operational disruptions
• Business performance monitoring -- integrate measurements and relevant business-level information displays

This article series also describes the application of the methods, tools, patterns, and SOA concepts to address the above requirements. We follow an iterative design and incremental development method, using patterns for modeling, development, and deployment. The methods emphasize the reuse of business processes and IT artifacts and the enablement of critical functions as Web Services. The major steps of our iterative design are:

1. Model the business process using IBM WebSphere® Business Integration Modeler (WBI Modeler)
2. Define the data object model using IBM Rational® XDE™
3. Develop the implementation using WebSphere Studio Application Developer Integration Edition (hereafter referred to as Application Developer)
4. Deploy the resulting applications on WBI Server Foundation
5. Monitor business metrics during execution using WebSphere Portal

We first describe the scenario, requirements, and a few use cases. We also provide highlights of modeling, implementation, performance monitoring, pattern solutions, and the system architecture. The other articles in this series provide more detailed descriptions of the above, with emphasis on the methods, tools, and patterns to apply when implementing an on demand business process solution.

Back to top

Scenario

An OTMPS enables its consumers to submit orders (see Stakeholders for details on various roles identified for this scenario). You can use the validated and configured orders as input to produce corresponding Bill of Materials (BOM) in manufacturing nomenclature. You can then submit the orders to the manufacturing plants for fulfillment. In a successful case, the submitted orders go through various steps before the corresponding BOM and manufacturing instructions are submitted to the manufacturing plants for fulfillment. There might be exceptions to this normal processing, which require human intervention (for example, an OTMPS operator might manually handle and correct an invalid order).

Functions

The following functional components are a representative subset of the OTMPS that we worked on:

1. Scheduler -- Schedule orders and initiates the processing of orders
2. Controller -- Controls sequence and execution of order processing
3. Grouping -- Finds relationships between orders and groups them
4. Validation - -Validates the order with pre-defined rules
5. Translation -- Creates BOM output in manufacturing nomenclature
6. Manufacturing -- Packages output appropriately for each manufacturing plant

You can use some variation of these functional components for the design and implementation of the OTMPS.

Back to top

Requirements

Based on interviews with the owners, the analysts specified the following sample requirements for the OTMPS implementation:

1. It should process saved orders in batch mode.
2. It should process online orders in real time.
3. It should adapt to changes in business and IT policies.
4. It should notify an administrator in case of a system error.
5. It should allow an administrator to check and update the system status in real time.
6. It should notify the operators of an invalid order and allow them to correct the order.
7. It should generate and display key business metrics in real time.
8. It should notify owners when key business metrics breach the pre-defined ranges.
9. It should integrate with legacy applications (for example, hardware configuration).
10. It should integrate with external partners (for example, part suppliers).
11. It should support different protocols and data formats (for example, Simple Object Access Protocol (SOAP)/HTTP or EDI.
12. It should allow the dynamic substitution of compatible partners.
13. It should keep track of the actions of the Staff, Administrators, and Owners.
14. It should enable Staff, Administrators, and Owners to collaborate.
15. It should be implemented following a SOA.

Back to top

Use cases

Based on the requirements and the scenario above, an OTMPS needs to implement the following use cases (not a complete list).

• UC0: Create order
• UC1: Schedule a set of orders online
• UC2: Start/stop the scheduler process
• UC3: Process orders
• Group orders
• Validate orders
• Create BOM
• Send output to manufacturing plants
• Request parts from suppliers
• Create business metrics
• UC4: Notify operator of validation errors
• UC5: Notify administrator of system exceptions
• UC6: Notify the owner of a service level breach
• UC7: Monitor business metrics dashboard
• UC8: Change business rules
• UC9: Update order
• UC10: Cancel order
• UC11: Check order status

For illustration, we elaborate three use cases (UC1, UC4, and UC7):

UC1: Schedule a set of orders online

Actor: Operator

Pre-condition: Portal and Business Integration servers are up and running

Main success scenario:

1. Operator logs in to the portal server.
2. System presents the "Process" page.
3. Operator enters the list of orders and clicks Execute button.
4. System presents the running log of the system activity.
5. System executes UC3.
6. System presents the message "Executed successfully".

Extensions: 5a. System presents the message "Failed"

UC4: Notify operator of validation error

Actor: Operator

Pre-Condition: Invalid order encountered during the successful execution of UC3

Main success scenario:

1. System creates a staff activity for the Operator.
2. Operator logs in to the portal server (if not already logged in).
3. System displays the to-do activities to the Operator.
4. System waits for the Operator to claim the activity.
5. System displays the invalid order to the Operator .
6. Operator updates the order and clicks the Update button.
7. System updates the order in the backend database.

Extensions: 6a. Operator collaborates with the consumer and updates or cancels the order.

UC7: Monitor business process metrics

Actor: Business owner

Pre-Condition: UC1 has been executed successfully at least once

Main success scenario:

1. Owner logs in to the portal server
2. Owner opens "Monitor" page
3. System displays the specified business metrics (see Business process monitoring).

Figure 2 illustrates all the use cases presented above. For example, in UC7, the business owner interacts with the Monitor system to view business performance information. In another example, the operator connects to the Order Application to execute UC1, which in turn executes UC3 on the Order Processing system. The Suppliers represents the external suppliers' systems which provide the interface for requesting parts. Legacy System and Validation System represents the existing applications that are used by UC3.

Back to top

Development Process Overview

Figure 3 highlights the development process lifecycle along with the tools and methodology used at each stage. The development process starts by modeling the business processes using the WBI Modeler. The first step is for an analyst to engage the business subject matter experts to clearly delineate the business process requirements. Using this input, the analyst models the existing "as-is" business processes using the WBI Modeler. As-is business processes are then migrated, using a collaborative process, to a more useful "to-be" business process. Pre-existing modeling artifacts, called Process elements (see Service and process elements), from a central repository are used where appropriate, and new modeling artifacts are created for future use. The analyst also identifies business metrics that need to be measured during the process execution.

Once satisfied with the model, the business analyst passes the process model to the IT development team for implementation. In practice, IT architects should be involved in the modeling process to ensure a smooth transition, as described below.

The WBI Modeler exports the process model and its associated business-level object definitions in a combination of Business Process Execution Language (BPEL), XSD, and WSDL artifacts. The implementation of the process model requires integration with additional artifacts such as adaptors for accessing legacy functions, components for business logic, Web service bindings, and so forth. Many relevant patterns are applicable for the analysis and design of the model and its implementation (see Pattern solution).

Back to top

Oneida lifecycle

Using IBM Rational XDE, an architect defines the object model for the additional IT artifacts and generates the corresponding Java code for them. A developer then uses Application Developer to integrate the outputs of the WBI Modeler and Rational XDE with business partner services, legacy systems, and the rule framework. Using Application Developer, the developer associates the additional artifacts (XML schemas, Java code, services, and rules) with the BPEL workflow. You can use Common Event Infrastructure (CEI) APIs to generate relevant process events. The resulting application implementation deploys on a WBI Server Foundation runtime.

During execution, the CEI infrastructure enables the monitoring of the process performance. When available, you should use WBI Monitor V5.1. It supports CEI and provides the appropriate monitoring tools. Alternatively, you can use WebSphere Portal Server to display the performance information. The analysts later use this information to improve the business process, closing the lifecycle loop.

As described above, process modeling and implementation are done by separate roles, as they require different skills. Process semantics, which includes the identification of the process flows, policies, and performance metrics, must be conveyed across this business-IT gap. Incremental and iterative development across this gap is not trivial, as changes in each side might have significant implications for the other. Thus, it is very important to have close collaboration between the roles to help identify and resolve business architecture decisions.

Back to top

Business process modeling

Modeling includes the decomposition of a business process into sub-processes to identify functions, components, and services, along with data inputs and outputs, policies, and metrics. As-is models can be used for simulation and to identify the current bottlenecks. As-is business processes are then converted into to-be business process which implement the desired changes. The to-be models can then be simulated to identify potential process improvements. The analyst also identifies business metrics that need to be measured during the process execution. Figure 4 illustrates a common process segment in WBI Modeler V5.1. This simple OTMPS model illustrates the flow of orders through validation and manufacturing. The model integrates a validation service partner, using the validate and generate topology service invoke step. The figure also shows a decision point, validation successful?, two data format conversion tasks, local data repositories to store customer orders for later use in the process, and a process loop to select and forward orders to the correct manufacturing plant.

The analyst might apply pre-existing modeling artifacts (for example, service or process elements) to facilitate and speed up the construction of the model (see Service and process elements). These assets are stored on a central repository for business artifacts.

The third article of this series introduces techniques and guidelines to conduct an iterative modeling process using WBI Modeler V5. The article describes how to define core process elements:

• Control flows
• Sub processes
• Rules
• Roles
• Measurements for the OTMPS scenario

After identifying the core business components, we illustrate the modeling method starting with:

• Identification and listing of tasks
• Sequencing of the tasks
• Creation of flow controls between tasks
• Introduction of data into the process
• Integration of services with the process model

We briefly describe the use of WBI Modeler to perform model validation and analysis through static and dynamic simulations. We conclude with a description of the various export facilities available in WBI-Modeler and describe the generated artifacts.

Back to top

Implementation

The WBI modeler produces BPEL, XSD, and WSDL artifacts, which provide the starting point of the implementation. Using Rational XDE, an architect defines the object model for the additional IT artifacts and generates the corresponding Java code for them. We used the the Application Developer 5.1 "Business Integration" perspective to create a service project, with artifacts such as XML schemas, Web services, and objects and processes. The Java classes and XML schema artifacts generated using XDE and Application Developer respectively are used for accessing external partner services. The BPEL workflow is extended (through Java code) to integrate rules, support legacy service interaction, and to generate business events. Figure 5 shows a view of the Application Developer BPEL editor.

A process connects to its partners using a static binding mechanism, which is generated at the time of process deployment. The necessary binding, deployment code, and component packages are integrated. These include code generated for legacy facade components, generating WSDL/XSD, and deployment artifacts (Enterprise JavaBeans (EJB) and SOAP bindings). Exceptions are handled by an external macro flow, which is a long-running process with provisions for introducing staff who could evaluate the exception conditions and make decisions on how to handle them.

In article 4 of the series, we describe how to take the output from WBI Modeler and Rational XDE into Application Developer, as well as how to integrate them together. The article also describes the implementation of process and service components and how Java classes and XML schema artifacts are added to them as input/output messages and state objects. To complete the implementation requires wrapping of and connecting to external partner services and rules. We describe some best practices for improving the performance of workflows. We explain the differences between micro flow and macro flows in transactional behavior, parallelism, and performance. We suggest which type is appropriate for different situations and the best way to combine them. We describe different data mapping methods, invocation styles, bindings, deployment topologies, and their performance impact.

Back to top

Customization: Policies and rules

Over time, the OTMPS owners introduce new requirements on the OTMPS implementation (for example, changing policies for deciding how to configure orders). The objective is to quickly adapt the OTMPS to such rapidly changing requirements.

Analysts might specify the intended policies. But policies need to be enforced by explicit, executable rules. See the Policy, rules, and enforcement points section for the definitions of policies, rules, and enforcement points.

In traditional applications, rules are embedded with the code inside the application. In such applications, when policies change, the application code needs to be updated and re-deployed. Externalizing the rules allows business analysts and other less-technical users to modify policies that have been defined without changing the process logic and without re-deploying the application.

To reuse the existing workflow artifacts, it is essential that the architecture enables late customization for policy changes. These customizations are achieved through dynamic changes during workflow execution to the externalized rules that implement and enforce business polices.

As part of the OTMPS pilot, we implemented a simple rules service framework, which consists of a Rules Service Facade and a Rule Engine Selection (for details see the 5th article in this series). Our implementation used Business Rule Beans (BRBeans) (see Figure 6) framework.

BRBeans is a framework in WBI-SF for creating, modifying, and invoking rules. It is implemented using EJBs such as Rule, RuleFolder, and RuleHelper. In the BRBeans framework, each rule is represented by an entity bean that persistently stores information related to that rule. Each rule is assigned an appropriate name, associated properties (for example, start date, end date, available, and javaRuleImplementorName), and stored in an appropriate rule folder. A rule implementation is an algorithm written in Java and associated with the rule through 'javaRuleImplementorName' rule property.

Instead of directly invoking the BRBeans APIs from a workflow, we suggest a service invocation, which in turn uses a rules framework to invoke the BRBeans APIs, as shown in Figure 7. All application specific rules are wrapped in a service facade, with each rule being exposed as a method. All rules that are sharable across applications (for example, security, business performance, and so forth) can be defined in other common services facades. Rules framework hides the rule engine and enables selection of different rule engines. The specific rules are codified by an analyst using the specific rule engine administration system (using a rule administration GUI) and deployed to the corresponding rule engine.

At the policy enforcement points, the rules are invoked as normal Web services, passing the necessary parameters for execution. We applied the strategy pattern for the selection of the appropriate rule engine. A command pattern is created for the selection of the correct rule and its execution in the corresponding rule engine. Once this rule command class is created, it is triggered to execute the correct rule in that specific rule engine.

Back to top

Business process monitoring

Business process monitoring capabilities allow the owners and administrators to monitor Key Performance Indicators (KPIs - see Key Performance Indicator) in real time. They also allow the analysts to identify the problems/bottlenecks in the existing processes, closing the development loop as illustrated in Figure 3. Based on this feedback, analysts might decide to adjust and change the business processes and repeat the development cycle. For example, in the pilot project, the OTMPS owners defined the following key performance measurements:

• Average order throughput
• Success ratio for orders
• Number of invalid orders
• Average problem resolution time

The CEI infrastructure enables you to create and distribute the events in a uniform fashion. You can also create applications/tools that use these events to deduce and display useful information. Events are typically used to emit the business process related information which is later used to calculate performance metrics. The events are generated in Common Base Events (CBE) format using the CEI APIs included with WBI-SF V5.1.1. We used WebSphere Portal Server Express to render and aggregate information into composite pages to provide information to users in a compact form. We customized the Web page portlet provided by WebSphere Portal Server Express to display business events and performance information.

In a future article of this series, we show how to do business process monitoring using CEI. We discuss how to specify the KPIs in WBI Modeler V5.1, how to create the corresponding events using BPEL editor and CEI APIs in Application Developer V5.1.1, and how to query these events using CEI APIs. We briefly describe the structure of CBEs, show how to query them using the XPath query language, and how to create event groups using WBI-SF V5.1.1 and use them to query events using CEI APIs.

Back to top

A pattern solution

There are many relevant patterns (see Patterns) that can be used for analysis, testing, e-business, deployment, and so forth of an OTMPS. It is not always clear how these patterns tie together, and how to apply them in a given context to create a flexible and responsive solution. In article 2 of the series, we describe a recipe for creating a pattern solution for the OTMPS, using patterns for e-business. For an introduction to patterns for e-business, see Jonathan Adams, Srinivas Koushik, Guru Vasudeva, George Galambos, Patterns for e-business: A Strategy for Reuse, IBM Press, 2001, ISBN 1-931182-02-7. For additional patterns for e-business resources in IBM developerWorks, see IBM Patterns for e-business.

In article 2, we introduce four designs which are either variations of existing patterns or have the potential to become new (formal) patterns:

1. Business process composite pattern, allows a human to initiate a business process that requires collaboration and needs to be monitored.
2. Page aggregation application pattern, an access integration application pattern that provides a structure for giving access to multiple applications through a common interface that can be customized.
3. Single point of access runtime pattern, a basic runtime pattern, corresponding to the Page Aggregation application pattern that provides a single point of access to various Web applications.
4. Web client runtime pattern is a managed collaboration runtime pattern that allows the Web clients to collaborate asynchronously in a pre-defined manner.

Back to top

System Architecture

As described at the beginning of this article, we implemented an on demand transformation for real OTMPS. In the following articles (see Resources), we describe in detail the methods and techniques which you can use to design and build similar systems. Figure 8 illustrates the runtime relationships among the major components in our prototype OTMPS:

• WebSphere Portal -- contains the portlets that provide user access to OTMPS services.
• WBI Server Foundation V5.1.1 - provided the following features:
  • Web container -- contains the servlets used to handle the requests that originate from the portlets (for example, to start a new instance of a business process, to collect performance data, and so forth).
  • Process container -- provides engine that executes the (BPEL) business processes.
  • BRBeans -- enables the externalization of business rules.
  • CEI -- used to generate and collect business events.
• DB - -data stores (DB2®) for storing the BRBeans rules and for storing CEI data.
• External configurator and legacy service -- external partner services used for order configurations and validations. The supported protocols were MQ and FTP.

Back to top

Conclusion

This article series presents an overview of the development lifecycle and technologies needed to implement agile business processes that can meet continually evolving requirements. We describe an order processing scenario which provides a common context and a set of use cases for the other articles in this series. The first step is to model the existing and desired business processes using WBI Modeler. The model output artifacts are then augmented with additional artifacts, and the resulting application is then deployed on WBI-SF. The CEI is used to generate relevant events for measurements of business metrics to be computed and displayed in business dashboards. These metrics then provide input to the analysts to improve the process, closing the cycle. The architecture design is based on the application of a recipe with multiple patterns for e-business to produce a pattern solution.

Resources

• Read all parts of the On demand business process life cycle, and keep track as we add new installments.
  
  
• Get information about the On Demand operating environment from the following articles:
  • The On Demand operating environment (developerWorks, August 2004)
  • Operating environment essentials for an on demand breakthrough (developerWorks, August 2004)
  • Architecting on demand solutions: Best practices for using the thirteen capabilities of the IBM On Demand Operating Environment (article series, developerWorks)
  
  
  
• Find out more about Patterns for e-business in the book Patterns for e-business: A Strategy for Reuse , by Jonathan Adams, Srinivas Koushik, Guru Vasudeva, and George Galambos (IBM Press, 2001, ISBN 1-931182-02-7).
  
  
• You can also learn more about IBM Patterns for e-business on the developerWorks site.
  
  
• Download the "Business Process Execution Language for Web Services, Version 1.1" specification (developerWorks, March 2003).
  
  
• Browse for books on these and other technical topics.
  
  
• Want more? The developerWorks SOA and Web services zone hosts hundreds of informative articles and introductory, intermediate, and advanced tutorials on how to develop Web services applications.
  
  

About the authors

Dr. German Goldszmidt is a Senior Technical Staff Member working in the IBM Software Group, with focus on architecture of an integrated platform for delivering, customizing, and deploying on demand solutions. Previously, he was a researcher at the IBM T.J. Watson Research Center, and led the design and implementation of several technologies, including Oceano, the first prototype autonomic computing eUtility, and Network Dispatcher, the load balancer component of WebSphere.

Joshy Joseph is a Software Engineer working with the IBM On Demand development organization. He is an architect and programmer with primary skills and expertise in the areas of distributed computing, grid computing, Web services, Business Process, and workflow development. He is the author of the book Grid Computing from Prentice Hall, 2003. In addition, he has written numerous technical articles about Grid computing, Business Process development, and Web services.

Naveen Sachdeva is an Advisory Software Engineer with IBM's Application Integration Middleware group. He has over 10 years of experience in large-scale system integration, and the design and development of distributed computing systems. He currently helps IBM business partners with technical enablement and proof-of-concept using WebSphere products.

Wei Liu is a Software Engineer from IBM Software Group. She is currently working with IBM On Demand development team. Her area of expertise includes application server, web service and workflow development.

Comments

Back to top

Trademarks

Table of contents

• Introduction
• Scenario
• Requirements
• Use cases
• Development Process Overview
• Oneida lifecycle
• Business process modeling
• Implementation
• Customization: Policies and rules
• Business process monitoring
• A pattern solution
• System Architecture
• Conclusion
• Resources
• About the authors
• Comments

Local resources

• IBM Innovation Center - Austin, TX
• IBM Innovation Center - Chicago, IL
• IBM Innovation Center - Dallas, TX
• IBM Innovation Center - San Mateo, CA
• IBM Innovation Center - Waltham, MA
• Technical Briefings in North America

My developerWorks community

Dig deeper into SOA and Web services on developerWorks

We want to know you!

Update your My developerWorks profile and start connecting with others

Special offers