Infor ION Desk Development: Application Registration, Data Fabric Queries, and Event Subscription Management

ION Desk is the configuration and modeling interface for the entire Infor ION platform, and every enterprise integration built on Infor technology eventually passes through it. Whether you are connecting a new application to the BOD message bus, querying structured data from Infor Data Fabric using Compass SQL, or setting up event subscriptions that alert teams when a business condition is breached, ION Desk is where that work is done. This article examines the technical mechanics of each of those three areas in depth, drawing directly from the Infor ION User Guide (Cloud) at docs.infor.com and the ION Development Guide documentation.

If you are starting from scratch with ION, the step by step integration guide on this site covers the foundational orientation. This article assumes you are already working in ION Desk and need a precise technical reference for the three areas listed above.

The ION Desk Environment and Its Core Architecture

Before going into application registration, Data Fabric queries, and event subscriptions, it helps to understand what ION Desk is architecturally. As defined in the Infor ION User Guide (Cloud), ION is a browser based interface used to configure and monitor all Infor ION services. It encompasses ION Connect, which handles document flow modeling and connection point management, as well as Event Management, Workflow modeling, the Data Catalog, and the ION OneView monitoring interface.

ION Desk runs within the Infor OS grid and is accessed through the Infor OS Portal. The ION API Gateway sits in front of all external API interactions, enforcing OAuth 2.0 authentication, throttling, and security policy. According to the ION API Administration Guide, the gateway acts as the API front end, receives requests, passes them to the backend service, and returns the response to the requester. It also handles analytics collection and caching at the gateway layer, not at the application layer.

The logical ID is the fundamental addressing concept within ION. Every connection point has a logical ID in the format lid://infor.namespace.name. This ID is how ION routes documents between applications. When you model a data flow that sends a BOD from one application to another, you are defining the path between logical IDs. This addressing model is persistent across cloud and on premises deployments, and it is what allows ION to decouple the physical location of an application from its identity in the integration mesh.

Application Registration in ION Desk

Registering an application in ION Desk involves two parallel steps: creating the authorized application record in the ION API Gateway and creating the connection point in ION Connect. These two objects are separate but dependent. The authorized application provides the OAuth credentials. The connection point defines the document types the application can send and receive and binds those to the logical ID.

Connection Point Types: IOBOX and IMS

As documented in the Infor ION Desk User Guide for the 2024.x release on docs.infor.com, application connection points are of two types: IOBOX and ION Messaging Service (IMS).

IOBOX sends messages using outbox tables and receives messages using inbox tables. The inbox and outbox are connected through JDBC. Only BOD document types are supported with an IOBOX connection point. This is the connector that native Infor applications typically use. The application writes outbound BODs to the outbox table, ION picks them up via JDBC, routes them according to the defined data flow, and deposits inbound BODs into the inbox table, where the application reads them.

IMS exchanges messages with an application through predefined REST methods and authenticates through OAuth 1.0. According to the Infor Application Connector (IMS) documentation on docs.infor.com, IMS does not require direct access to an application database. Instead, it communicates through the secured HTTPS protocol, making it a loosely coupled connector. IMS supports all document types defined in the ION Data Catalog, not just BODs. This makes IMS the correct connector type for third party or custom applications that cannot use JDBC but can make and receive HTTP calls.

One operational note from the official documentation: IMS can send and receive multiple message requests in parallel. This means the sequence of message transport is not guaranteed when using IMS. If your integration depends on message ordering, you need to build ordering logic at the application layer, not rely on ION to preserve sequence.

For transport performance, particularly for larger messages, the IMS connector supports DEFLATE and GZIP compression. The official documentation notes that ION internals are DEFLATE optimized, and decompression happens before delivery to the receiving application so the consuming side does not need to handle decompressed content explicitly.

Creating an Authorized Application and Downloading Credentials

The authorized application creation process begins in the Infor OS Portal under the API Gateway section. As documented in the ION API authorized app configuration guidance on docs.infor.com, you navigate to ION API, open Authorized Apps, and create a new application of type Backend Service. The application is given a name, the token expiry is configured, and once saved, credentials are downloaded.

The download process generates a service account. According to the official credential download documentation, you do not need to specify a username for this service account because ION does not authorize incoming requests based on user authorizations. The downloaded .ionapi credential file contains the tenant ID, the environment base URL, the client ID (ci), the client secret (cs), the OAuth token endpoint (oa and ot properties), and the service name. Every field in that file is required when configuring the application to call ION API endpoints.

The client ID from the credential file is then used when creating the IMS connection point in ION Desk. You navigate to Connect, then Connection Points, create a new connection point of type IMS via ION API, and in the Connection tab, enter the client ID in the ION API Client ID field. This binds the connection point to the authorized application record in the API Gateway. At this stage the connection point is unidirectional. Making it bidirectional, so the application can both send to and receive from ION, requires an additional step of enabling the IMS endpoint on the connection point and providing a service account credential file that ION will use to call the application’s IMS endpoint.

Configuring Document Types on the Connection Point

The Documents tab on the connection point defines which BOD or custom document types the application can send or receive. This is not decorative configuration. ION uses the document list on the connection point to validate routing at the time a data flow is activated. If a data flow attempts to route a document type to a connection point that does not list that type, the routing fails at activation, not at runtime. Getting the document list correct during connection point setup prevents silent routing failures in production.

For applications integrating with Infor LN or Infor CloudSuite, the relevant BOD types are determined by the business process being integrated. An inventory integration will use Sync.InventoryCount and Sync.ReceiveDelivery among others. An order management integration will use Sync.SalesOrder and Acknowledge.SalesOrder. The ION Data Catalog, accessible within ION Desk, is the authoritative reference for the available BOD nouns and the verbs supported for each.

Data Fabric Queries via ION Desk

Infor Data Fabric, managed within the Infor OS platform, is the data repository layer where Infor applications publish structured data objects at scale. As documented in the Infor Data Fabric User Guide on docs.infor.com, Data Fabric provides several methods for extracting and querying data including Compass SQL APIs through the API Gateway, data object retrieval APIs, a JDBC interface, and ION data flow integration that uses Data Lake as the starting point for a downstream flow.

The Compass SQL Query Platform

Compass is a suite of Data Fabric tools that provide data consumers with interfaces for connecting to and processing ANSI SQL queries against data objects stored within the Data Fabric. As defined in the official Compass documentation on docs.infor.com, Compass exposes RESTful APIs that allow data developers and client applications to programmatically submit SQL queries and stream results to a data consumer. The Compass Query Editor is available to browser based users in Infor OS for prototyping and testing SQL before embedding queries in automated processes.

Compass queries operate on flat data in DSV (delimiter separated values) or newline delimited JSON format. This is an important constraint. Data objects stored in Data Fabric as hierarchical JSON cannot be queried directly through Compass SQL without first being surfaced as a flat structure. Applications that publish BOD data to Data Lake need to be aware of how that data lands in storage and whether the resulting schema is flat enough for SQL querying. According to the Data Fabric documentation, for document types that are not flat, the data object retrieval APIs are available as an alternative, though their filtering capabilities are more limited than Compass SQL.

The Compass API call goes through the ION API Gateway, which means it requires OAuth 2.0 authentication. The requesting application obtains a bearer token using its authorized app credentials and includes that token in the Authorization header of the Compass API request. Compute time consumed by Compass API queries is metered according to the Infor ION API service levels, and data egress when results are streamed out of the Infor cloud environment is also subject to egress metering. These are not administrative footnotes: in high volume integration scenarios with large result sets, compute and egress consumption need to be factored into the integration design.

ION AnySQL Modeler and Data Flow Integration

For integration scenarios where queried data from Data Fabric needs to flow downstream to another application, ION provides the ION AnySQL modeler within the data flow designer. As documented in the Data Fabric integration guide on docs.infor.com, integration designers can retrieve raw data objects or design SQL queries with the ION AnySQL modeler and send the resulting payloads to eligible ION technology connectors. This allows data analysts to model Data Lake as the source in a data flow rather than an operational application.

An important caveat from the official documentation applies here: Compass SQL APIs are not supported within Infor ION Workflow. If your integration architecture routes Data Fabric query results through an ION Workflow step, you cannot use Compass for that retrieval. You would need to use the AnySQL modeler within a document flow instead, or route the query through an external service that sits outside the workflow execution context.

The ION data flow approach using Data Lake as a source is recommended for lower frequency integration and reporting scenarios. For complex query development requirements, the official Infor documentation recommends using the Compass Query Editor for prototyping and then building client interfaces that use the Compass SQL JDBC driver or REST API endpoint for production automation.

Data Catalog API

The Data Catalog runs within the ION Grid and exposes a REST Service that allows programmatic access to metadata about data objects. As documented in the Data Catalog API reference on docs.infor.com, the API methods support retrieving a list of all existing objects in the Data Catalog, registering object metadata for JSON and DSV objects, retrieving metadata for JSON and DSV objects, retrieving a list of BOD nouns, and retrieving noun properties for BODs.

The Data Catalog API authenticates through OAuth 1.0. This is a different authentication model from the OAuth 2.0 used by the API Gateway for other ION API operations. Your integration code needs to handle both authentication flows if it interacts with both the Data Catalog API directly and with other ION API endpoints. The credentials for the DataCatalog service come from the system administrator, separate from the authorized app credentials used for connection points and data flow operations.

The Data Catalog API is relevant for any integration that needs to dynamically discover what data structures are available in the ION environment at runtime, rather than hardcoding schema assumptions. For platforms like Infor Birst or external analytics tools consuming ION data, using the Data Catalog API to retrieve noun properties before query construction prevents schema mismatch errors when underlying BOD structures change across ION version upgrades.

Event Subscription Management in ION Desk

Event subscription management in ION Desk covers two distinct but related areas: Event Management, which monitors business conditions and triggers alerts, and the broader data flow subscription model, which routes BOD events from source applications to consuming applications and services.

Event Management: Business Condition Monitors

Event Management in ION allows you to define monitors that evaluate business conditions against incoming BOD data and generate alerts, tasks, or notifications when those conditions are met. As described in the Infor ION User Guide (Cloud), Event Management enables monitoring of business events based on predefined business conditions and alerts users when exceptions take place.

A monitor in ION Event Management is bound to a specific BOD noun. When ION processes a document of that type through a data flow, Event Management evaluates it against the monitor conditions. If the conditions are met, the monitor creates an alert or fires a workflow. The alert is visible to users in the ION ActivityDeck within Infor OS. Alert activities have a status lifecycle: created and distributed with no user action, manually assigned to a specific user or role, unassigned, completed, or canceled. The system administrator can cancel alerts from the Activities management interface in ION Desk.

From an application development perspective, your application can also create alerts, tasks, and notifications programmatically by sending Pulse BODs to ION. As documented on docs.infor.com, any application connected to ION can create activities in the ION Activities engine by sending PulseAlert, PulseTask, or PulseNotification BODs. This means your external application does not need to be running through a monitor definition to put actionable items into users ION ActivityDecks. It sends the Pulse BOD, ION receives it, and the activity is created. The application can also receive status updates for those activities and can cancel them by sending the appropriate BOD.

Data Flow Event Subscriptions

The data flow is the primary subscription mechanism in ION Connect. As defined in the Infor ION Desk User Guide, a data flow is a sequence of activities that send or receive documents. Data flows are event driven: when a document is published by an application, the next step in the flow is triggered. Each flow starts and ends with one or more connection points, and connection points can be reused across multiple data flows.

This event driven architecture is what makes ION Connect different from a scheduled polling integration. When an Infor EAM application publishes a Sync.MaintenanceOrder BOD to ION, it does not push that document directly to a downstream application. It publishes it to the ION message bus. The data flow definition determines which connection points receive that document and in what sequence. If no data flow is defined for that document type from that connection point, the document is processed but goes nowhere. This is a common source of silent integration failures: the source application is publishing correctly, but no data flow subscription exists to route the document to the target.

Data flow activation is an explicit step in ION Desk. A flow must be activated before it routes documents in production. Deactivating a flow to make configuration changes, such as adding a connection point or modifying document type mappings, stops all routing for that flow. For production environments, this means data flow changes need to be coordinated with integration change windows because any documents published while the flow is inactive are not retroactively routed after reactivation.

Message Listeners and Content Based Routing

ION Connect also supports message listeners, which intercept documents in a data flow and apply conditions to determine downstream routing. Message listeners enable content based routing: the same BOD type from the same source can be routed to different targets based on the content of the document. For example, a Sync.PurchaseOrder BOD might be routed to a procurement system if the order total is above a threshold, and to a different system if below that threshold. The routing condition is evaluated by the message listener before the document is forwarded.

ION also supports filtering at the connection point level, which prevents certain document types from flowing through a connection point even if a data flow is technically configured to route them. Filtering is distinct from content based routing: filtering excludes documents by type, content based routing selects destinations based on values within the document.

For organizations integrating ION with external systems using message queues, the JMS connection point type allows ION to act as either a server or a client for a JMS queue. According to the Infor documentation on message queue connection points, when an external XML message is passed to ION through a JMS connection point, ION wraps it in a BOD envelope so it can be handled and monitored within ION Desk like any native BOD. This means the full ION monitoring, mapping, and routing toolset applies to messages that originate as raw XML in external systems.

ION OneView and Subscription Health Monitoring

ION OneView, accessible within ION Desk, provides a tracking interface for monitoring the complete lifecycle of every document that passes through ION. For event subscription management, OneView is the diagnostic surface for understanding whether a document was received, routed, delivered, and acknowledged as expected. The timeline view in OneView shows each step in the processing chain, from the moment a document entered ION through the connection point to the final delivery confirmation.

According to the ION Desk sanity check documentation on docs.infor.com, when diagnosing integration failures, the ION Grid Management pages show the operational status of each host, system node, and application node. A node status of OK confirms that the ION Grid component is running from a grid perspective, but the documentation notes explicitly that not all functionality is guaranteed to be loaded even when node status is OK. For complete diagnosis, the node log files accessible through the ION Grid Management interface give the detailed error output that the status indicators do not surface.

For the Infor ION integration services work that Sama’s team delivers, the combination of OneView tracking and ION Grid log analysis is the standard diagnostic approach for production event subscription issues. Status indicators tell you something is wrong. Log files tell you what is wrong and at which layer.

Bringing the Three Disciplines Together

Application registration, Data Fabric queries, and event subscription management are not independent topics in an ION Desk implementation. They form a dependency chain. Application registration creates the connection points and authorized app credentials that the data flow and event subscription infrastructure depends on. Data Fabric queries extend the integration surface by allowing data flows to source from the Data Lake as well as from live application BOD events. Event subscription management defines what happens after a document enters ION: who receives it, under what conditions, and what monitoring tells you whether the delivery was successful.

Teams working across all three of these areas in the same ION Desk tenant need to coordinate on logical ID naming conventions, document type registrations in the Data Catalog, and data flow activation windows. An application registration that uses an ad hoc logical ID naming pattern creates downstream confusion when data flow modelers need to reference those connection points months later. A Data Fabric query that assumes a specific BOD noun schema will break silently when a connected application upgrades and the noun structure changes. An event subscription with no monitoring coverage in ION OneView produces integration failures that are invisible until a downstream business process reports a data gap.

The Infor ION platform is architecturally coherent, but it requires deliberate design discipline at each of these three layers to deliver reliable integration infrastructure. For organizations building or extending their Infor integration footprint, having practitioner level knowledge of ION Desk development across all three of these areas is what separates integrations that hold up in production from those that require constant intervention.

To discuss your ION Desk implementation requirements or get a technical assessment of your current integration architecture, reach out through the Sama Consulting contact page.