Process design guidelines

Operational efficiencies can be gained when creating a process by implementing general details first, and addressing more specific details later. The following suggested workflow is effective for minimizing the effort required to support changes that are made to process diagrams when initially mapping the business process on the process diagram:

1. Create the process diagram using abstract modelling elements to represent the activities in the process.

2. After the activities of the process are represented and the routes are drawn to show the order of execution, replace the abstract elements with operations and event types.

3. Create variables and configure the properties of the operations as required.

   This order of implementation is effective for the following reasons:

   • Abstract modelling elements can be easier to work with when initially drawing the process diagram because the intended representation of activities is flexible.

   • The order in which operations are executed should be determined before they are configured because their order affects the flow of data, which informs the configuration of the operations. Changing the order before you configure the operations does not require reconfiguration of the operations.

     Additionally, modelling the business process using abstract modelling elements requires a different skill set than implementing the model with service operations. These tasks can be performed by different team members that play different roles.

To maximize resources at design time, as much as possible, you should develop processes so that they can be initiated by other processes.

When processes are activated, they are available as services that you can initiate from other processes. When a process’s service is called from another process, the called process is a subprocess.

If more than one of your business processes include a common pattern of activities, you should implement the common activities as a separate process and use it as subprocesses. The end result of calling the subprocess rather than including the common pattern of activities in each process is identical. However, when you use subprocesses, you only need to develop common patterns once.

If you are planning multiple processes at the same time, you can realize commonalities before you create the process diagrams and integrate the subprocess architecture into your plans immediately.

If you have already created a process and later realize that a new process that you are planning uses a common pattern of activities, you can implement the subprocess architecture retroactively. You can isolate the common activities from the existing process in a new process by copying. You then replace the common activities in the existing process with the subprocess’s invoke operation.

To make efficient use of RAM and space used in the LiveCycle database, when possible you should reuse variables to store process data. Each variable that you create uses RAM at run time, and, for long-lived processes, space in the database for persisting the data.

Reusing variables involves saving different data to a variable at multiple points the process. Each time new data is saved to the variable, the existing data is overwritten. Save new data to a variable only when the existing data is no longer required in the process.

For example, a process routes form data to a series of users in a process. Each time a person submits form data, the data is saved in the same xfaForm variable because the data that was submitted by the previous user is no longer required in the process.

To conserve memory and database storage, you can also keep the number of complex data types to the minimum required, and use simple data types where possible.