---
# === IDENTITY ===
id: business/erp-integration/infor-ion-messaging/2026
canonical_question: "How does ION Messaging work for async event-driven integration using BODs?"
aliases:
  - "What are Infor ION Business Object Documents and how do they work?"
  - "How to configure ION Connect document flows for BOD messaging"
  - "Infor ION publish-subscribe messaging architecture explained"
  - "How to set up async event-driven integration with Infor ION BODs"
entity_type: erp_integration
domain: business > erp-integration > infor-ion-messaging
region: global
jurisdiction: global
temporal_scope: 2024-2026

# === SYSTEM PROFILE ===
systems:
  - name: "Infor OS / ION"
    vendor: "Infor"
    version: "2024.x"
    edition: "Essentials, Professional, Enterprise"
    deployment: "cloud"
    api_surface: "ION Messaging (BOD/XML), ION API Gateway (REST)"

# === VERIFICATION ===
last_verified: 2026-03-02
confidence: 0.82
version: 1.0
first_published: 2026-03-02

# === TEMPORAL VALIDITY ===
temporal_validity:
  status: evolving
  last_breaking_change: "2024.x — Kafka connection points added"
  next_review: 2026-08-29
  change_sensitivity: high

# === CONSTRAINTS ===
constraints:
  - "Message size: 5 MB (Essentials/1-3,499 units), 20 MB (Professional/3,500-34,999), 50 MB (Enterprise/35,000+) per tenant"
  - "ION API Gateway: no payload limit for streaming, 10 MB for buffered policies"
  - "ION API Gateway timeout: default 1 min, max 5 min for synchronous; up to 2 hours for async requests"
  - "LN/Baan connection points: max 10 bshells per channel"
  - "Processing capacity: 350 units (Essentials), 3,500 (Professional), 35,000 (Enterprise) — add-ons in multiples of 350"
  - "OneView history retention: 45-180 days (complete records), 180-360 days (in-flight records) depending on tier"
  - "Document flows with intermediate steps: recommended max payload 5 MB regardless of tier"

# === SKIP CONDITIONS ===
skip_this_unit_if:
  - condition: "User needs Infor ION REST API Gateway details, not BOD messaging"
    use_instead: "business/erp-integration/infor-ion-api-gateway/2026"
  - condition: "User needs Infor ION Workflow automation, not messaging"
    use_instead: "business/erp-integration/infor-ion-workflow/2026"
  - condition: "User needs SAP IDoc or ALE messaging"
    use_instead: "business/erp-integration/sap-idoc-ale/2026"

# === AGENT HINTS ===
inputs_needed:
  - key: integration_pattern
    question: "What integration pattern do you need?"
    type: choice
    options:
      - "real-time sync (individual records, <1s latency)"
      - "batch/bulk (scheduled, high volume)"
      - "event-driven (publish-subscribe BOD messaging)"
      - "file-based (CSV/XML import/export via SFTP)"
  - key: data_volume
    question: "What's your daily data volume?"
    type: choice
    options:
      - "< 1,000 records/day"
      - "1,000-100,000 records/day"
      - "> 100,000 records/day"
  - key: direction
    question: "What's the data flow direction?"
    type: choice
    options:
      - "inbound (writing to Infor CloudSuite)"
      - "outbound (reading from Infor CloudSuite)"
      - "bidirectional sync"

# === DISTRIBUTION ===
canonical_source: "https://knowledgelib.io/business/erp-integration/infor-ion-messaging/2026"
suggested_citation: "Source: knowledgelib.io — AI Knowledge Library (verified 2026-03-02)"

# === RELATED UNITS ===
related_kos:
  depends_on: []
  related_to:
    - id: "business/erp-integration/infor-ion-api-gateway/2026"
      label: "Infor ION API Gateway — REST API surface for synchronous integration"
  solves: []
  alternative_to:
    - id: "business/erp-integration/sap-idoc-ale/2026"
      label: "SAP IDoc/ALE — SAP's equivalent async messaging framework"
  often_confused_with:
    - id: "business/erp-integration/infor-ion-workflow/2026"
      label: "ION Workflow — process automation layer built on top of ION messaging"

# === SOURCES ===
sources:
  - id: src1
    title: "Infor OS Service Limits"
    author: Infor
    url: https://docs.infor.com/inforosulmt/xx/en-us/usagelimits/nkb1720800864258.html
    type: official_docs
    published: 2024-07-01
    reliability: authoritative
  - id: src2
    title: "Infor ION Technology Connectors Administration Guide — Cloud Edition"
    author: Infor
    url: https://docs.infor.com/inforos/2024.x/en-us/useradminlib_cloud/iontechconceag_cloud_osm/isc1450707133987.html
    type: official_docs
    published: 2024-01-01
    reliability: authoritative
  - id: src3
    title: "BOD Verbs — Infor Documentation Central"
    author: Infor
    url: https://docs.infor.com/depm/2022.x/en-us/depmolh/configuring_ion/mdp1510174564018.html
    type: official_docs
    published: 2022-01-01
    reliability: authoritative
  - id: src4
    title: "BOD Message Structure — Infor Documentation Central"
    author: Infor
    url: https://docs.infor.com/depm/2022.x/en-us/depmolh/configuring_ion/exl1510174563113.html
    type: official_docs
    published: 2022-01-01
    reliability: authoritative
  - id: src5
    title: "Business Object Documents — Learn Infor M3"
    author: Learn Infor M3
    url: https://learninform3.wordpress.com/2020/06/28/business-object-documents/
    type: community_resource
    published: 2020-06-28
    reliability: moderate_high
  - id: src6
    title: "Infor ION API SDK — GitHub"
    author: Infor
    url: https://github.com/infor-cloud/ion-api-sdk
    type: official_docs
    published: 2024-01-01
    reliability: high
  - id: src7
    title: "Infor ION Integration Guide — SAMA Consulting"
    author: SAMA Consulting
    url: https://samaconsultinginc.com/blogs/infor-ion-integration-guide-streamlining-enterprise-systems-for-2025/
    type: technical_blog
    published: 2024-10-01
    reliability: moderate_high
  - id: src8
    title: "ION API Gateway Timeout Limits — Infor Documentation"
    author: Infor
    url: https://docs.infor.com/inforos/2024.x/en-us/useradminlib_cloud/apigatewayag_cloud/ayc1656493867736.html
    type: official_docs
    published: 2024-01-01
    reliability: authoritative
---

# Infor ION Messaging: Async Event-Driven Integration with BODs

## TL;DR

- **Bottom line**: ION Messaging uses Business Object Documents (BODs) — standardized XML messages with verb+noun structure — in a publish-subscribe architecture via ION Connect. Sync BODs broadcast changes from the system of record; Process/Acknowledge BODs handle request-reply patterns.
- **Key limit**: Message size caps at 5 MB (Essentials), 20 MB (Professional), or 50 MB (Enterprise) per tenant; intermediate-step flows should stay under 5 MB regardless of tier. [src1]
- **Watch out for**: System of Record (SOR) designation determines message flow direction — agents often incorrectly assume the ERP is always the SOR, but business requirements determine ownership. [src5]
- **Best for**: Async event-driven integration between Infor CloudSuite applications (LN, M3, CSI) and third-party systems using standardized XML messaging with built-in routing, mapping, and monitoring.
- **Authentication**: OAuth 2.0 via ION API Gateway for external access; internal BOD messaging uses connection point credentials (JDBC Inbox/Outbox, IMS, or Enterprise Connector). [src6]

## System Profile

Infor ION (Intelligent Open Network) is the middleware integration platform embedded in Infor OS. ION Messaging is its core async communication layer, routing Business Object Documents (BODs) between applications using a publish-subscribe model. ION Connect acts as the central messaging hub where you define connection points (application endpoints) and document flows (routing rules for BODs between connection points). This card covers the BOD messaging subsystem — not the ION API Gateway REST surface, ION Workflow automation, or ION Mapper transformations, though all three depend on ION Messaging.

All Infor CloudSuite applications (LN, M3, CloudSuite Industrial, CloudSuite Distribution, etc.) ship with pre-built BOD interfaces. Third-party systems connect via Technology Connectors — File, Database, Message Queue, API Gateway, or Kafka connection points. [src2]

| Property | Value |
|---|---|
| **Vendor** | Infor |
| **System** | Infor OS / ION 2024.x |
| **API Surface** | ION Messaging (BOD/XML pub-sub), ION API Gateway (REST) |
| **Current Version** | 2024.x (Cloud Edition) |
| **Editions Covered** | Essentials (350 units), Professional (3,500 units), Enterprise (35,000 units) |
| **Deployment** | Cloud (multi-tenant), On-Premise (12.0.x) |
| **API Docs URL** | [Infor Documentation Central](https://docs.infor.com/inforos/2024.x/en-us/useradminlib_cloud/ioncedg_cloud_osm/lsm1436532221257.html) |
| **Status** | GA |

## API Surfaces & Capabilities

ION provides multiple integration surfaces. BOD messaging is the native async mechanism; the API Gateway handles synchronous REST calls. [src2, src7]

| API Surface | Protocol | Best For | Max Payload | Rate Limit | Real-time? | Bulk? |
|---|---|---|---|---|---|---|
| ION Messaging (BOD) | XML/HTTPS pub-sub | Event-driven sync between Infor apps | 5-50 MB (tier-dependent) | Throughput units (tier) | Near-real-time | No |
| ION API Gateway | REST/HTTPS | External system CRUD, real-time queries | No limit (streaming), 10 MB (buffered) | Not published | Yes | No |
| File Connection | FTP/SFTP/Windows share | Batch imports/exports, CSV/XML files | Filesystem limit | N/A | No | Yes |
| Database Connection | JDBC/SQL | Direct DB reads/writes for non-BOD apps | Query-dependent | N/A | Near-real-time | Yes |
| Message Queue | JMS | Integration with external MQ systems | JMS provider limit | N/A | Yes | No |
| Kafka Connection | Apache Kafka | High-throughput streaming integration | Kafka topic config | N/A | Yes | Yes |

## Rate Limits & Quotas

### Per-Message Limits

| Limit Type | Value | Applies To | Notes |
|---|---|---|---|
| Max message size (Essentials) | 5 MB | 1-3,499 processing units | Per tenant |
| Max message size (Professional) | 20 MB | 3,500-34,999 processing units | Per tenant |
| Max message size (Enterprise) | 50 MB | 35,000+ processing units | Per tenant |
| Intermediate-step payload | 5 MB recommended max | Document flows with mapping/enrichment | Regardless of tier |
| API Gateway payload (buffered) | 10 MB | Policies that buffer request/response | Streaming has no limit |

[src1, src8]

### Throughput / Capacity Limits

| Limit Type | Value | Window | Edition Differences |
|---|---|---|---|
| Processing capacity | 350 / 3,500 / 35,000 units | Subscription-based | Add-ons in multiples of 350 |
| Data Lake ingestion | 600 per 1 TB storage | Per customer | Shared across all tiers |
| API Gateway timeout (sync) | Default 1 min, max 5 min | Per request | Configurable per endpoint |
| API Gateway timeout (async) | Up to 2 hours | Per request | For long-running operations |
| LN/Baan bshells | Max 10 per channel | Per connection point | Exceeding causes queue backpressure |

[src1, src8]

### History Retention Limits

| Tier | Complete Records | In-Flight Records |
|---|---|---|
| Essentials (1-3,499 units) | 45 days | 180 days |
| Professional (3,500-34,999) | 90 days | 270 days |
| Enterprise (35,000+) | 180 days | 360 days |

[src1]

## Authentication

ION uses different authentication methods depending on the integration surface. [src6, src7]

| Flow | Use When | Token Lifetime | Refresh? | Notes |
|---|---|---|---|---|
| OAuth 2.0 Authorization Code | Native/desktop apps, web apps accessing ION API | Session-based | Yes | Standard 3-legged flow via Infor IFS |
| OAuth 2.0 Resource Owner Password | Server-to-server access via ION API Gateway | Session-based | Yes | Uses service account AccessKey + SecretKey |
| OAuth 2.0 SAML Bearer | Apps integrated with Infor Ming.le | Session-based | Yes | For SSO-enabled environments |
| JDBC Inbox/Outbox | BOD messaging between Infor apps | N/A (persistent connection) | N/A | Internal; uses application connection point credentials |
| IMS (ION Messaging Service) | REST/HTTPS-based BOD delivery | N/A | N/A | Enterprise Connector routes traffic |
| Enterprise Connector | On-premise to cloud bridge | Certificate-based | N/A | Requires EC agent installation on-premise |

[src2, src6]

### Authentication Gotchas

- ION API Gateway OAuth requires four credentials for backend services: ClientID, Client-Secret, Service Account AccessKey, and Service Account SecretKey — missing any one causes silent auth failure. [src6]
- Enterprise Connector certificate expiration breaks all on-premise-to-cloud BOD flows with no automatic renewal — set calendar reminders for cert rotation. [src2]
- OAuth token endpoints are tenant-specific — hardcoding URLs across environments (dev/test/prod) will break when tenants differ. [src6]

## Constraints
<!-- Agents: read this section before recommending any integration approach from this unit.
     These are hard constraints that must not be violated. -->

- **Tier-dependent message size**: Essentials tier caps at 5 MB per message — large BODs (e.g., full item master syncs) may require splitting into multiple messages. [src1]
- **Intermediate-step 5 MB recommendation**: Even on Enterprise tier, document flows with ION Mapper or enrichment steps should keep payloads under 5 MB for reliable processing. [src1]
- **LN/Baan channel limit**: Maximum 10 bshells per channel — high-volume LN integrations need multiple connection points or queue-based throttling. [src2]
- **No native replay/rewind**: Unlike Kafka, ION Messaging does not support message replay from an offset — failed messages go to Confirm BOD (error queue) for manual resubmission via ION Desk. [src3]
- **API Gateway sync timeout**: 5-minute maximum for synchronous calls — long-running integrations (data migrations, bulk imports) must use async patterns or file-based flows. [src8]
- **OneView retention**: Historical message data is purged after 45-180 days depending on tier — export audit data before retention window closes. [src1]

## Integration Pattern Decision Tree

```
START — User needs to integrate with Infor CloudSuite via ION
|-- What's the integration pattern?
|   |-- Event-driven (BOD pub-sub, near-real-time)
|   |   |-- Infor-to-Infor app?
|   |   |   |-- YES -> Application Connection Point (IOBOX/IMS), Sync BODs
|   |   |   +-- NO -> Technology Connector (File/DB/MQ/Kafka/API)
|   |   |-- Need request-reply confirmation?
|   |   |   |-- YES -> Process BOD (request) + Acknowledge BOD (response)
|   |   |   +-- NO -> Sync BOD (broadcast, fire-and-forget)
|   |   +-- Need data enrichment in transit?
|   |       |-- YES -> ION Mapper in document flow (keep payload < 5 MB)
|   |       +-- NO -> Direct connection point to connection point
|   |-- Real-time synchronous (individual records, <1s)
|   |   +-- ION API Gateway REST endpoint (max 5 min timeout)
|   |-- Batch/Bulk (scheduled, high volume)
|   |   |-- Data volume < 5 MB per batch?
|   |   |   |-- YES -> BOD messaging with scheduled trigger
|   |   |   +-- NO -> File Connection Point via SFTP
|   |   +-- Need incremental or full load?
|   |       |-- Incremental -> Sync BODs (change-driven)
|   |       +-- Full -> Get/Show BOD pair or file export
|   +-- File-based (CSV/XML)
|       +-- File Connection Point (SFTP from Cloud or Enterprise Connector)
|-- Which direction?
|   |-- Inbound (writing to Infor) -> Process BOD to system of record
|   |-- Outbound (reading from Infor) -> Subscribe to Sync BODs from SOR
|   +-- Bidirectional -> Define SOR per business object FIRST
+-- Error tolerance?
    |-- Zero-loss required -> Monitor Confirm BODs in ION Desk + alerting
    +-- Best-effort -> Sync BODs with retry on subscriber side
```

## Quick Reference

### BOD Verb Reference

| Verb | Direction | Pattern | Response Required | Use Case |
|---|---|---|---|---|
| **Sync** | SOR -> Subscribers | Publish-subscribe (broadcast) | No | Data changed in SOR — notify all subscribers |
| **Process** | Requester -> SOR | Point-to-point (request) | Yes (Acknowledge) | Request SOR to create/update a record |
| **Acknowledge** | SOR -> Requester | Point-to-point (response) | No | Accept/reject a Process request |
| **Get** | Requester -> SOR | Point-to-point (query) | Yes (Show) | Request specific records (initial load, recovery) |
| **Show** | SOR -> Requester | Point-to-point (response) | No | Return requested records to Get requester |
| **Post** | Sender -> Receiver | Point-to-point | No | Similar to Process but no Acknowledge expected |
| **Load** | Non-SOR -> SOR | Point-to-point (push) | No | Force-create document in SOR — cannot be refused |
| **Update** | Non-SOR -> SOR | Point-to-point (notify) | No | Notify SOR of event-triggered changes |
| **Confirm** | ION -> ION Desk | System-generated (error) | No | Error notification — contains original message for resubmission |

[src3, src5]

### Action Codes (within Sync and Process verbs)

| Action Code | In Sync Verb | In Process Verb |
|---|---|---|
| **Add** | Notifies that a new record was created | Requests creation of a new record |
| **Change** | N/A | Requests update to existing record |
| **Replace** | Notifies that an existing record was updated | N/A |
| **Delete** | Rarely used — cancellation preferred for audit trail | N/A |

[src3]

### Connection Point Types

| Type | Protocol | Use When | Cloud? | On-Prem? |
|---|---|---|---|---|
| Application (IOBOX) | JDBC Inbox/Outbox | Infor apps with native BOD support | Yes | Yes |
| IMS | REST/HTTPS | Infor apps using ION Messaging Service | Yes | Yes |
| LN/Baan | Bshell | Infor LN/Baan specific | Yes | Yes |
| File | FTP/SFTP/Windows share | Non-BOD apps, batch files | Yes (SFTP from Cloud) | Yes |
| Database | JDBC/SQL | Direct DB integration, non-BOD apps | Via EC | Yes |
| Message Queue | JMS | External MQ systems (IBM MQ, RabbitMQ) | Via EC | Yes |
| ION API | REST | External REST APIs | Yes | Yes |
| Kafka | Apache Kafka | High-throughput streaming | Yes | Yes |

[src2]

## Step-by-Step Integration Guide

### 1. Register application and create connection point in ION Desk

Open ION Desk and navigate to Connect > Connection Points. Create a new connection point matching your integration type. For third-party applications, a Technology Connector (File, Database, API, MQ, or Kafka) is required. For Infor applications, use the pre-built Application Connection Point. [src2]

```
ION Desk > Connect > Connection Points > + Add
  - Name: "EXT_MyApp_CP"
  - Type: Select connector type (File, Database, Message Queue, API, Kafka)
  - Configure credentials and endpoint details
  - Select BODs to send (outbox) and receive (inbox)
  - Save and activate
```

**Verify**: Connection point status shows "Active" in ION Desk with green indicator.

### 2. Define a document flow between connection points

Create a document flow that routes specific BODs from the source connection point to the target connection point. Add ION Mapper nodes if data transformation is needed between different BOD schemas or custom formats. [src2, src7]

```
ION Desk > Connect > Document Flows > + Add
  - Name: "ItemMaster_ERP_to_WMS"
  - Source: Select source connection point
  - Target: Select target connection point
  - BODs: Select specific BODs (e.g., SyncItemMaster, ProcessPurchaseOrder)
  - Optional: Add ION Mapper node for field transformation
  - Activate flow
```

**Verify**: Document flow shows active status; test with a sample BOD and confirm delivery in ION OneView.

### 3. Publish a Sync BOD from the source system

When data changes in the system of record, it publishes a Sync BOD to ION. For Infor apps, this is automatic when subscriptions exist. For custom apps, write the BOD XML to the outbox table or send via IMS/REST. [src3, src5]

```xml
<!-- Example SyncItemMaster BOD -->
<SyncItemMaster xmlns="http://schema.infor.com/InforOAGIS/2"
                releaseID="9.2"
                versionID="2.12.0">
  <ApplicationArea>
    <Sender>
      <LogicalID>lid://infor.myerp.1</LogicalID>
      <ComponentID>ERP</ComponentID>
    </Sender>
    <CreationDateTime>2026-03-02T10:00:00Z</CreationDateTime>
    <BODID>bca4f1e8-3d7a-4b2e-9c1d-abc123456789</BODID>
  </ApplicationArea>
  <DataArea>
    <Sync>
      <ActionCriteria>
        <ActionExpression actionCode="Replace"/>
      </ActionCriteria>
    </Sync>
    <ItemMaster>
      <ItemMasterHeader>
        <ItemID>
          <ID>ITEM-10042</ID>
        </ItemID>
        <Description>Widget Assembly Unit</Description>
      </ItemMasterHeader>
    </ItemMaster>
  </DataArea>
</SyncItemMaster>
```

**Verify**: Check ION OneView for the published BOD — status should show "Delivered" to all subscriber connection points.

### 4. Handle Process/Acknowledge request-reply flow

For request-reply patterns, the requesting system sends a Process BOD. The system of record processes it and returns an Acknowledge BOD indicating acceptance or rejection. The requester must handle the async pending state between request and acknowledgement. [src3, src5]

```xml
<!-- Step A: Requester sends ProcessPurchaseOrder -->
<ProcessPurchaseOrder>
  <ApplicationArea>
    <Sender>
      <LogicalID>lid://infor.procurement.1</LogicalID>
    </Sender>
    <BODID>proc-order-001</BODID>
  </ApplicationArea>
  <DataArea>
    <Process>
      <ActionCriteria>
        <ActionExpression actionCode="Add"/>
      </ActionCriteria>
    </Process>
    <PurchaseOrder>
      <!-- order details -->
    </PurchaseOrder>
  </DataArea>
</ProcessPurchaseOrder>

<!-- Step B: SOR responds with AcknowledgePurchaseOrder -->
<AcknowledgePurchaseOrder>
  <ApplicationArea>
    <Sender>
      <LogicalID>lid://infor.erp.1</LogicalID>
    </Sender>
    <BODID>ack-order-001</BODID>
  </ApplicationArea>
  <DataArea>
    <Acknowledge>
      <OriginalApplicationArea>
        <BODID>proc-order-001</BODID>
      </OriginalApplicationArea>
      <ResponseCriteria>
        <ResponseExpression actionCode="Accepted"/>
      </ResponseCriteria>
    </Acknowledge>
  </DataArea>
</AcknowledgePurchaseOrder>
```

**Verify**: Original Process BOD shows "Acknowledged" in ION OneView; Acknowledge BOD delivered to requester.

## Code Examples

### Python: Send a BOD via ION API Gateway

```python
# Input:  OAuth credentials (.ionapi file), BOD XML string
# Output: HTTP 200 on successful BOD submission

import requests
import json

# Load ION API credentials from .ionapi file
with open("myapp.ionapi", "r") as f:
    creds = json.load(f)

# Step 1: Obtain OAuth token
token_url = f"{creds['pu']}/as/{creds['oa']}/token.oauth2"
token_resp = requests.post(token_url, data={
    "grant_type": "password",
    "username": creds["saak"],    # Service Account Access Key
    "password": creds["sask"],    # Service Account Secret Key
    "client_id": creds["ci"],
    "client_secret": creds["cs"]
})
access_token = token_resp.json()["access_token"]

# Step 2: Send BOD XML via ION API
headers = {
    "Authorization": f"Bearer {access_token}",
    "Content-Type": "application/xml"
}
bod_xml = """<SyncItemMaster xmlns="http://schema.infor.com/InforOAGIS/2">
  <!-- BOD content here -->
</SyncItemMaster>"""

response = requests.post(
    f"{creds['pu']}/{creds['ot']}/IONMessaging/api/bod",
    headers=headers,
    data=bod_xml
)
print(f"Status: {response.status_code}")  # 200 = success
```

### cURL: Test ION API Gateway authentication

```bash
# Input:  OAuth token endpoint, client credentials, service account keys
# Output: Access token JSON response

# Step 1: Get OAuth token
curl -X POST "https://{tenant}.inforcloudsuite.com/as/{tenant_id}/token.oauth2" \
  -d "grant_type=password" \
  -d "username={SERVICE_ACCOUNT_ACCESS_KEY}" \
  -d "password={SERVICE_ACCOUNT_SECRET_KEY}" \
  -d "client_id={CLIENT_ID}" \
  -d "client_secret={CLIENT_SECRET}"

# Expected response:
# {"access_token":"eyJ...", "token_type":"bearer", "expires_in":3600}

# Step 2: Send a BOD
curl -X POST "https://{tenant}.inforcloudsuite.com/{tenant_id}/IONMessaging/api/bod" \
  -H "Authorization: Bearer {ACCESS_TOKEN}" \
  -H "Content-Type: application/xml" \
  -d @sync_item_master.xml
```

## Data Mapping

### BOD XML Structure Reference

| Element | Location | Type | Purpose | Gotcha |
|---|---|---|---|---|
| LogicalID | ApplicationArea > Sender | String (lid://...) | Unique app instance identifier | Format: "lid://infor.{app}.{instance}" — must match connection point config |
| BODID | ApplicationArea | UUID | Unique message identifier | Must be globally unique — use UUID v4; duplicate BODIDs cause silent drops |
| CreationDateTime | ApplicationArea | DateTime (UTC) | When BOD was created | Always UTC format "yyyy-MM-ddTHH:mm:ssZ" — local time causes routing errors |
| ActionExpression | DataArea > Verb | Attribute (actionCode) | Add, Replace, Change, Delete | Sync uses Add/Replace; Process uses Add/Change — mixing causes rejection |
| Tenant | Embedded in LogicalID | String | Multi-tenant routing key | Wrong tenant ID routes BOD to wrong environment |
| AccountingEntity | DataArea > Noun | String | Financial entity context | Required for multi-entity deployments — omission defaults to first entity |

[src4, src5]

### Data Type Gotchas

- All dates and times in BODs must use UTC format "yyyy-MM-ddTHH:mm:ssZ"; missing time values default to midnight (00:00:00Z) which can cause off-by-one-day errors in timezone-aware systems. [src4]
- BOD UserArea allows custom fields via Property/NameValue elements — the @type attribute specifies data type, but there is no schema validation on UserArea content, so receiver must validate. [src4]
- Quantity elements require a UnitCode attribute (e.g., `<Quantity UnitCode="EA">10</Quantity>`) — omitting UnitCode does not cause a BOD schema error but will fail in the receiving application. [src4]

## Error Handling & Failure Points

### Common Error Patterns

| Error | Meaning | Cause | Resolution |
|---|---|---|---|
| Confirm BOD generated | Message processing failed at receiver | Receiver app threw exception or timed out | Review Confirm BOD in ION Desk; fix data issue; resubmit from ION Desk |
| Connection point "Paused" | No messages processed for this endpoint | Manual pause or system maintenance | Resume connection point in ION Desk; messages will replay from queue |
| BOD schema validation error | XML does not match expected OAGIS schema | Wrong namespace, missing required elements | Validate BOD against Infor OAGIS schema before sending |
| LN/Baan processing timeout | Bshell did not respond in configured time | Complex business logic or DB locks in LN | Increase timeout on connection point; optimize LN processing logic |
| "Message size exceeds limit" | BOD payload too large for tier | Large item master or BOM sync | Split into multiple smaller BODs; upgrade tier if persistent |
| OAuth token expired | API Gateway returns 401 | Token not refreshed before expiry | Implement token refresh logic; cache token with TTL check |

[src2, src3]

### Failure Points in Production

- **Confirm BOD accumulation**: Failed messages generate Confirm BODs that accumulate in ION Desk. Without monitoring, these pile up silently until storage or processing limits are hit. Fix: `Set up ION Desk alerts for Confirm BOD count > threshold; review daily`. [src3]
- **Enterprise Connector disconnection**: On-premise EC agent loses connection to cloud ION — all on-prem BODs queue locally until reconnection, but local queue has finite storage. Fix: `Monitor EC health endpoint; set up auto-restart on the EC agent service`. [src2]
- **SOR designation mismatch**: Two applications both configured as SOR for the same noun — Sync BODs conflict, causing data oscillation (A updates B, B updates A in infinite loop). Fix: `Define SOR per noun explicitly in architecture documentation; use Process/Acknowledge for non-SOR updates`. [src5]
- **BOD versioning drift**: Different applications running different OAGIS versions — newer BOD fields silently ignored by older receivers. Fix: `Pin BOD versionID in all document flows; test with all receiver versions before upgrading sender`. [src4]

## Anti-Patterns

### Wrong: Polling ION API Gateway for changes instead of subscribing to Sync BODs

```
# BAD — Polling REST API every 30 seconds for changes
while True:
    response = requests.get(f"{base_url}/api/items?modifiedAfter={last_check}")
    process_changes(response.json())
    time.sleep(30)
# Wastes API Gateway capacity, misses changes between polls,
# and hits timeout limits under load
```

### Correct: Subscribe to Sync BODs via document flow

```
# GOOD — Configure document flow in ION Desk
# 1. Create connection point for your application
# 2. Create document flow: ERP (source) -> YourApp (target)
# 3. Select SyncItemMaster BOD
# 4. ION pushes changes to your inbox automatically
# Result: Zero polling, guaranteed delivery, near-real-time
```

### Wrong: Sending large bulk data as a single BOD

```xml
<!-- BAD — 50,000 line items in one SyncItemMaster BOD -->
<SyncItemMaster>
  <DataArea>
    <Sync/>
    <!-- 50,000 ItemMaster elements = ~30 MB -->
  </DataArea>
</SyncItemMaster>
<!-- Exceeds Essentials/Professional tier limits;
     even Enterprise tier risks timeout in document flows with mapping -->
```

### Correct: Chunk into smaller BODs with batch coordination

```xml
<!-- GOOD — Split into batches of 500 items each -->
<!-- BOD 1 of 100 -->
<SyncItemMaster>
  <ApplicationArea>
    <BODID>batch-001-of-100</BODID>
  </ApplicationArea>
  <DataArea>
    <Sync/>
    <!-- 500 ItemMaster elements = ~300 KB -->
  </DataArea>
</SyncItemMaster>
<!-- Stays well within all tier limits;
     use BODID convention to track batch completeness -->
```

### Wrong: Assuming SOR is always the ERP

```
# BAD — Hardcoding ERP as system of record for all business objects
# "Customer master comes from ERP" — WRONG if CRM owns customer data
# Results in: Sync BODs from CRM ignored, Process BODs rejected by ERP
```

### Correct: Define SOR per business object based on business requirements

```
# GOOD — SOR designation per noun:
# Customer -> CRM is SOR (publishes SyncCustomer)
# ItemMaster -> ERP is SOR (publishes SyncItemMaster)
# PurchaseOrder -> ERP is SOR (receives ProcessPurchaseOrder from procurement)
# SalesOrder -> CRM is SOR (publishes SyncSalesOrder to ERP)
# Document the SOR map before configuring any document flows
```

## Common Pitfalls

- **Ignoring Confirm BODs**: Confirm BODs are ION's error queue — they contain the original failed message and the error details. Teams that don't monitor Confirm BODs lose data silently until someone notices missing records downstream. Fix: `Configure ION Desk alert rules for Confirm BOD generation; assign daily review to integration support team`. [src3]
- **Not testing message size across tiers**: A BOD that works fine in Enterprise-tier dev/test fails in Essentials-tier production because the 5 MB limit is hit. Fix: `Test with production-volume data in a tier-matched environment; design BODs to stay under 5 MB for portability`. [src1]
- **Hardcoding LogicalIDs**: LogicalIDs change between environments (dev/test/prod). Hardcoding them in BOD templates breaks when promoting to production. Fix: `Parameterize LogicalID per environment using config files or environment variables`. [src5]
- **Missing BODID uniqueness**: Duplicate BODIDs cause ION to silently discard the second message. Fix: `Generate UUID v4 for every BODID; never reuse BODIDs even for retries — use OriginalApplicationArea to reference the original`. [src4]
- **Overloading document flows with mapping**: Adding complex ION Mapper transformations to high-volume flows causes processing bottlenecks and hits the 5 MB intermediate buffer. Fix: `Keep high-volume flows simple (direct routing); do complex transformation at the application layer`. [src1]
- **Not accounting for message ordering**: ION does not guarantee message ordering across multiple connection points. Fix: `Include sequence numbers or timestamps in BOD data; implement idempotent receivers that handle out-of-order delivery`. [src2]

## Diagnostic Commands

```bash
# Check ION connection point status
# ION Desk > Connect > Connection Points > select CP > Status tab
# Look for: Active (green), Paused (yellow), Error (red)

# Monitor document flow throughput
# ION Desk > Connect > Document Flows > select flow > Monitoring tab
# Shows: messages/hour, failed count, queue depth

# View Confirm BODs (failed messages)
# ION Desk > Connect > OneView > filter by Status = "Error"
# Each Confirm BOD contains: original BOD, error message, timestamp

# Test BOD delivery end-to-end
# ION Desk > Connect > Test > select document flow > Send test BOD
# Verify: message appears in target connection point inbox

# Check Enterprise Connector health (on-premise)
# EC Admin Console > Status > check "Connected" indicator
# Verify: heartbeat timestamp < 5 minutes old

# Monitor message queue depth
# ION Desk > Connect > Connection Points > select CP > Queue tab
# Alert threshold: queue depth growing faster than processing rate
```

## Version History & Compatibility

| Version | Release Date | Status | Breaking Changes | Migration Notes |
|---|---|---|---|---|
| 2024.x (Cloud) | 2024-01 | Current | Kafka connection points added | New connector type — no impact on existing flows |
| 2023.x (Cloud) | 2023-01 | Supported | SFTP from Cloud connector added | Alternative to EC-routed SFTP |
| 12.0.x (On-Premise) | 2020-01 | Supported | Last major on-premise release | Cloud migration path via Enterprise Connector |
| 11.x (On-Premise) | 2017-01 | EOL | — | Upgrade to 12.0.x or migrate to cloud |

[src2]

### Deprecation Policy

Infor maintains backward compatibility for BOD schemas across releases — existing document flows continue to work after upgrades. New BOD nouns and verbs are added incrementally. On-premise 12.0.x continues to receive patches but new features are cloud-only. Infor has not published a formal API deprecation timeline, but the industry pattern is 2-3 year notice for breaking changes. [src2]

## When to Use / When Not to Use

| Use When | Don't Use When | Use Instead |
|---|---|---|
| Async event-driven sync between Infor CloudSuite apps | Synchronous real-time CRUD with <1s response | ION API Gateway REST endpoints |
| Standardized XML messaging with built-in routing and monitoring | Custom binary or non-XML payload formats | File Connection Point or Kafka Connection Point |
| Multi-subscriber broadcast of data changes (pub-sub) | Point-to-point low-latency API calls | ION API Gateway direct REST |
| Need guaranteed delivery with error handling via Confirm BODs | Need message replay/rewind from arbitrary offset | Kafka-based integration architecture |
| Integration between on-premise and cloud Infor systems | Pure cloud-to-cloud REST API integration | ION API Gateway with OAuth |

## Important Caveats

- Processing unit capacity is contractual — exceeding your tier's capacity causes throttling, not hard failures. Contact Infor for capacity upgrades before peak seasons. [src1]
- Message size limits are per tenant, not per connection point — a single large BOD from one flow can impact capacity for all flows in the tenant. [src1]
- ION Desk monitoring (OneView) data retention is tier-dependent — Essentials retains only 45 days of complete records. Export audit data before the retention window closes if compliance requires longer retention. [src1]
- On-premise deployments (12.0.x) may have different constraints than cloud 2024.x — always verify limits against your specific deployment model and version.
- BOD schemas follow OAGIS standards but Infor extends them with custom namespaces — third-party systems must handle Infor-specific extensions in the XML schema.

## Related Units

- [Infor ION API Gateway — REST API surface for synchronous integration](/business/erp-integration/infor-ion-api-gateway/2026)
- [SAP IDoc/ALE — SAP's equivalent async messaging framework](/business/erp-integration/sap-idoc-ale/2026)
- [ION Workflow — process automation layer built on top of ION messaging](/business/erp-integration/infor-ion-workflow/2026)
