Bug 1015221 - Generated process which has an escalation definition uses the 'ID' attribute not the 'errorCode' to identify it in an event.
Summary: Generated process which has an escalation definition uses the 'ID' attribute ...
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: JBoss BPMS Platform 6
Classification: Retired
Component: jBPM Core
Version: 6.0.0
Hardware: Unspecified
OS: Unspecified
high
medium
Target Milestone: ER5
: 6.0.0
Assignee: Marco Rietveld
QA Contact: Marek Baluch
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2013-10-03 16:53 UTC by Marek Baluch
Modified: 2016-09-20 05:04 UTC (History)
2 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2014-08-06 20:13:29 UTC
Type: Bug
Embargoed:


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Eclipse Project 418607 0 None None None Never

Description Marek Baluch 2013-10-03 16:53:35 UTC
Description of problem:

See linked issue.

Comment 2 Kris Verlaenen 2013-10-03 22:04:13 UTC
Marco, it seems you changed the escalation handler to make sure escalations are referenced by escalationCode, not id.  I believe that may be incorrect, as escalationCode is just a string type, that would mean the type of escalationRef doesn't match.  I believe escalationRef in escalationEventDefinition probably needs to point to the id anyway.

It used to be like that, but you recently changed it:
https://github.com/droolsjbpm/jbpm/commit/dce8c01c36009521e6b4e59cb23ffafd2337261a#diff-5380748f8963db99f9a156e84fca7cbaL72

I couldn't find a lot of examples, ended up bumping on one of yours even, which I believe is correct:
https://github.com/mrietveld/jbpm-more-examples/blob/master/exception-handling/src/main/resources/intermediate-throw-escalation-process.bpmn2#L87

Comment 3 Marco Rietveld 2013-10-04 12:26:27 UTC
Hi Kris, 

Would you mind taking a look at table 8.42 in the BPMN2 spec? It looks like your initial implementation was incorrect, which was why I changed it. 

Thanks!
marco

Comment 4 Marco Rietveld 2013-10-04 13:17:18 UTC
Kris, 

I also just looked in Silver's BPMN Method & Style (v2) and it says this, on page 232: 

"errorCode and escalationCode are simple strings to match throw-catch pairs. Throwing events must provide it, but it is optional for boundary events."
...
"An Error boundaryEvent will catch any error signal with matching errorCode thrown from a child level event, and similarly for Escalation."

Unfortunately, we don't yet support "general" error and escalation boundary events because there's no way to determine the origin of a thrown error or escalation event in the jbpm engine code (and wheyther or not it's from a child level event). Ironically, this is a very similar problem what we have with compensation. 

In any case, it seems pretty clear to me that escalationCode is the proper attribute to refer to the Escalation being caught. 

Thanks,
Marco

Comment 5 Marco Rietveld 2013-10-07 11:02:54 UTC
Waiting on Kris to confirm or deny that my comments above on the spec.

Comment 6 Kris Verlaenen 2013-10-07 12:12:44 UTC
Marco,

I think the explanations above do make sense, and they refer to the behaviour of these nodes at runtime, but I don't think that they have any implications on the XML level that the errorCode must be used in references.

I do understand that different event nodes (throwing and catching escalation) are "paired" by using the same errorCode for both of them.  However, this imho doesn't implicate that the escalationRef (that an escalationEventDefinition uses to reference its escalation element, which contains the escalationCode) must be the escalationCode, and not the id of the escalation.  I believe that references must always use the id, an escalationCode simply is not unique so cannot be used for this purpose really.  

So to have a paired throwing and catching escalation event, I believe either 
 * both events have an escalationEventDefinition referring to the same escalation (by id, so same id for both) and therefore share the same escalationCode
 * both events have an escalationEventDefinition referring to a different escalation (by id, so each having a different id to refer to their specific escalation element), but these two escalations have the same escalationCode

Kris

Comment 8 Marek Baluch 2013-12-03 20:28:13 UTC
Verified on ER5.


Note You need to log in before you can comment on or make changes to this bug.