Author: Sebastian Bergmann Date: 2007-02-05 19:32:05 +0100 (Mon, 05 Feb 2007) New Revision: 4627
Log: - Sync with thesis paper. Modified: experimental/Workflow/design/requirements.txt Modified: experimental/Workflow/design/requirements.txt =================================================================== --- experimental/Workflow/design/requirements.txt 2007-02-05 13:21:37 UTC (rev 4626) +++ experimental/Workflow/design/requirements.txt 2007-02-05 18:32:05 UTC (rev 4627) @@ -1,5 +1,5 @@ eZ component: Workflow, Requirements -~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + :Author: Sebastian Bergmann :Revision: $Revision$ :Date: $Date$ @@ -8,23 +8,36 @@ Introduction ============ -Description ------------ +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. -This document contains an initial set of requirements for a generic and -dynamic workflow management system. This system is to be developed as a -part of the eZ components. At a later stage, the system will probably -become a part of eZ system's new flagship product codenamed eZ telemark - -a multi-purpose content/information management system for the enterprise -market. +eZ Publish 3 +============ -Current implementation ----------------------- +eZ Publish 3 comes with an integrated workflow mechanism that makes it possible +to perform different tasks with or without user interaction. -Both the architecture of the current eZ publish version as well as its -workflow feature have shortcomings that are to be overcome by this -component: +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 @@ -32,42 +45,106 @@ - Support for checking the state of executing workflows and control over them is limited. - Support for conditions is limited. -- Interaction not possible once a workflow is deflected to a cronjob. -Design goals -============ +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. -Eventually, the workflow management system should become an important part -of the overall solution. However, it must not be tightly integrated and/or -too much dependent on other parts of the system (and vice versa). This means -that the solution must be flexible and provide good interfaces which allow it -to co-exist and plug into the software. +Requirements +------------ -Clear APIs and communication channels must be provided. Modifications to the -workflow system should not require too many modifications when it comes to -the host environment which is using it. +We start with the requirements that are relevant to the underlying workflow +model of the workflow component that is to be implemented: -Requirements -============ +- 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. -- Overview of what is happening in the system. -- It should be easy to understand the system (new users, etc.). -- Easy-to-use hook-ins for developers (and users). -- Easy for admins to control and model the flow model(s). -- Any non-trivial operation (publishing, removal, modification, - etc. of any object) in eZ publish should be a workflow. -- It should be easy integrate the workflow system with background processes. -- It should be easy to deflect workflows to background processes. -- Ability to manually control control the execution of a workflow. -- Support for conditions, parallel split (join, AND/OR, cycles). -- It should be easy to check the states/statuses (again, overview). -- Workflow system should be made ready for user-interaction. -- Possibility to store/retrieve the state of workflows to DB/other storage - system. -- Simulation of the workflows should be possible (debugging purposes). -- Documentation is essential. The solution must be well documented in the - form of text backed up by illustrations that clearly explain how the system - actually works. -- API documentation must also be provided. -- The solution should come with generic testing systems (for example unit - tests). +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. -- svn-components mailing list svn-components@lists.ez.no http://lists.ez.no/mailman/listinfo/svn-components