Case Study: Process SOA Scenario

Transcription

1 Redpaper Martin Keen Michele Chilanti Veronique Moses Scott Simmons Srinivasan Vembakkam Case Study: Process SOA Scenario This paper one in a series of service-oriented architecture (SOA) papers that feature a case study involving a fictitious company called JKHL Enterprises (JKHLE). The focus of the case study in this paper is the challenges and solutions associated with the business process for opening new accounts. This paper describes how to apply the realization pattern of the Process SOA Scenario to solve the business and IT challenges as they relate to the case study. Copyright IBM Corp All rights reserved. ibm.com/redbooks 1

2 Introduction to the case study JKHL Enterprises (JKHLE) is undergoing a set of fundamental business changes in an effort to ultimately maximize profits. JKHLE has decided to adopt SOA principles to address the business and IT challenges that it faces. The JKHLE team is focusing on solving the challenges that are presented by creating new customer accounts in a consistent manner throughout each of the sales channels. This SOA adoption initiative is known as the Account Open Project. Using an SOA approach will allow for a more rapid implementation and greater flexibility for future changes that the business might need. Note: For more detailed information about the case study, refer to Case Study: SOA Account Open Project Overview, REDP The case study that we describe in this paper includes the following key actors and roles: Sandy Osbourne-Archer, Chief Technical Architect Ian McCallen, Integration Developer Paige Alvarado, Senior Development Manager Ronnie Espinoza, Business Analyst Account Open Project challenges The JKHLE Account Open process challenges that we define in this paper are associated with the Process SOA Scenario. The Account Open Project architecture team is focused on solving the significant issues with the existing multiple mechanisms that customers use when opening accounts with JKHLE. They want to develop an improved, single mechanism for opening accounts from both the business and IT viewpoints. The Account Open Project will be the first test case for a new SOA implementation within JKHLE. Account Open Project requirements Sandy Osbourne-Archer, Chief Technical Architect, briefed her team on the objectives for the project. We want to better align our IT infrastructure with our business objectives and turn around some of the losses that we have suffered. We have chosen to fix the Account Open process first, because it is hurting customer satisfaction. 2 Case Study: Process SOA Scenario

3 Paige Alvarado, Senior Development Manager, is working on Sandy s Account Open Project architecture team. Paige s organization is assigned to work with the line of business (LOB) and operations to automate the new business process. The Account Open process requires the integration of multiple back-end systems, human workflow integration, and composite services to support an end-to-end solution. Sandy has defined some clear requirements for the project. REQ-01: Automate the Account Open activation process JKHLE has a goal to automate the Account Open activation process by minimizing the manual and paper documentation. Furthermore, there is a requirement to automate 75% of credit report retrievals which is a sub-process of the Account Open process. REQ-02: Incorporate human interaction for credit verification and approval A comprehensive solution for the Account Open process requires the involvement of human workflow to support the credit verification and approval process, which is a sub-process of the Account Open process. REQ-03: Provide real-time views of the Account Open process The automated process should provide real-time views into the business operations to measure and monitor the Account Open and credit functions. Note: For solution details for all of these requirements, refer to Process Automation and Human Workflow on page 5. Applying the SOA realization pattern to the case study This section discusses how Paige s team, with the support of Ian McCallen, Integration Developer, will change and improve the automation and, therefore, optimize the execution of the Account Open process in an SOA-enabled environment. JKHLE will use the Process Automation and Human Workflow realization pattern from the Process SOA Scenario. Case Study: Process SOA Scenario 3

4 The definition of a business process A business process is a set of business-related activities that are invoked in a specific sequence to achieve a business goal. Business processes consist of tasks, which are comprised of: Human interaction Automated workflow Information services Business rule interactions Sub-processes Invocation of functions and services The difference between a process and a service is that a process is made of tasks represented as a separate service or set of services, whereas a service represents an individual, repeatable business task (for example, checking customer credit). Figure 1 shows a view of a business process compared to a service. Business Process Services Figure 1 Business process and services The defacto industry standard for implementing processes on computing platforms is represented by the Business Process Execution Language for Web Services (WS-BPEL). WS-BPEL is an XML-based language that allows you to define the logical flow of execution of services that constitutes a business process. 4 Case Study: Process SOA Scenario

5 Process Automation and Human Workflow Ian proposes a solution to Paige that describes a fully automated process with an integrated human workflow to allow for management of the credit approval process. Ian reminds Paige that before he builds this business process, a number of other things have already happened: Ronnie Espinoza, Business Analyst, has documented and analyzed the current Account Open process using IBM WebSphere Business Monitor. This is known as the As-Is model. Based on the analysis of the As-Is model, Ronnie and Ian worked together to model a new improved process, known as the To-Be model. Ronnie used the simulation capabilities of WebSphere Business Modeler to perform statistical analysis and what-if scenarios to identify and correct bottlenecks and workload imbalances. Note: These modeling activities are described in the Process Modeling and Simulation realization pattern that is part of the Business Process Management SOA Scenario. For more information about this realization pattern, refer to Case Study: Business Process Management SOA Scenario, REDP Case Study: Process SOA Scenario 5

6 Ian tells Paige that the Account Open process will be constructed as a WS-BPEL process. He shows Paige the IBM products that will be used to construct this process and where these products fit into the SOA life cycle (see Figure 2). WebSphere Integration Developer WSDL, XSD Rational Software Architect Account Open process EAR files + process KPIs Update Legacy BPEL CRM Account Rep (Create customer checking account) Update SAP Third Party Web Service (Send customer a checkbook) Order Credit Card Notification Human Tasks Start Batch BSMs Maps Rules/Selectors WebSphere Process Server WebSphere Portal Server WebSphere Business Monitor Process metrics SCA CEI Adapters Figure 2 Products and SOA life cycle phases The products shown in Figure 2 are used as follows: IBM WebSphere Integration Developer and IBM Rational Software Architect are used to create the business objects, interfaces, and WS-BPEL process for the Account Open process. IBM WebSphere Process Server is the runtime where the Account Open WS-BPEL process will run. IBM WebSphere Portal Server provides an effective way to present tasks assigned to users within the context of the Account Open process. IBM WebSphere Business Monitor is used to capture key state changes and business events. 6 Case Study: Process SOA Scenario

7 Assembling the business process Ian assesses and takes advantage of the existing services and assets. He creates new services to automate the Account Open business process. These existing services and assets exposed as services along with the newly created services will be activities within the business process. A business process can consume Service Component Architecture (SCA) services or it can be consumed by other SCA services. The way in which Web Services Description Language (WSDL) message data is exchanged between the SCA service and the process depends on how the process was modeled. Note: SCA allows developers to build component-oriented solutions by grouping the interaction of components into executable modules. All integration artifacts in WebSphere Process Server processes, business rules, human tasks, and so forth are represented as SCA service components. SCA can invoke service components through both synchronous and asynchronous programming styles. Ian uses WebSphere Integration Developer as the primary development tool to assemble the Account Open process. With WebSphere Integration Developer, there are several editors that allow Ian to build the other components that are needed such as: An integrated BPEL editor to support the team in the creation of the business process. A human task editor to define human tasks. A business rules editor to create, manage, and associate business rules with the process. An assembly editor to support the actual assembly of the services to compose executable business processes. Ian also uses Rational Software Architect as the primary development tool to support the requirements of developing new services, as well as visual interfaces (such as portlets and Java Server Faces solutions). After Ian builds the actual Account Open process, the JKHLE team needs to test the solution components in accordance with the defined test plan. WebSphere Integration Developer provides graphical tools for testing SOA components and solution artifacts. Deploying the business process JKHLE needs to deploy the artifacts of the Account Open process (WS-BPEL process, new services, portlets, and so forth) into the production environment. The JKHLE environment consists of a WebSphere Process Server Case Study: Process SOA Scenario 7

8 implementation, which is the integrated runtime for the SOA based process automation. WebSphere Process Server provides the runtime engine for all the components defined in the assembly step. The Account Open process contains activities requiring human intervention, so JKHLE is required to install and deploy artifacts to WebSphere Portal Server. This runtime component provides the containers for enabling the integration of the Account Open application and customer Account Open interface, the credit management workspace to support ongoing credit management functions, and the VP Finance dashboard to support visualization of key business performance indicators. In the development and deployment of the Account Open process, any identified non-functional requirements must be reflected in this phase. As a result, the architecture of the deployed environment needs to support performance, availability, security or other non-functional requirements for JKHLE. Managing the business process A requirement of JKHLE is to have business level and IT operational monitoring. IT operational monitoring is accomplished using IBM Tivoli Composite Application Manager for SOA product. IBM Tivoli Composite Application Manager for SOA provides the ability to drill down and gather diagnostics for the WebSphere Process Server and WebSphere Portal runtime environments. JKHLE uses this product to support views into the service interactions from the WebSphere Process Server, as well as actual services to support the Account Open applications. Coupled with IT operational monitoring, JKHLE must also take advantage of business monitoring a key facet of JKHLE Account Open solution. The intent of the business monitoring is to provide real-time information about the status and results of the JKHLE Account Open solution so that business decisions can be informed, can address problem areas quickly, and can reposition the organization to take full advantage of emerging opportunities. The JKHLE team (be it the IT department or the line of business) can monitor work-in-process items and perform corrective actions by reassigning, reprioritizing, or suspending them. They can use actual process metrics to answer what-if questions and make process improvements. 8 Case Study: Process SOA Scenario

9 Summary Sandy and Paige are delighted with the business process solution that Ian assembled. The new Account Open business process improves response time and customer satisfaction significantly. The process also allows for continual improvement because JKHLE can use the results from monitoring to guide changes back into their business process to remain aligned with their IT objectives. In summary, JKHLE uses the following IBM products to implement the Process SOA Scenario in their environment: Assemble: IBM WebSphere Integration Developer IBM Rational Software Architect Deploy: IBM WebSphere Process Server IBM WebSphere Portal Server Manage: IBM WebSphere Business Monitor References This section includes reference information for further reading materials that are related to the Process SOA Scenario: IBM SOA Sandbox found at: opic=/com.ibm.soln.soasandbox.nav.fw.doc/home_pages Business Process Management: Modeling through Monitoring Using WebSphere V6.0.2 Products, SG Case Study: SOA Account Open Project Overview, REDP-4376 Case Study: Business Process Management SOA Scenario, REDP-4383 Case Study: Process SOA Scenario 9

10 The team that wrote this IBM Redpaper This paper was produced by a team of specialists from around the world working with the International Technical Support Organization (ITSO). Martin Keen is a Senior IT Specialist for the IBM ITSO in Raleigh, NC, USA. Michele Chilanti is an IBM Senior Consultant, WebSphere Services, Rochester, MN, USA. Veronique Moses is an IBM Product Manager, SOA Scenarios, Raleigh, NC, USA. Scott Simmons is an IBM Executive IT Architect, SOA Technical Sales, Boulder, CO, USA. Srinivasan Vembakkam is an IBM Executive IT Architect, SOA Technical Sales, Madison, WI, USA. Thanks to the following people for their contributions to this project: Erica Carmel, IBM Program Director, SOA Platform Consumability, USA Cindy Macrafic, IBM Senior Project Manager, SOA Platform Consumability, USA John Ganci, Architect and Specialist, Scenario Analysis Lab, Raleigh, NC, USA Linda Robinson, Graphics Artist, IBM ITSO, Raleigh, NC, USA 10 Case Study: Process SOA Scenario

11 Notices This information was developed for products and services offered in the U.S.A. IBM may not offer the products, services, or features discussed in this document in other countries. Consult your local IBM representative for information on the products and services currently available in your area. Any reference to an IBM product, program, or service is not intended to state or imply that only that IBM product, program, or service may be used. Any functionally equivalent product, program, or service that does not infringe any IBM intellectual property right may be used instead. However, it is the user's responsibility to evaluate and verify the operation of any non-ibm product, program, or service. IBM may have patents or pending patent applications covering subject matter described in this document. The furnishing of this document does not give you any license to these patents. You can send license inquiries, in writing, to: IBM Director of Licensing, IBM Corporation, North Castle Drive Armonk, NY U.S.A. The following paragraph does not apply to the United Kingdom or any other country where such provisions are inconsistent with local law: INTERNATIONAL BUSINESS MACHINES CORPORATION PROVIDES THIS PUBLICATION "AS IS" WITHOUT WARRANTY OF ANY KIND, EITHER EXPRESS OR IMPLIED, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF NON-INFRINGEMENT, MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Some states do not allow disclaimer of express or implied warranties in certain transactions, therefore, this statement may not apply to you. This information could include technical inaccuracies or typographical errors. Changes are periodically made to the information herein; these changes will be incorporated in new editions of the publication. IBM may make improvements and/or changes in the product(s) and/or the program(s) described in this publication at any time without notice. Any references in this information to non-ibm Web sites are provided for convenience only and do not in any manner serve as an endorsement of those Web sites. The materials at those Web sites are not part of the materials for this IBM product and use of those Web sites is at your own risk. IBM may use or distribute any of the information you supply in any way it believes appropriate without incurring any obligation to you. Information concerning non-ibm products was obtained from the suppliers of those products, their published announcements or other publicly available sources. IBM has not tested those products and cannot confirm the accuracy of performance, compatibility or any other claims related to non-ibm products. Questions on the capabilities of non-ibm products should be addressed to the suppliers of those products. This information contains examples of data and reports used in daily business operations. To illustrate them as completely as possible, the examples include the names of individuals, companies, brands, and products. All of these names are fictitious and any similarity to the names and addresses used by an actual business enterprise is entirely coincidental. COPYRIGHT LICENSE: This information contains sample application programs in source language, which illustrates programming techniques on various operating platforms. You may copy, modify, and distribute these sample programs in any form without payment to IBM, for the purposes of developing, using, marketing or distributing application programs conforming to the application programming interface for the operating platform for which the sample programs are written. These examples have not been thoroughly tested under all conditions. IBM, therefore, cannot guarantee or imply reliability, serviceability, or function of these programs. You may copy, modify, and distribute these sample programs in any form without payment to IBM for the purposes of developing, using, marketing, or distributing application programs conforming to IBM's application programming interfaces. Copyright International Business Machines Corporation All rights reserved. Note to U.S. Government Users Restricted Rights -- Use, duplication or disclosure restricted by GSA ADP Schedule Contract with IBM Corp. 11

12 This document REDP was created or updated on January 21, Send us your comments in one of the following ways: Use the online Contact us review Redbooks form found at: ibm.com/redbooks Send your comments in an to: Mail your comments to: IBM Corporation, International Technical Support Organization Dept. HYTD Mail Station P099, 2455 South Road Poughkeepsie, NY U.S.A. Trademarks Redpaper The following terms are trademarks of the International Business Machines Corporation in the United States, other countries, or both: Redbooks (logo) IBM Rational Tivoli WebSphere The following terms are trademarks of other companies: Java, and all Java-based trademarks are trademarks of Sun Microsystems, Inc. in the United States, other countries, or both. Other company, product, or service names may be trademarks or service marks of others. 12 Case Study: Process SOA Scenario