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

Reply via email to