topic Re: Abuse of the dataInputAssociation in Alfresco Archive

Abuse of the dataInputAssociation

bernd_ruecker — Mon, 24 Jan 2011 07:26:10 GMT

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#p3

Re: Abuse of the dataInputAssociation

bernd_ruecker — Mon, 24 Jan 2011 07:35:30 GMT

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?

Re: Abuse of the dataInputAssociation

tombaeyens — Mon, 24 Jan 2011 08:06:53 GMT

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?

Re: Abuse of the dataInputAssociation

bernd_ruecker — Mon, 24 Jan 2011 08:32:35 GMT

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…

Re: Abuse of the dataInputAssociation

tombaeyens — Mon, 24 Jan 2011 08:58:27 GMT

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>

Re: Abuse of the dataInputAssociation

bernd_ruecker — Mon, 24 Jan 2011 09:55:38 GMT

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

Re: Abuse of the dataInputAssociation

jbarrez — Mon, 24 Jan 2011 10:25:21 GMT

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.

Re: Abuse of the dataInputAssociation

bernd_ruecker — Mon, 24 Jan 2011 11:39:06 GMT

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…

Re: Abuse of the dataInputAssociation

jbarrez — Mon, 24 Jan 2011 11:43:24 GMT

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

You can always access the superExecution in the executionListener?

Re: Abuse of the dataInputAssociation

bernd_ruecker — Mon, 24 Jan 2011 12:46:09 GMT

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?

Re: Abuse of the dataInputAssociation

jbarrez — Mon, 24 Jan 2011 13:21:36 GMT

Ok, I think I understand your reasoning. But I dont see the problem with completing (execution listeren end event) and completed (activityBehavior).

Where would that differentiation cause problems?

Re: Abuse of the dataInputAssociation

ronald_van_kuij — Mon, 24 Jan 2011 13:25:37 GMT

<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?

I'm in favour of this one.. maybe with the dataInput/Output as Bernd described. Using the listener feels like abuse to me and it certainly is not directly clear if you write bpmn xml by hand 🙂

Re: Abuse of the dataInputAssociation

bernd_ruecker — Mon, 24 Jan 2011 17:00:01 GMT

Okay I asked Falko for his opinion as well, and he voted for the in/out extension. Since there were no more answers here, I implemented that and commit it.

Here the example from the new test case:


    <callActivity id="callSubProcess" calledElement="simpleSubProcess" >
   <extensionElements>
     <activiti:in source="superVariable" target="subVariable" />
     <activiti:smileysurprised:ut source="subVariable" target="superVariable" />
   </extensionElements>      
    </callActivity>

Re: Abuse of the dataInputAssociation

bernd_ruecker — Mon, 24 Jan 2011 17:49:13 GMT

Okay, I added a new schema version ending with 5.2, any more to do in that area?

For the webservices I created http://jira.codehaus.org/browse/ACT-570

Re: Abuse of the dataInputAssociation

jbarrez — Mon, 24 Jan 2011 18:57:31 GMT

I'll look at the code tomorrow morning.

Have you documented and tested it?

Re: Abuse of the dataInputAssociation

bernd_ruecker — Mon, 24 Jan 2011 19:10:59 GMT

See http://jira.codehaus.org/browse/ACT-560, documentation is still open since we decided on a final version.
A TestCase is there, yes.

Re: Abuse of the dataInputAssociation

tombaeyens — Tue, 25 Jan 2011 13:29:57 GMT

Bernd, we've reviewed the names once more and think that we should go for these names:

<callActivity id="callSubProcess" calledElement="simpleSubProcess" >
  <extensionElements>
    <activiti:variableIn superVariable="superVariable" subVariable="subVariable" />
    <activiti:variableOut subVariable="subVariable" superVariable="superVariable" />
  </extensionElements>      
</callActivity>

Can you update the parsing?

Re: Abuse of the dataInputAssociation

bernd_ruecker — Tue, 25 Jan 2011 13:38:28 GMT

Hi Tom.
Then it doesn't fit for ServiceTask's any more, that's why I don't like the "variable" in the name any more. Then it is 100% bound to CallActivities.
Where is the advantage?
Cheers
Bernd

Re: Abuse of the dataInputAssociation

tombaeyens — Wed, 26 Jan 2011 07:56:28 GMT

Can you remind me about the situation how this was to be used for service tasks?

There were a couple of situations that I wanted to unify at first. But we've gone through those yesterday when I was talking to Joram and we only found one (task properties) and decided that that is OK to be dealt with differently.

Re: Abuse of the dataInputAssociation

bernd_ruecker — Wed, 26 Jan 2011 08:07:26 GMT

The ServiceTask Shortcut to pass parameters and hand results… See Tests for the WebServiceTask (the "…simplistic…" one).