define the application workflows [since 2.0]
Workflows are designed to achieve processing intents
of some sort, such as physical transformation, service provision,
or information processing.
OBEROn implements a workflow management system: it manages and defines
a series of tasks within an organization to produce a final outcome
or outcomes. It allows you to define different workflows for different
types of jobs or processes. At each step in the workflow,
one individual or group is responsible for a specific task. Once
the task is complete, OBEROn ensures that the individuals responsible
for the next task are notified and receive the data they need to
execute their stage of the process.
Business Administrators create Workflow definitions that contain
a set of activities (steps) connected with links that allow branching
within the process. Users
enabled to manage Workflows (see user
access rights  )
can design a new workflow definition by clicking the "Add
new Workflow" button from the "Context Design" menu.
The access rights tab allows to define users, teams
and assignments enabled to execute the workflow (create a process
for this workflow).
A workflow can have global parameters, you can define
them in the "Parameters" panel and set a default value
for each one. Global parameters are common to all workflow steps
and can be accessed during the workflow execution.
workflow design: steps and transitions
By the workflow designer tool, the business administrators can define
the workflow activities and trace the information flow. The workflow
elements are called steps and links between them are called
transitions.
With a mouse right-click on the canvas the designer can add new
steps choosing the step type from the list; types of step that he
can use in the design are the following:
| Step Type |
Description |
| start |
there will be one and only one
starting step and this will be the first step executed when
a workflow instance (process) is started. This step is mandatory
and automatically included. |
| action |
are the main steps, because they define the workflow user
actions; these tasks will appair in the dashboard of all user
enabled to perform the operations (members of enabled team
and assignment listed in the step "Execute Rights"
panel). [1 input - 1 output]
|
| system |
are actions associated to a
program or to an external batch process, performed directly
by the system. [1 input - 1 output] |
| lifecycle |
perform a specific lifecycle action on the primary object associated to the workflow-process at runtime. [1 input - 1 output] |
| decision |
is a step where users decide what the next steps
will be taken, according to their choices (for example with
a poll between them).The decision possible choices corresponds
to the step output transitions. [1 input - N outputs] |
| notification |
allows to send notifications
to some recipients (user, assignment, team members or external
email address) [1 input - 1 output] |
| split |
is an automatic system step that decomposes the
information flow in two or more branches; this element has only
one input and two or more output paths. [1 input - N outputs] |
| or-join |
is a system step that unifies
two or more branches of the information flow; this step will
be overcome and so the execution will go forward to next step
when ONE of the input tasks will be completed. [N inputs - 1
output] |
| and-join |
is a system step that unifies two or more branches
of the information flow; this step will be overcome and so the
execution will go forward to next step when ALL input tasks
will be completed. [N inputs - 1 output] |
| stop |
when the process reaches this step the execution
of workflow will be terminated independently from other branches.
You can have more than one stop elements in the workflow but
note that only one of these will be executed. If a workflow
branch should end without stopping the global execution then
simply leave the last action of this branch unconnected to other
elements. [1 input - 0 output] |
If the steps are unlocked (use "Lock/UnLock Steps" popup
commands), he can also drag the element in the preferred position
on the graph. Alternately it is possible to move a single step dragging
it with mouse while the ALT key is kept pressed on the keyboard.
The "Zoom In/Out" and "Normal View"
functions allow to enlarge, reduce or go back to the default visualization
aspect ratio.
Moreover, the designer can create flow transitions from a
given step to the next: right-click on the element and select the
"Start Transition.." option on the popup menu, then right-click
the destination element (step) and select "Transition (<from
step name>)" [or "Abort Transition" to cancel
the first selection]. The above items in the popup menu are visible
only if the step allows new input/output transition; for example
an "action step" allows only one input and one output
transitions while a "split step" allows only one input
but unlimited outputs.
After created, he can edit the transition properties
in this way: move the mouse over the transition until it is highlighted,
double click on it or right click and select the popup option "Edit
Transition".
Transitions between steps can be created/edited also inside the
step definition form; in particular you can set a name and a description
for each transition but you can also add a check trigger
and an action trigger to them. These programs will be automatically
executed to check if some particular conditions (defined in the
program) are satisfied and to perform additional actions during
the transition between current step and the next (stepfork).
The alignment functions allow to align steps on the
canvas: just keep pressed the CRTL key and select the steps with
mouse (they will be highlighted in red color), then right click
on the canvas to see the "Alignment" option on the popup
menu, finally select the alignment mode.
Enabled users can create a Workflow Instance called Process: when
a workflow is launched, the workflow instance (process) and all
the constituent activity instances are automatically created. Only
valid workflows can be executed, so after the flow design you can
check the validity of the workflow with the "Validate"
button. The checks performed control if all steps are rightly connected,
if you have defined the start step and if the flow doesn't generate
deadlock loops.
The designer can specify a name, a description
and a duration (days-hours-minutes-seconds) for each step
and other options according to the step type. The duration is the
maximum time for execution and it is used to compute the expiration
date based on the step start time.
In addition, the designer can define some local parameters
available only for the current step. A local parameter can have
a default value or it may receive the value from a workflow/process
global parameter ("Get Value From"). When a step completes
his execution, local parameter values may be copied back into a
process global parameter ("Copy Value To") and so available
for next steps.
action-step
Additional parameters for action steps are:
- completion: is a way that determines when the step is completed
| |
any |
when a single user performs the related action,
the step is considered as completed |
| |
all |
it is required that all users in the "execute
rights" list perform the step action |
| |
min |
it is sufficient that a (declared) minimal number
of users complete the step activity |
- href: the url associated to the step action;
when a user is enabled to perform the step activity, he can find this
link inside the user dashboard (or user activity list) during the
step execution. (*)
- label: the action label for the url link (usually is dictionary
translated) (*)
- completion trigger: a program automatically executed every
time a single user complete the step activity ( EVENT = USER_COMPLETE_ACTION
)
- holder execute: a workflow can be associated to an object
instance, if this flag is checked, the object holder will be enabled
to perform the step action and will be included in the process-step
execution user list.
- notify: send a notification to all recipients [users/teams/assignments
in the execution list] as soon as the step starts running (mail Subject
will be the translated step label (*); you can set a "SENDER"
parameter for the step). When enabling this option, the "Mail
Body" panel is showed for editing the mail body text (*).
(*) substitution keywords can be
used:
- object data replacements: <..any object get_option..> (i.e.
<id>,<class>,<currentstage>,....)
- dictionary replacements: <[dict_section,dict_key]>, <[dict_key]>
- step or process parameters: <{parameter_name}>
- mixed replacements: <[dict_section,<..any object get_option..>]>,
<[<..any object get_option..>]>
The users that are involved during the
step execution are listed inside the "Execute Rights"
panel; in particular you can add user/team/assignments to the list.
When a action step is executed (becomes a process-step) and the
completion mode is "all" or "min", the list
of users is explicited replacing the assignments/teams with their
members and eventually adding the object holder.
system-step
Additional parameters for system steps are:
- executable: abosolute path of a system executable file
(.exe,.bat,.sh,.com.....)
- action program: a OBEROn program to execute
you must define one of them or both.
lifecycle-step
You need to define the operation automatically performed by the system
on the primary object lifecycle: progress , regress , setstage (+ the stage name) , validate / ignore / refuse (+ the validation name)
decision-step
Like for action steps, the users that are involved
during the step decision are listed inside the "Execute Rights"
panel; additional parameters for decision steps are:
- type: is a way that determines how the decision is performed
| |
single |
only one choice is allowed; may be represented
as a radio button group |
| |
multiple |
the user can select more than one option (or transition);
represented as a checkbox group |
- completion: is a way that determines when
the step is completed
| |
any |
when a single user provides the decision, the
step is considered as completed |
| |
all |
it is required that all users in the "execute
rights" list make the choice |
| |
min |
it is sufficient that a (declared) minimal number
of users make the choice |
- href: the url associated to the step decision
page; when a user is enabled to make decision, he can find this link
inside the user dashboard (or user activity list) during the step
execution. (*)
- label: the action label for the url link (usually is dictionary
translated) (*)
- completion trigger: a program automatically executed every
time a single user makes his decision/selection ( EVENT = USER_COMPLETE_ACTION
). This trigger is also executed at the step completion to let the
system make the final decision according to the user choices. (EVENT
= STEP_DECISION )
- holder execute: a workflow can be associated to an object
instance, if this flag is checked, the object holder will be enabled
to perform the step decision and will be included in the process-step
execution user list.
- notify: send a notification to all recipients [users/teams/assignments
in the execution list] as soon as the step starts running (mail Subject
will be the translated step label (*); you can set a "SENDER"
parameter for the step). When enabling this option, the "Mail
Body" panel is showed for editing the mail body text (*).
(*) substitution keywords can be
used:
- object data replacements: <..any object get_option..> (i.e.
<id>,<class>,<currentstage>,....)
- dictionary replacements: <[dict_section,dict_key]>, <[dict_key]>
- step or process parameters: <{parameter_name}>
- mixed replacements: <[dict_section,<..any object get_option..>]>,
<[<..any object get_option..>]>
notification-step
When this kind step runs, a notification mail will
sent to the "Recipients"; additional parameters for notification
steps are:
- subject: the mail subject (*)
- language: when specified this language will be used for
all recipients, otherwise for each user/team/assignment will be
used the default language.
- body form: it is a form used to generate
the mail body text
You can set also a "SENDER" parameter
for the step or add more external mail addresses setting
the "to" / "cc" , "bcc" step parameters.
Their values are lists of mail addresses separated by comma (for
example: "to" = "mail1@domain.com,mail2@domain.com,\"Name
Sur3\" <mail3@domain.com>" )
The "Mail Body" panel is also showed
for direct editing the mail body text (*).
(*) substitution keywords can be
used:
- object data replacements: <..any object get_option..> (i.e.
<id>,<class>,<currentstage>,....)
- dictionary replacements: <[dict_section,dict_key]>, <[dict_key]>
- step or process parameters: <{parameter_name}>
- mixed replacements: <[dict_section,<..any object get_option..>]>,
<[<..any object get_option..>]>
and-join-step
Additional parameter for and-join steps is:
- threshold: is the minimum number of input steps to be completed
for the step completion. Input steps are connected to the and-join
step by transitions, if some of this transitions are marked as "required",
the step may result not completed even if the threshold number is
reached. You can set the "required" condition on a transiction
setting the flag on the "R" column; required transitions
are drawed with a different color on the workflow canvas.
or-join-step
Additional parameters for and-join steps are:
- stop others: the or-step is completed when only one input
step is completed; if this flag is enabled the others input steps
will be stopped.
- expire others: the same behaviour of "stop others"
but it will force the other steps to the expired condition.
Notes:
You can create loops employing the split and the join
elements; in details, the join element can receive the loop transition
as input while the split element can manage the loop conditions
like in the following example.
When the system validates the workflow, it requires the presence
of a check trigger at least in the feedback transition, otherwise
an infinite loop is surely generated during the execution. Of course,
this doesn't avoid infinite loops because depends from the trigger
program, but represents a first level control. Best practice is
to add check triggers also in the other split transitions which
should represent complementary conditions respect to the retroactive
path.
Equivalent workflow administration can be made with
OOQL commands
.
|
