Chapter 3   Planning an Application


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

This chapter includes these sections:

• Planning Overview

• Planning the Process Map

• Planning Assignments

• Determining the Data Requirements

• Planning Forms

• Planning Custom Scripts

• Planning Searches

• Planning Deployment

Planning Overview

---

Process Builder provides a powerful and intuitive visual environment to create and deploy Process Manager 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 Process Manager 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 Process Manager 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 Process Manager's automation and database capabilities.

For more information on Process Maps, see Chapter 5 "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.

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:

• Manager approval, where the manager either approves the request or asks for clarification.

• Clarification, where the employee provides any requested clarification

• HR approval, where HR approves the request

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

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.

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 Process Manager 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.

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 Process Manager application that can be called from within another Process Manager 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.

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.

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).

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.

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.

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.

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 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:

• Who needs to perform this step?

• Should this step be assigned to a single individual, or to a group of individuals so that any one of the group can perform the work item?

• Is this an activity where a number of individuals need to approve some information before the process continues (parallel approval)?

• Does the person who performs the activity vary depending upon the process instance? For example, a vacation request might have an activity for the manager's approval. The manager who needs to approve the vacation, depends on which employee requested the vacation for a particular process instance. In other cases, the assignee might be the same regardless of the process instance. For example, if every purchase over a certain amount needs to be approved by the Chief Financial Officer, the assignee of that approval activity is the same regardless of the process instance.

• If the assignee depends upon the particular process instance, what information do you need to have in order to determine who the assignee should be?

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.

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:

• Who in the company can initiate a process?

• If approval is needed, what needs approval and who needs to do it?

• If you need to use a group of people in your application, is the group already defined in the corporate user directory?

There are four default groups and roles for an application:

• creator (the person who initiates a process instance)

• admin (people allowed to administer the application)

• all (any interested party)

• trusted users (people allowed to connect to the subprocess)

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 6 "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:

• What information do assignees need to see to perform each step?

• What information do you need to gather from assignees at each step?

• What data do you want to have a record of?

• What information do the scripts in the application require?

• If you're using subprocesses, what information is passed between a parent and child process?

• If you're using a custom activity, what information is passed between the Process Manager application and the external component or service?

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 7 "Defining Data Fields."

If the standard data field classes provided with Process Manager 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:

• You must define a URL on your Enterprise Server to store these documents.

• You must set the Enterprise Server's access privileges for the URL, so that the documents are available to a public user.

  Setting up the public user allows all users to upload documents to that area. Web Publishing must be turned on in your Enterprise Server.

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

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 8 "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:

• At what step in the process is the form used?

• Who views the form (is the viewer the assignee, a participant in the process, or an observer?) If the viewer is a participant in the process, what group or role do they belong to?

• Do you want the form to be viewed by multiple groups and roles?

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.

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 9 "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:

• Who do I want to allow to search application data?

• What fields do I want to allow people to use for searching? For example, in an application for publishing documents to a web site, you might want to be able to search based on the author's name or the document title.

For more information on searching, see Chapter 13 "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.

Process Manager 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."