Building an IBM Case Manager IBM WebSphere ILOG JRules Solution

Transcription

1 IBM Industry Solutions Building an IBM Case Manager IBM WebSphere ILOG JRules Solution Miniresidency Report and Experience IBM ICM Case Manager Solution Implementation Authored by IBM team: Bert Bukvarevic Boris Becker Carsten Rieger Dr. Tek-Seng The Walter Mayer Werner Fuehrich Witold Szczeponik IBM Software Group, Industry Solutions ECM IBM Software Group, Industry Solutions ECM IBM Software Group, Industry Solutions ECM IBM Software Group, Industry Solutions ECM IBM Software Group, Center Of Excellence ECM IBM Software Group, WebSphere BPM Dev. and Operations IBM Software Group, WebSphere,Senior IT Architect

2 Table of Contents Revision History... 4 Motivation and Solution Definition... 5 Overview... 6 IBM Case Manager (ICM)... 6 IBM Case Manager Builder... 7 Case Builder Tasks and Business Process Mapping... 7 IBM Case Manager Client... 8 Case Manager API... 8 Case Manager Administration Client... 9 Case Management Reporting Tools... 9 Case Management Contentt Analytics Forms IBM WebShere ILOG JRules (ILOG) ILOG JRules Architecturee ICMILOG Integration Sample Solution Scenario Implementing the ILOG JRules Solution Selecting the Project Workspace Creating the Rule Project Defining Input and Output Parameters Define Rule Packages Defining the Rules Creating a Decision Table Creating the Ruleflow Creating a RuleApp Deploying the RuleApp Validating the Rule Execution Environment Implementing the Case Solution Defining the Case Properties Defining the Case Roles Defining the Document Types Defining the Personal In-Basket Page 2 of 64

3 Defining the Case-Type Adding the Tasks Designing the Task Workflows Integrating the Case Solution with IBM WebSphere ILOG JRules Opening the Workflow Definition For Editing Enabling Direct Access to WSDL Links Determining the WSDL Link For the BRMS Rule Application Adding a Web service Invocation Step Registering Partner Link Mapping of Workflow Parameters to the Web service Interface Parameters Updating Case Attributes Deploying the Case Manager Solution Testing the Solution Summary Page 3 of 64

4 Revision History Rev Date Author Contributors Description /11/2011 Team Initial Draft /12/2011 Boris Becker Consolidation / Review /12/2011 Walter Mayer Review /01/2012 Witold Szczeponik ILOG Consolidation, Figures, Form /02/2012 Walter Mayer Summary, Final /02/2012 Walter Mayer Update ILOG steps and figures Page 4 of 64

5 Motivation and Solution Definition The mini-residency Building an IBM Case Manager (ICM) IBM WebSphere ILOG JRules solution in the IBM Germany Böblingen Lab from November 2011 was setup and defined with the following motivation: Exchange experience and knowledge between IBM Case Manager, IBM WebSphere One BPM initiative and IBM WebSphere ILOG experts Demonstrate how to build an ICM solution exploiting ILOG JRules from scratch in a predefined time frame Implementation of a pilot workshop scenario for a hands-on ICM/ILOG JRules integration to reuse in future customer or business partner events Get deep insights for the products involved, exchange knowledge and experience Create and publish a document describing the tasks to setup an ICM solution using ILOG JRules step by step, to enable consultants working with ICM and/or ILOG JRules to reproduce our scenario implementation. Basic technical knowledgee of ICM and ILOG JRules will be required to use this description. Choosing from a list of possible sample scenarios as a result of a brainstorming session, the team decided to implement an Airline Customer Complaint case management solution. When discussing the various use cases proposed, it became clear, that the airline customer management sample was well suited to implement the sample ICM/ILOG integration scenarios we were planning to test and document. First, the main characteristics of the software components used are described in the chapter Overview. The implementation details of the solution are described in the subsequent chapters, starting with describing the sample use case in the chapter Sample Solution Scenario followed by a step by step description of the implementation in the chapters Implementing the ILOG JRules Solution, Implementing the Case Solution, and Integrating the Case Solution with IBM WebSphere ILOG JRules. The mini residency team jointly developed the solution using a copy of the ICM PoT VMWare image which already included an ILOG JRules installation. Page 5 of 64

6 Overview Implementing a robust and effective case management solution requires a software platform providing a range of functionality, including content management, process management, business rules, collaboration and analytics. Advanced Case Management (ACM) from IBM brings together information, processes, and people to provide a complete case view for the user(s) and to achieve optimized outcomes when working on a case. The following diagram shows the high level architecture of the IBM case management platform including the various components providing case management functionality. The different components are described in more detail in the subsequent sections. Figure 1 - ICM High Level Architecture IBM Case Manager (ICM) IBM Case Management provides functionality to collect structured and unstructured case information and to coordinate and process case tasks. Many case activities are driven by the knowledge workers (or case workers) to achieve an optimized case outcome. IBM Case Manager is built on the FileNet P8 Platform and thus enables seamless use of content management and process management capabilities. See also 01.ibm.com/software/data/advanced-case-management/ The various components of the IBM Case Manager platform are describedd in the following sections. Page 6 of 64

7 IBM Case Manager Builder IBM Case Manager Builder is the tool used to build a case management solution. Providing a straightforward graphical user interface, Case Manager Builder simplifies the design of case management solutions, allowing business analysts to directly define the main artifacts of their business solution. Using Case Manager Builder, business analysts can create their case management solution in the development environment. Defining the solution consists of defining property types, document types, case types, task types, and processes linked to the tasks. After having created the solution, IBM Case Manager Builder is used to deploy the solution to an execution environment on the development environment. This enables the solution designer to quickly test the solution and thus supports an iterative development approach. When a solution is well tested it is deployed to the production system(s). A development environment can be segmented into project areas, each providing a target object store as a sandbox execution environment to test the solution. Each project area object store can be individually reset if needed. Case Builder Tasks and Business Process Mapping A task consists of one or more steps, or a reused business process workflow. A case type can have one or more tasks that must be completed by a case worker in the Case Manager Client to close the case. You can associate a task with workflows implemented with the IBM Business Process Manager Integration Designer or the IBM (FileNet) Process Designer. The FileNet P8 Process Engine supports extended workflow features that the Case Manager Builder does not support. You can edit your solution workflows in Process Designer, and later continue working in the Step Editor. Or you can associate solution task(s) with an automated process that is created by using IBM Business Process Manager Integration Designer and map the task to a new business process that implements the workflow for that task. The business process is implemented as an external web service. By using IBM Business Process Manager with IBM Case Manager, you can take advantage of the strengths each product offers: IBM Business Process Manager provides a platform on which you can implement process applications that involve human tasks or automated business processes. IBM Case Manager provides a platform on which you can implement case tasks that require case workers to act on decisions that are based on the context of documents and other content objects. The components of IBM Business Process Manager provide a unified BPM repository, tooling for authors, administrators, and users, and a runtime platform. Different configurations of the product support different levels of complexity and involvement with business process management. The following diagram illustrates a typical IBM Business Process Manager configuration: Page 7 of 64

8 Figure 2 - Typical IBM Business Process Manager configuration IBM Case Manager Client Case Manager Client is an iwidget-based application. IBM WebSphere Business Space is used as the container for the ICM widgets. Case designers can create and customize solution layouts using the out-of-the-box IBM Case Manager widgets or custom built widgets. At runtime, case management users access the resulting web application to work with the case management solution. Case Manager API The Case Manager API consists of three REST-based APIs: Content Management PE REST API Case REST API Interoperability Services (CMIS) Page 8 of 64

9 The Case Manager API provides an integration layer between the IBM Case Manager components and the underlying IBM FileNet engines. The Case Manager API provides a full set of functionalities for developers to build custom applications on top of Case Manager. Case Manager Administration Client The Case Manager Administration Client (CMAC) is used for configuring the IBM Case Manager environment. CMAC is also used for migrating solutions from a development environment to a production environment. Optionally FileNet Deployment Manager (FDM) can be used for migrating Case Manager solution components between environments. The following diagram shows the use of CMAC in development and production environments and for migrating solutions between these environments. Figure 3 - CMAC used for migration of solutions from development environment to production environment Case Management Reporting Tools IBM Case Analyzer is a component that allows extracting audit data from the underlying IBM FileNet engines (Content Engine (CE) and PE Process Engine (PE) ) using the Event Publisher. Case Analyzer makes these event records available in a dedicated reporting and analysis database. The Case Analyzer cubes created in this database are used for historical data reports based on case management data and events. For real-time monitoring, Cognos Real Time Monitoring (Cognos RTM) is used to prepare the data and present it to the users. Cognos RTM also uses the data from the IBM FileNet engines Page 9 of 64

10 sent to the Case Analyzer database using the Event Publisher. Optionally Cognos BI (Business Intelligence) can be used to load and display advanced reports. Case Management Content Analytics IBM Content Analytics supports crawling for unstructured and structured data associated to cases. Using this information, it allows analyzing historic case data, taking all information associated to these cases into account. Forms IBM Case Manager provides an integration of P8 eforms and IBM Forms to use electronic form functionality in case management solutions. IBM Case Manager provides forms integration allowing capturing of user data from a form and the transfer of the forms data to the case and task objects. Forms can also be added to a case and they can be accessed from the case or the case tasks. IBM WebShere ILOG JRules (ILOG) A Business Rules Management System (BRMS) enables customers to extract business rules and decisions from business processes and manage them independently, thereby allowing the processes to be streamlined. Content Centric IBM Case Management BPM tasks systems and the ILOG BRMS are integrated to deliver case management solutions which provide high agility and extensibility. For example, in our sample airline complaint verification process, the business policies to assess the eligibility of customer complaints have to consider legal regulations regarding passenger rights and at the same time have to make sure to avoid unnecessary paybacks or mileage vouchers to maximize the airline s profit without losing customer loyalty. Therefore, hard coding these policies in the process definition is not a good idea, since it is then hard to manage and update the rules. It is much better to separate the design and execution of the business rules from the complaint process itself. IBM WebSphere ILOG JRules provides the functionality to manage and execute these rules and allows integrating the rules execution within Case Manager tasks. The three ILOG modules Rules Studio, Rule Execution Server and Rule Team Server (see diagram below) can be installed on one server or they can be distributed to multiple machines. Page 10 of 64

11 Figure 4 - ILOG JRules architecture and how to use The Eclipse based Rules Studio is required to define the rule data-model, rule structure, rule flows, and rule verbalizations. Rules Studio can also be used to define the rules. The rules are then processed on the Rules Execution Server. Rules Team Server is required when business users need to dynamically access and update the business rules. It provides a user interface to access rules definitions manages role based access to rules, controls and audits changes and manages the deployment process. The rules are stored in the Rules Team Server db repository, more details are described below. ILOG JRules Architecture IBM WebSpehere ILOG JRules is a comprehensive Business Rules Management System, which comprises of three main components: Rule Execution Serverr (module Rule Execution Server ) Central Rule Repository (module "Rule Team Server ) Rule Editing and Testing Tools (module Rule Studio ) Each of these components will be described in more details in the following sections. Rule Execution Serverr The Rule Execution Server is responsible for all runtime aspects of the execution of business rules. This includes the actuall execution of the rules, i.e., the evaluation of the rules, depending on the data the rules operate on. All rules are grouped in so called Rule Sets which in turn are bundled in dedicated rule set containers, so called Rule Applications. The Rule Execution Server can maintain multiple versions of individual applications simultaneously. To this end, the Rule Execution Server maintains a repository of Rule Applications where they can be deployed to from other tools. Being the execution unit, the Rule Execution Server can also feed the Decision Warehouse, a store where the decision trail can be stored, documenting the rules being executed, the order in which they were executed, as well as the data that was being utilized in the decision process. The Decision Warehouse is highly configurable and can be adapted to individual needs and requirements. This feature is particularly interesting for compliance conformance. Page 11 of 64

12 Finally, the Rule Execution Server offers several interfaces to access the individual Rule Sets, exposing them as Transparent Decision Services which can be consumed in a SOA like service fashion. If it was to be described in very simple terms, the Rule Execution Server is the centralized Business Rule Execution engine, sometimes abbreviated as BRE. Central Rule Repository The Rule Repository, tagged Rule Team Server Repository in the architecture picture, stores all artifacts related to rule development and governance. The rules that are stored in this repository can be then exported to the Rule Execution Server where they can be made available for execution. The purpose of the central repository is to provide a centralized place where rules can be stored, augmented with metadata (e.g., an expiration date ), where the change history of the rules is maintained, access to the rules is given or granted depending on a user's role and its associated rights, etc. Being a central component, this repository can be used by multiple clients, each being able to make changes that are transparent independent of the client used to access the repository. The repository plays an important role in the deployment of a BRMS solution in the sense that is makes it possible to implement a business role governance supported by dedicated tools that is not an integral part of an IT department but rather can be implemented by the business departments which can define, write, test, and deploy rules without the direct involvement of IT departments. (All of this of course only works, if the proper processes and models are in place.) Rule Editing and Testing Tools In order to fully utilize the power of the components described above, tools are needed that make use of these components. These are part of the development and authoring tools which support different user groups by providing them with different tools, if required or wanted (e.g., a business user may want to use his or her familiar office tools for rules development, whereas someone else may be absolutely fine with a browser based tool set). Irrespective of the user group, these tools need to be able to support rule definition, validation, and testing. As the rule execution needs to be put into an organized context, for otherwise it may become impossible to manage hundreds if not thousands of rules and their corresponding interdependencies, these tools need also allow for the orchestration of the rules. And finally, as rule definition, testing, and deployment is subject to some (rule) governance model, the tools need support for it as well. Needless to say, that an integration of the rule editing and testing tools with the other components needs to be seamless, allowing for a full rule lifecycle. ICMILOG Integration The ICM task implementations using an IBM FileNet Process Engine (PE) workflow are loosely coupled with the WebSphere ILOG Rules Execution server using web services calls that are implemented using PE web services invocation system steps. The following high level configuration steps are required to integrate IBM ILOG JRules with an IBM Case Manager task implementation: In Rules Studio or Rules Team Server, create the rules and deploy them to the ILOG JRules Rules Execution Server where they are exposed as Web service In Case Builder, createe the ICM task and implement the task workflow Page 12 of 64

13 In FileNet Process Designer, open the Case Manager solution and update the workflow definition for the case management task inserting the web servicess call invoking the rules execution The steps to integrate the rules execution in the task workflow are described in detail in section Integrating the Case Solution with IBM WebSphere ILOG JRules. Page 13 of 64

14 Sample Solution Scenario The sample solution implements a customer complaint management system for an airline. The simplified complaint process includes the following steps: 1. The customer calls or sends an to the agent and initiates a complaint case 2. The agent opens the case in the case management system and add the complaint document (case statuss New ) 3. A Verify Complaint task is started automatically. For our sample implementation, this task consists of a single step assigned to the Agent role to verify that the complaint is valid. The agent can either chose to close the case (case status set to Closed ) or to continue processing the case by setting its status to Verified 4. When the status is set to Verified, the task Investigate Complaint is started automatically 5. In the Investigate Complaint task, certain settlement options are automatically evaluated using the rules engine. The result of this evaluation (score, legal entitlement) is then displayed to the agent in an Investigate Complaint step assigned to the Agent role. 6. The agent has the option to either close the case in this Investigatete Complaint or mark the case as Accepted. 7. When the case status has been set to Accepted the task Settle Complaint is started. The following diagram shows possible status changes. the task sequence of the three case tasks described and the Figure 5 - Flow chart of the complaint tasks Page 14 of 64

15 The decision management system is used within the Investigate Complaint task to determine whether the customer has a legal entitlement to receive a compensation based on his complaint what his score is, whereby the score determines the range within the agent can decide whether and how to compensate the customer (for example by granting him additional bonus miles, vouchers, etc.). The higher the score, the more options for compensation the agent will have Input for these rules will be the case data entered in the Complaint Verification phase (as for example the type of complaint, the flight delay, etc.). In the sample implementation, the agent also has to enter customer related data like total miles, customer status, etc. thesee values would be retrieved from a backend db system in a real live solution implementation. Page 15 of 64

16 Implementing the ILOG JRules Solution The following steps are required to implement the ILOG JRules part for the airline complaint case management sample scenario: 1. Create Project Workspace 2. Create Rule Project 3. Define In and Outcomes 4. Define Rule Packages and Business Rules 5. Create Rule Flow a. Create Rules b. Create Decision table 6. Create RuleApp 7. Deployment 8. Technical validation a. Rules Execution Server b. e.g. SOAP UI Selecting the Project Workspace In the "Rule Studio" select or create a new workspace as the current project environment. This step is not necessary if you want to use an already existing workspace. However, if you start Rule Studio for the very first time, you will be asked for the location of a workspace unconditionally. Figure 6 - Choosing a workspace After the project workspace has been created or selected, Rules Studio opens its main window. Users used to the Eclipse product will find the layout familiar and intuitive to use. Page 16 of 64

17 Creating the Rule Project Figure 7 - Main window of "Rules Studio" Now that the project workspace has been defined, the next logical step is to create the actual rules. To this end, we need to create a so-called Rule Project which will contain all artifacts of an ILOG JRules solution. In addition, each Rule Project defines a Rule Set, which is the smallest collection of executables artifacts. A Rule Set is defined by its input and output parameters and includes the actual logic to perform the business rule execution. The latter is also called the Orchestration of business rules. To create a Rule Project, select New from the File menu. From the choices given, select Rule Project which will open a new project wizard which will guide you through the process of creating a new rule project. Figure 8 - New "Rule Project" Wizard Page 17 of 64

18 The wizard offers several choices of which the first, Standard Rule Project, is the one that is wanted. 1 After the project type has been selected, a click on Next presents the next screen. On this screen, you can enter the name of the rule project. In our example, we used the name CSMAL Rules as the project name. Figure 9 - Providing a name for a Rule Project The following pages of the wizard are for the more experienced user wheree she or he can provide additional information for the creation of the project. Clicking Finish is a viable option for the scenario set forth in this document. This action creates the actual project, including all necessary artifacts, and opens the perspective to work with rule projects. Figure 10 - "Rule Studio, main screen After this step, the parameters, the rule orchestration logic, and the actual rules can be defined. This is done in the following sections. Defining Input and Output Parameters All rules work on so-called facts 2 which need to be made available by some means to the rule engine that is executing thesee rules. The easiest way to make them available is to declare input 1 The Hello World Project is a simple project that says Hello and helps to get started, while the Rule Project with a BOM creates a more complex project with an embedded Businesss Object Model, BOM. 2 The term fact is used in the academic world and by some other tools. In ILOG JRules, these are called Business Objects. Page 18 of 64

19 and output parameters for a rule project. This way, the ruleset that is represented by the rule project will receive the parameters defined as input and return the parameters defined as output. One can think of it as a service. In order to define these parameters, select the rule project and right-click. This opens a context menu, where you can perform many actions on this project. To define the input and output parameters, select Properties, which is located at the end of the menu. This opens a new window, where different properties can be selected on the left hand side of the window. The ruleset parameters are definedd through the Ruleset Parameters entry. Figure 11 - Defining input and output parameters In the window that is displayedd on the right side of the screen, you can add, edit, or remove either input or output parameters. For our example, we will define the following input and output parameters: Name miles status complainttype delay score entitlement Type int java.lang.string java.lang.string int int boolean Input, or output, or both input input input input output 0 output Default value False Table 1 - Input and output parameters Verbalization miles flown the status the complaint the flight delay the score the legal entitlement Page 19 of 64

20 Of special interest is the last column in this table: the verbalization. It defines the representation of the parameter (name) in the business rules. This will become clear when the business rule are written. Define Rule Packages Before we can create a Ruleflow we need to define the Rule package and the Business Rules which will help us to better structure the project. Open the project and right click on the rules folder. From here, select New and Rule Package, and follow the wizard to create the individual packages. The following packages need to be created: 1. initialization 2. investigation a. initialization b. entitlement c. score d. finalization 3. refinement Defining the Rules It is now time to define the actual rules. Business rules describe in non-technical terms (business language) a condition that needs to be satisfied in order for some action to be executed. They follow a simple if then pattern. 3 Business rules are created in rule packages which we have created in the previous section. Again, wizards help us to create such rules. The following two figures below show two business rules, each having a descriptive name. Please note the terms that are used to define the rules and compare them to the verbalized input and output parameters. Beneath the 1. initialization rule package we define the business rules (select right click New Business Rule): init entitlement o Code: then set 'the legal entitlement' to false ; init score o Code: "then set 'the score' to 0 ; Beneath the 2.b investigation.entitlement rule package we define the business rules (select right click New Businesss Rule): baggage loss o Code: if 'the complaint' contains "Baggage Loss" then set 'the legal entitlement' to true ; flight delay o Code: if 'the complaint' contains "Flight Delay" and 'the flight delay' is at least 5 then set 'the legal entitlement' to true ; 3 This is not completely true. There are also if then else patterns and some more choices. However, for the sake of simplicity, the if then pattern will suffice. Page 20 of 64

21 Figure 12 - Business Rule "Baggage Loss" Figure 13 - Business Rule "Flight Delay" Page 21 of 64

22 Creating a Decision Table Beneath the 2.c investigation.score rule package above we define a decision table (select right click New Decision Table): status Business rules can also be described as so-called Decision Tables. This format is particularly suited when several rules have the same structure but differ only in selected parameters. In a Decision Table, each row describes a rule, whereas each column defines a parameter. What makes Decision Tables so powerful is that the actual values for the parameters need not to be set: in this particular case, the corresponding part of the rule is omitted from the rule. So our first column named Status (Condition Column) has the Condition Definition applied o 'the status' contains <a string> So our second column named Miles (Condition Column) has the Condition Definition applied o 'miles flown' is <a number> Our third column named Score Bonus (Note: This is our Action Column) has the Action Definition applied o set 'the score' to ( 'the score' + <a number> ) The following figure shows our Decision Table status. When the cursor is places over a row number, the actual rule is hovered. Figure 14 - A "Decision Table" Page 22 of 64

23 Creating the Ruleflow Now that that inputs and outputs have been defined, the business rules and our decision table it is time to define the Ruleflow which describes how the rules, which will be organized by packages, are executed. The ruleflow defines the execution logic using the following features: it has a start and stop point is can include branching it can be nested The tasks that are to be executed by the rule flow, the so-called Rule Tasks, comprise of either individual rules, or packages, or combinations of both. In order to define the rule flow, select and right click the rule project, select New and then Ruleflow. A new window opens, the Ruleflow Editor where you can define the ruleflow itself. The following figure depicts the result of the ruleflow definition. The rule tasks have been defined by dragging the individual packages onto the editor s pane. In our case the packages: 1. initialization 2. investigation (nested ) a. initialization b. entitlement c. score d. finalization 3. refinement Figure 15 Our main investigation Ruleflow with nested investigation Ruleflow Page 23 of 64

24 Figure 16- The nested investigation Ruleflow Creating a RuleApp The RuleSet, as described by the Rule Project, is the smallest executable unit. However, in order to be executable by the Rule Execution Server, it needs to be packaged into so-called RuleApp s. One RuleApp can contain one or more RuleSets. The creation of a RuleApp follows the same pattern as the creation of a Rule Project. A wizard can be started from the File menu, selecting New and Other. This will list all artifacts that can be created using the New -wizards. Select RuleApp Project from the list to continue. Page 24 of 64

25 Figure 17 - Creating a "RuleApp Project" As with a Rule Project, a RuleApp Project needs to have a name. For the example, we chose CSMAL RuleApp and click Next. Figure 18 - Giving a "RuleApp Project" a name This will open a new wizard window where Rule Projects can be selected. Click Add and select the Rule Project CSMAL Rules. Page 25 of 64

26 Figure 19 - An empty RuleApp Figure 20 - Selecting a Rule Project for a "RuleApp Project" Now, the Rule Project is included by the RuleApp. Page 26 of 64

27 Figure 21 - A "RuleApp Project" definition after a "Rule Project" was added Clicking on Finish finally creates the RuleApp Project. The result is shown the following picture. Figure 22 - The workspace with two projects If required, additional Rule Projects can be added to the RuleApp Project later. Deploying the RuleApp Now that the RuleApp has been prepared, it can be deployed to the Rule Execution Server, RES. The basic steps are very simple: a reference to the RES needs to be defined and thereafter, the RuleApp can be deployed. Page 27 of 64

28 Deploying a RuleApp means to transfer all artifacts that make up a RuleApp. This includes all RuleSets that are defined by rule projects. To deploy a RuleApp, you can either either open the file archive.xml in the RuleApp Project and to click on the Deploy link on the right pane, or right-click on the RuleApp Project and select RuleApp and Deploy. Both alternatives are depictedd in the following figures. Figure 23 - Deploying a RuleApp from the RuleApp manager Figure 24 - Deploying a RuleApp from the context menu Both alternatives start the same deployment wizard which asks for a version numbering scheme first. Page 28 of 64

29 Figure 25 - Selecting RuleApp versioning scheme RuleApps are versioned by the Rule Execution Server, and more than one version of a RuleApp can be deployed at any time. Each version number consists of a version number of the RuleApp itself and of version numbers of the referenced rulesets. Each version number has a major and a minor number part, e.g., 2.1, where the 2 is the major part while the 1 is the minor part. For the sake of simplicity, we select the first option which increments the RuleApp major version. Hence, if the previous version of the RuleApp were 2.1, the new version would start with 3. After the versioning scheme was selected, the next step is to choose the RES where to deploy the RuleApp to. Figure 26 - Choosing an RES for deployment Keep or select Create a temporary Rule Execution Server configuration: as the local Rule Execution Server installation and enter the corresponding user credentials for interactively logging into the RES. Page 29 of 64

30 The values presented by the wizard are the default values which can be used if the deployment of the RES was done without changing of any of the values that can be tweaked during the installation. Note: If you perform this step for the first time, you may be asked if the changes you made to the configuration of the RuleApp Project are to be saved or not. Please do so. The deployment of the RuleApp is is quick process that finishes usually within a few seconds. During the deployment, statuss messages are displayed in the Console view. Figure 27 - A successful RuleApp deployment A successful deployment may look like the following code snippet. The "CSMAL RuleApp" RuleApp project was successfully deployed on the "temporaryserver"" configuration. /CSMALRuleApp/1.0 -> /CSMALRuleApp/2.0: Version changed and element added /CSMALRuleApp/1.0/CSMALRules/1.0 -> /CSMALRuleApp/2.0/CSMALRules/1.0: Version changed and element added Validating the Rule Execution Environment The Rule Execution Server can expose the deployed RuleApp as a Web service, i.e., it automatically generates a WSDL file and implements the actual service itself. This is sometime very useful, particularly for testing purposes. To validate the deployment of the RuleApp and to ensure that the deployment has been really transferred, the WSDL can be retrieved, a technical test (not functional) can be started. Using tools like soapui ( even simple unit tests can be implemented this way. The easiest way to verify that the RuleApp has been deployed properly is to login into the Rule Execution Server and to look up the application using the RES s console. Page 30 of 64

31 To this end, start a Web browser and point it to the RES URL, which is by default. 4 As the RES Console uses a role model for its components, a user needs to log in and to provide proper credentials. In the following sections, we logged in as the RES s administrator, resadmin. Figure 28 - Logging in into RES After access to the console has been granted, the RES Explorer is displayed. There are several tabs, of which the Explorer will guide us through the application. Figure 29 - Main screen of the RES Console To this end, expand the RuleApp folder on the left hand side of the screen. This displays all RuleApps that are deployed, together with their version number. Below the RuleApp folder, each ruleset that is included in the RuleApp, is displayed. We can see that the CSMALRules ruleset is deployed. In order to verify the WSDL, we open the ruleset by clicking on its link. 4 This is same URL as the one used by the Rule Execution Server configuration during the deployment of the RuleApp. Page 31 of 64

32 Figure 30 - A ruleset in the RES Of particular interest are the two lines Get HTDS WSDL for the ruleset version Get HTDS WSDL for the latest ruleset version which will retrieve the WSDL files for this ruleset. The difference between the former and the latter is that the latter will retrieve the most up-to-date version of the ruleset in the selected RuleApp version, whereas the former will retrieve the exact version of the ruleset. Hint: Iterating the deployment process leads to several versions of the RuleApp-packages. You could decide whether to take the latest version or one of the prior developed applications (e.g. for troubleshooting or test scenarios). A well formatted xml-file should appear after having selected one of the above mentioned WSDL-links. Figure 31 - The WSDL of a ruleset This concludes the technical deployment test. It remains to verify the Web service communication. Page 32 of 64

33 We will now briefly show how a technical test using the soapui tool can be performed. As it is outside of the scope of this document to describe how to use the tool, we just j show the relevant picture which shows the result of a request to be sent to the Rule Execution Server and the result of this request. Figure 32 - Testing the ruleset using a SOAP testing tool Comparing the results with the input and the rules defined above, we see that the ruleset delivers the proper results. Page 33 of 64

34 Implementing the Case Solution This section describe how the Customer Management Airline solution is implemented with IBM Case Manager Builder. Open the Case Builder application in the browser (URL for the PoT VMWare used in the residency e.g. :9083/CaseBuilder/login/login.jsp) and login as an administrative user. On the Case Manager Builder start page, select "Add Solution" in the "Creating the solution" pane..we name our solution Customer Management AirLine (CustomerManagementAirLine) with prefix CSMAL.. Figure 33 Create a ICM solution with IBM Case Manager Builder Note: The final solution definition is stored in the Design Object Store. Whereby each case solution is represented by a set of files, the solution package including the: Solution Definition File (SDF) Configuration files XML files Workflow definition files XPDL files o One per case type The implementation of the scenario can be done straight forward by completing the configuration tasks in the Case Builder tabs one by one from left to right. In these steps the following solution artifacts are defined: Properties Roles Document types Personal In-baskets Case Types Defining the Case Properties Add the properties to the solution as described below. Properties without description are optional. Page 34 of 64

35 Figure 34 - Case Properties Tab The properties ComplaintStatus and ComplaintType have an associated choice list with the following values: PropertyName ComplaintStatus ItemName ItemValues New New Settled Settled Verified Verified Closed Closed Accepted Accepted Page 35 of 64

36 Table 2 Complaint Status Choice List PropertyName ComplaintType ItemName ItemValues Baggage Loss Baggage Loss Flight Delay Flight Delay Other Other Table 3 PropertyName Choice List Defining the Case Roles Figure 35 - Example of defining a property with a choice list In the sample scenario only one role is needed: Agent. A subtask of the role definition is the configuration of the role In-basket. Figure 36 - Role Definition Page 36 of 64

37 Defining the Document Types Optionally a complaint document type can be defined. Document types organize and classify the documents that belong to a case and can assign e.g. a complaint document type to start a new case or as a precondition for a task. Note: As our focus was on rules integration we decide not to require a document to run our sample scenario triggering the rules execution. Defining the Personal You have the ability to create Figure 37 Add a new Document Type In-Basket a personal In-basket for Users. Note: In our sample scenario, all task steps will be associated to the Agent role and therefore will appear in the Agent role In-basket, not in the personal In-basket. Defining the Case-Type Figure 38 - Personal In-basket In the Case-Type definition the tasks are configured and linked to the objects prepared in the preliminary stages. A case type contains tasks. A task has one or more steps that must be completed in order to complete the task. A case is not complete until all required tasks are completed or manually disabled. A case organizes all of the tasks and steps (work items in the Case Manager Client) that case workers must complete to close the case. Page 37 of 64

38 Figure 39 - Add a new Case Type Click "Add Case Type" you will get to the screen as shown below. Our case type name is Complaint Figure 40 Specify the new Case Type attributes Page 38 of 64

39 In the Properties pane add "all Properties" defined for the solution to the Complaint case type. Figure 41 Add and define properties For the view Case Data, addd all properties assigned to the case type and adjust the layout according to your needs: Page 39 of 64

40 Figure 42 Define how the Complaint properties in the Case Data View are displayed in the Case Manager Client For the views Case Summary and Case Search, add the properties you want to make visible for these views. As we are not using documents for our sample scenario, no case folders are created for the solution. Adding the Tasks In the next steps the tasks as identified for the sample scenario (see chapter Sample Solution Scenario ) are added for the case type Complaint. Hit the "Add Task" Button and create three tasks corresponding to the three phases of the example scenario: "Verify Complaint" "Investigate Complaint" "Settle Complaint". Page 40 of 64

41 Figure 43 Add Tasks When you select the pencil symbol on the right side of the task box, the task property pane will be opened. Set the task parameters as shown below for the different tasks. Page 41 of 64

42 Figure 44 Edit and define the Verify Complaint Task properties Figure 45 Edit and define the Investigate Complaint Task properties Page 42 of 64

43 For the Investigate Complaint task, the "Precondition" must be set to "A Property condition is met" and the condition ComplaintStatus = Verified needs to be added. This will make sure the task is automatically started once the Verification phase is completed. Figure 46 Precondition to start the Investigate Complaint task In our sample solution, this will be done manually by the agent, changing the ComplaintStatus property to Verified. Settle Complaint task properties: Figure 47 Edit and define the SettleComplaint Task properties Page 43 of 64

44 For the Settle Complaint task, the "Precondition" must be set to "A Property condition is met" and the condition ComplaintStatus = Accepted needs to be added. This will make sure the task is automatically started once the Verification phase is completed. Figure 48 Precondition to start the SettleComplaint task In our sample solution, this will be done manually by the agent, changing the ComplaintStatus property to Accepted. Designing the Task Workflows For each of the tasks added, the task workflows have to be defined. This is done clicking on the Open Step Editor symbol on the right side of each task box. For each of the tasks, add a Role Lane by dragging the role icon below the existing swim-lanes. Make sure the role Agent is assigned. Page 44 of 64

45 Figure 49 Verify Complaint Step Editor For each of the three tasks, add a single step in the Agent swim-lane and connect it to the Launch step. Create the following agent steps Verify Complaint for the Verify Complaint task Investigate Complaint for the Investigate Complaint task and Settle Complaint for the SettleComplaint task Example for the Verify Complaint task: Figure 50 Verify Complaint step and connection Page 45 of 64

46 For all three tasks, select the step you added to the workflow and add the available properties in the Step properties pane to the field Parameters Figure 51 Add case properties to the Verify Complaint step Click OK in the Case Properties pop-up windows, add the Responses Verified, Close and after also click OK in the Step Properties Save the solution and close the solution design page. Page 46 of 64

47 Figure 52 - Investigate Complaint step Editor For the Investigate Complaint task we add two Stub Steps (name Invoke and Assign) Implemented, see next chapter, with the Process Designer to call the Rules Engine and assign the Score and Legal Entitlement returns to our corresponding case properties. Note: You can add properties to a stub step in an application outside of IBM Case Manager, such as Process Designer. Stub steps appear only in the system swimlane. Use a connector to connect a stub step to the appropriate parts of the process. Click Validate. The steps and routes are validated and a message is displayed in the status bar. Correct any errors before proceeding. To save the task and solution, click Save Close Validate Save and Close the solution. Page 47 of 64

48 Integrating the Case Solution with IBM WebSphere ILOG JRules Now the the rules invocation step needs to be inserted in our Complaints case task workflow definition. This webservice invocation is implemented using an Invocation system workflow step in the Investigate Complaint task workflow implementation. To insert this step, the IBM FileNet Process Designer is used to edit the IBM FileNet Process Engine (PE) task workflow definition. The following high level steps are required to integrate the rules execution - Opening the Investigate Complaint PE workflow definition for editing in Workplace XT Process Designer - Enabling Direct WDSL link - Determining ILOG execution server webservice endpoint - Registering Partner Link - Adding the webservicee invocation in the workflow - Mapping of workflow parameters to webservice interface parameters - Assigning returned values to the case Opening the Workflow Definition For Editing Open IBM FileNet WorkplaceXT and start the Process Designer Figure 53 Open IBM FileNet Process Designer Open the Customer Management AirLine solution (File Solution Edit ) from the ICM Design Object Store by: Page 48 of 64

49 Figure 54 Edit a process solution definition in IBM FileNet Process Designer Figure 55 Select and Open the Customer Management AirLine Solution Definition Enabling Direct Access to WSDL Links You need to allow entering a WSDL link in the Process Designer without browsing for the WSDL using a directory registration when creating the Partner Link. To change this configuration, open the Configuration Console : Page 49 of 64

50 Figure 56 Open the Configuration Console Open the Properties page for the IBM FileNet PE region configuration: Figure 57 Open PE region Properties Switch to the Web Services tab and tick the checkbox Enable Process Designer to enter WSDL links without browsing for Web Services and select OK. Note: Close and workflow tabs if exist but not the Configuration tab! and after open e.g. the CSMAL_SettleComplaint workflow Page 50 of 64

51 Figure 58 Tick Enable Process Designer to enter WSDL links without browsing for Web Services Note: After setting the parameter, make sure to close any open workflow tabs and reopen the workflow for editing to apply the configuration change. Determining the WSDL Link For the BRMS Rule Application Open the rules execution server web console Figure 59 Sign into Rule Execution Server Page 51 of 64

52 Switch to the Explorer tab and navigate to the CSMALRules rule set in the Rule Apps tree. Figure 60 Rule Execution Server Ruleset View Select the Get HTDS WSDL for the latest ruleset version, copy the WSDL link and paste it into a text editor Figure 61 Our Rules Application WSDL link Remove the version 1.0 in the URL if you want to make sure to always access the latest Rule App version: Figure 62 - Our Rules Application WSDL link without Version Page 52 of 64

53 Verify the URL, using a browser session. Make sure the WSDL specification is displayed as shown below Figure 63 Verify the WSDL URL Adding a Web servicee Invocation Step Switch to the CSMAL_InvestigateComplaint workflow definition: Figure 64 Open CSMAL_InvestigateComplaint workflow Note: Make sure the Web Services Palette is enabled: Page 53 of 64

54 Figure 65 If not enable Web Services Palette Delete all steps accept the Launch and Investigate Complaint Step if exist. Drag the Invoke system step into the workflow map between the Launch Step and the Investigate Complaint and connect the Launch step to the Invoke step and the Invoke step to the Investigate Complaint step. Select the Invoke Step and change the Step Name to Invoke ILOG Rule : Figure 66 Enter Step Name of the Invoke step Registering Partner Link Switch to Workflow Properties Web Services Partner Links. Page 54 of 64

55 Figure 67 Create a new Partner Link in the Web Services pane Create a new partner link. Specify the name ILOGInvestigationRule and tick the checkbox Invoke. Enter the WSDL link you prepared in the previous steps, ses Figure 62 above, into the field WDSL URL. Make sure DecisionServiceCSMALRules is selected as Port Type! Figure 68 Enter Web Service WSDL URL Select Invoke ILOG Rule step General select the Partner Link ILOGInvestigationRule you created in the steps before and select the operation executedecisionservice Page 55 of 64

56 Mapping of Workflow Parameters Figure 69 Select Operation executedecisionservicee Not all in and out parameters for the rules web services interface need not be mapped to data attributes that have been defined in Case Builder. Nevertheless all webservice interface parameters must be mapped to some workflow fields in the invoke step settings. Therefore additional local workflow attributes need to be defined for the following parameters that do not correspond to case fields: Outgoing Parameters: o DecisionID Incoming Parameters: o Ilog.rules.outputString o Ilog.rules.firedRulesCount o DecisionID Parameters to the Web service Interface Page 56 of 64