Design SOAP integrations with IFS Cloud and IFS Connect

Explore this learning path

Documentation-based guide draft · Reviewed against sources on 2026-09-27 · Not executed in an IFS environment. IFS references use 26R1 unless stated otherwise. Confirm available APIs, components, and permissions in your installed release.

Use this procedure to prove an inbound IFS Connect request before connecting a file flow or middleware worker. The goal is one accepted message, a traceable processing result, and a reproducible failure case.

Before you start

Ask the integration administrator for the development gateway URL, the selected inbound interface, authentication requirements, a minimal valid sample, and the routing rule/queue that should receive it. If the interface exposes a WSDL, obtain it from that environment. A SOAP Gateway URL alone does not define the business operation or message body.

Use an integration identity with the intended grants. Keep the request small. The 26R1 gateway documentation states a 25 MB request limit; your proxy or integration contract may impose a lower one.

1. Select one gateway format

Choose the format your configured route expects:

Format	Request preparation
SOAP_IFS	Use the interface’s envelope and IFS-specific header values used for routing
JSON	Use the agreed JSON schema and Content-Type: application/json
Text	Send the text content/attachment form expected by the interface; set its text content type and X-IFS-Content-Disposition filename

Do not wrap a JSON payload in SOAP simply because the endpoint is called SOAP Gateway. Conversely, an ordinary SOAP envelope without the expected IFS routing header may not match a SOAP_IFS rule.

2. Prepare the request in Postman

1. Create a private collection for this integration.
2. Create a POST request using the administrator-confirmed URL.
3. Configure its Authorization tab with a token from the IFS authentication procedure.
4. For a WSDL-backed SOAP interface, generate/import its sample request and fill the mandatory elements with fictional, valid development data.
5. Use the content type and SOAP action, if required, defined by the binding. SOAP 1.1 and SOAP 1.2 header conventions differ.
6. For a JSON route, use the approved sample as a raw JSON body instead.

For a text route, an illustrative header pair is:

Content-Type: text/csv; charset=utf-8
X-IFS-Content-Disposition: LAB-INBOUND-031.csv

The filename is a message attribute, not authorization to access a local file. Its meaning and routing behavior must match the configured receiver.

3. Send once and preserve the receipt

Include a unique business/message reference where the interface permits one. Send exactly once. Save UTC time, HTTP status, any returned message identifier, and a sanitized response body.

Inspect the entire response. A SOAP fault is a failed operation even if an intermediary presents an unexpected HTTP status. For asynchronous processing, HTTP acceptance means the gateway queued work; it does not prove the target business object changed.

4. Follow the message inside IFS

Open Application Messages in the development environment. Search using the returned identifier or the narrow submission time/reference. Open the message and inspect its state, routing result, message body, and error details as permitted by your role.

For a successful message, verify the expected business record using its normal IFS page. Record both the application-message reference and business key. For synchronous interfaces without a queued message, use the documented response and relevant service logs instead of assuming an Application Messages row always exists.

5. Diagnose the first failing boundary

Evidence	Action
401 before a message exists	Renew/check token and target environment
Accepted but no matching route	Compare format, routing headers, and rule conditions
Transformer error	Save sanitized input; reproduce with XSLT testing or the Java transformer fixture
Business validation error	Correct the input/key against the target API contract
Timeout with uncertain result	Search by the original reference before sending again
Duplicate business record	Stop retries; add receiver-side duplicate handling before automation

Change only one variable between trials so the evidence identifies the cause.

6. Prove retry and cleanup behavior

Submit an invalid business reference and confirm an observable rejection. Then repeat a valid message using the same reference. Your integration contract must define whether it rejects or returns the existing result; a second business result is unacceptable for a deduplicated operation.

Use supported application-message recovery actions only after confirming whether business work already completed. Do not delete queue rows or message records directly. Remove lab records through their supported business actions and retire the collection’s local token when finished.

Sources and scope

• IFS SOAP Gateway
• IFS Connect architecture

Older IFS Applications examples are historical context, not evidence of Cloud compatibility. No third-party code, screenshots, or downloadable workflows are reproduced.