cancel
Showing results for 
Search instead for 
Did you mean: 

UserTask with an optional form

gwaptiva
Champ in-the-making
Champ in-the-making
Sorry if the title is a bit confusing, not sure how to express this better. I'll try to explain:

Embedded Activiti 5.10


In my flow, I have a multi-instance <c>subProcess</c>, to execute x times in parallel. In the <c>subProcess</c> I define a <c>UserTask</c>, with a <c>TaskListener</c> (on <c>create</c>) to provide the <c>Task</c> with text in the user's preferred language, evaluate text variables based on the state of the system, etc.

When the user completes the <c>Task</c>, and the underlying system has state A, user should be presented with a Form to take some input that will then lead to a particular operation in the next part of the flow. However, if the system has state B, the user should not get a form upon clicking Complete.

I have defined an <c>activiti:formKey</c> attribute with a variable, and an <c>activiti:formHandlerClass</c> that extends <c>DefaultFormHandler</c> and will set the variable to the <c>formKey</c> required to produce a form in the user's preferred language. I cannot, however, let my <c>formHandlerClass</c> set the <c>formKey</c> attribute to null; that makes the entire instance go BOOM.

e.g.

<userTask id="someid" activiti:formKey="${myFormKey}" activiti:formHandlerClass="MyDefaultFormHandler">
    <extensionElements>
        <activiti:taskListener event="create" class="MyUserTaskCreator" />
    </extensionElements>
</userTask>


Is there a more elegant way to manipulate the flow to skip dealing with the formKey/formHandlerClass combination under certain circumstances (other than defining an <c>exclusiveGateway</c> before and have one <c>UserTask</c> with and one without the form)?

Hope this was clear enough, and thanks in advance for any suggestions.

Gwap
2 REPLIES 2

trademak
Star Contributor
Star Contributor
The activiti:formHandlerClass attribute is that something you implemented yourself? Because that's not supported in Activiti.
Couldn't you use a task listener to update the form key value?
Otherwise an exclusive gateway is probably the best approach.

Best regards,

gwaptiva
Champ in-the-making
Champ in-the-making
No, activiti:formHandlerClass attribute is defined in <c>activiti-bpmn-extensions-5.4.xsd</c> in <c>org.activiti.impl.bpmn.parser</c>, in Activiti 5.10 that we're (still) using.
<code>
<attribute name="formHandlerClass">
    <annotation>
      <documentation>
        Attribute on a startEvent or userTask.
        Allows to specify a custom class that will be called during the parsing
        of the form information. Thus way, it is possible to use custom forms and form handling.
        This class must implement the
        org.activiti.engine.inpl.form.FormHamdler/StartFormHandler/taskFormHandler interface
        (specific interface depending on the activity).
      </documentation>
    </annotation>
    <simpleType>
      <restriction base="string">
        <!– regular expression taken from http://regexlib.com/REDetails.aspx?regexp_id=2821 –>
        <pattern value="([a-z]{2,3}(\.[a-zA-Z][a-zA-Z_$0-9]*)*)\.([A-Z][a-zA-Z_$0-9]*)"/>
      </restriction>
    </simpleType>
  </attribute>
  </code>
[sic on the typo in FormHamdler]

And it works a treat too (I haven't found my back to where it is actually evaluated yet, but I did a year or so ago, and have used it ever since). It allows me to construct a different form depending on the user in the session (or really anything else, because the class is called _right_ before the form's path is loaded.

Problem with the exclusiveGateway is that this is a UserTask, and that the taskListener is called at the wrong moment. The choice between UserTask or UserTask-with-form is made based on the state of the system at time 0, but then the UserTask is serialized to database, weeks can go by and the state of the system can get changed in a significant manner. Then user comes along and clicks Complete on his task and user gets a result that's weeks old.

I don't really want to present users with dialogs that have a "Oh, sorry, nevermind, seems the reason I display this message is no longer there" message (i.e. just a silly info message)… Seems that may be the way to go though, or I have to find a way to hack a way into the Implementation (with all associated risks acknowledged and accepted) and override everything until I get to the point where I can 'remove' the 'activiti:formKey' effect dynamically.

Gwap

[EDIT: Ah, here we go: <c>org.activiti.engine.impl.bpmn.parser.BpmnParse#parseTaskDefinition(Element, String, ProcessDefinitionEntity)</c> line 1991-etc]