Follow Us on Twitter

Mediator throwing incomplete BusinessFaultException

by Mike Heeren on October 31, 2017 · 0 comments

A while ago I ran into the issue that business fault information was not returned to the calling system by the Mediator component in the SOA composite. Instead, only a message that a business fault occurred was responded to the calling system. The response would look something like the below example:

<env:Envelope xmlns:env="http://www.w3.org/2003/05/soap-envelope">
	<env:Header/>
	<env:Body>
		<env:Fault>
			<env:Code>
				<env:Value>env:Receiver</env:Value>
			</env:Code>
			<env:Reason>
				<env:Text xml:lang="en-US">oracle.fabric.common.BusinessFaultException</env:Text>
			</env:Reason>
			<env:Role/>
			<env:Detail>
				<exception/>
			</env:Detail>
		</env:Fault>
	</env:Body>
</env:Envelope>

In this blogpost I will describe what caused this issue, and how it could be solved.

Fault policies and Mediators

Let’s start with some information about fault policies in combination with Mediator components. When fault policies are introduced to a composite, you need to keep the following things in mind:

  • When the Mediator is configured sequencial, only the following fault policy actions are supported on the Mediator component: Abort, Rethrow and Java code.
  • When the Mediator is configured parallel, only the following fault policy actions are supported on the Mediator component: Retry, Rethrow, Human intervention, Abort and Java code.

What was causing the issue?

In our case the SOA composite exposed both synchronous and asynchronous services. The composite was also using fault policies. There were 2 fault policies defined:

  • A fault policy for asynchronous services. This fault policy would trigger a Human intervention action.
  • A fault policy for synchronous services. This fault policy would trigger a Rethrow action.

Because most components in the composite were asynchronous, the fault policy on composite level was configured to the asynchronous fault policy. For all synchronous BPEL components, this fault policy was overridden on component level.

The issue was caused by the fact that the synchronous fault policy was only applied to the BPEL components, and not to the Mediator components. So when a (business) fault was raised in the BPEL component, the fault policy would rethrow the fault to the Mediator. However, the Mediator would try to start a Human intervention action (due to the asynchronous fault policy on the composite level), which is not supported for a sequencial configured Mediator.

This could also be seen in the Enterprise Manager. The rule marked in the image below was not displayed at that moment.

Solving the issue

With the above knowledge, it was not very hard to solve the issue. Instead of configuring the fault policy on composite level to the asynchronous fault policy, we configured the composite fault policy to the synchronous fault policy. For every asynchronous BPEL component the fault policy was overridden on component level.

This resulted in faults like the below example being returned to the calling systems again:

<env:Envelope xmlns:env="http://www.w3.org/2003/05/soap-envelope">
	<env:Header/>
	<env:Body>
		<env:Fault xmlns:ns0="nl.whitehorses.services/faults/1.0">
			<env:Code>
				<env:Value>env:Receiver</env:Value>
				<env:Subcode>
					<env:Value>ns0:fault</env:Value>
				</env:Subcode>
			</env:Code>
			<env:Reason>
				<env:Text xml:lang="en-US"/>
			</env:Reason>
			<env:Role/>
			<env:Detail>
				<FaultDetails xmlns="nl.whitehorses.services/faults/1.0">
					<Code>F12345</Code>
					<Description>TEST</Description>
				</FaultDetails>
			</env:Detail>
		</env:Fault>
	</env:Body>
</env:Envelope>

Sources:

Ratings:
VN:F [1.9.22_1171]
Rating: 0.0/5 (0 votes cast)

{ 0 comments… add one now }

Leave a Comment

 

Previous post:

About Whitehorses
Company profile
Services
Technology

Whitehorses website

Home page
Whitebooks
Jobs

Follow us
Blog post RSS
Comment RSS
Twitter