Previous Next Contents Index


Chapter 12 The Office Setup Application

This chapter describes the Office Setup sample application that is available with PAE.

This chapter contains the following sections:


Office Setup Application Overview
This application controls the process of setting up an office for a new employee. This application illustrates parallel processing.

This application contains a number of tasks that different people must perform to get an office ready. Some of the tasks must be carried out sequentially; for example, the purchasing department must order the computer before the MIS department can install it. Some of the tasks can be carried out in parallel; for example, the MIS department can set up the phone while the purchasing department is ordering the computer.


Office Setup Process Map
The process map for the Office Setup application is shown in Figure 12.1.

Figure 12.1    Process Map for the Office Setup application


Office Setup Walkthrough
This section walks through the complete process, which contains the following entry points, activities (work items), splits, joins, and exit points:

Start Entry Point
The process begins at the Start entry point, as shown in Figure 12.2:

Figure 12.2    The Start entry point

To start the process, the hiring manager fills in an entry point form specifying the new employee's name and start date in the form for the Start entry point, prepareForNH.html. This form is shown in Figure 12.3:

Figure 12.3    The prepareForNH.html form

This form sets the values of the following data fields:

dfEmpName. The name of the new employee.

dfStartDate. The new employee's start date. This must be in the format MM/DD/YYYY.

dfMgr. The hiring manager.

dfDeptName. The department that the new employee will be joining. This datafield is a SELECT data field with a menu offering the choices Engineering, Human Resource, Marketing, and Sales.

This entry point has a completion script, setRequesterField, that sets the value of the dfRequesterName data field based on the process instance creator.

Assign Office and Specify Computer Work Item
The next step is for the manager's administrative assistant to assign an office and specify a computer, as shown in Figure 12.4:

Figure 12.4    The Assign Office and Specify Computer work item

The administrative assistant enters the office location and computer for the new employee, as shown in Figure 12.5. This form sets the values of the following data fields:

dfCubeNo. The new employee's office number.

dfFloor. The floor containing the office.

dfBldg. The building where the office is located.

dfComputer. A description of the computer to order for the new employee.

Figure 12.5    The assignCube.html form

Basic Setup Split
At the Basic Setup split, the process splits into two parallel branches, as shown in Figure 12.6:

Figure 12.6    The Basic Setup split

One branch controls the process of installing the phone and network connection. The other branch controls the process of ordering and installing the computer.

The split has two conditional transitions leading off from it. As with decision points and automated activities, you can specify conditions to determine whether a route leading from a split is followed or not. By default, the condition for all routes leading out of a split are set to true, so that they are all active.

When you place a split icon on the process map, the icon splits and appears on the map in two halves. The split part appears where you placed it, and the corresponding join icon appears to the right. The distance between the split and join icons allows for the insertion of two activities between them. When you place the split icon, you may need to scroll your process map to the right to bring the join icon into view.

Each route leading away from a split must ultimately end at the corresponding join. It cannot go to an exit point or to a join for another split. Each branch of the split represents a series of activities that are be performed in parallel and ultimately merge back into a single path.

A split icon does not represent an activity, so there are no forms for it.

Set Up Phone Work Item
In the network installation branch, the first step is for the MIS department to assign a phone number and set up the phone. The process map for this step is shown in Figure 12.7:

Figure 12.7    The Set Up Phone work item

The MIS person uses the setupPhone.html form, as shown in Figure 12.8. This form sets the values of the following data field:

dfPhone. The new employee's phone number.

Figure 12.8    The setupPhone.html form

Install Network Connection Work Item
The next step, also done by the MIS department, is to install the network connection, making sure that the office has network cables and hardware. The process map for this step is shown in Figure 12.9:

Figure 12.9    The Install Network Connection work item

The MIS department uses the setupNetwork.html form for this work item, as shown in Figure 12.10. This form sets the values of the following data field:

dfNetworkAddress. The network address.

Figure 12.10    The setupNetwork.html form

Order Computer Work Item
There is no need to wait for the phone and network setup to be finished before ordering and installing a computer in the office. Thus a parallel branch of the process controls the purchase and installation of the computer. In the computer installation branch, the first step is for someone in the purchasing department to order a new computer. The process map for this step is shown in Figure 12.11:

Figure 12.11    The Order Computer work item

This work item has the form orderComputer.html, as shown in Figure 12.12. This form sets the values of the following data fields:

dfCompOrderDate. The date on which the computer was ordered. This value must be a date such as 12/12/1998. This value is set by a client-side script, but the person ordering the computer can overwrite it. For more information on the client-side script, see "Embedded Client-Side Script" on page 272.

dfCompOrderID. The ID or PO number for the order.

Figure 12.12    The orderComputer.html form

Install Computer Work Item
The next step is for the MIS department to install the computer. The process map for this step is shown in Figure 12.13:

Figure 12.13    The Install Computer work item

This work item uses the installComp.html form, as shown in Figure 12.14. This form does not set any data field values. Its purpose is to enable the MIS department to specify when the computer is installed so that the office setup process can progress to the next step.

Figure 12.14    The installComp.html form

Basic Setup Join
When the network setup and computer installation is finished, the two parallel branches merge back together into the main branch of the process at the join. The process map for this step is shown in Figure 12.15:

Figure 12.15    The Basic Setup join

As with a split, the transitions leading away from a join can be conditional. The default condition for each transition is true, and the first transition evaluated that is true is the one followed for a particular process instance.

CheckSetup Work Item
The final step is for the administrative assistant to double-check that the office has been set up properly and has a chair and new package. The process map for this step is shown in Figure 12.16:

Figure 12.16    The CheckSetup work item

This work item has the checkSetup.html form, as shown in Figure 12.17.

Figure 12.17    The checkSetup.html form

This work item has a completion script, verifySetup, that ensures that the administrative assistant has checked "yes" for the following entries:

Chair in office?. This is the dfChairPresent radio button data field.

New Hire Stationary Packet on desk?. This is the dfNewHirePacket radio button data field.

Computer starts correctly?. This is the dfComputerOK radio button data field.

Setup Complete Exit Point
This application has one exit point, which is reached after the administrative assistant successfully submits the Check Setup form. The exit point is shown in Figure 12.18:

Figure 12.18    The Setup Complete exit point

This exit point has a notification that sends mail to the process instance creator telling them that the process instance has finished. The body of the notification is constructed by the buildExitNotification toolkit script.


The Office Setup Groups
This application contains the following application groups:

Purchasing. The purchasing department performs the Order Computer work item.

Admin Assistant. The administrative assistant performs the Assign Office and Specify Computer work item, as well as the CheckSetup work item.

MIS Dept. The MIS department performs the Set Up Phone, Install Network Connection and Install Computer work items.

admin. This is the general administrative group.

To make it easier to install and use the sample application in "test" mode, a single admin user has been put into each of these groups. If you want to add additional users or change the user, see "Configuring the Office Setup Application" on page 274 for more information.


Data Dictionary
The data dictionary has the following data fields:

dfBldg. The building where the new employee's office is located. This is set by the administrative assistant in the Assign Office and Specify Computer work item.

dfChairPresent. This is a radio button with choices "yes" and "no" to indicate whether or not the administrative assistant has checked that a chair is present in the new employee's office. This value is set by the administrative assistant in the Check Setup work item.

dfCompOrderDate. The date on which the new computer was ordered. This value is set automatically by a client-side script in the Order Computer work item.

dfCompOrderID. The order number for the new computer. This value is set by the purchasing department in the Order Computer work item.

dfComputer. A description of the computer to order for the new employee. This is set by the administrative assistant in the Assign Office and Specify Computer work item.

dfComputerOK. This is a radio button with choices "yes" and "no" to indicate whether or not the administrative assistant has checked that the computer in the new employee's office starts up. This value is set by the administrative assistant in the Check Setup work item. (Although the MIS personnel who installs the computer would be expected to check the installation, the administrative assistant also starts it once to do a double check.)

dfCubeNo. The new employee's office number. This is set by the administrative assistant in the Assign Office and Specify Computer work item.

dfDeptName. The department that the new employee will be joining. This is set by the hiring manager in the entry point.

dfEmpName. The new employee's name. This is set by the hiring manager in the entry point.

dfFloor. The floor where the new employee's office is located. This is set by the administrative assistant in the Assign Office and Specify Computer work item.

dfMgr. The new employee's manager. This is set by the hiring manager in the entry point.

dfNetworkAddress. The IP address for the new employee's network connection. This is set by the MIS department in the Install Network Connection work item.

dfNewHirePacket. This is a radio button with choices "yes" and "no" to indicate whether or not the administrative assistant has put a new hire stationery packet in the new employee's office. This value is set by the administrative assistant in the Check Setup work item.

dfPhone. The phone number for the new employee. This is set by the MIS department in the Set Up Phone work item.

dfRequesterName. The name of the person requesting the office setup. This would usually be the same as the new employee's hiring manager. This is set by the hiring manager in the entry point. This data field would be useful to keep track of the requestor in cases where someone other than the hiring manager is starting the process.

dfStartDate. The start date for the new employee. This is set by the hiring manager in the entry point.


Form Dictionary
The application uses the following forms:

All of these forms except the status.html form are described in "Office Setup Walkthrough" on page 249.

The status.html form, shown in Figure 12.19, is used to show the status of the office setup to interested parties. It shows the data gathered on the other forms in the areas of new employee details, office location, phone information, network information, and computer. It is available to members of "all" beginning with the Assign Office and Specify Computer step and throughout the rest of the process.

Figure 12.19    The status.html form


Script Dictionary
The process uses customized scripts of the following kinds:

The process also uses one client-side script to automatically set the order date when a new computer is ordered.

Completion Scripts
This process uses two completion scripts: setRequesterField and verifySetup.

setRequesterField
This runs as a completion script on the entry point. It checks the Directory Server for the person that initiated the request, and puts their common name as the value of the dfRequester field. If the creator is not found in the Directory Server, the dfRequester field is not set. The purpose of setting this field is to store the process instance creator in a data field.

The code for this script is as follows:

function setRequesterField(){

  // Get the process instance.

  var pi = getProcessInstance();

  // Get the distinguished name of the creator of the

  // process instance from the Directory Server.

  var creator = pi.getCreatorUser();

  // If we can't find the creator in the Directory Server, log

  // an error, but it's not a show-stopping error so keep going.

  if (creator == null || creator == "undefined") {

    logErrorMsg("creator can not be located");

  }

  // If we found the creator in the Directory Server

  // put their common name in the dfRequester data field.

  else {

    var creatorName = creator.cn;

    pi.setData("dfRequesterName", creatorName);

  }

  // Return true so that the activity succeeds

  // and the process continues.

return true;

}

verifySetup
This runs as a completion script on the Check Setup work item. This script checks that the dfChairHere, dfComputerOK, and dfNewHirePacket radio button data fields are all set to "yes." If any of them are not set to "yes," the completion script returns false, which means the work item cannot be completed.

The plan is that the administrative assistant checks these buttons after checking that the new employee's office has a chair, the computer starts up, and a new hire stationery packet is on the desk.

The code for this script is as follows:

function verifySetup(){

var pi = getProcessInstance();

// Return false if any of the dfChairPresent, dfNewHirePacket

// or dfComputerOK data fields are not set to yes.

if ((pi.getData("dfChairPresent") != "yes") ||

    (pi.getData("dfNewHirePacket") != "yes") ||

    (pi.getData("dfComputerOK") != "yes"))

{

// Tell the user why the form could not be submitted.

setErrorMessage("You must ensure that the computer is OK, " +

+ "and there is a chair and new hire packet in the office.");

return false;

}

// If everything's OK, return true.

return true;

}

Toolkit Scripts
There is one toolkit script, buildExitNotification.

buildExitNotification
This scripts builds a string to use as the body of an email that gets sent by the exit point to the process instance creator.

This email informs the process instance creator that the process instance has terminated.

The code is as follows:

function buildExitNotification(){

  // Get the process instance.

  var pi = getProcessInstance();

  // Get the current work item.

  var wi = getWorkItem();

  var nodeCN = wi.getCurrentActivityCN();

  // Construct a string to use as an email body such as:

  // "The office setup request you initiated on 10/10/  1998 for

  // new hire Nikki Beckwell has finished at the Setup Complete

  // exit point.

  var body = "The office setup request you initiated on "

          + pi.getCreationDate()

          + " for new hire "

          + pi.getData("dfEmpName")

          + " has finished at the "

          + nodeCN

          + " exit point.";

return body;

}

Embedded Client-Side Script
The orderComputer.html form uses a client-side script to automatically set the date on which the computer is ordered. The purchasing department can override this date.

This script makes use of the fact that every data field shown in the form has a corresponding form element of the same name. Thus by setting the value of the dfCompOrderDate form element, we are effectively setting the value of the dfCompOrderDate data field.

function getDate( )

{

  var currDate = new Date();

  /* Get the current year.

  NOTE: according to the JavaScript Reference,

  The getYear method returns either a 2-digit or 4-digit year:

  For years between and including 1900 and 1999, the value returned

  by getYear is the year minus 1900. For example, if the year is 1976,

  the value returned is 76.

  For years less than 1900 or greater than 1999, the value returned

  by getYear is the four-digit year. For example, if the year is 1856,

  the value returned is 1856. If the year is 2026, the value returned

  is 2026.

  */

  var currYear = currDate().getYear();

  if( currYear < 100 )

    currYear += 1900;

  // Jan is 0, Feb is 1 etc... so add 1 to the month.

  var dateString = (currDate.getMonth() + 1) + "/"

      + currDate.getDate() + "/"

      + currYear;

  return dateString;

}

// Put the current date in the dfCompOrderDate

// element in the form.

document.forms[0].dfCompOrderDate.value = getDate();


Customizing the Appearance of the Forms
The forms used in this sample application were edited in an external HTML editing tool to fine-tune their appearance.

All HTML forms link to a single style sheet, mystyles.html, that defines a class that is used to define the purple border for the paragraph at the bottom of each form.

The html pages for forms appear at the top level of the subdirectory of Applications that contains your application.

To edit these forms, use an HTML editor that meets the following requirements:

HTML editors that meet these requirements include Netscape Communicator (versions 4.5 or later) and Microsoft Internet Explorer (versions 4.0 and later).

If you edit the forms in an external editor, be sure not to modify any of the customized SERVER tags, or you the data fields on the forms will not work.

If you edit a web page for a form while it is also open in Process Builder, be sure to click on the form again in Process Builder before saving the application. When you click on a form that has been edited externally, Process Builder asks if you want to load the modified form with the latest changes.

Note that the web page for the form only contain a portion of the information the end-user sees on the form. The Process Engine inserts the banner, buttons, and comment areas of the form, as well as the <FORM> tag itself.

For more information on using an external editor with Process Builder, see "Modifying Forms" on page 165.


Configuring the Office Setup Application
Before you can deploy the Office Setup application, you must make sure your environment meets the following requirements:

Typically, you don't need to add users to the above groups, because an admin user is added to each of those groups by default. However, you must add users if:

To add users, perform the following steps:

  1. Make sure that you have defined a corporate directory for the application. For more information, see "Applications and the Corporate Directory" on page 69.
  2. In Process Builder, open the application tree view.
  3. In the Groups and Roles folder, right-click the group name you want to change, and then choose Properties.
  4. 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.
  5. Close the dialog box.
After you have saved the application, you are ready to deploy it.

 

Copyright © 1999 Netscape Communications Corp. All rights reserved.