WebSphere Business Modeler V7.0Modeling case management WebSphere Business Modeler V7.0 Modeling case management This presentation provides a discussion of the new features in WebSphere Business Modeler V7 to support case management modeling. Goal Goal Provide an understanding of the new Case Management modeling features available with WebSphere Business Modeler V7 Provide an understanding of the new Case Management modeling features available with WebSphere Business Modeler V7 Agenda Agenda What is case management How it is implemented in WebSphere Business Modeler V7 Collaboration scopes and case folders Example In this presentation you will learn about what case management is and how it is implemented in WebSphere Business Modeler and WebSphere Integration Developer V7 Case management Case management A dynamic workflow pattern The result of human interactions A workflow is typically laid out at design time, using a tool such as WebSphere Business Modeler In some cases the flow of the work is not predictable. The flow depends on information coming from the people involved in doing the work Example: A patient in the hospital Sees many different doctors, has tests, accumulates expenses, and so on. Each procedure is documented and added to the Case Folder. Allows the different people working with the patient to collaborate The order in which the patient visits the different medical departments is not fixed Case management is a work flow pattern that involves human interactions. It is very dynamic, the order in which the tasks get done is not fixed. There is often a typical flow that can be captured, but depending on the actors and the context, the flow can go in different directions. The example shown here is one of a patient going to the emergency room. The patient is checked in at the reception area. Their charts are pulled from the archives or a new one is created. During the course of their visit they are seen by nurses, doctors, and technicians. As the information is gathered, it is added to their chart. Each nurse, technician or doctor reviews the available information, adds to the chart and makes decisions about where to send the patient next. The course the patient takes through the system is not predictable. Requirements for dynamic human workflow Requirements for dynamic human workflow More Examples: A patient in the hospital An accident being reported to an insurance company A customer portfolio with a financial institution Problem resolution What’s needed A place to keep the shared data The case folder abstraction Add arbitrary pieces of data to the folder Attached documents Ability to redirect the flow easily The collaboration scope Move back to a previous task Skip over a task that has been done or is not necessary anymore Redo a task that was already done Collaboration adornment Case xyz What do you need in order to support this particular work flow pattern? Consider a few more examples. There is the patient in the hospital, then there are the accident reporting, financial reporting and problem resolution scenarios. What do these all have in common? The first thing that is needed is a place to keep the shared data. The data are not necessarily in a common standardized format. It might be that they are pictures, photocopies of documents, or links to Web sites. Then there must be a way to let the human actors in the scenario control the flow of the business process. In the classical work flow system, this is done by the work flow engine. What is needed is a way to let the actors temporarily drive the work flow engine. The shared data is managed by using a ‘case folder’ abstraction. A case folder is a predefined data type that you can use to attach documents related to the business process. The data can be easily accessed by each task and each task can contribute to the information in the folder. Managing the dynamic aspect of the business process is done using a collaboration scope. A collaboration scope is a technical feature associated with a sub-process. Within the collaboration scope, the actors can redirect the flow to a previous task, skip a task or redo a task. Managing this behavior is a function of the runtime, therefore in modeler, it is a matter of declaring the collaboration scope. You can easily identify a collaboration scope in a process diagram by the bi-directional arrows that become part of the icon for the sub-process element. The case folder and collaboration scope The case folder and collaboration scope A folder abstraction is used to collect data at each step such that it is available for all subsequent steps. The data are not structured or defined by the business process per se. They are documents or images that can be referenced by a URL link An alternative is to use a local repository for the tCaseFolder Continuing with the hospital emergency room example. Shown here is a general flow for a visit to the emergency room. This is a typical flow that might happen. After the triage, the X-Rays might be skipped but something shows up later, during the evaluation task, that indicates X-Rays are needed. The doctor doing the evaluation can redirect the patient to X-Ray and when that is done the lab work can be skipped, because it was already done. When the x-rays are done, they are available electronically by way of a URL that is attached to the case folder. There are several points to make here. This is a special kind of sub-process called a collaboration scope. You can tell by the bi-directional icon on the lower boundary of the sub-process. The input to the collaboration scope uses the predefined case folder. This is only necessary if you want to attach unstructured data or documents that are not defined by the business process. This means that you don’t have to plan and design for every possible data type that might be used throughout this part of the process. As an example, think of how you might share the x-rays which are much different than the lab reports. And for sure, their formats will change over time and new types are introduced to the business process. The predefined case folder type is not mandatory and does not have to be exposed at the top level as shown here. It can be nested in a complex object such as the ERSummary. The details of this special, predefined object are discussed on the next page. Importing the tCaseFolder predefined type Importing the tCaseFolder predefined type First you need to import the special predefined type To use the predefined tCaseFolder you first need to import it into your project. The link to invoke the dialog for importing technical types is available from the ‘type selection’ dialog that you use when setting the type for an attribute. It might not be apparent that it is a link, but it is. Here, it is highlighted with the red circle. Once you select the type you want, it is imported into your project and placed in a folder called, ‘Predefined business service objects’. Once it has been imported you use it as any other type. So, what does this tCaseFolder type look like? Using the case folder Using the case folder The data structure and the resulting form. Intended to be used with a user task The details of the tCaseFolder object are shown in the screen capture on the upper right. The main attribute is called ‘attachment’ and it has two attributes, ‘attachmentInfo’ and ‘value’. The details of the structure are not really designed for human consumption. The second screen capture, on the bottom, is the default form that is created for the tCaseFolder type. Here you can see the fields that you need to work with. The add and remove buttons are clues that the structure is a array. Using these buttons you can very easily add or remove elements to the array. At each task within the collaboration scope you can choose to add one or more attachments. The three fields are all mandatory. The first one is the label, the second is the universal resource locator that points to the document location. And the third field is so you can keep track of who attached the document to the business process. Collaboration scopes Collaboration scopes Used to create dynamic human workflows Introduced with WebSphere Integration Developer and WebSphere Process Server V6.2 They can now be modeled using WebSphere Business Modeler and the proper constructs are generated when imported into WebSphere Integration Developer V7.0 To create…. Set the modeling mode to WebSphere Process Server Edit the general section of the Technical Attributes properties of a subprocess Semantic constraints and validation are applied Cannot contain Local Subprocess Loops Join/Fork gateway The collaboration scope is a runtime concept that was introduced with WebSphere Process Server and WebSphere Integration Developer V6.2. It is designed to support dynamic human workflows that we’ve been describing. With WebSphere Business Modeler V7, the business process modeler has been enabled to use this feature also. It is intended to fill out the support for the IT-hand-off and modeling-for-execution scenarios. To use this feature you must first be in the WebSphere Process Server modeling mode. Next, you select the local sub-process and go to the ‘technical attributes’ tab. Here you’ll see the check box that will allow you set your sub-process as a collaboration scope. Because of the dynamic nature of this feature there are a few constraints you’ll have to work with. You cannot have local sub-processes, loops or parallel branching within your collaboration scope. The modeling editor checks for these conditions and will flag them as errors if you have any of them in your collaboration scope. Example of using a collaboration scope Example of using a collaboration scope You can test your business process using the Business Process Choreographer Explorer or by using the interactive process design feature of WebSphere Business Modeler Using interactive process design: Verify Process Design… Use the ‘Step Through Human Workflow’ widget To work with the collaboration scope you use the ‘step through human workflow’ widget. If it is not displaying your process flow, select the task in the ‘claim available task’ widget. Don’t claim or edit it there. Selecting it will refresh the widget as shown here. The green background defines the collaboration scope. The check mark in the first screen capture shows that the triage task has been completed. To move to the next step you select the task icon and the pop-up menu is displayed. You have the option of skipping the x-rays and going straight to the lab. To claim the task you select edit, fill out the form associated with the user-task and then submit it. If you need to go back a step, in this case to the triage step, you select the task icon and you’ll see that the pop-up menu now shows the redo option as well. You select redo and then select it again to get the edit option. It is a two step operation. Summary Summary What is case management How it is implemented in WebSphere Business Modeler V7 Collaboration scopes and case folders Example In this presentation you learned what case management is and how to use it in WebSphere Business Modeler V7. There are two parts, the collaboration scope, which defines the boundary and imposes certain constraints, and then there is the case folder. The case folder is optional and is used for collecting and sharing unstructured data, such as documents or images. You also learned how to configure and use these new constructs in your business process models. Feedback Feedback Your feedback is valuable You can help improve the quality of IBM Education Assistant content to better meet your needs by providing feedback. Did you find this module useful? Did it help you solve a problem or answer a question? Do you have suggestions for improvements? Click to send e-mail feedback: mailto:iea@us.ibm.com?subject=Feedback_about_WBPMv70_Modeler_Case.ppt This module is also available in PDF format at: ../WBPMv70_Modeler_Case.pdf You can help improve the quality of IBM Education Assistant content by providing feedback. Trademarks