Adding the Coach to activities
- Add a Coach for the Submit Request. According to best practice,
name this Coach as
Submit Request, as shown in Figure 5.
Figure 5. Submit Request Coach’s flow diagram
The purpose of the Submit Request activity is submitting a request, which means you have to populate values for the request data as shown in Figure 6 via the user interface (web). The next step is building a Coach for the Submit Request.
Figure 6. Submit Request Coach’s variables
- Design the Submit Request Coach UI as shown in Figure 7.
Figure 7. Submit Request Coach UI
The Request Description has the number for the row, which is 4.
You can drag and drop the variables into our Coach Design window. In this tutorial, there is a variable named
request,which you drag to the Coach. Lombardi Edition automatically generates the graphical user interface (GUI) for you. With a little customization on the GUI, you can have a friendly user interface.
- Add the script shown in Listing 1 into the Setup activity.
Listing 1. Code for the Setup activity
CODE LINE 1 tw.local.request.requestorId = tw.system.user_loginName; CODE LINE 2 tw.local.request.requestID = tw.system.currentProcessInstanceID;
- Attach this newly designed coach to the Submit Request activity,
if you have not done this yet. Map the process application's data
to the Submit Request Coach's data: input and output to
- Add the Coach to the Review Request activity. Create another new
Review Request, as shown in Figure 8.
Figure 8. Review Request Coach diagram
- For the architect data of this new coach, you need to define the
data required for this coach, as shown in Figure 9.
Figure 9. Variables
- Add the implementation for the Init Response. You need to
initialize the response data. The requestID is assigned to the
requestID of request. The response's reviewerID is assigned to the
loginned(see Listing 2).
Listing 2. Code for Init Response
CODE LINE 1 tw.local.response.requestId=tw.local.request.requestID; CODE LINE 2 tw.local.response.reviewerId=tw.system.user_loginName;
- Design the Review Request Coach as shown in Figure 10. You need to
design a GUI for the user to interact with during the Review
Figure 10. Review Request Coach design
With this design, the response data will be populated when the user clicks on the Reject or Approve button. Therefore, you need a script to handle this and to re-modify the diagram (Figure 11).
Figure 11. Review the Request diagram
Reject Decision components. See Listing 3 and Listing 4 for the JS
Listing 3. Code for Approve Decision
CODE LINE 1 tw.local.response.decision = "true";
Listing 4. Code for Reject Decision
CODE LINE 1 tw.local.response.decision = "false";
- Attach this coach to the Review Request activity, if you have not
done so already. Remember to map data for this
activity and its coach.
You have just finished with the Review Request activity. The next step is to implement the Review Result activity.
- Add the coach to the View Result activity. You need to create
another new coach for the View Result activity (third activity) so
that the user can view his request's result after proceeding with
the reviewer. Name this new Coach as
Review Result. See Figures 12, 13, and 14 for details of the Review Result Coach.
Figure 12. Review Result Coach diagram
Figure 13. Architect data for Review Result Coach
Figure 14. Coach design of Review Result Coach
- The Request Description has a number for the row as 4.
- The decision is a combo box, not a check box.
- Attach this new coach to the View Result activity, if you have not done so already, and map the data for this activity and its coach. You can now run a test with this BPD.