]project-open[ : @This Wiki

Welcome, Unregistered Visitor

User Profiles

8 registered users

in last 24 hours

]po[ Petri-Net Workflow

This package lets you define the process that your projects, vacation requests, invoices or any other important object of interest must go through to avoid that any cases falls through the cracks.

Order Fulfillment Workflow

What is a Workflow?

Workflows are a way to formalize and understand any business process involving multiple steps and complex participation amongst workers to achieve the final result. In a manufacturing or engineering setting the workflow can be quite rigid and inflexible, while in service and consulting industries changes can be rapid and a process completly out of order and coordination among project members can take a diverse/infinite number of steps and paths towards completion. ]project-open[ workflows are adaptable and customizable to account for and attempt to portray the actual realities of the business world.

Elements of a Workflow

]po[ workflows are based on the Petri-Net formalism, inspired by an article from W.M.P. van der Aalst. A ]po[ workflow consists of the following elements:

Transitions - the square boxes in the diagram above.
Transition represent actions. Actions can be performed either by a user, or by the system.
Places - the little circles in the diagram above.
Places represent the "state" of the workflow.
Arcs - the arrows that connect transitions with places.
Guards - logical conditions on arcs, written in [brackets] in the diagram above.
Guards allow for implementing business rules and other logical conditions.

]po[ supports several types of transitions, as depicted in the figure above:

User transitions:
These are the most common forms of transitions. These transitions will appear in the Inbox (see below) of all assigned users, who can "start" the transition to indicate that they have started the activity, and then "finish" the transition.
Automatic transitions:
There is no user interaction with these transitions. However, the transitions can call API functions to perform actions.
Timed transitions:
Time transitions fire at a specified time. They are used to implement timeout logics etc.
Message transitions:
Message transitions wait for a trigger from outside the workflow to continue. This can be used to integrated ]po[ with an external application.

Using these basic elements, the Petri-Net formalism allows to specify arbitrarily complex processes. Petri-Nets are known to be sufficiently powerful to represent even workflows specified in workflow formalisms such as BPMN and EPC.

Workflows and Business Objects

In ]po[, every workflow is related to a business object such as a project, vacation request, [translation task] etc. There are more then 40 business objects in ]po[. There can be more then one active workflow per business object.

There are several links between the business objects and it's workflow:

Status: The workflow can modify the "status" of its business object:
For example, a vacation request may "requested" after the user has entered the data, and may only receive the status "confirmed" if the employee's manager has approved the request.
Type: The "type" of the business object determines the workflow:
For example, both "vacation request" and "sickness leave" are sub-types of the user absence object type. However, a vacation request should be handled by a "vacation_request_wf" workflow for approval of the employee's supervisor, while a sickness leave request just needs to be confirmed by the HR department via a "sickness_leave_wf" workflow.
Variables: The workflow can access the business object's fields.
"Guard expressions" can use the business object's fields to determine if the workflow should take one route or another.
Input Fields: Storing user input captured during the workflow:
Workflows frequently requires user input that needs to be stored somewhere. The business object provides a suitable space to store this information, in particular in combination with the DynField dynamic field extension that allows adding new fields to business objects.

Starting a Workflow for a ]project-open[ Objects

With ]project-open[ V3.4.0, the following objects already include a workflow integration:

Project,
[Timesheet Confirmation Object],
[Freelance RFQ Answer],
Absence (Vacation Request),
Expense,
[Translation Task] and
Helpdesk Ticket.

In order to start a workflow for these objects, you have to:

Create a suitable workflow in the Admin -> Workflows
Go to Admin -> Categories -> Intranet <Object> Type and enter the workflow key into the "String1" property of the categories.

For example, you may create a new workflow with the key "simple_vacation_approval_wf" designed for the approval process of absences of type "Vacation". In order to enable this workflow, please enter the "simple_vacation_approval_wf" into the "String1" field of Admin -> Categories -> Intranet Absence Type -> "Vacation". The next time you create a new "Vacation" absence, a workflow is automatically created.

Please note that the WF integration of the objects above includea "skipping" the first WF transition. This trick allows to design workflows with a clean optical appearance with the first transition representing an "Edit Object" action that is not necessary directly after the creation of an object.

The Inbox - Interacting With Users

The "Inbox" is the interface between the user and the workflow. The inbox will show a new task every time that a user needs to perform a certain workflow action - for example approve a vacation request. This way, the inbox acts like a cockpit for every ]po[ user and allows the user to take actions (approve or reject vacation requests) to follow-up the status of the users's own requests.

The inbox can also send out Email notifications to user for each new task.

Assignments - Who Should Take Action?

Real-world experience with workflows shows that the assignment of users to actions/transitions is suprisingly complex. Assignments depend on the workflow transition (approving a project budget vs. executing the project), on the type of workflow (PMs approve vacation requests of their project members, HR approves sickness leaves) and on the context (project budgets > 50.000 EUR need to be approved by Senior Managers, while the Account Managers may approve smaller budgets).

In order to deal with these real-world requirements, the ]po[ workflow provides several options to assign a transition to a user:

Static assignment to a user or profile:
Assign a specific WF transition to a single user or a group of users.
Dynamic assignment as part of the WF:
]po[ allows the assignee of one transition to specifiy the assignee for the next transition.
Custom assignments via Callbacks:
Callbacks allow to implement custom assignment logic, for example in the case of a vacation request:
"All PMs can approve the vacation request who are the PMs of a projects in which the user is participating".

Panels - Working with User Input

Once a user is assigned to a transition and he clicks on the link in his Inbox, the user is transferred to a page ("panel") where he or she can interact with the system - pressing an "Approve" button, entering a comment or filling out a form.

The ]po[ workflow provides a number of default panels:

Default Start/Finish Panel:
Allows the user to say "start - I have started the work on this transition" and "finish - I have finished the work on this transition".
Default Approval Panel:
Allows the user to choose Yes/No to a specific question such as "Approve this Vacation Request"?
Default Assignment Panel:
Allows the current user to assign other users to upcoming transitions.
Business Object Panels:
Many of the normal edit screens for ]po[ business objects can be used as a panel.
No development is required in this case, and the DynField package allows to configure the fields that specific user profiles can enter.
Custom Panels:
Panels are nothing but a normal TCL screen, so developers can use the full power of TCL and the ]po[ system to develop panels. Once developed, such a TCL panel can be assigned to one or more workflow transitions.

Callbacks - Taking Action

"Callbacks" is the mechanism that allows ]po[ workflows to modify its underlying business object and the system in general. For example let's assume that the HR department has approved a vacation request. We now want to set the status of the vacation request to "approved". Technically, a callback is nothing but the name of a PL/SQL procedure, and the following PL/SQL procedure is readily available for this purpose:

im_workflow__set_object_status_id(case_id, transition_key, object_status_id)

The "case_id" and "transition_key" variables are filled in by the ]po[ workflow automatically, so that a developer only needs to specify the "object_status_id". Looking at Admin -> Categories -> Intranet Absence Status we see that the status "active" has the status_id=16000.

Other callbacks are used to assign users to otherwise unassigned transitions and to implement the business logic for "guard" decisions.Please see the Workflow Developer's Guide for a detailed description of callbacks.

Technical Workflow Documentation

Workflow Concepts Reference - introduction.
Workflow Conceptual Guide - transitions, routing, and- and or joins.
Workflow Developer's Guide - explaining callbacks and other advanced topics
Workflow Maintainer's Guide - operating workflows
Petri Nets in the Workflow Package - more on and/or splits.

and for reference:

Petri Net Workflow Initial Requirements - workflow requirements.
Workflow Design Documentation - designing the package

Pre-configured Workflows

These workflows come pre-defined (as of version 3.4) as part of the basic ]project-open[ download and install.

[Expense Approval]
[Vacation Approval]
[Timesheet Approval]

References

Related Help

Contents