This article presents the ]project-open[ "Petri-Net Dynamic Workflow" and explains the role that this component will play in future ]po[ releases. Target audiences are ]project-open[ consultants and partners, and enterprise software architects in general.
Why Use a Workflow?
A dynamic workflow represents a "variation point" in the ]po[ application: a place in the application where a ]po[ consultant can adapt the application behavior to a customer's needs. In particular, workflows represent variation points in the sequencing of actions and processes, as opposed to functional variations (Package Manager), data model variations (DynFields), parameters, security configurations, and functional variation points (user exits).
What is a ]po[ Workflow?
A ]po[ workflow is a graphically configurable combination of a "wizard" and a status engine. It represents the life cycle of an object by a number of statuses. The "transitions" between the statuses allow users to enter data or take actions.
With these features, the ]po[ workflow is basically comparable with the SAP or Oracle workflows, which says a lot. Here are several real-world examples:
The ]po[ Workflow Engine
The ]po[ workflow engine is actually part of the OpenACS platform underlying ]po[. It was written by Lars Pind in 2000 and has been fixed and extended since them, making it a proven and stable platform today. Quest uses this engine as the main component of its AIMS grant management system, distributing literally billions of pounds per year.
However, it is a rather complex technical structure, and the graphical workflow editor is currently not exactly user-friendly, to say the least.
The ]po[ WF Roadmap
Though the engine is not perfect, we believe it is a powerful foundation for the upcoming ]po[ projects in large companies and more complex organizational structures. We also hope that one day we'll find a customer willing to pay for an improved Workflow editor, which would allow us to cover up the most important disadvantages.
]po[ V3.2 and V3.3:
In V3.2 we used the engine for the first time in order to implement an interface to the Ophelia translation memory system. We've developed several display components for the workflow, including screens that allow users to assign team members to workflow transitions, for example. This code is still part of V3.2 and V3.3, but is kind of hidden. You can check the "Petri-Net" project in our V3.3 demo server (just search for "petri" using the ]po[ search engine).
In addition, during the IT management project at Basler Kantonalbank, we developed a ticket-management system based on the workflow and implemented several reusable components for workflow debugging and visualization.
]po[ V3.4:
V3.4 development basically started with the project at Cambridge Technology Partners (CTP, a success story under development). For this customer we developed the three existing workflows listed above in order to manage approval processes with financial implications. You can check out these workflows in our V3.4 demo server, for example when creating a new "Absence."
V3.4 ITSM and other future development:
For the future, we plan to use workflows everywhere. Here are some examples:
- Project budget approval (status: planning)
- Project customer self-service approval (status: planning)
- ITSM Ticket management (status: prototype)
There are currently several issues with the WF that increase the learning time for new developers. We plan to resolve these issues, but it may take us several months or quarters to do so:
- Lack of Documentation:
Lars Pind left us with some documentation, but it's nowhere near enough. We have started to write up some guides, but they're far from complete. - Ugly WF Design GUI:
The GUI looks good at the first glance, but you will soon find out that menus are located in inconsistent places and that the GUI doesn't really support any assignment logic, or anything of the sort. - Written in PL/SQL:
The main part of the workflow is written in PL/SQL. This means yet another language that you need to understand, and the communication from the PL/SQL to the TCL layer is clumsy. - Difficult to Debug:
Debugging in a workflow environment basically means postmortem analysis. There is already a workflow log to protocol all workflow "decisions," but this is still clumsy.
The ]po[ workflow is a proven, stable and extremely powerful component. We will use it for nearly all new ]po[ development in the future, and gradually improve its weak points. As it stands, most workflow development needs to be performed by ]po[ core members or certain OpenACS developers with experience in the workflow.
References
