The core of the Metastorm BPM Designer is the
process designer. Here you design the actual process, define
business rules, set roles and associate forms. The main components
of the process are where you start from, the steps or 'stages' that
will be traversed, and the endpoints. In Metastorm BPM terms each
'instance' of the process is a 'Folder', just as in the description
of a typical office process above.
Each folder will start at the start box which is
shown as a clapperboard icon. From here you have any number of
'Actions'. An action in a Metastorm BPM process will move a folder
from one stage to another.
There are also what we term 'loopback' actions
which allow editing of the folder without moving from one stage to
another.
You can think of a 'Stage' as a step in the
process, a folder resting on someone's desk, or a status of that
folder. All three descriptions are accurate and most of the time
all three apply. There are special stages, such as system stages,
where this is not strictly true. In the system stages for example
the system will typically define which action occurs next, or the
folder may remain here without being on anyone's task list until a
certain deadline is reached.
At each stage we can define to lists of roles.
The first and most important is termed a To-do list. The second is
a Watch list. These may be considered as Task lists, and Track
lists respectively. If a folder is on your To-do list there is
something you have to do, whereas the folder is on your Watch list,
it may just be a folder you may wish to look at but not action
directly. In many cases users will be tasked to perform certain
actions on certain folders, and their managers would track the
progress of their work without being directly involved with the
processing.
This to-do and watch lists are defined by a set
of roles. The role in Metastorm BPM can be either static or
dynamic. Static roles are merely the name that is applied to a
particular role, for example "administrator", whereas dynamic roles
can be defined in many ways, such as the actual data within the
folder itself. An example of this might be where we have a list of
users, and one user is selected from this list. That username can
be assigned to a variable in the folder, and that can be used in a
dynamic role. In this way we can allow users to select who will be
tasked to do a certain job.
In order to move a folder from one stage to
another, users or the system perform actions. User actions are
restricted by selecting the role or roles that may perform that
action. We may also select a form to be used for any user
action.
During this action we can also define how the
fields within the form behave, such as whether or not they are
optional, required, hidden or read-only. In this way we can define
the data that we force users to enter at each point in the process.
This allows us to ensure that the data we require for processing is
captured.
The system actions that exist are conditional,
timed and flagged. Conditional actions allow us to define a set of
decisions that are evaluated in sequence. The first conditional
action that evaluates to true will be executed by the system. This
allows us to route folders through our process automatically. Timed
actions, as the name suggests, will be performed at a specific
time. This time will typically be calculated based on a business
rules setting, and possibly from data within the folder itself.
Finally, flagged actions are triggered from elsewhere within this
process, other processes, or even from external system. Flags are
in fact the simplest method for integrating systems with Metastorm
BPM.
At each point in the process, when stages are
started, ended, when actions are started, and when actions are
completed, we are able to execute statements build using the Visual
Scripting editor (see below).
What is Metastorm BPM?
