Wednesday 11 February 2009

Oracle ESb Dynamic routing error

Response Document
The invocation resulted in an error: .


<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/">

<soapenv:Body>

<soapenv:Fault>

<faultcode>soapenv:Serverfaultcode>

<faultstring>BEA-380001: Internal Server Errorfaultstring>

<detail>

<con:fault xmlns:con="http://www.bea.com/wli/sb/context">

<con:errorCode>BEA-380001con:errorCode>

<con:reason>Internal Server Errorcon:reason>

<con:location>

<con:node>RealmBasedRoutingcon:node>

<con:path>response-pipelinecon:path>

con:location>

con:fault>

detail>

soapenv:Fault>

soapenv:Body>

soapenv:Envelope>


If i look under the Invocation tree, Under the Message context


Message Context Changes
added $outbound
changed $body

<soapenv:Body xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">

<soapenv:Fault>

<faultcode xmlns:ns1="http://xml.apache.org/axis/">ns1:Client.NoSOAPActionfaultcode>

<faultstring>no SOAPAction header!faultstring>

soapenv:Fault>

soapenv:Body>






This error was resolved by adding Transport level SoapAction header when doing dynamic routing. SoapAction was set to empty string, this resolved the error as service then looks for operation details in soap body

3 comments:

Ganapathi.V.Subramanian[VG] said...
This comment has been removed by the author.
Ganapathi.V.Subramanian[VG] said...

Configuring Transport Headers in Message Flows
The transport header action is a communication type action, and it is available in pipeline stages and error handler stages.

Configuring Global Pass Through and Header-Specific Copy Options for Transport Headers
The following options are available when you configure a transport headers action:

The Pass all Headers through Pipeline option specifies that at run time, the transport headers action passes all headers through from the inbound message to the outbound message or vice versa. Every header in the source set of headers is copied to the target header set, overwriting any existing values in the target header set.
The Copy Header from Inbound Request option and the Copy Header from Outbound Response options specifies that at run time, the transport headers action copies the specific header with which this option is associated from the inbound message to the outbound message or vice versa.
Use the options in a way that best suits your scenario. Both options result in the headers in the source header set being copied to the target header set, overwriting any existing value in the target set. Note that the Pass all Headers through Pipeline option is executed before the header-specific Copy Header options. In other words, for a given transport headers action configuration, if you select Pass all Headers through Pipeline, there is no need to select the Copy Header option for given headers.

However, you can select Pass all Headers through Pipeline to copy all headers, and subsequently configure the action such that individual headers are deleted by selecting Delete Header for specific headers.


Please refer: http://download-llnw.oracle.com/docs/cd/E13171_01/alsb/docs30/userguide/modelingmessageflow.html#ConfiguringTransportHeadersInMessageFlows

http://download-llnw.oracle.com/docs/cd/E13171_01/alsb/docs30/consolehelp/proxyactions.html#wp1239233

Ganapathi.V.Subramanian[VG] said...

Handling Errors as the Result of a Service Callout
You can configure error handling at the message flow, pipeline, route node, and stage level. The types of errors that are received from an external service as the result of a service callout include transport errors, SOAP faults, responses that do not conform to an expected response, and so on.

The fault context variable is set differently for each type of error returned. You can build your business and error handling logic based on the content of the fault variable. To learn more about $fault, see Fault Variable.

Transport Errors
When a transport error is received from an external service and there is no error response payload returned to ALSB by the transport provider (for example, in the case that an HTTP 403 error code is returned), the service callout action throws an exception, which in turn causes the pipeline to raise an error. The fault variable in a user-configured error handler is bound to a message formatted similarly to that shown in Listing 3-11.


Refer:
http://download-llnw.oracle.com/docs/cd/E13171_01/alsb/docs30/userguide/modelingmessageflow.html#ConfiguringTransportHeadersInMessageFlows