|
Architecture
The Process Management Layer
 Workflow
Business Process Management or BPM is the heart of LIT Process Automation and
drives all transactions as formal processes called workflows. Any external
event can initiate a BPM workflow. These events are matched with specific
Master Workflows to create a workflow instance within the core system. Events
can be internal to the system, produced by user application screens, or by
external communications.
Once a workflow Starts, processing activities are associated with workflow
states or tasks to complete the work.
As explained earlier, there are two important concepts in workflow, States and
Waits. States are points along the process flow where the process must wait for
the completion of a task (or set of tasks) before continuing to follow the flow.
States require waits while tasks may require waits.
States and Waits
All the boxes in a BPM workflow are called nodes. Nodes represent states,
tasks, decision flow splits and joins. State nodes include the concept of a
wait and could be called a wait state. Tasks are like states if their
associated action can be directly executed and may include a wait. Otherwise,
tasks execute without waits following the workflow stopping at a wait state,
join node, or the end of the process.
BPM Workflow Masters
BPM Workflow Masters are the road traveled by any automated process.
Workflow Masters are editable and version controlled. They can be provided and
deployed into the Workflow engine from a Process Application Suite or a
graphical editor via an XML file.
Versioning is maintained in the workflow engine which allows current version
flows to be completed while new instances will begin with the newer version.
Master workflows are named and owned by a company and are available only to the
company. Workflows may be copied and edited, and then given a new name. If the
name remains the same, a version number is incremented and used as the new
master. Masters can be owned by a community which is available to all companies
in a community. Masters can be owned by “Public” which allows everyone access.
Any master or version level can be selected as the default flow for a suite
Automation Process transaction. Suites can define and deploy as many workflows
as required. Master workflows and any associated actions from within any suite
are available to other suites within the same company restraints.
Workflow Instances
Workflow Instances are maintained in a database to provide data persistence for
each current process flow. Workflow instances include a context object where
user-defined fields can be used to link the index to a suite object. Context is
saved in the database with the instance and is available for searches,
processing, and status.
Decisions & Rules
Most, if not all, decisions are enacted as part of the workflow. In this way,
transaction logistics are graphically represented. Workflow decision points are
where there is more then one direction of flow to select. Normally, these
decisions are simple and are executed within the workflow definition. For more
complex decisions, toolkit actions may be called to execute more complex rules
to define the next branching workflow transition.
Optionally, decision points may be extended by employing an external rules
engine. As before, the final outcome should define a branching workflow
transition.
Nodes & Task Nodes
Nodes (boxes) are used to represent action points or steps. Action calls can be
associated to the entry or exit of a node. If the node is a state, which by
definition includes a wait on entry, action calls can be associated before or
after a signal to proceed beyond the wait point.
Task Nodes can be associated with actions which require a wait. The task will
be saves to the Work Queue for any external processing.
Action to Task Node Association
Actions are calls to a modular piece of code which is provided as part of a
Process Automation Suite. Workflow Task Nodes call actions by name. The suite
provides a single action call which selects from a toolkit library database a
specifically named action to execution. This is called warehousing.
The three standard call types include Database Updates, Communication, and those
calls used to manipulate the workflow engine. Yes, even the workflow calls are
developed as a suite. Any other call may be included in a suite library.
Incoming communication listeners use the same library calls to create new
application and workflow instances. The same library is available to
application screens in the workstation management layer.
Application Database
All Process Automation Suites include its own set of database tables. These
tables are available to any other suite via the action library. Any new direct
access should be made by a new library’ed action.
Timers in LIT are part of workflow. And can be included and set within the
process flow. Recovery timeouts work in the same manner.
|
