Previous     Contents     Index     DocHome     Next     
iPlanet Process Manager 6.0 (SP2) Process Builder's Guide



Chapter 16   The Loan Management and Credit History Applications


This chapter describes the Loan Management sample application and its subprocess, the Credit History application. These two sample applications show how to use a subprocess in your applications.

This chapter includes the following sections:



Loan Management Application Overview

The Loan Management application controls the process of approving a loan, from the first request to the final approval.

As part of the process, this application contains a subprocess step (Check Credit History) which launches the subprocess application Credit History. This application checks to see how much credit the person applying for the loan has been extended in the past, and returns the information to the Loan Management application. The Loan Management and Credit History applications are specifically designed to show how subprocesses work.

Note that the names for the Check Credit History subprocess and Credit History application are slightly different to distinguish the two. Check Credit History refers to the subprocess icon on the Loan Management process map and to the subprocess item's properties. Credit History refers to the actual application that is called by Loan Management as a subprocess.



Credit History Application Overview


The Credit History application can be run either as a subprocess of the Loan Management application or as a stand-alone application. It shows the process of checking a customer's previous credit. In the real world, that check would probably be done against a database of customer history, but for the purpose of this sample application the amount is hardcoded into the application.

Though the entry point for the Credit History application appears on the process map, it is not included in the walkthrough portion of this chapter. The entry point is only seen by a user if the user runs the Credit History application as a stand-alone application, instead of as a subprocess. Because the walkthrough shows the Credit History application called as a subprocess, the entry point is handled automatically when the Loan Management application starts the subprocess.



Loan Management Process Map


Figure 16-1 shows the process map for the Loan Management application:

Figure 16-1    The Loan Management process map



Credit History Process Map


Figure 16-2 shows the process map for the Credit History application.

If run as a stand-alone application, the user starts at the New Credit History Report entry point. If run as a subprocess, the New Credit History Report Entry point happens automatically when this application is called from the Loan Management application.

Figure 16-2    The Credit History process map



Loan Management and Credit History Walkthrough


This section walks through the complete process, including both the Loan Management and Credit History applications, step by step. The complete process contains the following entry points, work items (activities), subprocesses, and exit points:


New Loan Request Entry Point

The Loan Management process starts when a user puts in a new loan request. This user is someone at a bank who is responsible for helping customers with their loan applications.

Figure 16-3    The New Loan Request entry point

To start a new loan request, the person at the bank accesses the creation.html form in Process Express, as shown in Figure 16-4.

Figure 16-4    The creation.html form

This form sets the values of the following data fields:

title. The title of the process instance. Since it appears on the work list, this field needs a value that is meaningful to the end users, for example, the kind of loan requested.

customer. The name of the customer who is requesting the loan. This is a user picker widget. The customer name is used for the field role Customer. This user needs to be in the corporate directory.

amount. The amount of money the loan is for.


Verification Work Item

The next step is for the creator of the loan application to verify the information entered to make sure that it is correct. The process map for this step is shown in Figure 16-5.

Figure 16-5    The Verification work item

This step uses the same form as the entry point, creation.html, shown in Figure 16-4. The only additional field is the "comments" text area, where the creator can enter comments that will appear in the details and history. The comments section appears because the Allow to Add Comments property for the Verification activity is set to true.


Check Credit History Subprocess

At this step the Loan Management application calls a subprocess, the Credit History application. The process map for this step is shown in Figure 16-6:

Figure 16-6    The Check Credit History subprocess

This subprocess checks the credit history of the customer. If the subprocess terminates in the OK exit point, the loan request moves forward to the next step. If the Credit History application does not end at the OK exit point, the loan is denied.


Check Credit History Subprocess Properties

The Check Credit History subprocess in Loan Management has the properties as shown in Figure 16-7. (You can view properties by right-clicking the subprocess item in the process map and choosing Properties.)

The end user does not see these properties, but they govern how the Loan Management application starts the Credit History application as a subprocess.

Figure 16-7    Check Credit History subprocess properties dialog box

The Subprocess Entry shows that the subprocess application is CreditHistory, that the entry point accessed for this application is the New Credit History Report entry point, and that the form at this entry point is creation.html. A subprocess must use an entry point that only has one form. The fields on creation.html that would ordinarily be filled in by the user at the entry point are filled in automatically using data mapping. For more information, see Data Mapping.

The Subprocess Action is Submit, which is the transition that leads from the entry point to the first activity on the Credit History process map.

The "Initiate as" user ID is the ID of the user who initiates a subprocess. In many cases this field would use a script to determine the user by process instance. However, in this sample it is hardcoded to the static value of the admin user. If you are not using the admin user, or want a different user, you can replace this value. For information about revising the defined users, see Configuring the Credit History Application.

The Data Mapping, Completion Script, and Exception Manager properties are covered in the following sections.

The Transitions tab shows the order in which to evaluate the transitions out of the subprocess. First, the application evaluates the transition named getConclusion() == "OK" . This transition checks if the subprocess ended at the OK exit point. If that is true, the process continues to the Meeting work item. If the subprocess did not end at the OK exit point, the next transition is evaluated. Because the next transition is true, it acts as an "else" statement. If the subprocess ended anywhere except the OK exit point, the process follows this transition to the Loan Refused exit point.


Data Mapping

In the Data Mapping dialog box, the parent process fields are mapped to the subprocess fields that are required to complete the form at the subprocess's entry point. Figure 16-8 shows the dialog box for this sample application.

Figure 16-8    Data Mapping setting dialog box

In this sample application, the creation.html form (the form at the entry point of the Credit History application) contains two fields that must be filled in: title, and person.

The title field in the subprocess is mapped to the value in the parent process's title field. The script CustomerId() populates the subprocess data field person with the user ID of the customer stored in the parent process's customer field. For more information on this script, see CustomerId Toolkit Script.


Completion Script

The completion script storeCreditInformation takes the values from the Credit History application and stores them in the appropriate data fields in the Loan Management application. It also determines at what exit point the subprocess ended. For more information, see storeCreditInformation Completion Script.


The Subprocess Failed Exception Manager

If the subprocess fails for some reason, the application calls an exception manager named Subprocess Failed. The tree view shows this exception manager as a yellow triangle. It also appears on the process map, as shown in Figure 16-9, but it is not connected by transitions to any other items.

Figure 16-9    Exception manager

The exception manager is similar to an activity, in that you assign it to someone (usually the administrator), and that person can view a form and take action. For the Loan Management application, the exception manager is assigned to the creator by default, and the assignee views the create.html form.

The Subprocess Failed exception appears on a work list only if the subprocess fails. In most cases it won't appear.


Credit History Application as a Subprocess

When the process reaches the Check Credit History step, the Credit History application is started as a subprocess of the Loan Management application.

The process map for the Credit History application is shown in Figure 16-10. The process map displays the steps that take place before returning to the Loan Management parent process.

Figure 16-10    The Credit History process map

When Loan Management calls Credit History, the New Credit History Report entry point happens automatically. The fields in the form creation.html are filled in by data mapping, and the Submit action is performed automatically.


Check Authorization Work Item

The next step in the process is the first activity in the Credit History application, Check Authorization. The process map for this step is shown in Figure 16-11.

Figure 16-11    The Check Authorization work item

This work item is completed by the person responsible for authorizing credit reports. However, for the purposes of the sample application, this work item is assigned by default to the creator. The form associated with this step is form.html. This form contains a read-only field, person, which is the field role associated with the customer requesting the loan. This field role is picked up from the parent process, Loan Management. In Figure 16-12, the request has been made for the user's SuiteSpot Administrator.

Figure 16-12    The form.html form

The choices available from this step are Cancel Report and Create Report.

If you choose Cancel Report, the Credit History application continues to the Canceled exit point. If you choose Create Report, the process continues to the automated activity LookUp Credit History.


LookUp Credit History Automated Activity

The next step is the automated activity Look Up Credit History. The process map for this step is shown in Figure 16-13.

Figure 16-13    The Look Up Credit History automated activity

In a real-world situation, this automated activity would look up a customer's credit history in a database. However, for the purpose of this sample application, the values are hardcoded. The value of the data field credit_history is set to 10000.95. The Loan Management process uses this amount, along with the date, when the Credit History subprocess returns to the Loan Management application.

After this automated activity runs, the process continues to the OK exit point for the Credit History application.


Canceled Exit Point

If the report is canceled at the Check Authorization step, the process goes to the Canceled exit point, shown in Figure 16-14.

Figure 16-14    The Canceled exit point

This step displays the form refused.html. This form contains no fields, just the message that the credit history report is not authorized. From this exit point, the subprocess returns to the Loan Management process and continues to the Loan Refused exit point.


OK Exit Point

If the request for the report is approved, the process goes to the OK exit point, shown in Figure 16-15.

Figure 16-15    The OK exit point

This step displays the form completed.html, shown in Figure 16-16.

Figure 16-16    The completed.html form

This form shows the information gathered by the LookUpCreditHistory script. It has the following fields:

person. The person for whom the credit history is gathered. The same as customer in the Loan Management application.

credit_history. The amount of money the person has been loaned in the past.

credit_date. The date the credit history check was performed.

From this exit point, the subprocess returns to the Loan Management process and continues to the Meeting work item.


Meeting Work Item (Parent Process)

The Check Credit History subprocess has a completion script, storeCreditInformation. If this script finds that the subprocess concluded at the OK exit point, the subprocess proceeds to the Meeting step, shown in Figure 16-17.

Figure 16-17    The Meeting work item

In the Meeting step, the person making the loan meets with the customer to review the loan contract's details. For this sample application, the Meeting activity is assigned by default to the creator of the process instance.

At this point, the customer can either approve or refuse the terms. If the customer approves the terms, the process continues to the Loan Approved exit point. If the customer refuses the terms, the process continues to the Loan Refused exit point.

The form displayed at this step is summary.html, shown in Figure 16-18.

Figure 16-18    The summary.html form

Based on the results of the meeting, the two actions available to the person making the loan are Accept or Refuse. Clicking Accept sends the process to the Loan Approved exit point, whereas clicking Refuse sends the process to the Loan Refused exit point.

Note that this form is also used throughout the process for the group "all," so that everyone can see a summary of the loan process. This form is also used at the "Subprocess Failed" exception manager.

This form contains the following read-only data fields. They are the data fields from the original loan creation form, along with information gathered in the subprocess:

title. The title of the process instance. Since it appears on the work list, this field needs a value that is meaningful to the end users, for example, the kind of loan requested.

customer. The name of the customer who is requesting the loan. This is a user picker widget. The customer name is used for the field role Customer. This user needs to be in the corporate directory.

amount. The amount of money the loan is for.

credit. The amount of credit the customer has had, as determined by the Check Credit History subprocess.

last_modified. The date the credit was checked.


Loan Refused Exit Point

If the customer refused the loan terms at the Meeting step, or if the Credit History process ended at the Canceled exit point, the next step is the Loan Refused exit point, shown in Figure 16-19.

Figure 16-19    The Loan Refused exit point

The form for the exit point is summary.html, shown in Figure 16-18. However, since the process is at an exit point, the fields are display-only, and no action can be taken.


Loan Approved Exit Point

You reach the Loan Approved exit point, shown in Figure 16-20, if the loan is approved in the Meeting step.

Figure 16-20    The Loan Approved exit point

The form for the exit point is summary.html, shown in Figure 16-18. However, since the process is at an exit point, all the fields are display-only, and no action can be taken.



Groups and Roles


The Loan Management application has the following non-default role:

customer. A field-based role representing the customer who requested the loan. The data field customer is mapped to the person data field in the Credit History application, and so has the same value.

The Credit History application has the following non-default groups and roles:

person. A field-based role representing the person who requested the loan. The data field person is mapped to the customer data field in the Loan Management application, and so has the same value.

trusted users. An application group that is composed of users trusted by the application to start the application as a subprocess. These user IDs are the "Initiate as (user IDs)" of the parent processes that would call the process as a subprocess. For the Credit History application, this group by default contains one user, "admin," which is the default "Initiate as" user ID for the Loan Management application. You may have changed this value when you configured the Loan Management application. For more information on trusted users, see The Corporate Group Dialog Box.

For more information about configuring the groups and roles for these sample applications, see Configuring the Loan Management Application or Configuring the Credit History Application.



Data Dictionary


The Loan Management application has the following data fields in its data dictionary:

amount. The amount of the loan that the customer is applying for.

credit. The amount of credit the customer was last given, based on the credit history.

customer. The name of the customer who is requesting the loan. This is a user picker widget. The customer name is used for the field role Customer. This user needs to be in the corporate directory.

last_modified. The date the credit history was last modified.

title. The title of the process instance. Since it appears on the work list, this field needs a value that is meaningful to the end users, for example, the type of loan requested.

The Credit History application has the following fields in its data dictionary:

credit_date. The date the credit report was last updated.

credit_history. The amount of credit the customer was last given.

person. The user ID of the person whose credit history is requested.

title. The title of the process instance. Since it appears on the work list, this field needs a value that is meaningful to the end users, for example, the kind of credit history requested.



Loan Management Script Dictionary


The Loan Management application contains two scripts:


storeCreditInformation Completion Script

This script runs after the subprocess is complete. It finds out which exit point the subprocess reached. The script also gets the values of the fields set in the subprocess (credit_history and credit_date) and sets the values of the data fields in the parent process (credit and last_modified) to those values. Notice that this script takes advantage of the getSubProcessInstance function to get the subprocess instance data and state. The script's code is as follows:


function storeCreditInformation(){
  // Get Handle on subprocess instance
  var spi = getSubProcessInstance();
  
  // Get Handle on process instance
  var pi = getProcessInstance();

  // getConclusion returns the name of the exit point reached
  // by the subprocess
  switch( getConclusion() ){
    case "OK":
    // The subprocess instance has been successfully completed

      // Read data from the subprocess instance.
      // Please note that "credit_history" and "credit_date"
      // are names of fields defined in the child process.
      var credit_history = spi.getData("credit_history");
      var credit_date    = spi.getData("credit_date");
      
      // Store data in process instance.
      // Please note that "credit" and "last_modified"
      // are names of fields defined in this process.
      pi.setData("credit", credit_history);
      pi.setData("last_modified", credit_date);
      
      // Success
      return true;

    default:
      // No data transfer required
      return true;
  }
}


CustomerId Toolkit Script

This script is used during the data mapping from the parent process to the subprocess. It takes the value of the customer field in the Loan Management application and finds the associated user ID for that customer. The user ID is then entered into the person field in the subprocess application, Credit History.

This script is needed because field roles are entered as user IDs but are stored as distinguished names. Therefore, the value from the customer field must be converted from a distinguished name to a user ID before it can be entered into the person field.

The script's code is as follows:

function CustomerId(){
  // Get a handle on the process instance;
  var pi = getProcessInstance();

  // Get the customer user.
  var cus = pi.getRoleUser( "customer" );

  // Verify that the role has been populated correctly.
  if ( ( cus == "undefined" ) || ( cus == null ) ){
    logErrorMsg("CUSTOMER_NOT_DEFINED");
    return null;
    

  // return the user ID of the customer
  return cus.uid;
}



Credit History Script Dictionary


The Credit History application has one script, an automation script called LookUpCreditHistory.


LookUpCreditHistory Automation Script

This script is used by the automated activity LookUp Credit History. This script determines the values for the credit_history and credit_date fields. In a real-world situation, this data might be contained in a database. However, for the purpose of this sample application, the values are hardcoded into the script.

function LookUpCreditHistory(){   
  // Get a handle on the Process Instance.
  var pi = getProcessInstance();

  // Get the information about the user whose
  // credit history is requested.
  var user   = pi.getRoleUser("person");
  var userId = user.uid;

  // Based on the userId, determine the
  // credit_history and the credit_date.
  // These values are hardcoded, but we could instead
  // access an external database for more information.
  pi.setData( "credit_history", 10000.95 );
  pi.setData( "credit_date" , new Date() );
  
  return true;
}



Configuring the Loan Management Application


Before you can deploy the Loan Management application, you must make sure your environment meets the following requirements:

To add a user to the admin group, follow these steps:

  1. In the application tree view, right-click the admin group and choose Properties. Or highlight the group and click the Inspector button from the toolbar.

  2. Using the Browse option, find the users you want to add, and drag them to the List of users. Or using the Search option, highlight the users and click Add.

  3. Close the dialog box.

After you have set these properties, you can deploy the Loan Management application. However, you cannot run the application until you also deploy the application it uses as a subprocess, Credit History.



Configuring the Credit History Application


Before you can deploy the Credit History application, you must make sure your environment meets the following requirements:

  • Set the corporate directory as described in Setting Your Corporate Directory.

  • Add users in two groups: admin and trusted users. The admin can be anyone, but the default is the admin user. The trusted user must be the same user as defined in the Loan Management application for the Credit History subprocess.

To check this user value, perform the following steps:

  1. Open the LoanMgmt application.

  2. Open the Inspector window for the "Check Credit History" activity.

  3. Check the value for the "Initiated As (user id)" property. By default, this is set to admin.

To add a user to the admin or trusted user group, perform the following steps:

  1. In the application tree view, right-click the group and choose Properties. (You can also double-click the group, or highlight the group and click Inspector from the toolbar.)

  2. Using the Browse option, find the users you want to add, and drag them to the List of users. Or using the Search option, highlight the users and click Add.

  3. Close the dialog box.

After you have saved the application, you are ready to deploy it.


Previous     Contents     Index     DocHome     Next     
Copyright © 2001 Sun Microsystems, Inc. Some preexisting portions Copyright © 2000 Netscape Communications Corp. All rights reserved.

Last Updated March 13, 2001