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



Chapter 5   Designing a Process Map


This chapter describes the elements of a process map, their properties, and how to use them to design a process map.

This chapter includes the following sections:



Drawing the Process Map

When you create a new application, Process Builder displays an initial set of empty resource folders and a blank process map. As you draw the map, Process Builder adds items to the folders in the application tree view.

To design a process map, follow these steps:

  1. Create a new application.

  2. Drag items from the Palette to the Process Map pane.

  3. Update the properties of the items you add to the process map.

  4. Add transitions between the items.

A process map is the visual representation of an application's steps. You also need to create all the other items, forms, data fields, and so on, in order to make a working application.



Saving a Process Map to a File


Sometimes you want to export the process map—in other words, save the map outside of Process Builder. For example, by saving the process map as an image, you can later print it or insert it into an HTML document.

To export the process map, open the Application menu and choose "Save Process Map Image."

The "Save Process Map Image" dialog box appears, as shown in Figure 5-1. This dialog box lets you choose what kind of image file to save the process map as.

Figure 5-1    Save Process Map Image Dialog box

To choose where to save the image, select the Browse button, and navigate to the desired folder.

To choose what kind of image file to save the process map as, click the Image Type field, and choose an image type from the menu. The choices are:

  • JPEG Image

    This encodes and compresses the file and saves it with some lossage (that is, it drops some pixels). This format is great for portability and inclusion in web pages but occasionally you will see color bleeding. This format usually gives the smallest file size.

    This option lets you select the quality of the image as a percentage (0 is lowest quality, 100 is highest quality).

  • BMP Windows Bitmap

    This saves the image as a straight RGB image with no encoding, compression, or lossage. Use this format if you want an exact replica of your process map.

    This option allows you to select the color depth of the image.

  • PNG Image

    This saves the image in the portable network graphics format, which is a compressed, possibly color indexed image, with no lossage. PNG format was designed as a replacement for GIF due to copyright issues with GIF. It generally results in good compression.

    This option allows you to select amount of compression and the color depth of the image.

After the process map is saved, a dialog box appears, as shown in Figure 5-2. You can click OK to close this dialog box, or you can click the image link (for example, "JPEG image") to display the new image file that was created.

Figure 5-2    After saving the process map, you can view it by clicking the image link



Adding Items with the Palette


You create a process map by dragging items from the palette (shown in Figure 5-3) to the process map.

Figure 5-3    The palette

Using the palette, you can add the map items described in Table 5-1.


Table 5-1 Icons in the Activities tab

Icon

Description



 

Entry Point. A point at which a user can initiate a process. An application can have several entry points. For example, if the first few steps create an ID number for the user, a returning user who already has an ID can skip those steps.  



 

User Activity. A step within the process that requires a user to perform a task. Each user activity has an assigned user who performs the task (assignee) and a form the user needs to fill out in Process Express. After you place activities in the process map, you define the sequence in which they are to be executed by connecting them with transition lines.  



 

Automated Activity. An automated step performed through a JavaScript script without user intervention.  



 

Subprocess. A step that calls a process from within another process. The process that calls the subprocess is considered to be the main, or parent process, and the subprocess is considered to be its subordinate or child process. A parent process can have several children processes, each of which is a stand-alone process complete with entry and exit points.  



 

Exception Manager. A step that allows the administrator to intervene manually if errors occur when users run the application.  



 

Decision Point. A conditional step that causes the process to use different steps based on a condition. For example, you might have a decision point that directs the process to different steps depending upon the cost of an item.  



 

Split-Join (parallel processing). A step within the process that branches in two or more branches so that two or more activities can execute in parallel.  



 

Exit Point. A step at which the process ends. An application can have several exit points. For example, in a vacation time off request application, an exit point could be the approved vacation request, and another could be a vacation that was not approved.  



 

Custom Activity. A step at which a Process Manager application connects to external components or services.  



 

Notification. An email notification that is triggered when a user activity is started. The email can serve many purposes. For example, it can inform the person who started the process or other users of the process's progress.  

To add items to your process map from the Palette, follow these steps:

  1. Click the Palette icon in the strip below the menu bar to display the Palette, if it's not displayed already.

  2. Drag an item from the palette to the process map.

    For notifications, you must drag the item into the user activity or exit point that already exists on the process map.

  3. Double-click the item or highlight it and click the Inspector icon.

  4. In the Inspector dialog box, define the item's properties.

    You can also right-click the items in the process map or application tree view. Since notifications do not appear on the process map, you must select them from the application tree view. For more information on the properties of specific items, see the section in this chapter for the type of item you added.



Deleting Items

To delete a process map item, you can do one of the following in the application tree view or the process map:

  • highlight the item and press the Delete key

  • right click the item and choose Delete from the menu

  • highlight the item from the Edit menu and choose Delete

When you delete an item that is connected to other items by transitions (actions), you must also delete the transitions. If you attempt to delete an item with transitions, a dialog box appears asking if you also want to delete the transitions.



Entry Points


An entry point is a point at which a user can create a process instance. You can have more than one entry point; for example, if you are designing an application to create a data sheet, you might have two entry points. One entry point might be for data sheets for which you have to create art. Another entry point, later in the process, might be for data sheets for which you already have art prepared.

Entry points have the following properties:

Name. The name of the entry point that appears in Process Builder and Process Express.

Description. An optional longer description of the entry point that appears in Process Express.

Completion Script. A script that runs when the step is completed. You must have already written the completion script you want before filling in this property.



User Activities


A user activity is a task that must be performed by a participant (the assignee) as part of a process. For example, a manager may have to approve an employee's time off. A form associated with the activity enables the assignee to take the required action so that the process moves to the next step.

User activities have the following properties:

Name. The name of the activity that appears in Process Builder, and in Process Express. Since this name appears on users' work lists, make it descriptive of the action they need to take.

Description. An optional longer description of the activity that appears in Process Express.

Allow to Save. True/false. When set to true, this option allows users to save a work item so that they can complete it at a later time. If you set this property to true, a Save button appears on the work item's form in Process Express. Defaults to false

Allow to Add Comment. True/false. When you set this option to true, end users are allowed to add comments to the activity. The comment field appears automatically on forms presented to users for that activity in Process Express. The assignee can add comments, which are then displayed in Process Express as part of the process instance's history. Defaults to true.

Allow to Delegate. True/false. When set to true this option allows users to delegate a step so that someone else can handle it for them. If a step is delegated, the person it is delegated to becomes the step assignee, with the associated access to forms. If you set this property to true, a "Delegate" button appears on the work item's form in Process Express. Defaults to false.

Assignment Script. The script that assigns a user or group of users to a work item. When a user is assigned a work item, it appears in the user's work list in Process Express. See Setting Activity Assignments for further details about the script properties. You can use a predefined assignment script or create your own. If you create your own, the script must already exist before you can enter it in this property.

Expiration Setter Script. The script that sets an expiration date or time for a work item. See Setting Activity Expirations for further details about the script properties. The script must already exist before you can enter it in this property.

Expiration Handler Script. The script that runs when a work item has not been completed by its expiration date or time. The script must already exist before you can enter it in this property.

Verification Script. A script that runs when the step is completed. The verification script must already exist before you can enter it in this property.

Completion Script. A script that runs when the step is completed. The completion script must already exist before you can enter it in this property. The completion script runs after the verification script.

Exception Manager. If an error occurs, the Exception Manager invokes a new work item for correcting the error. Errors can occur in two cases: if a verification or completion script returns false, or if a runtime error occurs in a script (for example, in an assignment, expiration setter, or expiration handler script). See Exception Manager.


Setting Activity Expirations

When you create a user activity, you can set an expiration date or time for it in the Expiration Date Selection window, either by specifying an expiration or a script to set the expiration. To set an expiration, follow these steps:

  1. Open the Inspector Window for an activity by double-clicking the activity or highlighting it and clicking the Inspector icon, or right-click and choose Properties.

  2. From the Expiration Setter Script field, click the right arrow button.

    The Expiration Date Selection dialog box appears, as shown in Figure 5-4.

Figure 5-4    The Expiration Date Selection dialog box

  1. Click the radio button for the type of expiration you want.

  2. Click OK to close the dialog box.

The following options are available:

Never expire. The activity never expires. This is the default value.

Expire in. The activity expires in a specified amount of time. You set the number and a unit of measurement (Months, Weeks, Days, Hours, Minutes).

Defined by a script. The script that determines when the activity expires. The product contains no built-in scripts of this type. You can write your own JavaScript scripts, which will then be available in the drop-down list below the Defined by a script radio button.

If you need to set parameters for your script, you define them in the last field in the dialog box. You can give the parameter values, or the names of scripts that return the value. You can also enter your own script here. Enter your own script if you want to use a script that you haven't written yet, or if you want to use a script that is not a expiration setter script (for example, a toolkit script). If you write your own script, it must follow the conventions for expiration setter scripts.

If you set an expiration time or date, you can also set an Expire Manager Script for the activity. An Expire Manager script runs when the activity expires. This script is optional. You must create your own JavaScript script, since none of these scripts are built-in.


Setting Activity Assignments

You can set a user to be assigned to an activity through an assignment script, many of which are built into Process Builder. You may need to set up some groups and roles before you can assign activities. See Chapter 6 "Defining Groups and Roles" for more information.

To assign an activity, follow these steps:

  1. Right-click the activity in the process map or application tree view and choose "Set assignee script". You can also access the property page and click the Assignment Script field.

    The Assignment Selection dialog box appears, as shown in Figure 5-5.

Figure 5-5    The Assignment Selection dialog box

  1. Click the radio button beside the type of assignment you want.

  2. Click OK to close the dialog box.

There are three ways to specify an assignment:

The creator. Assigns this activity to the creator (the person who initiated the process instance).

A group or a role. Select one of the roles or groups in the drop-down list. The list contains all the default roles and groups, as well as the ones you've created. If you assign a task to a group, the person in the group who first accepts the work item in Process Express performs the task. The other members of the group do not perform the task. If you want to assign a task to every member of a group for approval, see Using Parallel Approval.

Defined by a script. Assigns this activity using a script—either a built-in script specified in the drop-down list, or a script whose name you specify in the text field below the radio button.

If you select the "Defined by a script" radio button, you must supply values for parameters contained in angle brackets. For example, using the assignment script toManagerOfRole, you are asked to complete the parameter in toManagerOfRole("<rolename>"). You must replace <rolename> with the field role: for example, toManagerOfRole("product_mgr"). You can also replace parameters with scripts that return the parameter value.

For details on the available assignment scripts you can specify, see Assignment Scripts.


Using Parallel Approval

Usually only one user is assigned an activity. However, in some cases you might want to have several users perform the same activity consecutively, for example, if you want several people to approve a document or action before it moves on to the next step. To implement an activity of this sort, you use parallel approval.

You implement parallel approval by creating an activity with specific assignment and completion scripts, and a data field to store necessary information.

To set up a parallel approval activity, follow these steps:

  1. Create a data field fieldname to keep track of who has already performed the review and who still needs to perform it. This field must be a computed field with length of 2000.

  2. Add an activity to the process map.

  3. Right-click the activity in the application tree view and choose Properties to go to the Properties window for this activity (which will be your parallel approval activity).

  4. Click the arrow on the Assignment Script property to bring up the window for setting the assignment script.

  5. Choose toParallelApproval from the drop-down list.

  6. Replace the parameters arrayOfUserDNs and fieldname with appropriate values.

  7. Click OK to return to the activity's Properties window.

  8. Click the arrow on the Completion Script property to bring up the window for setting the completion script.

  9. From the drop-down list, choose checkParallelApproval.

  10. Replace the parameters fieldName and lableOfStopperAction with appropriate values, as described in the next section.

  11. Click OK.

  12. Fill in any other properties you need to for the activity.

  13. Close the window. Your changes are saved automatically.

From the end user point of view, a parallel approval item is assigned to all users in the group that need to give approval. If a user starts the work item and approves it, Process Manager stores the result in the data field and reassigns the work item to every user but the user who has approved the work item. This continues until all users have approved the item, or until one of the users has not approved the item. If all users have approved the item, the process continues in one direction. If one of the users has not approved the item, the process continues in another direction.


Parallel Approval Completion Script

To use parallel approval, you must use the completion script checkParallelApproval(fieldName, labelOfStopperAction).

This script runs when the parallel approval activity is completed. If any user chooses the "stopper action" (that is, refuses to approve the item) the completion script performs the appropriate action. If all users complete the activity without choosing the "stopper action" (that is, all approve the item) this script performs the appropriate action.

The parameters are fieldName and labelOfStopperAction.

  • The fieldName is the field that keeps track of who has performed the approval and who still needs to do so. The field is a computed field of length 2000 that you have to add to the data dictionary.

  • The labelOfStopperAction is the name of the action or transition that a user can select that stops the approval.



Automated Activities

Automated activities are steps performed by Process Manager without user intervention, through one or more JavaScript scripts. Automated activities are triggered as soon as the process instance reaches the activity, unless the activity is deferred. If the activity is deferred, it is triggered at its specified date and time.

Automated activities have the following properties:

Name. The name of the automated activity that appears in Process Builder.

Description. An optional longer description of the activity.

Schedule. The schedule for deferred activity. You need to set the Deferred property to true to use this schedule. You set the schedule property in a pop-up dialog box, shown in Figure 5-6.

Figure 5-6    Automated Activity Schedule dialog box

Enter a time into any of the day fields to have the automated activity run at that time on that date. Enter times in the 24-hour clock format (for example, 1300 for 1:00 pm To enter more than one time for a day, separate the times with a comma. If you enter only two digits, Process Builder assumes they are the hour.

Deferred. This property specifies if the activity should be performed as soon as the process reaches the automated activity, or if it should be deferred. If you set the property to true, the automated activity is deferred to the time you specify in the Schedule property. If this property is set to False, the automated activity is performed immediately. The default is false.

Automation Script. The script that performs the automated step. The script must already exist before you can enter it in this property.

Verification Script. A script that runs when the step is completed. The script must already exist before you can enter it in this property. For automated activities, the step is completed when the automation script has finished running, so the verification script runs immediately after the automation script.

Completion Script. A script that runs when the step is completed. The script must already exist before you can enter it in this property. The completion script runs after the verification script.

An automated activity also has a Transition Order window, where you can rearrange the possible transitions when there is more than one. You display the Transition Order window by clicking the Transitions tab in the Inspector window.

Transitions out of automated activities always default to true, because a true outcome means the process instance moves on to the transition. When you have more than one transition out of an automated activity, the activity operates in the same way as a decision point, which evaluates multiple conditions (for example, if the price is over $100 or less than or equal to $100) in a specific order. You set the order in the Transition Order window, by clicking the up and down arrows. The top condition in the window is evaluated first. Process Manager uses the first transition condition that is true to route the process instance.

Exception Manager. If an error occurs, the Exception Manager invokes a new work item for correcting the error. Errors can occur in two cases: if a verification or completion script returns false, or if a runtime error occurs in a script (for example, in an assignment, expiration setter, or expiration handler script). See Exception Manager.



Subprocesses


A subprocess is a fully functional process that is called from within another process. The process that calls the subprocess is considered to be the parent process and the subprocess is considered to be its child process. A parent process can have several children processes, each of which is a stand-alone process complete with entry and exit points.

Subprocesses allow process designers to reuse processes across their environment. For example, if a bank has many different loan management processes, all of which require a credit check at a certain point in the process, each of the loan management processes can use the same credit check subprocess. Chapter 16 "The Loan Management and Credit History Applications" describes the Loan Management sample application and its subprocess the Credit History application; the two sample applications show how to use a subprocess in your applications.

Another advantage of subprocesses is that the logic flow of the main process map may be simpler to follow because a certain portion of its processing is hidden behind the subprocess icon. For example, in the Loan Management sample application, the Check Credit History processing is handled in the Credit History subprocess and is not exposed in the main Loan Management process map.

You can use a subprocess in the same way as an automated activity (see Automated Activities). You can place it anywhere on the process map, have multiple transitions coming out of it, and place complex scripts within the subprocess to perform actions that are hidden from the main process.

A timer agent coordinates how the parent and child process interact together. The parent process initiates a child process; when the child completes, it sets a value, wf_observer_url, in a Process database table. This is the URL of the parent process. A timer agent periodically checks this database table (by default, every five minutes). If there's a value in the wf_observer_url field, the timer agent attempts to connect the child to the parent process. Once the child successfully connects back to the parent, the value in the database table is set to null so the timer agent does not attempt to reconnect again.

If there's a problem in connecting to the child or to the parent, an exception is thrown and the exception manager allows the administrator to intervene. See Exception Manager for more information.

To set up a subprocess, follow these steps:

  1. Create a child process.

  2. Open the parent process map.

  3. Drag a subprocess icon onto the parent process map.

  4. Right-click the subprocess icon and choose Properties.

    The Subprocess Inspector Window appears, as shown in Figure 5-7.

Figure 5-7    The Inspector Window for a subprocess

  1. Fill in the properties for the subprocess.

  2. Close the window. Your changes are saved automatically.

All subprocesses have the following properties:

Name. The name of the subprocess.

Description. An optional longer description of the subprocess.

Subprocess Entry. The entry point in which the parent process enters the child process. To enter the subprocess entry:

  1. Click the right arrow next to the subprocess icon. The Subprocess Entry Chooser window appears.

  2. In the list of applications, click the plus (+) sign of the application you want to make a subprocess.

  3. Choose an action or an entry point and click OK.

Subprocess Action. The action that you follow from the Subprocess Entry field.

Data Mapping. The data that must be mapped between the child and parent process so that values can be passed easily between them. To define the data mapping:

  1. Click the right arrow in the Data Mapping field. The Data Mapping Setting window appears.

  2. In the Mapping Script column, click the arrow for each row. The Field Mapping window appears.

  3. Enter a static value, select a corresponding field from the parent data dictionary, or define a script and click OK.

  4. When you have mapped all the data fields, click OK.

Initiator User Id. The initiator of the subprocess.

You can use a dynamically derived value as the initiator. For example, in a hiring application that uses a child process to set up a secure ID card for each new hire, you identify a different new employee in each instance of the parent process and you want to use the new user IDs in the child process. In this case, you use a script to pull the new user ID from the corporate directory.

You can use the App User Id of the parent process as the creator of the child process. In this case, you leave the Initiator User Id blank because the default is to use the same user as the creator of the main process.

You can also use a static value as the initiator, which is especially useful when testing. The sample application, for example, uses a static value ("admin") to simplify setting up and deploying the application.

Verification Script. The script that runs when the child process is completed. The script must already exist before you can enter it in this property.

Completion Script. The script that runs when the child process is completed. The script must already exist before you can enter it in this property. The completion script runs after the verification script.

Exception Manager. If an error occurs, the Exception Manager invokes a new work item for correcting the error. Errors can occur in two cases: if a verification or completion script returns false, or if a runtime error occurs in a script (for example, in an assignment, expiration setter, or expiration handler script). See Exception Manager.


Connecting the Parent and Child Process

When a parent process arrives at a child activity, it tries to connect to the subprocess and launch it. The parent process normally invokes the subprocess with its App User ID as the initiator of the subprocess. It can also invoke the subprocess with a different user id, but in this case, this user id needs to be in the trusted user group of the subprocess. This requirement is in place to avoid spoofing. To add an initiator id to the trusted user group of the subprocess, see Creating Groups and Roles.



Custom Activities


Custom activities are Java classes created by a developer that you can use in Process Builder applications to perform complex automated tasks, such as connecting Process Manager applications to external applications and databases.

Custom activities are similar to automated activities, in that they perform tasks without user intervention. However, custom activities, because they are Java classes, can be used for more complicated tasks than the JavaScript scripts of automated activities.

This section presents an overview of custom activities. For a detailed example, see the Process Manager Programmer's Guide.


Using a Custom Activity

After you add a custom activity to the palette, you can use the custom activity in your process map. To do so, perform these main steps:

  1. Drag the custom activity icon from the palette to the process map.

  2. Right-click the custom activity icon on the process map and choose Properties. The Inspector Window appears.

  3. Click the Input and Output tabs to make sure the data is mapped correctly between the custom activity and the application's fields.


Custom Activity Inspector Window

Figure 5-8 shows the Inspector window for a custom activity when you first drag the activity to the process map.

Figure 5-8    Custom Activity Inspector

Note that there are only two tabs in the window: Properties and Transitions. The Properties tab displays the following properties:

Name. The name of the custom activity that appears in Process Builder, and in Process Express. Since this name appears on users' work lists, make it descriptive of the action they need to take.

Description. An optional longer description of the activity that appears in Process Express.

Custom Activity. The file that contains the Java class and its xml descriptor. Use Browse to go to an .xml, .zip, or .jar file to use. After you set this property, the Inspector window changes to reflect information defined by the custom activity you selected.

Version. The custom activity's version number.

Implemented By. The Java class that implements this custom activity.

Schedule. The schedule for deferred activity. You need to set the Deferred property to true to use this schedule. You set the schedule property in a pop-up dialog box, shown in Figure 5-9.

Figure 5-9    Custom Activity Schedule dialog box

Enter a time into any of the day fields to have the custom activity run at that time on that date. Enter times in the 24-hour clock format (for example, 1300 for 1:00 pm To enter more than one time for a day, separate the times with a comma. If you only enter two digits, Process Builder assumes they are the hour.

Deferred. This property specifies if the activity should be performed as soon as the process reaches the custom activity, or if it should be deferred. If you set the property to true, the custom activity is deferred to the time you specify in the Schedule property. If this property is set to false (the default), the activity is performed immediately.

Verification Script. A script that runs when the step is completed. The script must already exist before you supply it as a property. The verification script runs immediately after the custom activity finishes executing.

Completion Script. A script that runs when the step is completed. The script must already exist before you supply it as a property. The completion script runs immediately after the verification script.

Exception Manager. If an error occurs, the Exception Manager invokes a new work item for correcting the error. Errors can occur in two cases: if a verification or completion script returns false, or if a runtime error occurs in a script (for example, in an assignment, expiration setter, or expiration handler script). See Exception Manager.


Inspector Window After Setting a Custom Activity

Once you set the Custom Activity field, the Inspector window changes. An example is shown in Figure 5-10:

Figure 5-10    Custom Activity Inspector, after setting the Custom Activity property

After setting the custom activity, if an environment parameter is set in the custom activity file, the parameter appears in the properties window. In Figure 5-10, Language is an environment parameter.

Two new tabs also appear: Input and Output.

The Input tab shows the parameter names in the custom activity's input hashtable, and shows how the parameter value is derived. Figure 5-11 shows an example of the Input tab.

Figure 5-11    The Input tab

For example, the value for the input parameter claimId comes from getting the value in the application's claimid data field.

The Output tab shows the mapping between the output parameters in your custom activity and the data field in your application. Figure 5-12 shows an example of the Output tab.

Figure 5-12    The Output tab

In this example, the value from the output parameter, claimId, is put into the application's data field claimid.


Adding a Custom Palette

If you frequently use custom activities, you can add them to your palette, thereby giving you easy access to ready-made components.

To add a custom palette, follow these steps:

  1. Right click on the Map Palette window and choose "Add custom palette."

    A dialog box appears, as shown in Figure 5-13:

Figure 5-13    New Palette Dialog Box

  1. Enter the name of the palette and click OK

    A tab containing the custom palette is added to the Map Palette, as shown in Figure 5-14.

Figure 5-14    Blank custom palette

  1. Add an item to the custom palette by right-clicking on the custom palette an choosing "Add custom activity."

  2. Browse to the .xml, .jar, or .zip file that contains your custom activity.

    An icon representing the custom activity appears on the custom palette, as shown in Figure 5-15.

Figure 5-15    Custom palette with custom activity

  1. To add the custom activity to your application, drag the icon from the custom palette to the process map.

For information about writing the XML and Java code for a custom activity, see the Process Manager Programmer's Guide.



Exception Manager


Exception managers allow users to intervene if errors occur in the application. You create an exception manager by dragging the exception manager icon to the process map. Most process map items represent steps in the process and are connected by transitions. Exception managers, however, are usually placed off to the side on process maps. They are not connected to other steps; instead, they are called by activities when an error occurs. You set up which exception manager is used at each activity using the Exception Manager property in the activity.

If a problem occurs while the work item is being processed, the exception manager assigned to that activity is called. The exception manager then generates a work item based on the exception manager properties. The work item is assigned to a user by the assignment script. Often the person assigned the work item is an administrator or the creator of the process instance, because these people are in a good position to diagnose what went wrong with the process.

You can attach a notification to the exception manager, which sends mail to the administrator when an exception is thrown. See Notifications for more information.


Default Exception Manager

Every new process automatically has a default exception manager that appears in the application as soon as you create an activity that requires an exception manager. When you create new process map items that have Exception Manager properties, the properties default to the default exception manager.

To see the properties of the default exception manager, right-click the default exception manager in the application tree view and choose Properties. The default exception assigns the exception work item to the creator of the process instance. You can change the properties of the default exception handler, or you can create your own exception handler.


Creating an Exception Manager

To add your own an exception manager, follow these steps:

  1. Drag an exception manager icon from the map palette onto the process map.

  2. Right-click the exception manager icon and choose Properties. Update any properties as needed.

  3. Assign this exception manager to a user activity, custom activity, automated activity, subprocess activity or end point.

    Right-click the activity icon and choose Properties to go to the Properties window. In the Exception Manager field, choose the exception manager from the drop-down list.

  4. Either create a new form for the exception manager, or use an existing form. Because exception handlers don't have transitions, the button names are assigned automatically: Retry and Continue.

    Retry resubmits the work item where the error occurred. Continue skips the step in the process instance that caused the error. This option should be used with caution.

  5. Assign the form to the exception manager using the Form Access window.


Exception Manager Properties

All exception managers have the following properties:

Name. The name of the exception manager.

Description. An optional longer description of the exception manager.

Allow to Save. True/false. When set to true, this option allows users to save a work item so that they can complete it at a later time. If you set this property to true, a Save button appears on the work item's in Process Express. Defaults to false.

Allow to Add Comment. True/false. When you set this option to true, end users are allowed to add comments to the activity. The comment field appears automatically on forms presented to users for that activity in Process Express. The assignee can add comments, which are then displayed in Process Express as part of the process instance's history. Defaults to true.

Allow to Delegate. True/false. When set to true this option allows users to delegate a step so that someone else can handle it for them. If a step is delegated, the person it is delegated to becomes the step assignee, with the associated access to forms. If you set this property to true, a "Delegate" button appears on the work item's form in Process Express. Defaults to false.

Assignment Script. The script that assigns a user or group of users to a work item. When a user is assigned a work item, it appears in the user's work list in Process Express. You can use a predefined assignment script or create your own. If you create your own, the script must already exist before you can enter it in this property. See the programming information in this book for more information on creating scripts.

Expiration Setter Script. The script that sets an expiration date or time for a work item. See Setting Activity Expirations for further details about the script properties. The script must already exist before you can enter it in this property.

Expiration Handler Script. The script that runs when a work item has not been completed by its expiration date or time. The script must already exist before you can enter it in this property.

Verification Script. A script that runs when the step is completed. The script must already exist before you can enter it in this property.

Completion Script. A script that runs when the step is completed. The completion script must already exist before you can enter it in this property. The completion script runs after the verification script.



Decision Points


Decision points are places where the process branches into different steps depending upon conditions. For example, if a price is above a certain amount, the process might branch to include an approval step that is unnecessary if the price is below a that amount.

Decision points have the following properties:

Name. The name of the decision point that appears in Process Builder.

Description. An optional longer description of the decision point.

Completion Script. A script that runs when the step is completed. The script must already exist before you can enter it in this property.

You add possible outcomes to the decision point by adding transitions with conditions. For example, you could create two transitions, one if the price stored in the price_final field is over $1000, and another if the price is less than or equal to $1000. Make sure that all possible outcomes are covered in your transitions. For example, if you made transitions with the conditions that the price had to be greater than $1000 or less than $1000, you have not covered the condition of the price being equal to $1000. If you do not have options that cover all cases, the transaction rolls back and the user receives an error message.

Decision points also have a Transition Order window, where you can rearrange the transitions leading from the decision point. You display the Transition Order window by clicking the Transitions tab at the top of the Inspector window. An example from the DataSheet sample application is shown in Figure 5-16:

Figure 5-16    The decision point Transition Order window

The top item in the window is evaluated first, but you can rearrange items by using the arrow icons. Process Manager uses the first transition condition that is true to route the process instance. So for the example above, the process checks first to see if the price_final field is less than 1000.00. If that is true, the process continues with that transition. If the price_final field is more than 1000.00, the first condition is false, so the second condition is now evaluated. If the second condition is true, the process continues with that transition.

For more information on transitions, see Transitions.



Split-Join (Parallel Processing)


Parallel processing allows a process to branch in two or more directions so that two or more activities can execute in parallel. In complex processes, you can nest parallel processes within a larger parallel process. Note that the activities in the nested process are considered to be part of the nested process, not the larger process; that is, if you nest process "a" within process "A", each with its own pair of split-join icons, the activities in the nested process must progress from split "a" to join "a" not to join "A."

Chapter 15 "The Office Setup Application" describes the Office Setup sample application, which controls the process of setting up an office for a new employee. In this sample application, each subtask is grouped into a processing branch that progresses independently of the other subtasks. For example, the MIS department can set up the phone while the purchasing department is ordering the computer. Problems completing one task won't affect the progress of a parallel task.


Properties of a Parallel Process

Parallel processes have the following properties:

Name. The name of the split or join.

Description. An optional longer description of the split or join.

Completion Script. A script that runs when the step is completed. The script must already exist before you can enter it in this property.

Parallel processing also has evaluation order windows, where you can rearrange the transitions leading from the split or join icons. You reach the evaluation order window by clicking the evaluation order tab at the top of the inspector window. The top item in the evaluation order window is evaluated first. Rearrange items using the arrow icons.


Adding a Parallel Process

To use parallel processing in your application, follow these steps:

  1. Drag a split-join icon onto the process map.

  2. Between the split and the join icons, add the desired activities.

  3. Drag transitions from the split to the activities. The transitions are similar to the conditions out of decision points and default to a value of true. For more information, see Decision Points.

  4. You can reorder the evaluation order of the conditions as you would for conditions out of a decision point. For more information, see Decision Points.

  5. Drag transitions from each of the activities in all branches from a split so that they eventually end up in the corresponding join.

The rules for using parallel processing activities are as follows:

  • A branch (or thread) of activities out of a split must eventually complete in its corresponding join. Activities that are part of a processing branch out of a given split must progress through that branch until the corresponding join.

    • They cannot exit out of the processing branch directly to an exit point.

    • They cannot transition out of the processing branch to an activity that is part of another processing branch.

    • They cannot transition out of the processing branch to an activity that is part of a subordinate nested parallel process, which would be therefore part of another processing branch.

    • If they are in a nested parallel process within a larger, higher-level parallel process, they cannot transition to an activity that is in the higher-level parallel process.

    • They cannot transition back into the split icon that started the processing branch they are a part of.

    • They cannot transition back to the activity that precedes the split icon.

  • If you delete a split or a join, the corresponding half icon is also deleted (you must also delete any transitions in or out of a split or join at the same time).

  • After you deploy an application to test or production, you cannot delete a split or a join.

  • You cannot loop on a split or a join.

  • You can have conditions set on transitions that come out of a join. However, if the join fails, then the transaction rolls back to the most recent activity in the process block. Similarly, if no condition out of a split evaluates to true, then the process rolls back to the most recent activity.

  • By default, when you first create a new split or join, the other half icon is given the same name. You can change this later to display different names.



Notifications

Notifications are email messages sent when the process reaches an activity. One use of notifications is to notify the person who needs to perform the next step in the process. Another use is to give a status (for example, information about the document's progress within the process) to the person who created the document. You can attach notifications only to user activities and end points.

When the end user receives a notification, the title of the notification is the application's title field, followed by the priority field. For more information on these fields, see The Application Properties Dialog Box.


Notification Properties

Notifications have the following properties:

Name. The name of the notification that appears in Process Builder.

Description. An optional longer description of the notification. For example, it could describe the step in the application where the notification happens.

Email Address(es). The email address for the notification. This can be a static email address, but more commonly would be a script that assigns an email address based on the instance of the process. For example, a script like emailOfCreator sends a notification to the email address of the person who created the process instance. If you want to use a static email address, you must put quotation marks (" ") around it. Multiple addresses are separated by commas.

Content Type. The format the email message's content is in. You can choose between text/html (messages sent in HTML format) and text/plain (messages sent in plain text format). If your mail system does not support HTML mail, choose text/plain, or your notifications may not work. In both cases, the character set is us-ascii.

Email Body. The content of the email notification you want to send. If you enter static text, you must put quotation marks (" ") around it. You can also enter the name of a script that returns the email message string.

CC. The email addresses for people to be copied on the email message. See the description above for the Email Address(es) notification property.

Subject . The subject of the email message. If you enter static text, you must put quotation marks (" ") around it. You can also enter the name of a script that returns the email subject string.

Character set. The character set for the email message.


Built-in Email Notification Scripts

As shown in Table 5-2, Process Builder provides built-in scripts that you can use for addressing notifications.


Table 5-2 Built-in Email Scripts

Script

Definition

emailOfRole(roleName)  

Sends email to the user who is performing a field role for a process instance.

roleName is the name of the field role.  

emailOfAssignees()  

Sends email to the user assigned to the process step.  

emailOfCreator()  

Sends email to the creator of the process instance.  

emailByDN(userDN)  

Sends email to the specified user DN (distinguished name).  

emailById(userID)  

Sends email to the specified user ID  



Exit Points


Exit points are steps at which a user can exit a process. An application can have several exit points. For example, a vacation request process might end with the vacation being approved or denied.

Exit points have the following properties:

Name. The name of the exit point that appears in Process Builder.

Description. An optional longer description of the exit point.

Exception Manager. If an error occurs, the Exception Manager invokes a new work item for correcting the error. Errors can occur in two cases: if a verification or completion script returns false, or if a runtime error occurs in a script (for example, in an assignment, expiration setter, or expiration handler script). See Exception Manager.



Transitions


After you place items from the Palette on your process map, you must connect them to show how data flows or how actions flow. You connect steps with transition lines that have directional arrows indicating their destination item.


Note You cannot use transitions with exception handling. For more information, see Exception Manager.



Types of Transitions

There are two basic types of transitions:

  • regular transitions (which do not depend upon conditions and are represented on the process map as blue lines)

  • conditional transitions (which depend upon conditions and are represented on the process map as green lines)

Regular transitions originate from activities and do not have a property where you can set conditions for their use. If you have multiple regular transitions from an activity, the process branches. The user chooses between transitions them by selecting a button on a form.

Conditional transitions originate from automated activities and decision points. They are not executed until a condition is met. If you have multiple conditional transitions, they are executed based on evaluation order and condition. Process Manager evaluates the conditions in the order specified and the first condition of a transition that it finds to be true is the transition it executes.


Note In addition to continuing on to the next step in a process, a transition can loop back to a previous step. To draw a looping transition on a process map, drag the arrow icon backwards to a previous step. For example, if at one step in a process a graphic artist produces a graphic, and the next step is manager review of the graphic, two transitions can lead from the manager's approval step. The first transition, if the manager approves the graphic, continues to the next step in the process. The second transition, if the manager does not approve the graphic, loops back to the previous step so that the graphic artist works on the graphic again.



Adding a Transition

To add a transition, follow these steps:

  1. From the arrow just beyond the upper-right edge of an icon on the process map, drag the arrow to another icon. Do not release the mouse button until you've moved the arrow to the inside of the destination icon.

    An arrow connecting the two steps appears on the process map. The arrows are blue if they begin in an entry point or activity, green if they begin in an decision point or automated activity.

  2. Give the transition a descriptive name.

    This name appears as a button on the form (unless the transition is from an automated activity or a decision point).

  3. Define the transition's properties in the Inspector Window.


Transition Properties

All transitions have the following properties:

Name. The transition's name is the name of the button on the form for the activity at from which the transition originates. The name typically describes something about the activity that is the destination of the transition. For example, a line that goes from "Create Graphics" to "Review Datasheet" might be called "Publish for Review" because when the graphics are done, the art department wants to publish the new datasheet for review.

Description. An optional longer description of the transition.


Setting the Property for a Virtual Transition

Transitions that lead from a user activity also have the following property:

Virtual Action. If set to true, no button associated with this transition will appear on the assignee's HTML form. A common use for a virtual transition is for activities that expire. If you set up an activity so that it expires after a certain amount of time, the expiration handler script might use this virtual transition to advance the process to another step. The advance occurs through JavaScript, without the involvement of the assignee. For more information on using JavaScript to move from one process step to another, see the moveTo function in Appendix AJavaScript API Reference.


Setting the Property for a Conditional Transition

Conditional transitions (from automated activities and decision points) also have the following property:

Condition. The condition the activity must meet before executing the transition. Conditional transitions can be scripts that return true or false (you can type either the name of the script or type the script itself into the condition property). Conditions can also be based on values of data fields. For example, if your condition is that the price field be over 1000, then your condition can be price>1000, where price is the price field. If the value of the price field is over 1000, then this condition is true.

The condition defaults to true for automated activities and for custom activities. If there is more than one condition, you can prioritize the conditions in the evaluation order window. For more information on prioritizing conditions, see Decision Points.


Example Using a True/False Field

If you have a field with true and false as its valid values, you can use the field name as a transition's condition. An example is shown in Figure 5-17. Suppose you have a field named exceeds_budget, and the value can be true or false. In that case, the first condition is "exceeds_budget," and the second condition is "true."

Figure 5-17    Example of condition set to a field

To make sure these conditions are evaluated in the proper order, open the decision point's Inspector window and click the Transitions tab. This opens the Transition Order window, as shown in Figure 5-18.

Figure 5-18    Example of the Transition Order window for a decision point

The process evaluates the first condition, "exceeds_budget," to see if the value of the field is true or false. If the value of the field is true, then the condition is true, and the process continues with the "exceeds_budget" transition. If the value of the exceeds_budget field is false, the process evaluates the next condition. In this example, the next condition is true. Therefore, its outcome is always true, but it is evaluated last. A final condition of true works like an "else statement." That is, the true condition automatically advances the process if none of the previous conditions are true.


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