Tutorial: Credit Card Example

On this page, we take you through the basic steps involved in defining a YAWL process with control, data, and resource perspectives and demonstrate how this process can be enacted within the YAWL engine.

Specifying the control flow of credit application process

The credit application process starts when an applicant submits an application (with the proposed amount). Upon receiving an application, a credit clerk checks whether it is complete. If not, the clerk requests additional information and waits until this information is received before proceeding. For a complete application, the clerk performs further checks to validate the applicant's income and credit history. Different checks are performed depending on whether the requested loan is large (e.g. greater than $500) or small. The validated application is then passed on to a manager to decide whether to accept or reject the application. In the case of acceptance, the applicant is notified of the decision and a credit card is produced and delivered to the applicant. For a rejected application, the applicant is notified of the decision and the process ends.

Here we assume that you are familar with how to model the control flow in the YAWL and focus on the control flow of the credit application process only (See Figure1).

Figure 1: The credit application process

Specifying the data attributes

For demonstration purposes, we created three net variables, one for the loan amount (loanAmt), one to decide whether an application is complete (completeApp), another to indicate whether an application is approved (decideApp). The values for these variables can be input from the user and they are specified using task variables as shown in Figure 2. These values are then used in Xpath expressions at XOR-split decision points as shown in Figure 3.


Figure 2: Specifying the net variables

Figure 3: Specifying the decision criteria based on the loan amount

Specifying the resource assignments

In our example, we use role-based resource assignments to specify who is allowed to work on a particular task. In this case, we use two types of roles: manager and clerk to assign tasks. Figure 4 shows how we can specify that the Check for completeness task is to be done by a resource who has the role of a clerk.


Figure 4: Specifying the clerk role for the Check for completeness task

Enactment in the YAWL Engine

Once the control, the data and the resource perspectives of the credit application process have been specified in the YAWL editor, the specification is then exported and uploaded to the YAWL engine by an administrator. An uploaded specification can then been started by selecting "Launch Case" button on the screen (See Figure 5).


Figure 5: The Case Management Screen in the YAWL engine

For each started case of a specification, available workitems for that case will be displayed on the worklist of a resource who has the priviledge to work on this workitem (See Figure 6). After a resource has elected to start a particular workitem, he or she can then fill in the appropriate data by selecting the "View/Edit" button. Figure 7 shows the data screen for the Receive Application task where the loan amount can be entered. This example shows how a human resource can work on a particular workitem and provide the data back to the YAWL engine. It is also possible to invoke custom webservice from the engine to enact a particular workitem. The completion of a particular workitem will signal the progression of a workflow to the next stage. When all the workitems for a particular case of a specification has been enacted by various resources and/or custom web services, the case is removed from a list of running cases in Figure 5.


Figure 6: The Worklist Handler screen

Figure 7: Specifying the data values in a workitem