Infor OS Technical Architecture: Data Lake Integration, Homepages API, and Document Management

If you are already working inside Infor OS, you know that the platform is not just a container for your Infor applications. It is the middleware, the integration backbone, and the user experience layer all at once. But the way its three core capabilities, specifically the Data Lake, the Homepages API, and Document Management, fit together at a technical level is something that most day-to-day users never get a clear picture of. This post breaks that down in a way that is useful if you are an administrator, a developer, or a technical consultant who needs to make real decisions about configuration, integration, and architecture.

What Infor OS Actually Does Underneath

Infor OS is built on multi-tenant cloud architecture running on AWS. It acts as the common platform that ties together Infor applications such as CloudSuite, LN, M3, and others through a shared services layer. That shared layer includes identity and access management through Infor OS User Management, workflow orchestration through ION, API management through the ION API Gateway, and the three areas we are focusing on here.

The reason these three components matter more than most others is that they sit at the intersection of data, user experience, and content governance. When something breaks in a workflow or data does not show up where it should, it almost always traces back to one of these three areas.

Part 1: Data Lake Integration

How Data Gets into the Lake

The Infor Data Lake is a cloud-based repository built into Infor OS and hosted on AWS. It stores structured and unstructured data from across your Infor ecosystem. Data enters the lake primarily through two mechanisms.

The first is ION-based ingestion. When Infor applications publish Business Object Documents (BODs), ION routes those BODs through the ION API Gateway and into the Data Lake. This is the standard path for most Infor CloudSuite environments. The data arrives in near real-time, with the lake typically refreshing every ten minutes from application transactions.

The second mechanism is the ION ETL Client. This is a Windows-based tool that handles extraction, transformation, and loading of data from the Data Lake to an on-premises database. If you need to replicate Data Lake content to a local SQL environment for custom reporting or external system consumption, the ETL Client is what handles that. When you purchase the ION-S-DATALAKE-ETL license, the software becomes available for download from within Infor OS. One important operational note: Infor recommends spreading high-volume tables across multiple ETL jobs rather than running everything in a single job. Grouping large tables with smaller ones in each job gives you a more stable runtime and reduces the risk of timeout failures.

For those integrating the Data Lake with external platforms such as Snowflake or Databricks, the approach uses the Compass JDBC driver. You download the driver from ION in Infor OS, upload it to your external platform’s internal stage, and authenticate using ION API security credentials downloaded from the Infor OS Portal. The role of IONAPI-Administrator is required to generate those credentials.

The Compass Query Layer

The Compass query platform is the primary interface for querying data stored in the lake. It uses RESTful principles and supports both JDBC and API-based access. Compass is also what powers the Birst Data Lake Connector, which lets Birst pull data directly from the lake using schema-on-read intelligence rather than forcing data into a rigid pre-defined schema first.

There is a practical consideration worth noting here: Compass queries are subject to AWS service limits. If a query runs for more than 60 minutes, it will time out. This is not an edge case for organisations with large datasets and complex joins. Infor’s guidance is to use incremental queries where possible, limiting each query to delta changes rather than full table scans. The infor.lastModified() field is what most integration tools use to filter for records changed since the last sync.

Older Data Lake API endpoints have been deprecated and are being removed. As of recent Infor OS releases, the recommendation is to use the Data Lake and Compass endpoints from the Infor Data Fabric suite instead. If your environment still uses the legacy endpoints, this is worth reviewing in your next maintenance window.

The Data Catalog and Metagraph

Preventing your data lake from becoming what Infor calls a “data swamp” is the job of the Data Catalog. The Catalog provides metadata management across everything stored in the lake. It lets you register data objects, define metadata models, cross-reference relationships between datasets, and establish semantic governance through data dictionary services.

The Metagraph sits on top of the Catalog and provides a relational layer. It lets you assemble collections of data objects based on the metadata relationships you have defined in the Catalog, which is how you build meaningful datasets rather than just raw dumps of tables.

From an administration perspective, the Catalog also provides the security reference layer for the lake. Access to datasets is governed here, which means if a team is unable to query certain data through Compass, the first place to check is Catalog permissions rather than the application level.

If you are working on Infor ION integrations and feeding custom BODs into the lake, the Catalog is also where you register the schema for those custom objects so they are discoverable and queryable by other teams.

Data Fabric and What It Means in Practice

Infor has moved toward calling this entire stack the Infor Data Fabric. The Data Fabric encompasses the lake, Compass, the Catalog, the Metagraph, stream pipelines, data security, and ingestion tooling. If you see references to Data Fabric in Infor documentation, it is referring to this broader ecosystem rather than a specific single product. The key practical implication is that Data Fabric tools now integrate with AI and machine learning capabilities through Coleman, Infor’s AI layer, which means the data you store and govern in the lake is also what feeds predictive analytics and anomaly detection models.

Part 2: Homepages API and the Widget Framework

What Homepages Actually Is

Infor Homepages is the role-based landing page experience within Infor OS. It is not a static dashboard. It is an application that pulls live data from multiple ERP systems and surfaces that data through modular widgets on a single page. The technical layer that makes this possible is the Homepages Widget SDK, which is a TypeScript-based framework that any developer can use to build custom widgets that sit inside the Homepages application.

The Widget SDK is publicly available on GitHub under the infor-cloud organisation. It includes Angular source code, sample widgets, a development web server that defaults to port 8080, and a proxy for ION API communication during local development.

The Framework API and ION API Integration

Every widget communicates with two layers. The first is the Framework API, which handles communication between the widget and the Homepages application itself. This covers things like widget sizing, theme inheritance, refresh events, and inter-widget messaging. The second is the ION API, which handles communication with the actual Infor applications and data sources sitting behind the platform.

When you are developing a widget locally, you use the built-in proxy to forward ION API requests from your localhost environment to your actual Infor OS tenant. You configure this by setting the proxy_remote_host to your tenant’s hostname. This avoids CORS issues during development and lets you test against real data without deploying to production.

Widgets need to be compiled from TypeScript, bundled if they consist of multiple files, minified, and packaged into a zip before they can be uploaded to the Homepages environment. The SDK includes a minifywidget script for this purpose. The output zip is what you upload through the Homepages administration interface.

Role-Based Page Assignment and Security

Security for Homepages is handled at the Infor OS user record level. A Homepages security role must be assigned before a user can access the Homepages application at all. Beyond that, individual pages can be assigned to specific user roles, which is what makes the role-based page catalogue work.

The predefined pages that come with CloudSuite applications should not be modified directly. The correct approach is to copy a predefined page, make your changes on the copy, and then assign that copy to the appropriate role. This preserves the original definitions and makes it easier to reconcile differences after application updates.

For widget-level configuration, some widgets require a company and user ID combination to pull data correctly. If a user has access to multiple companies, you need to configure those widgets manually on duplicated pages rather than relying on automatic detection. This is a common source of confusion in multi-company environments running Infor CloudSuite or Infor LN.

What the Widget SDK Versioning Means for Your Environment

The Widget SDK is versioned to match specific Homepages and Infor OS release numbers. For example, SDK version 3.32.0 corresponds to Homepages 12.0.65 and Infor OS 2024.02.00. If you have custom widgets deployed, you need to verify that the SDK version they were built against is compatible with your current Infor OS release. Widgets built against an older SDK version do not always fail visibly; sometimes they silently fail to load data or render incorrectly without throwing a clear error.

The SDK has also updated to Angular 17 in more recent releases, which is a significant framework change. If you have custom widgets built on older Angular versions, this is something to account for in your update planning.

Part 3: Document Management (IDM)

What IDM Is and How It Fits into Infor OS

Infor Document Management, commonly referred to as IDM, is a cloud-based document repository that is part of Infor OS. It handles the full lifecycle of business documents including creation, storage, versioning, archiving, collaboration, and distribution. IDM can scale to manage millions of documents and stores content either in a cloud repository or on a local database server depending on your deployment configuration.

The key architectural distinction is that IDM is not a standalone application. It is embedded into the Infor OS experience and integrates directly with Infor applications through ION. When a user is working on a purchase order in M3 or a service order in LN, IDM surfaces related documents in context through the Related Information panel without requiring the user to leave the transaction screen or open a separate application.

Document Types, Attributes, and Access Control

The foundational unit in IDM is the document type. A document type defines the metadata attributes associated with a category of documents, the security rules that apply to it, and the workflow rules that govern its approval process. For example, a purchase order document type might have attributes like vendor number, PO number, and document date, and it might require approval from a finance manager before it moves to an archived state.

Attributes are how documents are searchable and relatable to ERP records. When you retrieve a document through the IDM REST API, you are typically querying by one or more attribute values. The API endpoint structure for a document retrieval by attribute looks like a URL with the document type and attribute name-value pairs as parameters. This is the mechanism used when external tools like InterFormNG or custom integrations pull documents from IDM programmatically.

Access control in IDM is granular. You can set permissions at the individual document level, not just at the document type level. This matters in regulated environments where certain users need access to some documents within a type but not others, such as HR document repositories where managers can see team documents but not cross-departmental records.

IDM Capture and Document Output

IDM Capture is the ingestion component. It automates the upload, separation, and classification of incoming documents. In practice, this is used for things like invoice scanning, where paper documents are scanned, OCR-processed, and automatically classified by document type based on content recognition rules. The classified documents then appear in IDM with attributes populated from the recognised content.

Document Output handles the distribution side. It lets you create print templates and distribute documents via email or enterprise print using Infor’s print infrastructure. This is what sits behind automated invoice sending, statement distribution, and similar outbound document workflows in Infor CloudSuite environments.

IDM REST API and the ION API Connection

The IDM REST API is how developers and integrations interact with IDM programmatically. Authentication is handled through the ION API Gateway. To generate credentials, you navigate to Infor ION API in your Infor OS environment, find the Authorized Apps section, locate the IDM backend service app, and download the credentials file. That credentials file is then used by external tools or custom code to authenticate their API calls.

The IDM Utilities tool is a separate Java-based GUI application for bulk operations. Common use cases include bulk importing documents from a file system into IDM, bulk exporting a specific document type to another repository, and batch updating metadata attributes across many documents. You launch it with a standard java -jar command and connect it to your environment using an IONAPI credentials file downloaded from Infor OS.

One practical note: if you are running Java 11 or later, you also need JavaFX installed separately because it is no longer bundled with the JDK. The launch command needs the module-path argument pointing to your JavaFX lib directory.

IDM and the Homepages Connection

There is a direct integration point between IDM and Homepages that is worth understanding. When a Homepages widget displays an entity such as a customer, item, or supplier, and that entity has an associated image stored in IDM, the widget will display that image. If no IDM image is found, the widget falls back to a default icon. This means that for organisations that want rich visual homepages, maintaining accurate document associations in IDM is part of the Homepages administration process, not just the document management process.

How These Three Components Connect

The Data Lake, Homepages, and IDM are not isolated services. They connect in a few specific ways that matter at an operational level.

Data from the Data Lake powers the analytical widgets on Homepages through Infor Birst or direct Compass API calls from custom widgets. When you build a custom widget that displays a KPI from your lake, the widget calls the ION API, which routes to Compass, which queries the lake and returns the result. The widget then renders it in the Homepages UI.

IDM integrates with ION to send real-time alerts when documents change. If a document approval is required, IDM can trigger an ION event that creates a workflow task or sends a notification through the platform’s notification layer. This means IDM-based approval workflows are visible in the Infor OS activity stream rather than requiring a separate email chain.

ION is the thread connecting all three. It handles the data ingestion into the lake, the API routing for widget data calls, and the event messaging for IDM workflow triggers. If you are troubleshooting data that is not appearing in the lake, widgets that are not refreshing, or IDM notifications that are not firing, the ION message flow logs are the first place to look. Our team at SAMA works extensively across these integration layers, and you can learn more about how we approach Infor ION integrations for clients running complex multi-application environments.

Common Issues and What Causes Them

Data not appearing in the lake after transactions are posted. This is usually an ION configuration issue rather than a lake problem. Check whether the application’s BOD publication is enabled in ION and whether the relevant BOD types are mapped to Data Lake destinations in your ION connection points.

Widgets loading blank or showing stale data. This typically comes down to one of three things: the widget was built against an incompatible SDK version, the ION API credentials used by the widget have expired or been revoked, or the user’s security role does not have access to the underlying data source.

IDM documents not appearing in context panels. Check that the entity attributes in IDM match the values being passed by the application. If the attribute value format differs between what the application sends and what IDM has stored, the Related Information panel will find no match and display nothing.

ETL client jobs failing or timing out. Review how your high-volume tables are distributed across jobs. If a single job is pulling tables with tens of millions of records, split it. Also check that your ETL client version is current. Infor deprecates older client versions on specific release cycles, and deprecated versions stop working entirely.

What to Consider When Planning Changes

If you are planning significant changes to your Infor OS environment, such as migrating from on-premises to cloud, upgrading to a new Infor OS release, or extending the platform with custom widgets or integrations, the interdependencies between these three components need to be part of your planning.

A release upgrade that changes the Homepages version also changes the compatible Widget SDK version, which can break custom widgets built for the previous release. A migration that moves document storage from on-premises to cloud IDM changes how credentials and API endpoints are referenced by integrations. A Data Lake schema change when new application modules are activated can break existing Compass queries that assume specific field names or structures.

None of these are reasons to avoid making changes. They are reasons to test them in a non-production environment first and to maintain clear documentation of which custom components exist and what they depend on.

If you need support planning or executing changes across these areas, our consulting team has deep experience with Infor OS architecture across manufacturing, distribution, and service industries. You can explore our services across Infor CloudSuite, Infor LN, Infor Birst, and Infor ION, or get in touch with us directly to discuss your specific environment.