Infor CloudSuite and IBM Sterling integration

What moves between them

Purchase orders and invoices created in Infor CloudSuite flow outbound through IBM Sterling. ml-connector reads new PO and invoice headers and line items from Infor CloudSuite on a polling schedule, maps them to EDI 850 (PO) and 810 (invoice) format, and writes them into IBM Sterling mailbox messages for routing to suppliers or customers. Inbound EDI 997 functional acknowledgments from trading partners are polled from IBM Sterling mailbox, decoded, and written back into Infor CloudSuite as payment or receipt records. Inbound 856 advance shipping notices (ASNs) are similarly polled from IBM Sterling, mapped to receipt lines, and posted into Infor CloudSuite inventory and AP receiving modules.

How ml-connector handles it

ml-connector stores both Infor CloudSuite OAuth credentials and IBM Sterling Basic Auth credentials encrypted and refreshes the ION API token before expiry (configured per tenant, typically 4-12 hours). On the Infor side, ml-connector constructs the instance-specific base URL from the stored .ionapi file contents, queries the transaction lists (APS100MI for invoices, PPS200MI for POs) filtered by modified date and status, and extracts line-level GL accounts and cost allocations where applicable. On the IBM Sterling side, ml-connector connects to the customer-provided host and port, polls GET /B2BAPIs/svc/mailboxMessages/ for new message IDs, extracts EDI payloads via GET /B2BAPIs/svc/mailboxMessages/{id}/extract, and decodes the X12 or EDIFACT content. EDI encoding (translation from Infor fields to 850/810/856 segments) follows the customer's trading partner agreement and configuration stored in IBM Sterling (segment order, mandatory vs optional fields, reference number mapping). Polling intervals are configured per document type and trading partner agreement. Rate limiting from Infor (typically 100-500 requests per minute) is respected with exponential backoff, and every record carries an audit trail with timestamp, source system message ID, EDI control number, and status. PO acknowledgments (997) that fail to decode are held in a failed-records queue for manual review.

A real-world example

A mid-sized distributor runs Infor M3 for procurement and inventory, and manages supplier relationships through IBM Sterling B2B Integrator for EDI delivery. Before the integration, when the procurement team created a purchase order in M3, the finance team had to download it as an EDI-formatted export, manually validate it against supplier requirements stored in Sterling, upload it to Sterling via the web UI, and monitor Sterling's outbound queue to confirm delivery. Inbound 856 ASNs from suppliers arrived in Sterling, but the receiving team re-entered ASN data into M3 by hand to match their internal receipt process, creating a time lag and frequent data mismatches during month-end. With Infor CloudSuite and IBM Sterling connected through ml-connector, each new PO in M3 is automatically encoded as an EDI 850, routed through Sterling to the correct supplier based on the supplier's EDI agreement, and marked delivered when Sterling confirms the 997. Inbound ASNs are automatically decoded and posted into M3 receiving, so goods are matched to PO lines and inventory is updated the same day the ASN arrives.

What you can do

• •Encode purchase orders and invoices from Infor CloudSuite as EDI 850 and 810 messages and route them through IBM Sterling to suppliers and customers.
• •Decode inbound EDI 997 acknowledgments, 856 advance shipping notices, and other documents from trading partners out of IBM Sterling and post them into Infor CloudSuite as receipt, payment, or adjustment records.
• •Map Infor CloudSuite supplier accounts, item numbers, and GL dimensions to trading partner agreements and EDI segment standards configured in IBM Sterling.
• •Authenticate Infor CloudSuite via OAuth 2.0 service account credentials and IBM Sterling via Basic Auth or OAuth 2.0, managing credentials and token refresh encrypted at rest.
• •Poll both systems on a schedule tied to your procurement and order-to-cash cadence, with exponential backoff on rate limits and a full audit trail on every EDI document and trading partner interchange.

Questions

How does ml-connector handle the different authentication and base URL requirements between Infor CloudSuite and IBM Sterling?

Infor CloudSuite credentials are extracted from the stored .ionapi file (which contains the customer-specific base URL, OAuth endpoints, and tenant ID). ml-connector constructs the full ION API base URL and manages OAuth 2.0 service account token refresh, typically valid 4-12 hours per customer configuration. IBM Sterling credentials are stored as Basic Auth (username and password) or OAuth 2.0 Client Credentials pointing to the customer's own B2Bi instance host and port. Both credential sets are encrypted at rest.

What EDI standards does ml-connector support between Infor CloudSuite and IBM Sterling?

ml-connector translates Infor CloudSuite purchase orders and invoices to EDI 850 and 810 format (ANSI X12 or EDIFACT depending on trading partner agreement). Inbound documents (997 acknowledgments, 856 ASNs, invoices) are decoded from whichever EDI standard the trading partner uses, as configured in IBM Sterling. The actual segment mapping and field-level validation rules are stored in IBM Sterling's trading partner profiles, so ml-connector respects your existing Sterling configuration.

How does ml-connector detect new documents without webhooks in either system?

Both Infor CloudSuite and IBM Sterling lack outbound webhooks, so ml-connector polls both systems on a regular schedule (typically every 5-15 minutes for order documents, tunable per customer cadence). On the Infor side, it filters transaction lists by modified date and status. On the IBM Sterling side, it polls the mailbox messages endpoint for new message IDs. Exponential backoff is applied if either system returns rate-limit (429) responses, and all poll timestamps are logged for audit purposes.