This section provides the following general guidelines
for designing processes:
Order of implementationOperational
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:
Create the process diagram using abstract modelling elements
to represent the activities in the process.
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.
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.
Process designs for reuseTo
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.
Reuse of variablesTo
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.
|
|
|