Output variables from CallActivity on BoundaryEvent trigger?

Hi,

In my context, I also tried to do this. My interpretation of BPMN execution semantics is it should be possible to attach some date to an Error Event so this should be possible.

This is not supported yet by Activiti AFAIK.

To circumvent the issue, I defined a pattern from the design model (using sth like Bizagi) to the executable model (done with Activiti) which says to use instead of the Error Boundary Event in this case a return code, mapped in the subprocess call activity, and test it in a gateway right after the subprocess.

Regards
Michel

iam

I already post a solution to this problem: ACT-1411

jonathan1

Thanks, iam and mdaviot, for both the pattern reference and upload.

I decided to post the variable to the parent process and wait for another Activiti release to address writing to output variables on boundary events.

Here is part of my comment I wrote ACT-1411 https://jira.codehaus.org/browse/ACT-1411

I am not sure, this is what is intended by specification. When an error occurs, it means that you were not able to do the job and output and variables are not valid. You can only send an error code to let the caller know what was the problem.
If you need variable data to produce the error code, it might be a good sign that error handling code is not in a good place. Maybe you can move the error processor to the scope of the variables, process variables and throw the error with error code. Something like the figure with the annotation " error handler has access to variables local to the subprocess" in Event Sub-Process section of activiti guide.

Hi,

Here is also my next reply on the JIRA, I suggest to reopen it if you agree with this suggestion.

I agree with what was said before, ie that normal mapping should not occur when an Error Event is thrown in the subprocess.

However, I also had a deep look at the spec for BPMN :
http://www.omg.org/spec/BPMN/2.0/

In section 8.3.3, we see that the Error has an ItemDefinition which the same as the one used in figure to define the "payload" of a Message.

So my suggestion is to implement in Activiti a way to set for an error event this payload, by using the ItemDefinition class. This way the Error Event can have some data attached to it (same as the variables used for an Start Event message for instance), and this data can be used in the calling parent process to know some context information about the cause of the error.

Regards
Michel

jbarrez

I see the point in that. I don't know if itemDefinition is the best way to do it … maybe extending BpmnError is a better way.
If you need this, please file a Jira issue with a link to this forum post.

OK, I created a new JIRA for that :

https://jira.codehaus.org/browse/ACT-1462

From Saeid : Based on spec, could you propose a sample xml bpmn doing the job ?

Based on the spec, a BoundaryEvent is a CatchEvent and thus has a DataOutput and DataOuputAssociation.
I suggest to use something similar to the implementation of the WebserviceTask which also uses dataOutputAssociation.

See an example of such a BPMN file here : https://github.com/Activiti/Activiti/blob/master/modules/activiti-cxf/src/test/resources/org/activiti/engine/test/bpmn/servicetask/WebServiceTaskTest.testWebServiceInvocationWithDataFlowXPath.bpmn20.xml

I don't understand all of it yet, but I think this shares enough features to be used in the implementation of the BoundaryEvent in Activiti.

Yes, I agree with your detailed analysis Saeid.
Something to take into account also is a ErrorEvent can be raised from within the Java code with the usage of the BpmnError exception. I suggest that this exception has a property of type Map to define the associated data.

Comment from Tijs:
We are not a big fan of the BPMN data input and output definition.
So this will definitely need a lot more discussion.
Because we are now finalising the source code to the 5.11 release I would ask to let this one rest to after the release.
Then we can startup a discussion about it.

Hi Tijs
I also think it is better to be implemented with the new version of parser. I will reopen the issue after release of 5.11.

From Tijs:

Hi Saeid,

Yes we can do that now. I think we need a similar definition as the call activity to define the payload of the error message.
In the case of an error end event we only need an output definition.
As I said before we don't like the BPMN itemdefinition approach so I would like to keep it similar to the current call activity input and output definitions.

Hi Tijs:
Do you mean something from BPMN standard or some activiti specific extension ?
Can you suggest an hypothetical xml sample ?

Hi Saeid,

Will have to think a bit about that one. I'll come back to this tomorrow.

Best regards,

Hi,

If we could add a Map to the BpmnError then we have a container to add variables.
The error event definition could something like this:

<blockcode>
<errorEventDefinition errorRef="myError">
<extensionElements>
<activiti:variable name="customerNr" />
<activiti:variable expression="${customer.name}" />
</extensionElements>
</errorEventDefinition>
</blockcode>

Do you think this would be a good way to define the payload of the BpmnError?

Best regards,

waldo

We also are in dire need of a way to pass results out of subprocesses (executed via CallActivities) in the case of errors in our project.

We currently use error end events to exit a subprocess in the case of an error and boundary error events attached to the CallActivities in calling processes. In a new use case we have to somehow attach data to the error event, because out-parameters of CallActivities (which we use to pass information back to the caller for regular end events) don't seem to be written in the case of error events.

I've seen there is a JIRA feature request for this https://jira.codehaus.org/browse/ACT-1462, but without progress in 2013. Is this feature still on the roadmap? Or is there some other way to pass information from callee to caller in the case of an error end event?

Many thanks!

Hi,

I was waiting for a response from Saeid (or somebody else).
I'll ping Saeid about this and let's see if we can add it to the 5.13 roadmap.

Best regards,

Hi Saeid,

I've updated the post with the code, it was gone due to the rendering of the new forum.
If you add a blockquote element to your code it will be better readable as well.
In the case of this error event definition, I don't think we need an source and target definition, but only a way to express which variables should be part of the error payload. So that's the background of my code proposal. WDYT?

Best regards,

Hi Tijs,
First of all, it seems that you have inserted a piece of XML in your above #17 comment, which is not readable Do you have it somewhere ?

Lets have a wrap up. We need extensions on two parts, catching and throwin. And either of them can be done in two ways, BPMN standard and activiti shortcut.

1. BPMN standard
If we want to stick to the standard, based on the specification, these could be throwing and catching parts.

Sample throwing, BPMN style, Long version:

<br><endEvent id="myErrorEndEvent"><br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <dataInput id="event_variable" /><br>&nbsp;&nbsp;&nbsp; <dataInputAssociation><br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <sourceRef> process_variable </sourceRef><br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <targetRef> event_variable" /><br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <assignment><br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <from> ${process_variable.field}</from><br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <to>${event_variable.field}</to><br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </assignment><br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </dataInputAssociation><br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <errorEventDefinition errorRef="myError" /><br></endEvent>&nbsp; <br>

or simpler:

Sample throwing, BPMN style, shorter version:

<br><endEvent id="myErrorEndEvent"><br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <dataInput id="event_variable" /><br>&nbsp;&nbsp;&nbsp; <dataInputAssociation><br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <sourceRef> process_variable </sourceRef><br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <targetRef> event_variable" /><br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </dataInputAssociation><br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <errorEventDefinition errorRef="myError" /><br></endEvent>&nbsp; <br>

sample catching, BPMN style, Long version:

<br><intermediateCatchEvent id="myErrorIntermediateCatcher"><br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <dataOutputAssociation><br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <sourceRef>event_variable</sourceRef><br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <targetRef>process_var2</targetRef><br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <assignment><br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <from> ${event_variable.field}</from><br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <to> ${process_variable.field}</to><br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </assignment><br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </dataOutputAssociation><br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <signalEventDefinition signalRef="MyMessage" /><br></intermediateCatchEvent><br>

or simpler:

Sample catching, BPMN Style, Short version:

<br><intermediateCatchEvent id="myErrorIntermediateCatcher"><br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <dataOutputAssociation><br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <sourceRef>event_variable</sourceRef><br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <targetRef>process_var2</targetRef><br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </dataOutputAssociation><br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <signalEventDefinition signalRef="MyMessage" /><br></intermediateCatchEvent><br>

Ok, You have already stated clearly at least twice that you are not a big fan of usage of BPMN Data input and Data output specification, but I would like to insist on keeping compatibility with BPMN as far as possible and the same time provide easier activiti specific shortcuts. Actually it is already used in web service task.
Here is my shortcut proposal:

Activiti extension:

Sample throwing, Activiti extension style:

<br><endEvent id="myErrorEndEvent"><br>&nbsp;&nbsp;&nbsp; <extensionElements><br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <activiti:in source="process_var" target="event_var" /><br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </extensionElements>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <br>&nbsp;&nbsp;&nbsp; <errorEventDefinition errorRef="myError" /><br></endEvent><br>

Sample catching, Activiti extension style:

<br><intermediateCatchEvent id="myErrorIntermediateCatcher"><br>&nbsp;&nbsp;&nbsp; <extensionElements><br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <activiti:smileysurprised:ut source="event_var" target="process_target_var" /><br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </extensionElements><br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <signalEventDefinition signalRef="myError" /><br></intermediateCatchEvent><br>

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:

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

and throwing part can be something like:

<br><intermediateCatchEvent id="catchSignalEvent" name="On Alert"><br>&nbsp;&nbsp;&nbsp; <!&ndash; signal event definition &ndash;><br>&nbsp;&nbsp;&nbsp; <XXXEventDefinition" /><br>&nbsp;&nbsp;&nbsp; <dataInputAssociation><br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <sourceRef>PrefixVariable</sourceRef><br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <targetRef>prefix</targetRef><br>&nbsp;&nbsp;&nbsp; </dataInputAssociation><br>&nbsp;&nbsp;&nbsp; <dataInputAssociation><br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <sourceRef>SuffixVariable</sourceRef><br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <targetRef>suffix</targetRef><br>&nbsp;&nbsp;&nbsp; </dataInputAssociation><br></intermediateCatchEvent><br>

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

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 Activiti

ut extensions to copy the values properly. Even better in Web service, which we both support BPMN standard and our simpler version.

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

ayload name="event_var" value="staticvalue" />
<activiti

ayload name="event_var2" value="${expression_var}" />
    </extensionElements>
    <errorEventDefinition errorRef="myError" />
</endEvent>
</blockcode>

<blockcode>
<intermediateCatchEvent id="myErrorIntermediateCatcher">
    <extensionElements>
        <activiti

ayload name="event_var" targetVariable="process_target_var" />
</extensionElements>
<errorEventDefinition errorRef="myError" />
</intermediateCatchEvent>
</blockcode>

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:

<br><intermediateCatchEvent id="myErrorIntermediateCatcher"><br>&nbsp;&nbsp;&nbsp; <extensionElements><br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <activiti:smileytongue:ayload name="event_var" targetVariable="process_target_var" /><br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <activiti:smileytongue:ayload name="${event_var}" targetVariable="process_target_var2" /><br>&nbsp;&nbsp;&nbsp; </extensionElements><br>&nbsp;&nbsp;&nbsp; <errorEventDefinition errorRef="myError" /><br></intermediateCatchEvent><br>

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 ?