Today many organizations are realizing the benefits of the business process management (BPM) methodology. WebSphere Business Modeler Advanced (hereafter called Modeler) supports this methodology by enabling business analysts to document their business processes, including those containing human tasks. When these processes are handed over to a development team, the task of enhancing the model with technical elaboration can be tedious and daunting, often resulting in major changes to the business analyst model. By following the best practices and guidelines in this article, the model prepared by the business analyst can be elaborated to add technical attributes with less work by the development team, which allows both business analysts and the development team to use the same models. The article includes downloadable artifacts you can use to work through the process described in the article.
When models contain tasks that will be performed by humans, the level of granularity provided by business analysts is often high. The model tends to have a task for each step performed by a human. When the model is imported into WebSphere Integration Developer (hereafter called Integration Developer), the developers find that they can consolidate many of the steps into one "human task". This results in major changes to the base model, which creates challenges when developers try to add technical details to the model, while still maintaining its business use. Some options for dealing with this are:
- Add technical details to the existing model, which requires a lot of editing in Integration Developer.
- Create a separate model for execution, which makes it difficult to keep the two models in sync.
- Consolidate tasks in the existing model to reflect the manner in which the process will be executed. This reduces the business information captured in the models.
As you can see, each of these options has disadvantages. This article describes a process you can use to consolidate the tasks in Modeler, making it easier for developers to add all execution details to the existing model, while still retaining all the information from the business analysts.
The process used in this article is fictional and is based on a request from a credit card holder to increase his or her credit limit. Modeler V6.0.2.1 and Integration Developer V6.0.2.1 artifacts are included for download, so you can work through the example as you read the article. Although artifacts for V6.1 are not included, you can use the artifacts here with V6.1 without any loss of functionality.
To get the most out of this article, you should be familiar with BPM and have a working knowledge of Modeler and Integration Developer. Some knowledge of modeling for execution techniques is beneficial as well.
Overview of the sample human-centric business process model
To view the sample business process, import HumanTask_v1.mar (included in the download) into Modeler.
In this process, a cardholder has requested an increase to his or her credit limit. The first task is to retrieve the applicant's credit score. If the score is above a specified threshold, the credit limit is increased and a notification is sent to the applicant. The human task comes in when the credit score is below the specified threshold. The business analysts have modeled several tasks that need to be done in this case. A credit officer will review the applicant's employment history, assets, credit report and debts. Upon review of these items, the officer creates options for the applicant and calls the applicant to discuss these options. If the options are accepted, the account is updated appropriately and a notification is sent to the applicant. If the applicant rejects the options, a notification is sent stating that the credit limit increase is denied.
Figure 1 shows the business model for the Credit Increase process.
Figure 1. Credit Increase business model
In this model, the business analyst placed separate tasks for each step that a human needs to perform. Looking at this as an executable business process, all these steps happen at the same time, by the same person, and hence would be done inside one human task in the BPEL flow.
The following table describes the artifacts included in the downloadable zip file.
| Artifact | Description |
| HumanTask_v1.mar | Modeler project archive – base model |
| HumanTask_v1.1.mar | Modeler project archive – human tasks tasks classified |
| HumanTask_v2.mar | Modeler project archive – final model with Human Task process |
| HumanTask_v1_WBM.zip | Modeler Process Server export – base model |
| HumanTask_V2_WBM.zip | Modeler Process Server export – final model |
| HumanTask_v1.zip | Integration Developer project interchange – base model imported to Integration Developer |
| HumanTask_v2.zip | Integration Developer project interchange – final model imported to Integration Developer |
| HumanTask_v2.1.zip | Integration Developer project interchange – final Integration Developer project; HT component updated |
Transforming the business model to an execution model - using the existing model
Now that the business analyst has completed the business model, it's time for the developer to add technical details to this model so it can be imported into Integration Developer. Let's look at what happens if you export the existing model, with the requisite technical elaborations, to Integration Developer.
Artifacts using the existing model
Let's say the development team didn't want to alter the business model and instead added technical details to the existing model. Then they imported this model into Integration Developer to start the development work. Figures 2 and 3 show the BPEL flow and assembly diagram for this example in Integration Developer. This is represented in the HumanTask_v1.zip project interchange included in the download.
Figure 2. CreditLimitIncrease BPEL flow
Figure 3. Module assembly diagram
As you can see, there is an invoke on the BPEL flow for each task in the Model. Remember that all the human tasks are really going to be executed by one Human Task in the BPEL flow, which means a developer would have to alter the BPEL flow. The assembly diagram also has a separate component for each task and these would have to be consolidated. For releases prior to V6.1, when you import a model into Integration Developer, any changes that were made in Integration Developer are lost. Therefore, it's best to limit the changes required in Integration Developer.
Transforming the business model to an execution model - a better way
Using the steps described in the following sections, you can modify the existing business process without losing any business information, and prepare the process to be exported to Integration Developer, without requiring significant changes in Integration Developer.
- Create a classifier group with values for each unique human task implementation expected in Integration Developer.
- Classify human-related tasks in the business process appropriately.
- View the process in swimlane mode by the human task classifier you created.
- Create a new process or processes in Modeler for each human task swimlane, then replace the tasks on the main process with an instance of the new human task process or processes.
Let's walk through each step individually. HumanTask_v1.1.mar (included in the download) is the Modeling project for steps 1-3 and HumanTask_v2.mar is the Modeling project for step 4.
Step 1: Create the classifiers
The first thing to do is to create a classifier group with a values for each unique human task. In our model, there's only one human task. To create the classifier, right-click Classifier in the navigation pane and select New => Classifier, as shown in Figure 4.
Figure 4. Create classifier
In the sample, the classifier is called Grouping. Once you've created the classifier, you can create classifier values. In the navigation pane, right-click the classifier you just created and select New => Classifier Value, as shown in Figure 5.
Figure 5. Create classifier values
Since we have only one human task in our process, we created one value called HT1. When you create the classifier value, you can assign it a color so you can easily see which tasks are assigned to the same classifier in the model. In the sample, the color we chose was orange.
Step 2: Assign classifiers to the tasks
The next step is to assign the classifier to the appropriate tasks in the model. Open the process CreditLimitIncrease. For each task that will be consolidated into the human task, assign the classifier using the Classifier tab of the Attributes view, as shown in Figure 6.
Figure 6. Classifier tab
In our model, the tasks we'll consolidate into one human task are:
- Review Employment History
- Review Assets
- Review Credit Report
- Review Debts
- Prepare options for cardholder
- Call cardholder to discuss options
To have the colors reflected in the model, right-click in the whitespace of the model and select Color by => Classifier. The model will display the colors, as shown in Figure 7.
Figure 7. Model colored by classifier
Step 3: View the model using classifier swimlanes
Another way to view the tasks by classifier is to use the swimlanes. This is very useful if you have multiple human tasks that you consolidated in the same model. To view the model by swimlanes, right-click on the whitespace of the model and select Switch to Swimlane Layout by => Classifier. In the resulting window, choose the Groupingclassifier that we created.
Figure 8. Model using classifier swimlanes
Step 4: Create new human task processes in Modeler
The next step is to create a new process for each human task. In this example, you need one new process, which we call HT1_ReviewAccount. You can cut and paste each task from the HT1 swimlane in the main process to this new process, and replace these tasks in the main process with an instance of the HT1_ReviewAccount process. If you are using Modeler V6.0.2.1, you'll only be able to cut and paste one item at a time. An enhancement in Modeler V6.1 allows you to copy and paste multiple items together. Figure 9 shows the new HT1_ReviewAccount process.
Figure 9. HT1_ReviewAccount process
Figure 10 shows the revised CreditLimitIncrease process.
Figure 10. Updated CreditLimitIncrease process
For the new model, the only process exported to Integration Developer is CreditLimitIncrease. The HT1_ReviewAccount process is not exported to Process Server and is used only to capture the granular details of the human task. The business analysts can right-click the HT1_ReviewAccount task in the CreditLimitIncrease process to open the new process and see its details.
Figure 11 and 12 shows the BPEL flow and assembly diagram when you import the new CreditLimitIncrease process into Integration Developer.
Figure 11. Modified CreditLimitIncrease BPEL flow
Figure 12. Modified Module assembly diagram
In the new version, the BPEL flow now has only one invoke for the human task instead of the multiple invokes in the previous import. Since HT1_ReviewAccount was defined as a global process in Modeler, the component type on the assembly diagram in Integration Developer is a BPEL flow, and an export is generated. To switch this to a human task, right-click the component and select Change Implementation => Human Task. You can also delete the export. Figure 13 shows the final assembly diagram.
Figure 13. Final module assembly diagram
In the sample, we didn't develop the Integration Developer project any further. Here is where developers would start implementing all the services and tasks, including defining the human task, which is beyond the scope of this article.
Using the technique described in this article, you can consolidate the human tasks in Modeler, thus minimizing the changes required in Integration Developer, and at the same time retaining all the information from the business analysts. The process to achieve this, described in detail in the article, is:
- Create classifiers for each distinct human task and update all the tasks in Modeler with the appropriate classifier.
- View the model using classifier swimlanes.
- For each human task swimlane, create a new process in Modeler.
- Copy the appropriate tasks from the main process to the new process.
- Add instances of the new human task processes to the main process in place of all the other tasks.
- Create an execution model for the main process only and export it, and business items, to Integration Developer.
| Description | Name | Size | Download method |
|---|---|---|---|
| Sample artifacts | DW_HumanCentricModeling.zip | 470KB | HTTP |
Information about download methods
-
developerWorks
BPM zone:
Get the latest technical resources for WebSphere business process management zone,
including articles, tutorials, downloads, webcasts, and more.
-
WebSphere
Business Modeler V6.1 Information Center:
Get complete product documentation.
-
WebSphere
Business Modeler V6 Information Center:
Get complete product documentation.
Lori Napoli is a Certified IT Specialist at IBM. She is a consultant in Software Services for WebSphere and has more than 20 years of experience with enterprise application software and middleware development. As a consultant, she has played key roles in the architecture, development and testing of Service Oriented Architecture (SOA) and Business Process Management (BPM) projects. You can reach Lori at lanapoli@us.ibm.com
Comments (Undergoing maintenance)
Table of contents
Next steps from IBM
My developerWorks community
Tags
Use the slider bar to see more or fewer tags.
Popular tags shows the top tags for this particular content zone (for example, Java technology, Linux, WebSphere).
My tags shows your tags for this particular content zone (for example, Java technology, Linux, WebSphere).
Popular article tags |
My article tagsSkip to tags list
Popular article tags |
My article tags
