eZ Component: Workflow, Design ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ :Author: Sebastian Bergmann :Revision: $Revision$ :Date: $Date$ Introduction ============ This document is divided into two sections. The first section presents the workflow mechanism that is part of eZ Publish 3. The second section discusses the requirements that the workflow engine for eZ Publish Telemark, the next version of eZ Publish, needs to fulfill. eZ Publish 3 ============ eZ Publish 3 comes with an integrated workflow mechanism that makes it possible to perform different tasks with or without user interaction. An event performs a specific task. eZ Publish 3 ships with a library of events and custom events can be implemented in PHP. A workflow defines an ordered sequence in which workflow events are executed and is initiated by by a trigger that is associated with a function of a module. It will start the specified workflow either before or after that the function has completed. The built-in workflow for publishing a content object in eZ Publish 3 can only be customized at the Publish in tree activity. This activity serves as the trigger for a custom workflow that can be executed either before or after the activity was executed. eZ Publish Telemark =================== Both the architecture of the current eZ Publish version as well as its workflow feature have shortcomings that are to be overcome: - Only some operations are workflows. This inconsistency has a negative effect on the maintainability of the software as a whole. - It is not easy to configure (hook in) the (internal) workflows. This makes extending the software hard. - Support for checking the state of executing workflows and control over them is limited. - Support for conditions is limited. Eventually, the workflow component should become an important part of the overall solution. However, it must not be tightly integrated or too much dependent on other parts of the system (and vice versa). This means that the workflow component must be flexible and provide good interfaces which allow it to co-exist and plug into the software. Requirements ------------ We start with the requirements that are relevant to the underlying workflow model of the workflow component that is to be implemented: - The workflow component should provide good support for expressing control flow (conditions, branching, merging, etc.). - Any non-trivial operation in eZ Publish, for instance the publishing, removal, and modification of content objects, should be a expressable through workflows. - Workflows should be composable through a concept of sub-workflows. Now we come to the requirements that relate to the actual software implementation: - The workflow component has to be implemented using version 5 of the PHP programming language. - It should be possible to integrate workflows with the background processes of eZ Publish (run workflow as background process, interact with a background process). - The workflow component should be customizable and extendable. - The data storage (for workflow schemas and the persistence of workflow instances) should be abstracted, relational databases must be supported as one backend. - Versioning of workflow schemas should be supported. - It should be possible to get information on the workflow instances that are currently executing. - It should be possible to manually control the workflow instances that are currently executing. - Simulation of workflow execution for debugging and testing purposes should be possible. Use Cases --------- Here are two use cases that should be supported by the workflow engine component that is to be implemented for eZ publish Telemark as part of this thesis. They are currently implemented using custom extensions for eZ publish 3. Multiple Approval, ISO Certification ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ This scenario is from a current customer of the eZ Publish ECMS providing quality assurance for dairy products. The customer has information about the dairy products stored in eZ Publish. When they update any content there is a strict ISO-governed process to follow. This process basically consists of a five-level approval: - Bertrand produces an article. - Approver Level 1: Bård decides who the next four approvers are. He can also edit the article and send it back to its creator. - Approver Level 2: Melissa reviews the article for political correctness. She can edit the article and send it back one level. - Approver Level 3: Vidar reviews the article for sales arguments. He can edit the article and and send it back one level. - Approver Level 4: Jennifer does grammar checks on the article. She can edit the article and and send it back one level. - Publisher: Markus approves the final article and chooses the time and location for publication. It is possible to see all on-going processes for an administrator. He or she can see each article as well as its state and which person currently handles it. Employment Process ^^^^^^^^^^^^^^^^^^ This scenario is from the intranet of a current customer of the eZ Publish ECMS and is used when a new employee is hired. - One person creates an Employee object (including name, address, email, etc.). - An e-mail with a link for final approval of the employment is sent to the CEO. - Once the CEO has approved the new employment three parallel activities are started: - An e-mail to the system administrator is sent with the request to create e-mail and other accounts. The e-mail contains a link for the system administrator to click when he is done. - An automatic process is started to set up accounts on different systems. - An e-mail to the administration is sent with the request to buy new hardware for the new employee. - Once these three activities have been completed, the workflow continues. - The Employee object is published. - An e-mail with detailed information is sent to the new employee. The on-going status for all employment processes at any time is available to anyone with the appropriate permissions.