IBM BPM, V8.0.1, All platforms > Create processes in IBM Process Designer > Create user interfaces for business processes

Building Coaches

You can build a Coach as the user interface that process participants use to interact with a service.

In the first stage of designing a Coach, your goal might be to build a mock-up. The mock-up contains static elements to visualize what data the Coach needs at run time and where the Coach displays the data in its layout. After you complete the first stage to design the look of the Coach, you need to feed real business data to the Coach controls. This step requires you to create bindings between the Coach controls and the data structures (variables) that represent the business data in your IBM BPM processes. Your process participants can then interact with the business data, which helps them make the appropriate decisions.

Building a Coach is often an iterative process in which you loop back to refine the Coach as you build it. Although you can do some of the steps in any order, in general you take the following steps:

1. Create one or more mock-ups for the Coach. Use the mock-ups to identify elements in the Coach that are common with other Coaches. Identify the following information:

   • The elements in the Coach that are reusable.

   • The best layout for the user interface elements in the Coach.

   You can then use this information to decide which parts of the Coach you can implement as reusable Coach Views.

   For example, after creating the mock-up, you see that your Coach contains two sets of identical address fields. Instead of creating the two sets of address field in the Coach, you create one address field Coach View. You can then use it for both sets of address fields.

2. If there are toolkits that contain artifacts that your Coach can use, add a dependency to these toolkits. These artifacts include business objects, Coach Views, and files.

3. If the Coach Views that your Coach will use do not exist, create them. For information, see Developing reusable Coach Views.

4. In the human service diagram, add the Coach to the diagram and then double-click it to edit it.

5. Drag Coach Views or variables onto the layout of the Coach. These Coach Views can be the Coach Views created earlier or the stock controls. The variables are business objects and their parameters that are defined for the human service . For the variables, the Designer puts the Coach View that is associated with the business object or parameter type onto the layout.

   For example, if you drop variable that is of the String type, the Designer puts a text stock control that is bound to the variable. If the variable type does not have an associated Coach View, the Designer puts a placeholder message on the layout instead. You can then use the placeholder to manually specify the binding between the variable and a Coach View.

   For examples of dragging a Coach View and variables onto a Coach, see Example: creating a tabbed Coach.

   Tip: For elements in the Coach that you do not plan to reuse, you can drop the appropriate palette component onto the Coach.

   For example, for text instructions for the user, you can drop an HTML element and add the text as HTML code. You can also drag fields within a variable directly onto the Coach.

6. To lay out the Coach Views in the Coach, use sections.

   For example, if you want two Coach Views beside each other, drop them into a horizontal section. You can embed sections within other sections.

7. To edit the Coach View instances, select them and then change their properties.

   For example, for text fields and buttons, change the label to something useful for users. Many Coach Views contain configuration options that you can set for each instance.

8. Wire the Coach into the service flow by connecting boundary events that the Coach Views fire to the appropriate elements in the service flow. For an example of wiring a Coach, see Example: wiring Coaches in a human service.

9. To validate the data that is in the Coach before the flow proceeds to the next step in the service flow, add a validation node to the flow. The validation node can be a nested service or a server script. The server script is the simpler implementation although the nested service provides greater flexibility. In the following diagram, Coach1 is being validated by a server script and Coach2 is being validated by a validation service:

   

   The following steps describe how to validate using a server script. For information about using a validation service to validate Coach data, see Example: validating a Coach with a service.

   1. To validate the Coach data before a particular boundary event occurs, select the line for that boundary event. In the properties for the line, set the Fire Validation property to Before. The Coach has a validate icon

      to indicate that you can now connect the Coach to the validation script.

   2. Add a server script to validate the data to the human service diagram.

   3. In the validation script, provide the logic to identify problematic data. Use APIs such as tw.system.addCoachValidationError(CoachValidation coachValidation, String errorBOPath, String errorMessage) to add the error data to the coachValidation system variable.

      For example, you want two fields to have a value. They are bound to var1 and var2. To ensure that they have a value, use code like the following example code:

      if (tw.local.var1 == ""){
      	tw.system.addCoachValidationError(tw.system.coachValidation, "tw.local.var1", "Enter a value for field 1");} if (tw.local.var2 == ""){
      	tw.system.addCoachValidationError(tw.system.coachValidation, "tw.local.var2", "Enter a value for field 2");}

      The tw.system.coachValidation parameter is the system variable that contains the validation information. The first string contains the full variable path to the data element with the problematic data. The second string is the message for the user. The message should identify what is wrong with the data or tell the user how to fix the problem.

      Important:

      • A Coach can use only one validation service or server script to validate its data. However, more than one Coach can use the same validation service or script.

      • If the data element being validated is not bound to a Coach View, there is nowhere to display a validation error if one occurs.

      • If a Coach View that is being validated contains rich text, code the validation server script to remove formatting before it validates the text contents.

   4. Connect the validate icon of the Coach to the validation script.

   5. Add a Stay on Page node. Connect the validation script to the Stay on Page node. This construction loops the flow back to the Coach if the data in the Coach is not valid. The system passes error information back to the Coach and users see an indicator beside the Coach View with the problematic data. If the validation script provides error messages, users see the appropriate message when they hover over an indicator. If the data is valid, the system processes the boundary event to move to the next step.

10. In the Designer or the Inspector, click .
11. Review the Coach and update the Coach or the Coach Views that it contains until the Coach looks and behaves as you intend.

Create user interfaces for business processes

Related concepts:
Boundary events
Building Heritage Coaches
Example: validating a Coach with a service

Related tasks:
Building a Human service
Developing reusable Coach Views

Related reference:
Stock controls
Stock content controls