Infor Enterprise Connector: A Technical Deep-Dive for Integration Engineers Working in Live Infor Environments

When you inherit or architect an Infor environment that spans CloudSuite Financials, Infor LN, M3, and WMS alongside external third-party platforms, the question of which integration mechanism to reach for is never academic. Each product line carries its own deployment topology, versioning cadence, and transport behaviour, and solving cross-system messaging with point-to-point API calls or flat-file exchanges accumulates technical debt faster than almost any other architectural decision. The Infor Enterprise Connector exists because that scenario is the rule, not the exception, in enterprise deployments.

What makes the Enterprise Connector distinct is not that it provides connectivity – everything in the Infor OS ecosystem provides some form of connectivity. What distinguishes it is where it sits in the hybrid topology: it is the bridge between ION Cloud Edition and locally deployed applications that have no direct network path to the cloud, operating over an asynchronous message bus governed by business object document semantics. Understanding this at the architecture level is the prerequisite for everything that follows in configuration, error handling, and platform selection decisions.

What the Infor Enterprise Connector Actually Does at the Architecture Level

The Infor Enterprise Connector is a hybrid service that runs on-premises or in a customer-managed network segment and serves as the bridge between ION Cloud Edition and locally deployed applications. Communication between the Enterprise Connector and ION CE is asynchronous, and a single Enterprise Connector instance can serve multiple on-premises applications simultaneously. This matters immediately for latency expectations: if your integration pattern requires sub-second response times, the Enterprise Connector is not the layer to build that pattern on.

Within the Infor OS multi-tenant cloud architecture, the Enterprise Connector is registered to an Enterprise Location in ION CE. All connection points referencing locally deployed applications must be associated with that Location before they can be activated. The connector relays BOD messages between the ION message bus and application connection points bound to its Location – ION itself handles document flow logic, filtering, transformation, and routing rules. The Enterprise Connector handles physical delivery to and from applications that cannot reach the ION cloud endpoint directly.

This is architecturally different from the ION API Gateway, which handles synchronous REST-based call patterns against APIs registered in the Gateway and does not operate on the BOD messaging bus in the same way. The transport types the Enterprise Connector supports cover the range of patterns common in on-premises and hybrid estates: IMS (ION Messaging Service, HTTPS REST-based), file transport via FTP, SFTP, and Windows shared folders, database integration via JDBC, message queue integration via JMS, and a native Infor LN/Baan connection type using LN-specific connection parameters including hostname, BSE environment, username, and Bshell. Each transport type maps to a specific connection point type in ION Connect and determines the configuration fields, credential model, and delivery semantics available for that connection point.

BOD Structure, Message Envelopes, and Schema Validation Inside Enterprise Connector Pipelines

Infor ION messages are Business Object Documents based on the OAGi standard. A BOD is an XML document composed of a verb component and a noun component – SyncPayableTransaction, ProcessLocation, and ProcessSupplierPartyMaster are representative production examples. Every BOD carries three structural areas: the ApplicationArea, which holds infrastructure metadata including sender logical ID, receiver logical ID, and message creation timestamp; the DataArea, which contains the verb definition and the noun payload; and optionally the UserArea for non-standard extension data. A single BOD can contain multiple instances of the same noun, but it cannot carry multiple noun types within a single message envelope.

Schema validation is enforced against the document registry in ION. When a BOD fails validation, the message enters the error state in the ION message log with a document-specific configuration error classification. This is important because document-specific errors do not trigger automatic retry. Engineers need to distinguish this from connection errors (HTTP 401, 500, 503, and 504), which do trigger automatic retry behaviour. Schema mismatch failures require manual intervention – either correcting the publishing application’s output or updating the document schema registration in ION.

The logical ID is the addressing mechanism that routes a BOD to the correct connection point. Logical IDs follow the pattern lid://infor.[type].[name] – for an IMS connection point named cp_myapp, the logical ID is lid://infor.ims.cp_myapp, as documented in the IMS configuration guide. The ApplicationArea of a BOD carries both sender and receiver logical IDs, and ION routing resolves delivery against these identifiers and the active document flows. At the plant-floor layer, where EAM and SCADA integration surfaces OT data into Infor document flows, namespace conflicts between industrial protocols and the Infor OAGIS namespace (http://schema.infor.com/InforOAGIS/2) are a reliable source of BOD validation failures that must be caught during flow testing, not in production.

Authentication, Security Configuration, and Credential Management

OAuth 2.0 is the authentication mechanism for ION API access in Infor OS. The standard authorized application configuration sets an OAuth 2.0 access token lifetime of two hours, with refresh token issuance enabled and a refresh token grant lifetime of zero, meaning the refresh token does not expire. Service account credentials are generated as a downloadable credentials file containing the client ID, client secret, token endpoint URL, and logical ID. This file is what the connecting service presents at runtime.

When OAuth 2.0 scope enforcement is enabled in the API Gateway configuration, each authorized application must explicitly declare its required scopes. A common silent failure pattern: a service account authenticates and receives a token, but API calls fail because the token scope does not cover the target resource. This occurs when scope enforcement is enabled but scope assignments are not configured on the authorized application. The correct approach is to verify scope assignments at Configuration > OAuth 2.0 in the API Gateway before testing any document flows.

Service account configuration in Infor OS IDP requires that the service account’s description property is populated. This is noted as a configuration requirement in the ION API connection point documentation and produces runtime errors that are not immediately obvious from the ION message log output. Role-based access at the connection point level requires that noun-verb combinations are explicitly listed in the Documents tab of each connection point. A connection point with empty document configuration will not route BODs even with an active document flow.

Credential rotation in live pipelines demands proactive alerting. Because the OAuth access token has a two-hour lifetime, a pipeline that is active at rotation time will continue processing until the current token expires, then fail on refresh. Alerting on HTTP 401 authentication errors at the connection layer – rather than waiting for downstream data issues to surface – is the correct way to detect this before message backlog accumulates. Handling that operational monitoring as a managed responsibility is discussed in the context of ongoing integration operations.

Configuring Connection Points and Document Flows in ION Connect

A connection point in ION Connect defines how ION interacts with a specific application instance. The governing fields are the logical ID, the connection type (which determines available configuration tabs and transport semantics), the Enterprise Location binding, and the endpoint definition. The Documents tab must explicitly list the noun-verb combinations the connection point is authorised to handle – without this configuration, no BODs of those types will be routed regardless of what the document flow specifies.

Document flows are directed routing configurations: source connection point, target connection point, and one or more document types. Activating a document flow makes it immediately effective in ION. Multiple flows can use the same source and target connection points with different document types or filter conditions. When multiple active flows route the same document type over the same route, ION combines them using logical OR – a looser filter on a second active flow can bypass restrictions on the first, which is a non-obvious interaction that engineers need to audit during troubleshooting.

Filtering in document flows operates at the message level. Either the entire BOD is delivered or nothing is delivered – there is no partial delivery. When a BOD contains a repeating element such as order lines, the document passes the filter if at least one repeating element matches the condition. Filtering is not applied to BODs used in Event Management.

Transformation steps handle cases where source and target systems use different BOD versions or field mappings. In-process transformation is performed within the ION service using mapping logic defined in the document flow. Out-of-process transformation delegates to an external mapping service and is appropriate when transformation logic exceeds the capability of the built-in mapping editor. The choice affects both performance and maintainability – in-process transformations are visible and versioned within ION Connect, while out-of-process transformations introduce an external dependency requiring independent monitoring. Finance module BOD routing – for example, SyncPayableTransaction flows between CloudSuite Financials and third-party payables platforms – follows the same connection point and flow structure; the technical implementation detail for M3 finance data flows covers specific configuration patterns at the module level.

Error Handling, Retry Logic, and Dead-Letter Behaviour

The Enterprise Connector’s error classification governs which messages retry automatically and which require manual intervention. HTTP 401, 500, 503, and 504 are classified as connection errors and trigger automatic retry with progressive backoff when retries continue to fail. All other non-2xx status codes are classified as document-specific configuration errors and move immediately to the error state in the ION message log without retry.

Failed messages are preserved in the ION message log with their full metadata record: sender and receiver logical IDs, document type, timestamp, and the error code that caused the failure. Engineers can query the log by direction, status, message ID, logical ID, and creation date. The message log is the primary diagnostic tool for failed BOD tracing, and its retention period is governed by Infor OS tenant configuration – operational teams should verify retention settings match audit and recovery requirements at deployment time.

Idempotency is not enforced automatically by ION on retry. When a message is retried after transient delivery failure, the target application may have already processed the original attempt. Implementing idempotency requires that the receiving application checks the DocumentID element in the BOD DataArea before applying the payload. For SalesOrder, PurchaseOrder, and CustomerReturn nouns, the DocumentID corresponds to the order number, providing a natural idempotency key. For custom BODs, the idempotency key must be defined explicitly in application-side receiving logic.

Error accumulation in long-running connector pipelines is a predictable pattern in environments without active alert routing – we examine this in the context of common ERP integration failure modes. Structured support and troubleshooting coverage for dead-letter resolution, including the workflow for reviewing failed messages and resubmitting BODs after configuration correction, is an operational requirement for any production Enterprise Connector deployment.

Performance Considerations and Throughput Limits

Enterprise Connector throughput is a function of the Infor OS infrastructure tier, the message size of the BODs being processed, and the number of active connection points per Enterprise Connector instance. ION does not publish a universal message-per-second throughput limit independent of deployment configuration, and performance characteristics in a given environment must be validated against the specific topology.

For IMS-based application connection points, messages are processed individually through the REST interface rather than as native batch payloads. For database connection points using JDBC, bulk retrieval from outbox tables can produce multiple BODs in a single polling cycle, but each BOD is still processed as a discrete message through the ION routing layer. For WMS or MES environments generating high-frequency transactional events, the polling interval configuration on the Enterprise Connector connection point directly affects how quickly message bursts are absorbed into the ION pipeline.

In scaled-out Enterprise Connector deployments, ION CE supports multiple hosts registered to the same Enterprise Location. The upgrade procedure for Enterprise Connector 2024.10 and later releases – which requires JDK 17 – coordinates version consistency across hosts via the installer. In environments scaling connector pipelines across multiple business units or Infor tenants, the design principles for modular, scalable integration architecture apply directly: flat connection point namespaces without naming conventions and document flow configurations that span business unit boundaries become operationally unmanageable as pipeline count grows.

Enterprise Connector vs ION API Gateway vs Infor OS REST API: Choosing the Right Integration Mechanism

The decision between these mechanisms is architectural. The Enterprise Connector is the correct choice for asynchronous BOD-based exchange: when a source system publishes state changes as BODs to be consumed by one or more targets, when multi-hop routing through ION document flows is required, and when the connecting application is locally deployed. ERP-to-ERP integration between CloudSuite and Infor LN, WMS-to-ERP synchronisation using standard BOD nouns, and event-driven workflows where an Infor application publishes a SyncSalesOrder or ProcessShipment BOD are canonical Enterprise Connector scenarios. The documented constraint that rules the connector out for certain patterns is latency sensitivity: asynchronous delivery subject to queue depth and polling intervals cannot guarantee near-real-time response confirmation.

The ION API Gateway is the correct choice when the calling system needs a synchronous request-response pattern against Infor data – external portals querying current stock levels, customer-facing applications verifying order status in real time, or non-Infor systems pushing data into Infor through a REST interface registered in the Gateway. The Gateway handles APIs registered with Swagger 2.0 or OpenAPI 3 documentation and applies OAuth 2.0 token authentication to API consumers through the same IDP infrastructure.

Infor OS REST APIs should be used directly when a developer-facing integration requires fine-grained CRUD operations against Infor OS object services that are not modelled as BODs. This is not a replacement for BOD-based integration in ERP scenarios; it is the correct layer for platform-level operations that do not correspond to the business event semantics BODs carry.

The practical decision matrix reduces to three questions: Is the pattern event-driven or request-driven? Does the target application support BOD semantics, or only a REST interface? Does the integration require on-premises connectivity through an Enterprise Location? For architecture decisions across a complex Infor landscape, working through mechanism selection before configuration begins – through integration consulting – avoids the cost of refactoring a live document flow topology. Our Infor integration implementation practice operationalises these decisions across active CloudSuite, LN, and M3 environments.

Common Configuration Mistakes and How They Manifest in Production

Incorrect logical ID assignment is the most common cause of BODs that publish successfully but never arrive at the target. The failure is silent from the source system: the BOD is published to ION without error, the document flow is activated, but the receiver never processes it. The ION message log will show the outbound BOD with a receiver logical ID that does not match any active connection point. The correct approach is to verify the logical ID in the ION Connect configuration and ensure it is used consistently in every system that routes to that connection point.

OAuth token scope misconfiguration produces silent authentication failures where the connector authenticates and receives a token, but subsequent API calls fail with access denied responses. This occurs when OAuth 2.0 scope enforcement is enabled in the API Gateway but the authorized application configuration does not declare the required scopes. Enabling scope enforcement and explicitly assigning required scopes before downloading credentials is the correct sequence.

Missing document configuration in a connection point produces a connection point that appears active in ION Connect but processes no BODs. The Documents tab must explicitly list noun-verb combinations the connection point is authorised to handle. This gap is not surfaced as an error during flow activation – the flow activates successfully and the absence of delivery is the only symptom.

Filter logic errors causing BODs to be silently dropped do not produce error entries in the ION message log, making them particularly difficult to diagnose. When a filter condition references an XPath that does not exist in the BOD structure, or uses a comparison value that never evaluates to true, the filter returns no matches and no delivery occurs. The correct diagnostic approach is to temporarily remove the filter condition, verify that BODs begin arriving at the target, and then re-examine the condition logic against actual BOD content from the message log.

Transformation mapping errors that pass schema validation but produce semantically incorrect data in the target system are the hardest category to catch. The BOD passes schema validation, the connection point delivers it without error, and the receiving application processes it – but business data is wrong. Field values are mapped to incorrect elements, identifiers carry values from a different data entity, or units of measure are transposed. This failure mode is most common when document flows are migrated between Infor product versions and transformation mappings are not updated for changed element paths. Testing with representative production BOD payloads – not only schema-valid synthetic documents – is the correct mitigation, and requires that environments for custom connector development and flow migration include production-representative data validation as a gate.

Deploying or reconfiguring the Infor Enterprise Connector in a production environment demands clarity on three architectural commitments before any configuration work begins: the transport model the connecting applications actually support, the authentication model the Infor OS IDP tenant is configured to enforce, and the document flow topology that will govern routing across the connection point estate. Each of these creates constraints that are difficult to change post-activation without affecting live pipelines, and misconfiguration costs – measured in failed message accumulation, data inconsistency, and diagnostic time – are disproportionately high relative to the investment required to validate the configuration before go-live.

The technical depth required to operate Enterprise Connector pipelines reliably at scale is not trivial. Schema versioning across divergent Infor product release timelines, credential rotation without message delivery interruption, and filter logic maintenance as business rules evolve are ongoing engineering responsibilities, not one-time setup tasks. Teams that inherit existing connector estates without complete documentation of logical ID assignments, document flow filter conditions, and service account scope configurations face the kind of diagnostic burden that makes sustained operational continuity a genuine risk rather than a theoretical concern.

If you are working through an Enterprise Connector architecture decision, a deployment problem in a live environment, or a platform selection evaluation across your Infor estate, reach out to discuss how we approach these problems in production.