Abuse of the dataInputAssociation

[bernd_ruecker]

I now use the same shortcut for the CallActivity which is used in the WebServiceTask. But what I recognized is, that it only works if you disable schema validation (basically because the IDREF doesn’t have a correct target). See http://forums.activiti.org/en/viewtopic.php?f=4&t=885&p=3731#p3731

I would say that is a no go! Either we implement the spec correctly, or we add own extensions. And forcing people to disable schema validation for shortcuts is a pretty bad idea. What do you guys think? Or does anybody know an easy solution to get the schema validation to work?

To test/see it go to the CallActivityAdvancedTest / testSubProcessWithDataInputOutput and switch the schemaValidation attribute of the @Deployment annotation to true (and the test will fail).

–
Joram:
mmm, never noticed that. Thanks for pointing that out, because that is most certainly NOT the idea.

So there are two options here:
- removing the shortcut, and implementing the real deal
- fixing the shortcut

I4'm actually more in favour of the first option at this point, since we wont get any surprises from that …

[bernd_ruecker]

Hi.

I think for BPMN Elements we should either use them completely (!) correct or add an activiti extension. Abusing them in any form adds unnecessary confusion without having a big advantage.

For the CallActivity using the correct BPMN 2.0 way would also mean, we have to declare process variables as items, which isn't used inside of the engine. So I find it hacky again, if we add them just to satisfy the Schema Validation. People will get puzzled by this.

So my proposal:
- We add an activiti extension now (I need it for 5.2), which is realized as extension, short and easy
- We add the true BPMN standard way later

The extension can be used for CallActivity and Web-ServiceTask. Proposal:

<callActivity id="callSubProcess" calledElement="simpleSubProcess" >
  <extensionElements>
    <activiti:dataInput sourceVariable="superVariable" targetVariable="subVariable" />
    <activiti:dataOutput sourceVariable="subVariable" targetVariable="superVariable" />
  </extensionElements>
</callActivity>

I don't like the term "variable" too much, because BPMN called it DataObjects, but since it is already used in some extensions and in Activiti internally, I think it makes the most sense…

Ok with everybody?

[tombaeyens]

It's good that this issue has been found.  Probably this approach dates back from before we decided how we deal with namespaces etc.  Thanks, Bernd for driving it!

What about a shorter version?

<callActivity id="callSubProcess" calledElement="simpleSubProcess" >
  <extensionElements>
    <activiti:in source="superVariable" target="subVariable" />
    <activiti:smileysurprised:ut sourceExpression="#{someExpression + 3}" target="superVariable" />
  </extensionElements>
</callActivity>
There is still 1 thing I dislike with this naming scheme: some inconsistency in source and target.  Meaning with 'in', source is in the outerscope and target refers to the inner scope.  And in an 'out' this is reversed: source refers to the inner scope and target refers to the outer scope.  I find that always a bit confusing.

We could make the combination to prevent mistakes

<callActivity id="callSubProcess" calledElement="simpleSubProcess" >
  <extensionElements>
    <activiti:in outerSource="superVariable" innerTarget="subVariable" />
    <activiti:smileysurprised:ut innerSourceExpression="#{someExpression + 3}" outerTarget="superVariable" />
  </extensionElements>
</callActivity>
But I'm not sure if this removes confusion instead adding.

WDYT?

[bernd_ruecker]

Yeah, I find it a bit confusing as well. But I think that should be better a reason for good documentation, but not changing. Your proposal is maybe a bit less confusing, but on the other hand not much 😉 but it is tied to sub processes, so we would need a different extension for webservices. Hence I would prefer to stick to the BPMN terms.

But agreed with the "source" and "sourceExpression".

For the "dataInput" versus "in" I don't see a big advantage in making it shorter. But for that decision I don't care too much…

[tombaeyens]

We could also perhaps work it out based on the existing execution listener schema.  That way, tools don't need to be updated for this.

<callActivity id="callSubProcess" calledElement="simpleSubProcess" >
  <extensionElements>
      <activiti:executionListener class="copyIn" event="start">
        <activiti:field name="outerSource" stringValue="superVariable" />
        <activiti:field name="innerTarget" stringValue="subVariable" />
      </activiti:executionListener>
      <activiti:executionListener class="copyOut" event="end">
        <activiti:field name="innerSource" stringValue="subVariable" />
        <activiti:field name="outerTarget" stringValue="superVariable" />
      </activiti:executionListener>
  </extensionElements>
</callActivity>

[bernd_ruecker]

Hi Tom.

Wouldn't that be an abuse of the executionListener semantics? Actually I like it much more to introduce an in/out extensions, feels much cleaner for me…

Cheers
Bernd

[jbarrez]

Bernd, how would it violate the execution Listener semantics ? We just provide a built-in execution listener that does exactly the same.

I'm always reluctant of introducing new extensions.
We must really be careful not to introduce too much extensions, as each extensions means

- updating the xsd
- updating the Modeler / Designer
- Extra documentation
- backwards compatibility for the forseeable future

So if a concept can be fit into some extension that already exists, that would be great.
So I would definitely like to learn why the one approach feels cleaner then the other for you.

[bernd_ruecker]

Hmm, the behavior is at least slightly different, since the copying of the variables back must be BEFORE the execution listener would fire (otherwise they are destroyed). So it IS NOT a execution listener.

Hmm…

[jbarrez]

Bernd, I dont get that last post… what do you mean?

You can always access the superExecution in the executionListener?

[bernd_ruecker]

Sorry, I am in a workshop today, that's why I just write quick pongs to be ready in the evening to finish what we agreed on 😉

The super process continues when the sub process has finished. That means it is moved to the history. And you have to access the variables BEFORE that, so that is a slightly different point of time than a "end-event" execution listener on the CallActivtity. See CallActivityBehaviour Method completing vs completed.

Hope that was more clear?