How do we handle outcomes and transitions in Activiti

[rmoskal]

I am porting an app from jbpm 4.  In jpdl we had the notion of different transitions for tasks.  It would be super helpful to me if I could understand how this notion translates to Activiti and BPMN.

In jpdl each task had a notion of different outcomes or transitions.  You could control flow by completing a task with a particular outcome.  In activity your only option is to complete a task.

I see how the gateways and conditional statements in conjunction with setting variables accomplish much the same thing.  But the old way seemed better in that outgoing transitions were self describing.  I could create a task node that lets a manager "approve" or "disapprove" a piece of work by creating those transitions.  I could read these transitions right off the task and create a UI that presented a choice of approve or disapprove. 

Can I do something like this in Activiti?  Looking at the docs it seems that one solution is to use a form enum variable.  Within an app one could perhaps  adopt a convention per human task to specify a variable called "outcomes" and to use it to hold a list of outgoing transitions. 

What I'd like to know is if this is the right way to go about thinking this sort issue.  Is the above a reasonable solution to the problem?  Is it even a problem? Perhaps I am stuck in a old way of thinking.

Any insight would be greatly appreciated.


Thanks for all the hard work!


Robert Moskal
Brooklyn, USA

[frederikherema1]

Hi Robert,

We ran into this when integrating Activiti in Alfresco. Alfresco has created a layer of abstraction on top op JBPM 3, the WorkflowService. This workflow-api took over the outcome/transitions behavior.

The way we implemented this with Activiti is the folowing:

• Forms are defined within alfresco, using taskform-config. We map it in the process-definition using the formKey.


• On the taskform-definition in ALF we define a property (eg: wf_approvalOutcome) which has a list-constraint on it, containing the transitions, eg. Approve and Reject. Also a property (hidden) with fixed name (bpm_outcomePropertyName) points to the name of the property that will determine the outcome (in this case, wf_approvalOutcome)


• The ALF-share UI renders this as 2 buttons (Approve and Reject) instead of a combo-box and only one button (Next) as usually with this kind of form-property on workflow-forms.


• A gateway right after the task uses the wf_approvalOutcome to determine further path.


• A tasklistener is added (transparently using parselistener) to each task. In the endTaskListener we copy the value of the wf_approvalOutcome to the property specified by Alfresco API, bpm_outcome, so the existing UI's show the outcome of all tasks just the way that it's done with JBPM.

So your idea with the outcomes variable sounds good. You can for example always use task-variables with the same name to keep the outcome in.

[ronald_van_kuij]

I'm trying to hande it in a kind of similar way. It works, but I'm not happy with it (not Activiti's fault) and personally I think that Activiti has a strong point proposing a 'composite' user task for BPMN2.1. Why? There already is a 'composite' gateway since one can be created by using others (and I do not know by heart which ones :-))

I even think a it would make a very welcome custom extension for the time being. Not sure about all the consequences though.

[jbarrez]

Basically you should store the value of the chosen button and use it later in an exclusive gateway.

[rmoskal]

Thanks. This has all been very helpful.  My preference is to let the work flow engine bear the weight of this (the form variables).  But others on the team may have other ideas and we may wind up doing something like the alfresco folks did.

Thanks again!

Robert