An alternative to simple workflow

[anweber]

Hi,

I will present you an alternative way to implement a simple workflow.  The aim of this post is just to share my experience.  Sorry for my poor English.    If it's not clear enough, please contact me.

For a proof of concept, we had to develop a workflow.  Currently, the only solution offered by Alfresco about workflows is the "simple workflow" mechanism. We have implemented our workflow with this "simple workflow" technique. Our workflow actions have been written in a script (JavaScript).  To launch those actions, we have defined rules that execute this script when the document arrives in a given folder.  The action of our "simple workflow" moves or copies the document into a given folder, a rule associated to this target folder (or to the parent folder) executes our script, then our script detects the current step and processes the corresponding business actions.  Using this way to implement workflows, we found some limitations:

• The user has the possibility (when it is defined) to launch the execution of a transition between two steps of our workflow via a menu associated to a document.  Then our transition should be in relation with one document and only one document (it's not possible to define - as in Documentum - that our workflow carries more than one document).  In fact, to be honest, I should admit that it was not a limitation in our case.


• Only one or two user actions are allowed for each step of the simple workflow (accept/reject actions).  In our case, we should have to let the user choose amongst: accept, reject to the sender, delegate to someone else.


• When the user launches a transition of the workflow (accept or reject), he can't give an argument (for example, to specify the delegate).


• In a simple workflow we can just move or copy the current file. But our workflow logic doesn't always imply such moves or copies of files.


• The messages that we send to the user to explain what he can do on the workflow are very limited (they are short static labels directly shown by the action menu).


• We met some problems when the script executed by the action of a rule defined on the target folder of a step of our simple workflow moves some files into the original folder.  By example, we attach a simple workflow step when a document arrives in the folder F1, the user action on our simple workflow step moves the current file into the folder F2, our script is executed when this document arrives in the folder F2, this script moves the current document back into the folder F1: in this case, the document back into the folder F1 do not get the defined "simple workflow" step (the user do not have the possibility to execute again the workflow transition).  In this case, we should have a recursive call to the same set of rules associated to the folder F1; it seems to be currently deactivated to prevent infinite loops.

To increase the possibilities during the delay we have to wait for a real workflow engine (expected in version 1.4), I propose an alternative:

• The actors of the workflow will receive HTML messages stored in simple folders into Alfresco.  Such message describes authorized decisions or notifications (for examples "accept" or "reject" or "delegate to .") with optional parameters (for example the delegate).


• The execution of the transition is launched when the user click on a hyperlink of his workflow message or on a submit button (it depends of the design of the HTML message).


• The execution of the transition is processed by a script (written in JavaScript) that contains the workflow logic.

A possibility to initialize the workflow, is to execute our script when a document arrives in a given folder (a rule associated to this folder specifies that our script will be executed when a document arrives).  The first step of our workflow is then to create the message allowing the first actor to go through the first transition(s) of our workflow.  Of course, it could involve several actors (and several messages).  Those messages are stored in input boxes (implemented as simple folders), each actor has his own input box.
We could decompose the logic executed by our script like this:

1. Determine the current transition (current step of our workflow + user choice) - to help this determination we have stored some hidden HTML input fields with useful information like the step number or the ID of the caller and we have added the ID of the decision made by the user to the HTTP submit (by example through an HTTP-get argument).


2. Check if requirements are OK (for example, we check if mandatory arguments to the decision of the user are present and valid) or send back an error message directly to the caller (HTTP answer).


3. Process business actions.


4. Determine next actors and retrieve information to insert in the messages that will be addressed to those actors.


5. Create and send message(s) to next actor(s) in their input boxes.


6. Delete the calling message.


7. Send back a direct message to the caller (HTTP answer) with information about the result of this transition.

To simplify the creation of the messages, I have developed a simple technique to use: "HTML templates with server-side JavaScript" evaluated by our script (see my previous post : http://forums.alfresco.com/viewtopic.php?t=2378).
I also have defined a custom type to represent our workflow instances and to keep their status and other useful information. 
This way to implement workflows is still limited to simple scenarios (the logic of our workflow is hard coded in our script) but offers some advantages compared to the "simple workflow" process originally offered by Alfresco:

• Each actor receives messages from the workflow in his input box (like in Documentum).


• We could ask an actor to choose amongst an arbitrary number of decisions/notifications.


• We could ask the user to add some arguments to some decisions.


• We do not have to move or copy documents to trigger transitions of our workflow.


• We could associate zero, one or more documents to each transition (we just have to insert links to those documents in our workflow messages).


• We do not meet the problem about recursive execution of the same set of rules associated to a folder because we do not use such rules (except to create a new workflow instance and to initialize it - but it concerns a single call to our script).


• We have the possibility to address more information to the actor about what the workflow is expecting from him (and about the current status of the process).

Skeleton of our script:

main(){
   if (document != null) {
      // execution by a rule, it should be on the INBOUND event in the folder where incoming documents arrive
      //    workflow instance initialization
      //      - we create a new workflow instance (using a custom type)
      …
      //      - we initialize the properties of this object
      …
      //   send HTML stored message to the first actor(s)
      …
      return;
      
   } else {
      // this script has been called by an HTTP get from a HTML stored message
      
      // get info from args (caller, current step in the workflow, action name, action arguments, .
      …
      // retrieve the workflow object and get info on current workflow instance
      …
      // treat actions 
      switch(workFlowStep){
         case 1:
            switch(actionName){
               case "accept": // for example
                  // do some business process
                  …
                  // create and send stored messages to next actors
                  …
                  break;
               …
            }
            break;
         case 2:
            …
            break;
         …
         Case <n>:
            …
            break;
      }
      If (success){
         // if all is OK, we delete the calling stored HTML message
         …
         // we send a direct answer to the user
         return("<HTML>Your request has been treated successfully</HTML>");  // for example
      } else {
         return(errorMessage);
      }
}

main();
 ‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍

If you are interested by this way to implement workflows, I would be happy to show you a more concrete example.

   Regards,

      Andre

[tcordova]

Andre,

I'm very interested in seeing this example…  I'm trying to implement something similar here.

Tom

[anweber]

Hi Tom,

   Do you have a simple scenario to submit for this example (by default, I will probably developp an example of votes on a given document - a vote with 3 options : accept / reject / no opinion - the document is accepted if the majority of voters have voted "accept" - each voter (amoungst the intial lits of voters) will receive information about the status of the vote).

   I will do that during my spare time (I expect to have finished for this week-end).  Is it urgent for you?

       Andr

[tcordova]

The urgency only comes from knowing whether or not it can be done.  I have to do a technology demo on Friday, but if I can get Alfresco to at least come up and show CIFS and the concept of how the spaces will be used, then that should be good enough for the immediate future.

My workflow seems similar to yours… the big difference for us is that the document shouldn't be published unless a unanimous decision has been reached on approval.  A single rejection sends it back to the writer for adjustment and the process starts all over again.

The other oddity is that each document can have a different set of voters assigned to it by the writer.

Thanks for your help!