cancel
Showing results for 
Search instead for 
Did you mean: 

Add variable copy to call activity

bernd_ruecker
Champ in-the-making
Champ in-the-making
See http://jira.codehaus.org/browse/ACT-560.

I currently asked Tom:

Is it possible to add own extensions in the activiti-bpmn-extensions-5.0.xsd? Or when is that allowed?
Or do we have to work with the existing ones?


Depending on that answer we can define, how the XML configuration should look like.
12 REPLIES 12

jbarrez
Star Contributor
Star Contributor
Bernd, this question already came up in the forum a few times, so yes I would like to see it implemented.
There was even already an issue for it: http://jira.codehaus.org/browse/ACT-354

The BPMN spec has a way of defining the variable mapping, but involves all the ioSpecification stuff, which we didnt do yet because it is too cumbersome.
So a shortcut for this cumbersome XML is indeed wanted in this case.

Is it possible to add own extensions in the activiti-bpmn-extensions-5.0.xsd? Or when is that allowed?
Or do we have to work with the existing ones?
The rule here is that when a new element is added in a certain release, you must create a newer xsd (ie activiti-bpmn-extensions-5.2.xsd).
The give a ping, so I can upload it to activiti.org.

So if you are to implement the feature you would need (besides the code):
- How the XML would look like (preferably discussed here in the forum)
- Tests added to the CallActivityAdvancedTest
- documentation

bernd_ruecker
Champ in-the-making
Champ in-the-making
Hi Joram.

Thanks for the quick answer. Damn it, I quickly searched for an issue but missed it 😉 I marked it as duplicate. Then we will propose an XML structure, I agree that we should have shortcut XML way for doing this (the standard way could be added later on as alternative I think).

Quick proposal for the XML:


<callActivity id="callCheckCreditProcess" name="Check credit" calledElement="checkCreditProcess">
  <extensionElements>
    <activiti:dataInput name="x" expression="#{myVar.x}" />
    <activiti:dataInput name="y" stringValue="test" />
    <activiti:dataInput name="z" variable="z" />
  </extensionElements>
</callActivity>

x,y & z would be the variables in the subprocess. What do you think?

The dataOutput (return values) is still missing, I will add that if we can somehow agree on the basics…

Thanks
Bernd

tombaeyens
Champ in-the-making
Champ in-the-making
I think we should also investigate the longer ioSpecification format. If it is only extra parsing, then we should consider implementing it to keep being spec compliant.

tombaeyens
Champ in-the-making
Champ in-the-making
I'm not yet sure about the name dataInput.  I'ld like to verify if it is possible to use the same names for all the use cases like these:
* sub processes
* task properties
* activity/scope local variables

i guess there are more situations.  just don't remember it right now.  any one else an idea which other situations we might need similar things?

jbarrez
Star Contributor
Star Contributor
Accodring to the BPMN spec, all activities could potentially have input/output

This is a shortcut we already have for webservices:

<dataInputAssociation>
        <sourceRef>NewCounterValueVariable</sourceRef>
        <targetRef>value</targetRef>
      </dataInputAssociation>

And this is the longer version:

<ioSpecification>
   <dataInput itemSubjectRef="tns:setToRequestItem" id="dataInputOfServiceTask" />
     <inputSet>
       <dataInputRefs>dataInputOfServiceTask</dataInputRefs>
     </inputSet>
     <outputSet />
</ioSpecification>
<dataInputAssociation>
   <sourceRef>dataInputOfProcess</sourceRef>
   <targetRef>dataInputOfServiceTask</targetRef>
   <assignment>
     <from>${dataInputOfProcess.newCounterValue}</from>
     <to>${dataInputOfServiceTask.value}</to>
   </assignment>
</dataInputAssociation>

Both snippets do the same. Both are spec compliant, however the first one is stretching it a bit.

bernd_ruecker
Champ in-the-making
Champ in-the-making
Okay, then I would first go for the shortcut and get that running with the functionality and the tests.

Adding the extra parsing as a second step should be easy then afterwards, and I don't want to risk the code freeze date for that?

So this is it?

  <dataInputAssociation>
        <sourceRef>counter</sourceRef>
        <targetRef>newCounter</targetRef>
  </dataInputAssociation>
  <dataOutputAssociation>
        <sourceRef>newCounter</sourceRef>
        <targetRef>counter</targetRef>
  </dataOutputAssociation>

jbarrez
Star Contributor
Star Contributor
Yup, that's spec compliant, without having to worry about the ioSpecification stuff.

bernd_ruecker
Champ in-the-making
Champ in-the-making
But then we just pass variables "as-is", no possibility to add expressions or the like for the moment? Do we think that's a problem? Actually I could live with that, at least for the moment… Hey, then we even do not need to adjust the extensions schema, problem solved 🙂

bernd_ruecker
Champ in-the-making
Champ in-the-making
Hi Joram.

There is one downside of this shortcut, we have to turn schema validation of, since it expects IDREF for sourceRef and targetRef, which we do not have. In think then the shortcut gets ugly! And we misuse the BPMN elements. Wouldn't it be better to got for an clear own extension instead then?

Cheers
Bernd