Category Archives: Testing

Receive empty SOAP response in Oracle Service Bus (invalid SOAP fault)

We had some problems using Oracle Service Bus to perform a callout to an external webservice. All callouts resulted in a general BEA-38001 Error. In the end we discovered that the issue was functional (wrong data in the request), however the technical documentation of the external webservice informed us that we should receive a SOAP Fault. However this apparantly was not the case, as could be seen in the debug console. The SOAP Body element was empty:

After enabling message tracing on the specific business service we noticed the following logging:

<BEA-398203> <
 [OSB Tracing] Outbound response was received.

Service Ref = someProject/BusinessServices/someBusinessService
 URI = https://externalhost:443/SomePort
 Error code = BEA-380001
 Error Message = Internal Server Error
 Message ID = 8592423476474314819--7dc5b3e6.138425ff239.-29c0
 Response metadata =
 <tran:headers xsi:type="http:HttpResponseHeaders" xmlns:http="" xmlns:tran="" xmlns:xsi="">
 <tran:user-header name="SOAPAction" value="&quot;&quot;"/>
 <http:Content-Type>text/xml; charset=utf-8</http:Content-Type>
 <http:Date>Thu, 28 Jun 2012 11:25:22 GMT</http:Date>
 <tran:response-code xmlns:tran="">2</tran:response-code>
 <tran:response-message xmlns:tran="">Internal Server Error</tran:response-message>
 <tran:encoding xmlns:tran="">utf-8</tran:encoding>
 <http:http-response-code xmlns:http="">500</http:http-response-code>
 Payload =
<env:Envelope xmlns:env="" xmlns:xsd="" xmlns:xsi=""><env:Body><env:Fault><faultcode xmlns="">env:003</faultcode><faultstring xmlns="">Standard Error: Authentication failed</faultstring><faultactor xmlns="">m86b1b2f-4d34-46cd-d538-c21ddb88743</faultactor></env:Fault></env:Body></env:Envelope>

Which is strange, because the payload clearly showed us that their is a soap envelope containing a soap fault. Normal OSB behaviour would mean this payload is then used in the <body> element of the SOAP response. However for some reason in this case the result was an empty <body> element, so looking more closely to the payload we could see that the content is:

<env:Envelope xmlns:env="" xmlns:xsd="" xmlns:xsi="">
 <faultcode xmlns="">env:003</faultcode>
 <faultstring xmlns="">Some Functional Error</faultstring>
 <faultactor xmlns=""someURI</faultactor>

The problem here seems to be the faultcode element, since it holds the value 003. However the W3C SOAP standard only allows the values: Client, Server, MustUnderstand and VersionMismatch. And it seems the  Oracle Service Bus is very strict about this.

After some additional testing with SOAPui as service consumer we can see that the message also fails there. Remember that SOAPui by default does not perform these validations and you will need Assertions for that.

This test (using a mockservice) shows that when the same response comes back with a valid faultcode the SOAPui assertions succeed. In the example we use the “.” seperator which is allowed and use Client as prefix since this is a valid faultcode.

The OSB is strict regarding the W3C standards and therefor elements like <body> are protected. (This is also why you shouldn’t use the Assign action on the $body variable, but better use the Replace node content functionality). So the real reason of the problem seems that the external service sends an invalid SOAP envelope.


In the past I had an identical problem with an endpoint that returned a HTML page (with some functional text information) instead of an expected SOAP message. Lessons learned: if you really want to know what you response looks like, enable tracing on the Business Service and examine the payload.


Posted by on 10-08-2012 in Oracle, OSB, SOAP, SOAPui


Tags: , ,

Using Greenhat Tester watch mode with Tibco EMS

In GH Tester version 3.3.0 and above, some transports like the Tibco EMS transport have a “watch” mode. In this watch mode, GH Tester receives any new messages sent to the queue but won’t remove them from the queue. In this way it is possible to passively access queue messages without affecting the queue itself. It does this by subscribing to system monitor topics and because of this the transport login configuration must have administration rights on the EMS server in question.

However when trying to perform a test we receive the following error:
Fatal error: Cannot subscribe to “Transports/TIBCO EMS.a3t” -Error creating listener Linked to error: The Transport Connection or Watch settings user is not an admin user

The error is a bit unclear, because we are in fact connecting with the admin user and should have full-access to the queues. But in some way the Greenhat Tibco Messenging plugin guide (pdf) shows the anser. You must uncheck the “Use JNDI to lookup destination” checkbox.

In our test scripts we can now actually monitor (“watch”) queues for messaging travelling through them and being picked up by other components in the workflow.
Leave a comment

Posted by on 30-08-2010 in EMS, GreenHat, Testing


Tags: , ,