Integration Hub fails to handle SOAP faults from Azure Logic Apps

BPM OutSystems
, , , , , , , ,
1

Our OutSystems Integration Hub is connecting to Azure Logic Apps via SOAP endpoints, but we’re getting generic error messages instead of the actual SOAP fault details when the Logic App returns an error. The Integration Hub just throws “External service error” without mapping the specific fault code or message.

Here’s a sample SOAP fault we’re receiving:

<soap:Fault>
  <faultcode>InvalidCredentials</faultcode>
  <faultstring>Authentication failed</faultstring>
</soap:Fault>

The cloud deployment configuration seems to strip out these details before they reach our error handling logic. We need the specific fault codes to implement proper retry logic and user notifications. Is there a way to configure Integration Hub to preserve and map SOAP fault details from Azure cloud services?

2

I’ll provide a complete solution addressing all three critical aspects of this integration challenge:

1. SOAP Fault Mapping Configuration:

First, enable detailed fault mapping in your Integration Hub cloud deployment. Access your environment’s Service Center and navigate to Integration Hub settings. Add this configuration to the advanced settings:

<SOAPConfiguration>
  <FaultHandling enabled="true">
    <PreserveFaultDetails>true</PreserveFaultDetails>
    <ParseCustomFaults>true</ParseCustomFaults>
  </FaultHandling>
</SOAPConfiguration>

This ensures SOAP faults aren’t converted to generic exceptions before reaching your application logic.

2. Azure Logic Apps Integration Setup:

Azure Logic Apps requires specific configuration to return properly formatted SOAP faults. In your Logic App definition, ensure the error response action uses the correct SOAP 1.1 format:

<Response action="SetFaultResponse">
  <StatusCode>500</StatusCode>
  <ContentType>text/xml</ContentType>
  <FaultCodeMapping>Azure-to-SOAP</FaultCodeMapping>
</Response>

Critically, Azure Logic Apps often wraps SOAP responses in HTTP layers. Configure your Integration Hub connector to handle HTTP 500 status codes and extract the SOAP fault from the response body rather than treating it as a transport-level error.

3. Cloud Deployment Error Handling:

Implement a custom exception structure in OutSystems that maps specific SOAP fault codes:


// Pseudocode - SOAP fault handler implementation:
1. Create SOAPFaultException structure with fields: faultCode, faultString, detail
2. In Integration Hub connector, add OnException handler
3. Parse raw SOAP response XML to extract fault elements
4. Map common Azure fault codes (InvalidCredentials, Timeout, RateLimitExceeded)
5. Throw structured exception with parsed fault details
6. Implement retry logic based on faultCode classification
// See Integration Hub SDK documentation section 6.3

Implementation Steps:

a) Create a Server Action called ‘ParseSOAPFault’ that takes the raw exception message and extracts fault details using XML parsing

b) Wrap all Integration Hub SOAP calls in a try-catch that calls ParseSOAPFault on exceptions

c) Configure Azure Logic App to include correlation IDs in fault details for traceability

d) Set up cloud logging to capture both the HTTP response and SOAP fault body

Testing and Validation:

  • Test with intentional fault scenarios (invalid credentials, timeouts, malformed requests)
  • Verify fault codes are correctly extracted and logged
  • Confirm retry logic triggers only for transient faults (Timeout, ServiceUnavailable)
  • Validate that permanent faults (InvalidCredentials, AuthorizationFailed) don’t retry

Common Pitfalls to Avoid:

  • Don’t rely on HTTP status codes alone - Azure returns 500 for multiple fault types
  • Ensure your cloud firewall/proxy doesn’t strip SOAP headers
  • Azure Logic Apps may cache fault responses - include cache-control headers
  • In multi-region deployments, fault formats might vary slightly between Azure regions

This comprehensive approach ensures reliable SOAP fault handling between OutSystems Integration Hub and Azure Logic Apps in cloud deployments, with proper error classification and retry logic.

3

This is a common issue with OutSystems Integration Hub when dealing with Azure Logic Apps. The default SOAP connector doesn’t automatically parse SOAP faults into structured exceptions. You need to enable detailed fault mapping in your Integration Hub configuration and create custom exception handlers for each fault code type you expect from Azure.

4

Check your Integration Hub’s SOAP service definition. There’s a setting called ‘PreserveFaultDetails’ that needs to be enabled for cloud-deployed services. Also, make sure your Azure Logic App is returning properly formatted SOAP 1.1 faults - sometimes Logic Apps default to REST-style error responses even on SOAP endpoints, which Integration Hub can’t parse correctly.

5

One workaround I’ve used successfully: implement a custom interceptor in Integration Hub that captures the raw SOAP response before it gets processed. This way you can extract fault details manually and log them properly. It’s more work than native fault mapping but gives you complete control over error handling, especially important when dealing with Azure’s sometimes inconsistent fault formatting across different Logic App configurations.

6

It’s not a licensing issue - you need to configure it through the Integration Hub’s advanced settings XML file in your cloud environment. The UI doesn’t expose all SOAP fault handling options. Also, Azure Logic Apps sometimes wraps SOAP faults in additional HTTP error layers when deployed in cloud mode, so you might need to handle both the HTTP status code and the SOAP fault body separately in your error handling flow.

7

I found the PreserveFaultDetails setting but it’s grayed out in our cloud deployment configuration. Is this a licensing limitation or do we need to enable something at the platform level first?