- Whitehorses - http://blog.whitehorses.nl -

Mediator throwing incomplete BusinessFaultException

Tweet [1]

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:

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:

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.

[2]

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: