红帽全球峰会此内容没有您所选择的语言版本。
7.26. Exception Handling Examples
Time-out: If you are using the EsbActionHandler action and the node is awaiting a callback, you can limit the waiting period. To do so, add a timer to the node. (That is how Service1 is configured in the process definition snippet below.) The timer can be set for a certain period, in this case, ten seconds:
Service1 has two outgoing transitions. The first of these is ok whilst the second one is time-out-transition.
Normally the call-back will signal the default transition, which is
ok , since it is defined as the first. However, if the processing of the service takes more then ten seconds, the timer will run instead. The timer's transition attribute is set to time-out-transition, meaning that this transition will be taken on timing-out.
The processing ends up in the
ExceptionHandling node. From here, you can perform compensatory work.
Exception Transition: You can define an exceptionTransition to handle any exceptions that occurs in the midst of the service being processed. Doing so sets the faultTo endpoint reference on the message, meaning that the Enterprise Service Bus will make a call-back to this node. This signals the exceptionTransition.
Service2 has two outgoing transitions: the ok transition will be taken when things are happening normally, whilst the exception transition will be taken when the service has, as its name indicates, thrown an exception during processing:
In the preceding definition of
Service2, the action's exceptionTransition is set to exception. In this scenario, the process itself also ends up in the ExceptionHandling node.
Exception Decision: Observe the configuration of Service3 and the exceptionDecision node that follows it. Service3 processes to a normal conclusion and the transition out of its node occurs as one would expect.
However, at some point during the service execution, an
errorCode was set, and the exceptionDecision node checks if a variable of the same name has been called here:
The
esbToBpmVars mapping element extracts the errorCode called SomeExceptionCode from the message's body and sets in the JBPM context. (This is assuming that the SomeExceptionCode is set.)
In the next node, named
exceptionDecision , the ok transition is taken if processing is normal, but if a variable called errorCode is found in the JBPM context, the exceptionCondition transition is taken instead.
To configure the system in this way, you need to use the JBPM's decision node feature. It allows you to nest multiple transitions within a condition:
<condition>#{ errorCode!=void }</condition>
<condition>#{ errorCode!=void }</condition>
Note
To learn more about conditional transitions, refer to the JBPM Reference Guide.
'%20d='M201.5%20305.5c-13.8%200-24.9-11.1-24.9-24.6%200-13.8%2011.1-24.9%2024.9-24.9%2013.6%200%2024.6%2011.1%2024.6%2024.9%200%2013.6-11.1%2024.6-24.6%2024.6zM504%20256c0%20137-111%20248-248%20248S8%20393%208%20256%20119%208%20256%208s248%20111%20248%20248zm-132.3-41.2c-9.4%200-17.7%203.9-23.8%2010-22.4-15.5-52.6-25.5-86.1-26.6l17.4-78.3%2055.4%2012.5c0%2013.6%2011.1%2024.6%2024.6%2024.6%2013.8%200%2024.9-11.3%2024.9-24.9s-11.1-24.9-24.9-24.9c-9.7%200-18%205.8-22.1%2013.8l-61.2-13.6c-3-.8-6.1%201.4-6.9%204.4l-19.1%2086.4c-33.2%201.4-63.1%2011.3-85.5%2026.8-6.1-6.4-14.7-10.2-24.1-10.2-34.9%200-46.3%2046.9-14.4%2062.8-1.1%205-1.7%2010.2-1.7%2015.5%200%2052.6%2059.2%2095.2%20132%2095.2%2073.1%200%20132.3-42.6%20132.3-95.2%200-5.3-.6-10.8-1.9-15.8%2031.3-16%2019.8-62.5-14.9-62.5zM302.8%20331c-18.2%2018.2-76.1%2017.9-93.6%200-2.2-2.2-6.1-2.2-8.3%200-2.5%202.5-2.5%206.4%200%208.6%2022.8%2022.8%2087.3%2022.8%20110.2%200%202.5-2.2%202.5-6.1%200-8.6-2.2-2.2-6.1-2.2-8.3%200zm7.7-75c-13.6%200-24.6%2011.1-24.6%2024.9%200%2013.6%2011.1%2024.6%2024.6%2024.6%2013.8%200%2024.9-11.1%2024.9-24.6%200-13.8-11-24.9-24.9-24.9z'/%3e%3c/svg%3e){kind=small}