Error Handling for Web Services with SOAPHTTP

21-8 Developers Guide for Oracle Application Integration Architecture Foundation Pack The implementation of the Session Pool Manager is application-specific, taking into consideration the Web service framework implementations.

21.2.4 Error Handling for Web Services with SOAPHTTP

This section discusses error handling for Web services with SOAPHTTP: ■ Section 21.2.4.1, For Inbound Connectivity ■ Section 21.2.4.2, For Outbound Connectivity ■ Section 21.2.4.3, Request-Response and Request-Only System Errors ■ Section 21.2.4.4, Request-Response Business Errors

21.2.4.1 For Inbound Connectivity

Participating applications should have the capability to consume WSDLs with fault messages defined. The WSDLs provided to participating applications are generated for the coarse-grained request-response services created using BPEL ABCS. The input and output payloads for these services are schemas provided by the participating applications. Fault schemas provided by applications aid in incorporating them in the definitions of the services WSDLs.

21.2.4.2 For Outbound Connectivity

The WSDLs of the participating application services are consumed by the AIA services. The error handling depends on the message exchange pattern.

21.2.4.3 Request-Response and Request-Only System Errors

■ Call from the participating application not successful The AIA layer returns HTTP 4xx Client Error and the participating applications must have the mechanism to resubmit manually or automatically. Example: FMW is down and AIA service is not accessible. ■ Call from the participating application successful but system resource not accessible The AIA layer returns 5xx Server Error and the participating applications must have the mechanism to resubmit manually or automatically. Example: From the AIA service execution, the cross-reference database is not accessible.

21.2.4.4 Request-Response Business Errors

■ WSDL of the participation application service has named fault In this case, the WSDL has a named fault with a specified fault message format. The AIA service, on encountering a business error, puts the error information in the fault message and reply back to the calling service. The participating application takes action accordingly. Example: An order with invalid options is pushed by CRM application to ERP application and fails validation in the ERP application. Upon receiving the fault, the AIA service constructs an appropriate error message, transforms it to the fault schema of the CRM application, and sends it back as a named fault. ■ WSDL of the participation application service has no named fault Establishing Resource Connectivity 21-9 This case has two possibilities: – WSDL response message has component and elements for specifying error In this case, the AIA service, on encountering a business error, would put the error information in the response message fault component and elements and reply back to the calling service. The participating application takes action accordingly. – WSDL specifies no valid way for receiving fault information Two options: Send back the fault as a SOAP fault if the FMW component used for the AIA service supports it. Model the interaction as Request-Only and make provisions for a separate participating application Web service to receive the result.

21.2.5 Security for Web Services with SOAPHTTP