![Close [x]](http://dw1.s81c.com/i/c.gif){kind=small}
Using the Process Designer
Extending the template using Process Designer
As the business analyst is implementing the solution, there will be instances where he will need to use Process Designer to implement additional required features. For this template, we have used Process Designer to integrate an eForm into the UI. Also, Process Designer is used to integrate ILOG JRules into the solution, which is discussed in more detail later in this tutorial.
Opening a solution in Process Designer
It is common to use functions or system fields to set values for case properties. To accomplish this, you must step outside of the Case Builder to work in Process Designer. Fortunately, there is good integration between these tools to make this transition seamless.
There are a few things you should be aware of as you move between Case Builder and Process Designer:
- Before opening a solution in Process Designer, make sure you have saved and closed the solution in Case Builder. You are likely to overwrite changes if both tools have the solution open. Make sure your solution doesn't appear as "checked out" before opening it in Process Designer.
- When opening the solution in Process Designer, make sure you
use the File > Solution > Edit menu
option.
Figure 12. Editing a Case Manager Solution in Process Designer
Navigate to the Solution directory, and select the Solution Definition file (shown in Figure 13) so the entire context of the process aspects of the solution is provided to Process Designer.
Figure 13. Editing a Case Manager Solution in Process Designer
- Case properties are referenced by their symbolic names in Process Designer. This is actually true anywhere outside of Case Builder. As an example, if your Auto Claims solution has a solution identifier of "AC," then all properties, document types, roles, etc. will have a prefix of "AC_." The symbolic name of a PolicyNumber property defined in Case Builder would be AC_PolicyNumber (note the case-sensitivity and removal of spaces).
- Case properties, case instance properties, and workflow data fields are different entities. As described earlier, when a case type is defined in Case Builder, it is modeled as a case folder in the FileNet P8 Content Engine. When you define a property within a case type, it is modeled as a property of the case folder. This is where property values for a case instance are persisted. Workflow data fields must be initialized with the case data properties. Case Builder does this for you automatically, but when you are using Process Designer to create steps, you must do this manually.
Let's look at an example.
Figure 14 shows the last three steps of the record claim task after importing the solution into Process Designer. It shows the step where the CSR completes the set of data for the execution of the claim case, a system step in which ILOG is invoked as a web service, and the step where the claims adjuster takes ownership of the claim. The field assignment is executed before the claims adjuster executes the last step.
Figure 14. Copying a property value to a case property
Our goal is to instantiate the evaluate potential fraud task, based on the outcome of a rule executed by ILOG. We created the evaluate potential fraud task as an automatic task and gave it the following precondition:
AC_FraudCheckRequired = TRUE |
When working in the Process Designer, the case property AC_FraudCheckRequired is available as the following, since case properties persist as properties of a case folder:
F_CaseFolder.AC_FraudCheckRequired |
So we need to set the value of the case property F_CaseFolder.AC_FraudCheckRequired by using the following assignment:
F_CaseFolder.AC_FraudCheckRequired= AC_FraudCheckRequired |
(Refer to Figure 14.)
Extending Auto Claims in Process Designer setting in-basket properties
Within Auto Claims, the customer service in-basket looks like Figure 15.
Figure 15. The columns of the CSR in-basket
The values for column Work Item is populated by manipulating case properties within Process Designer on a step-by-step basis. To see how this is done, consider the create estimate task flow.
Figure 16. Assigning property values in Process Designer
The review estimate step is selected, and we are looking at the assignments that occur after the step is completed. The work item property is highlighted (note the symbolic name is used: AC_WorkItem). In this example, we are updating the value of the work item property, based on the case worker's response when completing the step review estimate:
If(F_Response="2nd opinion", "Damage Estimation Request","Initiate Repair") |
