IFS Cloud 26R1: Automatically Send Customer Orders on Release — IFS Connect EDI to SFTP and HTTP

When a customer order gets released in IFS Cloud, your business partner often needs to know immediately — a 3PL staging a shipment, a contract manufacturer reserving capacity, a distributor updating promise dates. This tutorial walks through the complete, step-by-step setup of an outbound EDI flow in IFS Cloud 26R1: the moment a customer order is released, IFS Connect builds an XML message and delivers it to two destinations at once — the partner's SFTP drop folder and their HTTP API endpoint.

No middleware. No third-party EDI VAN. Just IFS Cloud doing what IFS Connect was built to do.

The Scenario

NorthFab Manufacturing (our example company) ships finished goods through a logistics partner, BlueBridge 3PL. The agreement: every time NorthFab releases a customer order in IFS Cloud, BlueBridge must receive the order data within seconds, in two places:

1. SFTP — an XML file dropped into /inbound/orders on BlueBridge's SFTP server (their warehouse system polls this folder).
2. HTTP — the same order posted to BlueBridge's REST API at https://api.bluebridge.example/edi/orders (their customer portal reads this).

One message, two destinations, zero manual steps. Here's the architecture:

The key IFS Connect concept that makes the dual delivery possible: a routing rule can carry multiple addresses in the same chain link — every address in that link receives a copy of the message. Different chain links would chain output-to-input; the same link means fan-out. We'll use one chain link with two addresses.

Before You Start

You'll need:

• IFS Cloud 26R1 with administrator access to Solution Manager → Integration → IFS Connect (the IFS Connect admin pages and permission sets in your environment).
• BlueBridge's SFTP details: host, port (default 22), username, password or private key, and the server's host key for the known-hosts file.
• BlueBridge's HTTP details: endpoint URL and credentials (we'll use OAuth2 Client Credentials — Basic and Bearer token are also supported).
• A test customer order you can release in a non-production environment.
• Roughly 60–90 minutes the first time through. Half that the second time.

Naming conventions used in this tutorial (adjust to your standards):

Step 1 — Configure the SFTP Transport Connector

The transport connector instance holds the connection-level settings. The routing address (Step 3) holds the destination-level settings.

1. Open Solution Manager → Integration → IFS Connect → Setup IFS Connect → Configure Transport Connectors.
2. Create a new SFTP Sender instance named SFTP_BLUEBRIDGE.
3. Set the parameters:

Step 2 — Configure the HTTP Transport Connector

1. Same page: Setup IFS Connect → Configure Transport Connectors.
2. Create a new HTTP Sender instance named HTTP_BLUEBRIDGE.
3. Parameters:

Everything else for HTTP — URL, authentication, headers — lives on the routing address, which is next.

Step 3 — Create the Two Routing Addresses

Go to Solution Manager → Integration → IFS Connect → Routing Addresses.

Address 1: BLUEBRIDGE_SFTP_ADDR (type: Sftp)

The output filename supports placeholders — %TIMESTAMP% gives you yyyyMMdd_HHmmss_z, and you can also use %GUID%, %SEQ_NO%, %MESSAGE_FUNCTION%, %SENDER%, %RECEIVER%, %DATE_ID%, or %TAG=<attribute> to pull values from the message itself. Timestamped, unique filenames mean no accidental overwrites and an audit trail for free.

Address 2: BLUEBRIDGE_HTTP_ADDR (type: Http)

Two transformer notes for the HTTP side:

• If BlueBridge's API speaks JSON (most do), attach the framework transformer IFS_XML_TO_JSON on this address. Your PL/SQL stays pure XML; the address converts on the way out. Remember the header then becomes Content-Type=application/json.
• For HTTPS against a partner with a private CA or self-signed cert, you can upload the certificate chain directly on the routing address — it must include the full chain (root + intermediates). For mutual TLS, import your client certificate into Solution Manager → Keystores and reference it with the special header parameter ssl:KeyStoreId. That's the only ssl: parameter I'd call production-safe; keep keystore passwords out of cleartext header parameters.

Step 4 — Create the Routing Rule (the Fan-Out)

1. Open Solution Manager → Integration → IFS Connect → Routing Rules and select the Outbound tab.
2. Create the rule:

Add a content-based condition:

MESSAGE_FUNCTION = CUSTOMER_ORDER_EDI

The routing engine matches conditions against the message header attributes (MESSAGE_TYPE, MESSAGE_FUNCTION, SENDER, RECEIVER). Add RECEIVER = BLUEBRIDGE_3PL as a second condition if you reuse the same message function for multiple partners.

Add both addresses to the rule — in the same chain link. Set Chain Link No = 1 for both BLUEBRIDGE_SFTP_ADDR and BLUEBRIDGE_HTTP_ADDR, and mark one (say SFTP) as the main address. Same chain link = every address gets a copy. That single detail is the entire trick to dual delivery.

Step 5 — Fire the Message When the Order Is Released

Now the trigger. We use a Custom Event on the CustomerOrder logical unit that fires when the order transitions into state Released.

1. Open Solution Manager → Configuration → Custom Events (page naming varies slightly by release — search "Custom Events" in the navigator).
2. Create event CUSTOMER_ORDER_EDI_SEND on LU CustomerOrder, fired after successful update, with the condition that the new state is Released.
3. Add an Event Action of type Execute Online PL/SQL:

--------------------------------------------------------------------------------
-- CUSTOMER_ORDER_EDI_SEND - Event Action (Execute Online PL/SQL)
-- Fires when a customer order transitions into state 'Released'.
-- Builds the EDI XML payload and posts an outbound application message
-- for IFS Connect to route.
--------------------------------------------------------------------------------
DECLARE
   xml_ CLOB;
BEGIN
   -- Guard: only on the transition INTO Released, never on later updates
   IF '&NEW:OBJSTATE' = 'Released'
      AND NVL('&OLD:OBJSTATE','-') != 'Released' THEN

      -- Order header
      xml_ := '<?xml version="1.0" encoding="UTF-8"?>' ||
              '<CUSTOMER_ORDER_EDI>' ||
              '<HEADER>' ||
              '<ORDER_NO>'       || '&NEW:ORDER_NO'                    || '</ORDER_NO>' ||
              '<CUSTOMER_NO>'    || '&NEW:CUSTOMER_NO'                 || '</CUSTOMER_NO>' ||
              '<CONTRACT>'       || '&NEW:CONTRACT'                    || '</CONTRACT>' ||
              '<DATE_ENTERED>'   || SUBSTR('&NEW:DATE_ENTERED', 1, 10) || '</DATE_ENTERED>' ||
              '<CURRENCY_CODE>'  || '&NEW:CURRENCY_CODE'               || '</CURRENCY_CODE>' ||
              '</HEADER><LINES>';

      -- Order lines
      FOR line_rec IN (
         SELECT line_no, catalog_no, buy_qty_due, price
           FROM customer_order_line
          WHERE order_no = '&NEW:ORDER_NO'
          ORDER BY line_no)
      LOOP
         xml_ := xml_ ||
                 '<LINE>' ||
                 '<LINE_NO>'      || line_rec.line_no     || '</LINE_NO>' ||
                 '<CATALOG_NO>'   || line_rec.catalog_no  || '</CATALOG_NO>' ||
                 '<BUY_QTY_DUE>'  || line_rec.buy_qty_due || '</BUY_QTY_DUE>' ||
                 '<PRICE>'        || line_rec.price       || '</PRICE>' ||
                 '</LINE>';
      END LOOP;

      xml_ := xml_ || '</LINES></CUSTOMER_ORDER_EDI>';

      -- Hand the message to IFS Connect. The three header attributes are
      -- what the routing rule matches on. Exact package/signature is
      -- documented under the PL/SQL Access Provider in the IFS Connect
      -- technical docs for your build - verify against your environment.
      PLSQLAP_Server_API.Post_Outbound_Message(
         message_function_ => 'CUSTOMER_ORDER_EDI',
         sender_           => 'IFS_CLOUD',
         receiver_         => 'BLUEBRIDGE_3PL',
         message_          => xml_ );
   END IF;
END;
/

Three things worth understanding about this code:

• The old-state guard is not optional. Without it, every update to a released order (a date change, a note added) fires another EDI message. You want exactly one message per release.
• Keep the event action fast. It runs inside the order-release transaction. Building XML for a few hundred lines is fine; calling external systems is not — that's the queue's job.
• The message function, sender and receiver are the contract. They must match the routing rule's conditions exactly, character for character. MESSAGE_TYPE defaults to CONNECT.

Prefer workflows over events? Some teams fire the same post from a BPA workflow on the order instead of a custom event. The IFS Connect half of this tutorial is identical either way — only the trigger changes.

What about classic Connectivity? IFS also ships the traditional EDI subsystem under Solution Manager → Integration → Connectivity (message classes, receivers, inbox/outbox) with standard classes for order responses, despatch advices and invoices. If your partner landscape is heavily EDIFACT/X12, that route is worth evaluating. For a point-to-point "send my order data here" requirement, the custom event + IFS Connect route above is simpler to build, simpler to monitor, and easier to hand over.

Step 6 — Test End to End

1. Point the HTTP address at a request bin first. Before involving BlueBridge, set the HTTP address URL to a temporary endpoint from a request-capture service (webhook.site or similar). You'll see the exact payload, headers and auth flow without waiting on anyone.
2. Create and release a test customer order in your test environment.
3. Open Solution Manager → Integration → IFS Connect → Application Messages. You should see one new message for your rule. With the queue processed, it moves through its lifecycle to a finished state.
4. Verify the SFTP side: the file CUSTORD_CUSTOMER_ORDER_EDI_<timestamp>.xml exists in /inbound/orders on the partner server, with complete content (no .part suffix).
5. Verify the HTTP side: the request bin shows one POST with the right body, Content-Type, and a 200-class response recorded as HTTP_RESPONSE_CODE on the message.
6. Negative test: disable the rule and release another order. The message should land in the UNROUTED system queue — confirming your conditions are what catches messages, not luck. Re-enable the rule and reprocess.

A finished message with both deliveries confirmed means you're done building. Now make it survivable.

Monitoring and Troubleshooting

Your home base is the Application Messages page (with Application Message Statistics and the Archive alongside it). Failed messages can be inspected — the error text from the connector is attached — and reprocessed after you fix the cause.

Production Checklist

Before you call this done:

• Async everywhere — the rule runs on a queue, and a monitored Batch Processor job drains it.
• Alerting — subscribe someone (an integration mailbox, not a person) to failed application messages. EDI that fails silently is worse than no EDI.
• Key-based SFTP auth — identity file over password, with a rotation calendar entry.
• Credentials in the right place — OAuth secrets on the address, certificates in Keystores, nothing hardcoded in PL/SQL.
• Volume test — release a few hundred orders in one go. Order-entry day-end bursts are real; make sure the queue drains faster than it fills.
• Idempotency agreement — networks retry. Tell BlueBridge duplicates are possible and the order number is the natural key.
• Archive policy — keep the Application Message Archive long enough to answer "did we send order X?" six months later.

Conclusion

In about an hour of configuration plus one small event action, IFS Cloud 26R1 turns "someone emails the 3PL a spreadsheet" into a monitored, retryable, two-channel EDI flow: order released → XML built → routed → filed on SFTP and posted to the API, with a full audit trail in Application Messages. That's the kind of integration that survives contact with production — because it's boring, observable, and owned by configuration rather than code.