B2B EDI Setup in IFS Cloud: Using IFS Connect and Projection Endpoints

IFS Cloud provides the plumbing for this in two layers: IFS Connect, the service bus that routes, transforms, and delivers messages, and IFS Cloud projection endpoints, the stable OData APIs that expose business entities for create, read, update, and delete operations. This post explains how the two work together and what a practical setup looks like for manufacturers.

Why B2B EDI Still Matters

Cloud-based EDI and integration remove the cost and fragility of manual file handling. Supplier delivery schedules, customer orders, warehouse ship notices, and invoices move automatically between IFS and the outside world. The business benefit is easy to state: fewer errors, faster order cycles, fewer chargebacks, and less time spent reconciling spreadsheets.

But the implementation is rarely trivial. Trading partners use different EDI standards and versions. Internal applications have their own data models and authentication requirements. The transformation layer has to normalize all of that into something IFS Cloud understands — and vice versa.

IFS Connect: The Service Bus Layer

IFS Connect sits between IFS Cloud and external systems. It handles inbound messages, applies routing rules, transforms payloads, and manages outbound delivery. In a typical setup you configure:

• Transport connectors: SFTP, file drops, REST, SOAP, or AS2/VAN depending on the partner or application.
• Envelopes: the wrapper that identifies sender, receiver, message type, and version.
• Routing addresses and rules: where messages come from and where they should go.
• Transformers: the logic that converts an external payload into IFS XML or an IFS event into the partner's expected format.
• Message queues: buffers that help manage asynchronous flows and retries.

For example, an inbound customer purchase order might arrive as an X12 850 or an EDIFACT ORDERS message. IFS Connect receives the file, unwraps the envelope, transforms the content into the IFS XML interface format, and routes it to IFS Cloud for customer-order creation.

Projection Endpoints: The API Layer

IFS Cloud exposes thousands of OData v4 projections as REST APIs. Not all projections are integration-safe: the standard Aurena UI projections can change between releases, while Premium/Integration projections and Entity Service APIs are intended for stable, version-tolerant integrations.

Projection endpoints are used directly when the integration target speaks REST — for instance, pushing a shipment status to a customer portal, reading employee records from Workday, or updating a ServiceNow ticket. Authentication runs through IFS Identity and Access Manager using OAuth 2.0 Client Credentials for server-to-server flows.

The key design decision is selecting the right projection for each operation. A read-heavy integration may use a different projection than one that posts records, and some projections are read-only or lack certain entity sets. This is where the IFS Cloud API Explorer becomes a critical planning tool.

Three Real-World Patterns

Implementation Steps

A first integration typically follows this sequence:

• Requirements: document the message or API set, fields, frequencies, and success criteria.
• Projection selection: identify stable IFS Cloud endpoints or XML interface files that match the target entities.
• IFS Connect setup: configure connectors, envelopes, routing addresses, and transformers.
• Authentication: set up IFS IAM clients, OAuth flows, and any external credentials.
• Mapping and validation: define field mappings, lookups, defaults, and error rules.
• Testing: run sample payloads through the full pipeline, including failure paths and retries.
• Cutover and documentation: deploy with monitoring, then hand over a runbook the internal team can support.

Common Pitfalls

• Building against UI projections: standard Aurena projections can change between releases and break integrations.
• Ignoring error routing: without clear error queues and alerts, failures sit silently until operations notices missing data.
• No duplicate prevention: reprocessing the same inbound order can create duplicate customer orders or receipts.
• Underestimating partner testing: trading partner EDI requires concurrent testing across document types before go-live.
• Missing transaction boundaries: updating related IFS entities out of sequence can leave records in invalid states.

Bottom Line

B2B EDI and application integration in IFS Cloud is not a black art. It is a combination of IFS Connect for message routing and transformation, projection endpoints for stable API access, and disciplined mapping, validation, and error handling. With the right design, IFS Cloud can reliably ingest and send data to the trading partners and business applications a manufacturer depends on.

If you are planning an EDI rollout or an integration to Workday, ServiceNow, Ultipro, or another system, the most expensive decision is usually doing it twice. A fixed-scope engagement that designs the architecture up front will almost always cost less than fixing a broken pipeline in production.