Output variables from CallActivity on BoundaryEvent trigger?

[jonathan1]

I have a call activity publishing an exit-code variable.  The call activity also has a boundary error event associated with it. 

After triggering the boundary event, I'd like to read the published exit-code variable in the parent process, but tracing the Activiti Engine, it appears that handling the boundary event preempts publishing the call activity's internal exit-code variable to the output variable, so the output variable isn't pushed out to the parent (it is set in the child process, looking at the DB).

Is there a way to ensure that the parent process can read a variable from it's child call activity in the event a boundary event is triggered?

[smirzai]

Hi Michel
Ok, I found it.
It is true that Error uses ItemDefinition, and it means that some data can exist in Error. Something we already know. It does not tell if the data could be read or written into it.
a clearer and more direct diagram is Figure 10.69 in section 10.4. It is clearly mentioned that "intermediate catch event" is inherited from "Catch Event" which is associated with "DataOutputAccociation". On the other hand, "Intermediate Throw Event" is inherited from "ThrowEvent" which is associated with "DataInputAssociation".
It could also be seen in xsd. in "Table 10.113 - IntermediateCatchEvent XML schema" is inherited from "tCatchEvent" which is explained in "table 10.104 - Catch Event XML Schema". And there association with "DataOuput" and "DataOutputAssociation" is clear. With the same logic "dataInput" and "dataInputAssociation" is stated for "intermediate Throw Event".
So the the catching part should be something like this:

<intermediateCatchEvent id="myIntermediateCatchEvent" >
    <XXXEventDefinition/>
    <dataOutputAssociation>
        <targetRef>dataOutputOfProcess</targetRef>
        <transformation>${dataOutputOfServiceTask.prettyPrint}</transformation>
    </dataOutputAssociation>
</intermediateCatchEvent>

and throwing part can be something like:

<intermediateCatchEvent id="catchSignalEvent" name="On Alert">
    <!– signal event definition –>
    <XXXEventDefinition" />
    <dataInputAssociation>
        <sourceRef>PrefixVariable</sourceRef>
        <targetRef>prefix</targetRef>
    </dataInputAssociation>
    <dataInputAssociation>
        <sourceRef>SuffixVariable</sourceRef>
        <targetRef>suffix</targetRef>
    </dataInputAssociation>
</intermediateCatchEvent>

of course, with whistles and bells defined in activiti guide
tu as eu raison.
Do you agree michel ?

[smirzai]

Hi Tijs,
Have I understood your proposal correctly ? This is my understanding:
You just name the variables in ErroEventDefinition. It will automatically get the value of the variable with the same name in process when throwing and when catching it will put it in a variable again with the same name. In this case what is the purpose of the line with  expression ?

Personally I do not like  the idea of copying values between variables just with name similarity. In BPMN standard the events data passing is in form of inputs and outputs, just like callActiviti but one only input in throwing and output in catching. I think it is better to keep the conformity to the standard as much as possible. If for any reason we are not willing to follow the syntax, I would suggest to follow the semantics and implement it in form of inputs and outputs.

This is the very same it is dealt with in Activiti about CallActiviti and WebService task for example. in CallActiviti we are also using Activiti:in and Activitiut extensions to copy the values properly. Even better in Web service, which we both support BPMN standard and our simpler version.

[trademak]

Hi Saeid,

Makes sense.
I don't like the use of in and out in the XML in this context. Because it's actually about working with the event payload.
What do you think about this:

<blockcode>
<endEvent id="myErrorEndEvent">
    <extensionElements>
         <activitiayload name="event_var" value="staticvalue"  />
         <activitiayload name="event_var2" value="${expression_var}" />
    </extensionElements>       
    <errorEventDefinition errorRef="myError" />
</endEvent>
</blockcode>

<blockcode>
<intermediateCatchEvent id="myErrorIntermediateCatcher">
    <extensionElements>
        <activitiayload name="event_var" targetVariable="process_target_var" />
    </extensionElements>
    <errorEventDefinition errorRef="myError" />
</intermediateCatchEvent>
</blockcode>

[smirzai]

Hi Tijs,

Looks good. Just two notes.
1. In the intermediateCatchEvent it should also be possible to assign an expression based on payload variables to a single variable. Just to keep the symmetry with endEvent. Something like this:

<intermediateCatchEvent id="myErrorIntermediateCatcher">
    <extensionElements>
        <activitiayload name="event_var" targetVariable="process_target_var" />
        <activitiayload name="${event_var}" targetVariable="process_target_var2" />
    </extensionElements>
    <errorEventDefinition errorRef="myError" />
</intermediateCatchEvent>

2. Till now, it works. It will do the job. It seems that you hate the BPMN standard Syntax. But let my try my chance.
According to BPMN, Activity and Event should be treated the same regarding data association. See this quote from section "2.1.2 BPMN Process Elements" of  spec:
To be consistent with the metamodel, this will require the following additional elements:

These both have REQUIRED attributes[sourceRef and targetRef] which refer to
itemAwareElements. To be consistent with the metamodel, this will require the following additional elements ioSpecification, inputSet, outputSet, Data Input, Data Output. When a BPMN editor draws a Data
Association to an Activity or Event it should generate this supporting invisible substructure. Otherwise, the
metamodel would have to be changed to make sourceRef and targetRef optional or allow reference to
non-itemAwareElements, e.g., Activity and Event.

I see no reason for adding a new syntax. But Aren't we claiming supporting BPMN standard ?

[trademak]

Hi Saeid,

1. Yes the name can also be an expression.
2. It's certainly not that I see a problem with the BPMN standard syntax. I'm just saying that we shouldn't introduce it only for the event definition payload. IOSpecification, data input and data output definitions etc. certainly make sense, but then we should implement as a core foundation of the engine. So process variables, conditions, form properties etc can all be based on data definitions. And that's quite a bit of effort to use an understatement.

Best regards,