SOAP Web Services in OutSystems: When and How to Use Them

In Service Studio, click the Logic tab on the right-hand panel. Expand Integrations. Right-click SOAP and select Consume SOAP Web Service. The Consume SOAP Web Service dialog opens with two import options: - Remote URL: paste the WSDL URL directly (e.g., https://service.example.com/service?wsdl) - Local File: browse to a downloaded .wsdl file — useful when the WSDL is behind authentication or on an internal network not reachable from Service Studio Click Next. Service Studio downloads and parses the WSDL. A tree view shows all available services, ports, and operations. Check the operations you want to import. Click Finish. Service Studio creates: a SOAP service node under Logic tab → Integrations → SOAP, one action per selected operation (callable as Server Actions), and Structures under Data tab → Structures for all WSDL-defined complex types.

Calling a generated SOAP action is identical to calling a Server Action. In any Server Action, drag the SOAP operation from the toolbox (or from Logic tab → Integrations → SOAP → [YourService] → [Operation]) into the action flow. The operation node has input and output parameters defined by the WSDL structures. Assign your data to the input parameters before the node and read from the output parameters after. Example action flow for an address validation SOAP service: Start → Assign (RequestAddress.Street = Input.Street, RequestAddress.City = Input.City, RequestAddress.PostalCode = Input.PostalCode) → ValidateAddress (SOAP operation, Request = RequestAddress) → Assign (IsValid = ValidateAddress.Response.IsValid, StandardizedAddress = ValidateAddress.Response.StandardizedAddress) → End The SOAP operation runs server-side — never drag it into a Client Action.

SOAP services often have different endpoint URLs for test and production environments. Override the endpoint URL without redeploying: O11 approach: 1. Create a Site Property: Data tab → Site Properties → right-click → Add Site Property. Name: SoapServiceEndpointUrl, Type: Text, Default: (test endpoint URL) 2. In Service Studio, click the SOAP service node → Properties → Effective URL → set to GetValue(Site.SoapServiceEndpointUrl) expression 3. In Service Center, set the Site Property to the production URL in the production environment This allows the same published module to connect to different SOAP endpoints per environment without any code change. Note: If the WSDL changes (new version of the service), you must refresh the WSDL. Right-click the SOAP service node → Refresh SOAP Web Service → provide updated WSDL → review structural changes → resolve any TrueChange errors → republish.

Many enterprise SOAP services (especially SAP, banking) require WS-Security headers in the SOAP envelope. Service Studio has built-in WS-Security support. In Service Studio, click your SOAP service node under Logic tab → Integrations → SOAP. In the Properties panel: 1. Find Authentication property → select Username/Password 2. Set Username expression to Site.SoapUsername (a Site Property) 3. Set Password expression to Site.SoapPassword (a Site Property marked as Secret) For more advanced WS-Security configurations (X.509 certificates, signature algorithms, timestamp requirements), you need Integration Studio to create a C# extension. The extension calls the service using .NET's System.ServiceModel.BasicHttpBinding with WCF security configuration, then wraps it in OutSystems actions via Integration Studio's action mapping. Common WS-Security modes OutSystems handles natively: None, Username/Password (UsernameToken PasswordText). Other modes (PasswordDigest, X.509, SAML tokens) require Integration Studio extensions.

SOAP services return errors as SOAP Fault XML responses, not HTTP error status codes. OutSystems translates SOAP Faults into Communication Exceptions automatically. To handle errors, right-click the Server Action flow after the SOAP operation → Add Exception Handler → Communication Exception. The CommException.Message contains the SOAP Fault string field. The CommException.ExceptionMessage contains the full fault detail. Action flow with error handling: Start → [SOAP Operation] → Assign (success output) → End [Communication Exception] → Assign (IsSuccess=False, ErrorMessage = "Service call failed: " + CommException.Message) → LogError (Module=YourModule, Message="SOAP fault: " + CommException.ExceptionMessage) → End For SOAP services that return business errors inside a successful SOAP response (not a Fault), inspect the response structure fields — the service documentation will define which fields indicate error conditions. Check them with If nodes after the operation call. Service Center → Monitoring → Integrations logs every SOAP request/response including the raw XML envelope — invaluable for debugging malformed requests or unexpected responses.

To expose OutSystems actions as a SOAP service for legacy consumers: 1. Logic tab → Integrations → SOAP → right-click → Expose SOAP Web Service 2. Name the service (e.g., LegacyIntegrationService) 3. Right-click the service → Add SOAP Web Service Method 4. Name the method (this becomes the SOAP operation name) 5. Add input/output parameters — these become the WSDL message types 6. Implement the method logic like any Server Action 7. 1-Click Publish After publishing, the WSDL is accessible at: https://<server>/<module>/SoapService.asmx?WSDL Provide this URL to the legacy system consumer to generate their client code. Note: Exposed SOAP services use the default OutSystems authentication unless you add custom validation in the method logic. For WS-Security on exposed services, check the HTTPRequestHandler for SOAPAction headers and implement token validation manually.

SOAP is a blocking factor for O11-to-ODC migration. Before beginning migration: 1. Audit all SOAP integrations: in Service Studio, Logic tab → Integrations → SOAP — list every consumed and exposed service 2. For each consumed SOAP service, check if the provider has a REST equivalent — most modern enterprise platforms now offer REST/OpenAPI alongside their SOAP endpoints 3. For SAP: use SAP OData APIs (REST-based) via Integration Builder (O11) or direct REST consumption (ODC compatible) 4. For custom legacy systems: work with the provider to expose a REST wrapper or implement a REST-to-SOAP adapter service 5. For exposed SOAP services: identify all SOAP consumers, migrate them to REST when feasible, or keep those specific modules in O11 as bridging services The O11 and ODC Conversion Assessment Tool (ODC Portal → Convert from O11) flags SOAP dependencies as migration blockers — resolve these before running the assessment.