nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

As we transition to the new Hyland Community, some post links may be temporarily disrupted as we finalize redirects. We apologize for the inconvenience and are working to resolve this as quickly as possible. Details.

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 …

Find more posts tagged with

Comments

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:

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

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" ><br>&nbsp; <extensionElements><br>&nbsp;&nbsp;&nbsp; <activiti:in source="superVariable" target="subVariable" /><br>&nbsp;&nbsp;&nbsp; <activiti:smileysurprised:ut sourceExpression="#{someExpression + 3}" target="superVariable" /><br>&nbsp; </extensionElements><br></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" ><br>&nbsp; <extensionElements><br>&nbsp;&nbsp;&nbsp; <activiti:in outerSource="superVariable" innerTarget="subVariable" /><br>&nbsp;&nbsp;&nbsp; <activiti:smileysurprised:ut innerSourceExpression="#{someExpression + 3}" outerTarget="superVariable" /><br>&nbsp; </extensionElements><br></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" ><br>&nbsp; <extensionElements><br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <activiti:executionListener class="copyIn" event="start"><br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <activiti:field name="outerSource" stringValue="superVariable" /><br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <activiti:field name="innerTarget" stringValue="subVariable" /><br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </activiti:executionListener><br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <activiti:executionListener class="copyOut" event="end"><br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <activiti:field name="innerSource" stringValue="subVariable" /><br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <activiti:field name="outerTarget" stringValue="superVariable" /><br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </activiti:executionListener><br>&nbsp; </extensionElements><br></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?

jbarrez

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?

ronald_van_kuij

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

bernd_ruecker

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:

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

bernd_ruecker

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

jbarrez

I'll look at the code tomorrow morning.

Have you documented and tested it?

bernd_ruecker

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

tombaeyens

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

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

Can you update the parsing?

bernd_ruecker

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

tombaeyens

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.

bernd_ruecker

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

tombaeyens

Right, thanks for the pointer.

I think the best approach is to have specific xml schemas for datamapping for sub process call activity and web service service tasks.
So you can now move forward with the latest proposal that I did.

Later we'll work out the web service servicetask data mapping schema. That is not urgent now. We do however need a good way on how to disable validation. So we'll concentrate on that today.