CPI Proxy Part 2: SOAP Adapter, WSDLs and WS-Security

📌 KEY POINTS
✅ The SOAP adapter exposes iFlows as web services and calls external SOAP services.
✅ WSDLs define operations and message structures used in mappings and adapter configuration.
✅ WS-Security can sign and encrypt messages using keystore certificates.
✅ SOAP faults must be mapped to proper error handling, not swallowed.
⚠️ Synchronous SOAP calls with long processing times cause timeouts for senders.

━━━━━━━━━━━━━━━━━━━━
▶ WHERE WE ARE
Part 1 covered proxies. Part 2 covers standard SOAP services.

━━━━━━━━━━━━━━━━━━━━
▶ 1. SENDER ADAPTER
A SOAP sender adapter turns an iFlow into a web service endpoint. With a WSDL, it publishes operations and validates messages; in a simpler mode it accepts any payload. Senders authenticate with certificates, OAuth or basic authentication.

━━━━━━━━━━━━━━━━━━━━
▶ 2. RECEIVER ADAPTER
A SOAP receiver adapter calls external services using their WSDL, endpoint and operation. Timeouts, authentication and proxy type (internet or on-premise via Cloud Connector) are configured per channel.

━━━━━━━━━━━━━━━━━━━━
▶ 3. WS-SECURITY
Partners may require signed or encrypted SOAP messages. WS-Security settings in the adapter use keys and certificates from the tenant keystore to sign outgoing messages, verify incoming signatures and encrypt or decrypt content.

━━━━━━━━━━━━━━━━━━━━
▶ 4. FAULTS
SOAP faults returned by receivers must be handled: either returned to the sender in synchronous scenarios or handled by exception subprocesses with alerts and retries in asynchronous ones. Swallowing faults creates silent data loss.

━━━━━━━━━━━━━━━━━━━━
▶ 5. SYNC VERSUS ASYNC
Synchronous request-reply scenarios hold the sender until the reply arrives; long back-end processing leads to timeouts. Prefer asynchronous designs with acknowledgements for long-running processing, and keep synchronous calls short.

━━━━━━━━━━━━━━━━━━━━
▶ STEP BY STEP

1. Expose an iFlow with a SOAP sender adapter and WSDL.
2. Call an external SOAP service with the receiver adapter.
3. Enable WS-Security signing with a test certificate.
4. Handle a SOAP fault in an exception subprocess.

✅ CHECKPOINT: SOAP calls in both directions work with security and proper fault handling.

A synchronous SOAP interface to a logistics provider timed out during peak hours, and the sender retried, creating duplicate shipments. The design was changed to asynchronous with an acknowledgement and a duplicate check at the receiver, ending the timeouts and duplicates.

• Long-running synchronous calls.
• Ignored SOAP faults.
• Certificates for WS-Security not monitored.
• No duplicate protection on retries.

• Async with acknowledgements for long processing.
• Explicit fault handling.
• Keystore-managed WS-Security.
• Idempotent receivers.

Interviewers ask how SOAP sender and receiver adapters are configured, how WS-Security works and how to handle faults and timeouts.