Previous Next Contents Index


Chapter 2 Planning an Application

This chapter describes the issues to consider when you are planning an application.

This chapter includes these sections:


Planning Overview
Process Builder provides a powerful and intuitive visual environment to create and deploy PAE applications. This chapter describes the things to think about before you develop your application. For an explanation of completed applications, see the sample application chapters in this book.

To plan your PAE application, you need to do the following tasks:

  1. Decide on the sequence of steps involved in a process and whether you need to create subprocesses or custom activities.

  2. Define who the people involved in the process are and what roles they play.

  3. Decide whether you want to give people who aren't directly involved in the process access to some of the process information.

  4. Decide what data you want the application to track on forms, internally within scripts, and what you need to pass to subprocesses and to other programs using custom activities.

  5. Define a useful set of forms to allow users to complete each step, and if you like, to allow users to monitor the process.

  6. Decide which users and groups should have access to which forms.

  7. Decide if you need to write any special scripts for your application.

  8. Decide if you want users to be able to search the application, and if so, for which information.
Planning the Process Map
Before you can create a PAE application, you must understand the process you want the application to handle.

The best way to create an application is to examine your current process, automated or manual, figure out the steps involved, and then improve the process with PAE's automation and database capabilities.

For more information on Process Maps, see Chapter 4, "Designing a Process Map."

Entry Points
After analyzing the existing process, you should decide at what point(s) in the process you want to start your application. You can have more than one entry point, depending upon the process, but you need to find starting points that still let you capture all the data you need to capture. If you start halfway through a process, you may not have all the data you need to carry the process through.

For example, if you have a process for posting documents on a web site, you might have one entry point for documents that need to be converted to HTML, and another entry point farther through the process for documents that are already in HTML.

For more information on entry points, see "Entry Points" on page 77.

User Activities
Each step in the process that a user needs to perform is called a user activity. When you figure out the steps in the process, you need to decide which steps need to be performed by a person and which can be performed automatically.

For example, in the application that handles an employee's vacation request, you might have three activities:

Since these all require a user to take action, they are all user activities, not automated activities. For more information, see "User Activities" on page 78.

Automated Activities
If a step can happen automatically, you'll want to create an automated activity, instead of an activity that requires a user to perform an action.

For example, the Data Sheet sample application uses an automated activity to build the data sheet. The automated activity runs a script that looks up price information and creates an HTML form based on this information. This saves a user from having to enter the data. The next step of the process is an activity that presents a user with the data for approval.

For more information on automated activities, see "Automated Activities" on page 84.

Custom Activities
You need to determine if you want to create a custom activity to connect to external services, to integrate information from other services into your PAE application, or to extend Process Manger to other services. For example, you can use custom activities to connect to Netscape Application Server Extensions for CICS or SAP. A developer needs to write a Java class, write an XML file that describes the Java class, and put the two together in a .zip or .jar file. You need to decide what data you need to transfer to the external component, and what data you need to receive back.

For more information on custom activities, see "Custom Activities" on page 91.

Subprocesses
You need to determine if you want to create a subprocess that can be used across your environment. A subprocess is a fully functional PAE application that can be called from within another PAE application. The Loan Management sample application, which controls the process of approving a loan, calls the subprocess Credit History. Credit History can be run either as a subprocess of the Loan Management application or as a stand-alone application. For more information on subprocesses, see "Subprocesses" on page 86.

Decision Points
You need to determine if the process has a single set of steps, or if it branches because of conditions. Decision points are where the process branches. For example, in the Data Sheet sample application, there is a decision point where if the price of the product on the data sheet is less than $1000, the data sheet is immediately published. However, if the price is greater than or equal to $1000, the data sheet must be approved by the Vice President before being published.

For more information about decision points, see "Decision Points" on page 100.

Parallel Processing
You need to determine if you want to use parallel processing, which allows your process to have two or more branches so that two or more activities can execute in parallel. In the Office Setup sample application, which controls the process of setting up an office for a new employee, 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. In complex processes, there can be several levels of nested parallel branches.

For more information about parallel processing, see "Split-Join (Parallel Processing)" on page 101.

Exit Points
You also need to decide where to end the process. You may have more than one exit point. For example, in the Time Off Request sample application, an employee's request for vacation time can end three ways: the vacation is approved or denied by management, or cancelled by the employee. Those three outcomes translate into three exit points in the application.

For more information on exit points, see "Exit Points" on page 105.

Transitions
Once you have the basic steps of the process in place, you need to determine the flow between them. The connections between steps are called transitions, and are represented on the process map by arrows connecting the steps. Since a decision point requires the process to branch, each branch has a transition leading to a different step.

For more information on transitions, see "Transitions" on page 106.

Notifications
Once you have the steps and transitions in place, you need to think about where in the process you want to set up email notifications, what information the notification contains, and who needs to receive the notifications. The notifications are sent as soon as the process reaches the step.

For example, in the Time Off Request sample application, the employee is notified if the vacation is approved or denied at the exit points for approved vacation and denied vacation. At the exit point where the employee cancels the vacation, no notification is required.

For more information on notifications, see "Notifications" on page 104.

Exceptions
Exception handling allows the administrator to intervene manually if errors occur. Every process step (other than an entry point) must be assigned an Exception. See "Exception Manager" on page 97 for more information on exception handling.


Planning Assignments
You need to look at each activity and determine who needs to do it. The person who performs an activity is called the assignee. You determine an activity's assignee by asking the following questions:

Once you have the answers to these questions, you know who needs to be assigned to activities, and that information helps you set up the groups and roles you need for an application.

For more information on assignments, see "Setting Activity Assignments" on page 81.

Planning Groups and Roles
Once you have figured out who needs to participate in the process and what they need to do in the process, you need to think about your groups and roles. If a user activity can be performed by any one person in a group, you must set up a group to assign the activity to.

For example, in the Office Setup sample application, one user activity is "Order Computer." Anybody in the purchasing group can perform this step, so the activity is assigned to a group called Purchasing.

If you have an assignee that varies by process instance, and the information needed to identify this person is stored in a data field for each process instance, you can set up a field role. For example, in a process where a web designer is working with a graphic artist on a web page, you could create a field role for the artist. The form initiating the web page art could have a field on it where the designer fills in the artist's name. The application then stores the artist for a particular process instance, and uses it throughout the process.

To figure out what groups and roles you need, ask the following questions:

There are four default groups and roles for an application:

If you need additional groups and roles, you need to create them. If the group already exists in your corporate user directory, you can create a group for your application that is tied to the group in the corporate user directory.

For more information on groups and roles, see Chapter 5, "Defining Groups and Roles."

Planning for Monitoring
In addition to the assignees in an application, you can also let other people who aren't directly involved in the application monitor the progress or view information on a read-only basis. If you want to give these nonparticipants access to information, you may need to create additional groups and roles.

Planning Delegations
For some activities, you may want the assignee to be able to delegate the work item to another user. If you want the assignee to be able to delegate, you must set the activity's Allow Delegation property to yes. Before allowing delegation, though, you need to think about whether the activity should be delegated. For example, if you had a process for approving departmental salary increases, you may want the head of the department to approve the increases personally. In this example, you would not allow delegation.


Determining the Data Requirements
After you have defined the steps in your process, you need to define what data you need to track. Once you've determined the data you need, then you can create the process' data dictionary using Process Builder. The following questions help you determine what data fields you need:

For each data field you create, you need to think about how to present it to users on the form (for example, is it a text field, radio buttons, or a file users need to attach?). You also need to think about how it will be stored in the database (is the data type text, a date, or an integer?)

For more information on data fields, see Chapter 6, "Defining Data Fields."

If the standard data field classes provided with PAE do not fit your needs, you can create your own. For example, you can use custom data fields to access external data sources and to generate dynamic content at entry points. To use custom data fields you need to write Java classes that implement the field.

File Attachments
Some information your application gathers may be files users contribute by attaching them to forms. You create specific data fields for file attachments. If you are using file attachment data fields in your application, you must plan for their use:

For more information on file attachments and the Enterprise Server, see "Setting Up the Content Store" on page 156.


Planning Forms
Once you have thought through the process steps, the data requirements, and the people involved you need to think about the forms to use to collect the data, move it from person to person, and display the data to people involved in the process.

You can design a different form for each role or group at each step in the process. Different forms let you display only the information needed by a particular person or group. For example, the assignee of an activity often has a special form which has more information on it than the forms for other people involved in the process, or people who are monitoring the process. Often the creator of the process instance has forms so he or she can follow the process instance's progress.

You create forms in a form wizard in Process Builder. You add fields to the forms in a form editor by dragging them from the data dictionary to the form. You need to decide which fields to put on a form, and whether they can be edited by the assignee or not.

For more information on forms, see Chapter 7, "Designing Forms."

Planning Access to Forms
Using form access you control which users see which forms. To plan form access for a process, use the following questions:

When you have the answers to these questions, you create the association between an activity, the role or group, and the form in the Form Access window.

For more information on form access, see "Setting Access to Forms" on page 172.


Planning Custom Scripts
Many of an application's actions are performed by JavaScript scripts. For example, JavaScript assignment scripts determine which user is assigned to a step. Process Builder includes some standard scripts; however you may find you need to write additional JavaScript scripts to perform actions specific to your application. In planning these scripts, consider what kind of scripts you need to write and whether you already have similar scripts you can base them on. Scripts you plan to reuse or plan to call from other scripts are stored in the Toolkit folder.

For more information on using scripts, see Chapter 8, "Using Scripts."


Planning Searches
If you want users to be able to search for information about process instances, or for specific field information, you need to design your application so that searching is allowed. Use the following questions to help you plan your searches:

For more information on searching, see Chapter 9, "Setting Up Searching."


Planning Deployment
After you have completed the application, you may want to deploy it for testing before rolling it out to a production server. In test mode, the person who designed the application can do a walkthrough to see that all steps are correct and that the information flows through the system correctly. In test mode, all activities are assigned to the creator of a process instance, so you cannot test form access fully until you deploy in non-test mode. Only then does the application use all the groups and roles.

PAE has two deployment stages: development and production. When you deploy to development, you can still change everything about an application. However, once you deploy to production, some information about the application can no longer be changed.

After you have tested the application and made any necessary fixes, you can deploy it for use in real-world environments. Once the application is deployed to end users, it usually leaves the builder's control. However, even after end users are using it, the builder and the process administrator need to communicate whether the application needs changes, if it needs to be replaced, or if it is made obsolete.

For more information on deploying applications and editing deployed applications, see Chapter 10, "Deploying an Application."

 

Copyright © 1999 Netscape Communications Corp. All rights reserved.