Reusing client-side human services
To break down a client-side human service into meaningful subflows that can be separately managed and reused in different contexts, you can define the reusable subflows as nested client-side human services.
About this task
You can reuse the nested services in other client-side human services, which can be either top-level, root client-side human services or other nested client-side human services. Root services can contain one or more single- or multi-layered nested services.
When you build the service logic for your tasks or instance user interfaces in the IBM® Process Designer web editor, you might want to reuse common steps that are defined in other client-side human services. For example, creating an insurance claim might include a common set of steps. If you define the steps in a nested client-side human service, you can reuse them in other client-side human services. At run time, the nested client-side human service or services run as part of the parent root service.
When you create a client-side human service, you can specify whether it can be used as a nested service or as a root service. You can revisit the selection that you made in the Overview tab.
- Usage settings
- The usage settings of a root client-side human service depend on its intended purpose, and you can specify them in the Overview tab. The Use as setting is disabled for nested services because the configuration of a nested service is tailored for reuse. To ensure that the behavior of the root service is consistent at run time, in the nested service use elements that are compatible with the specified usage type of the root service.
- For more information, see Defining usage settings for client-side human services.
- Variable scope
- In a hierarchy of nested client-side human services, variables are defined in isolation and are not automatically shared between the parent client-side human services and their nested services. To pass variables between a parent client-side human service and its nested services, you must set the data mapping. For more information, see Data mapping for nested client-side human services.
- For input and private variables that you define for either root or nested client-side human services, you can specify default values that take effect at run time. For the default values, you can specify both simple and complex values, as well as arrays for lists. Optionally, if you have environment variables or exposed process values (EPVs) that you want to use in your client-side human service, link them to the client-side human service in the Variables tab. See Declaring variables.
- Stay on page behavior
- When you use a stay-on-page event in a nested client-side human service, based on the logic that you defined, the stay-on-page behavior can loop the service diagram back to the last displayed coach, which can be either in the same service as the stay-on-page event or in an ancestor client-side human service.
- Error handling
- Error event handlers that are defined in a hierarchy of nested client-side human services are not visible to all the services in the hierarchy. An error event handler that is defined in a nested client-side human service catches errors from the service in which it is defined and from all the nested services below it.
- When an error end event is used in an error event handler in a nested client-side human service, it ends the flow of the nested service, but the execution of the parent service continues. If the client-side human service is used in a root process, the error end event propagates the error data all the way to the process. An error intermediate event that is set up at the process level can catch the error that is thrown by the error end event that is defined at the human service level.
- For more information about error handling in client-side human services, see Handling errors in client-side human services.
- Data change handling
- When client-side human services contain one or more nested client-side human services, only the root-level data change event handler is used. If the data change event handler in a nested service is bound to any coach views, you can redirect those bindings to the root data change event handler by selecting Trigger the root data change event handler in the Implementation details of the nested service activity.
- In the implementation properties of the data change event handler, the Behavior section lists all the coach boundary events in the current client-side human service that can trigger the root data change event handler. If there are nested services that have Trigger the root data change event handler selected, they are also shown in the Behavior list.
- Using the data change properties of a coach, you can perform client-side validation of the coach contents or control a button enablement through a conditional variable. To do that, you can add a fast-executing client-side JavaScript that has validation script logic that reacts to data changes in the coach. For more information about data change handling in client-side human services, see Validating coach data without exiting a coach.
The following procedure describes how to nest a reusable client-side human service in another client-side human service. A step-by-step example is also provided.
Procedure
To nest a reusable client-side human service in another client-side human service, complete the following steps:
onto the canvas and wire it as required
in the root service.