End Points, Publish Channels, and Enterprise Services: A Practical Guide to MIF Integration in MAS 9.1

The MIF Is Still the Backbone of Maximo Integration

The Maximo Integration Framework (MIF) is one of the oldest subsystems in the platform, and yet it remains the most common way to exchange data between Maximo and the rest of the enterprise. While the NextGen REST/JSON API has changed how lightweight integrations are written, the MIF is still the right answer for high-volume, scheduled, or transformation-heavy data exchanges.

This guide walks through the core MIF components in MAS 9.1, explains how they fit together, and shows the patterns that work in production.

Understanding the Core Components

The MIF is not a single feature. It is a collection of configuration objects, processing engines, and transport adapters that work together. Getting the relationships right is the difference between a maintainable integration and a tangle of cron tasks and one-off scripts.

End Points: The Transport Layer

An End Point defines _where_ and _how_ data leaves or enters Maximo. It is purely a transport definition: a URL, a directory path, a queue name, or an SMTP server. The End Point does not know what data is moving or why; that is the job of the channels that use it.

| End Point Type | Transport | Typical Use Case |
|---|---|---|
| HTTP | REST / SOAP web service | Real-time API calls to ERP, GIS, or external apps |
| FILE | Local or shared directory | CSV/XML drops for legacy systems, batch loads |
| JMS | Message queue (MQ, ActiveMQ) | Asynchronous, decoupled, high-volume flows |
| EMAIL | SMTP | Notification or approval-based triggers |
| DATABASE | Direct JDBC | Bulk extracts, cross-database replication |
| IFACE TABLE | Maximo interface tables | Staging patterns for high-throughput imports |

In MAS 9.1, the HTTP End Point has gained the most attention. You can configure it for RESTful exchanges with explicit HTTP method, custom headers, OAuth2 client credentials, and request/response transformation. This makes it possible to replace many SOAP-based flows with modern REST calls without leaving the MIF.

code block

Object Structures: The Data Contract

An Object Structure is a published view of one or more Maximo Business Objects (MBOs) and their relationships. It is the contract that determines which fields are visible to an external system, how they are named, and how related records are included.

Object Structures sit between the MBO layer and the integration layer. The MBO layer enforces Maximo's business rules, and the external system talks to the Object Structure. This indirection is what lets you rename a field for an external system without changing Maximo, and what lets you add validation, defaults, and processing rules at the integration boundary.

In MAS 9.1, the recommended approach is to use the NextGen Object Structure format for new integrations. It is JSON-native, supports nested objects, and avoids the legacy XML/CollectionDAOS pattern that dominated earlier releases.

Publish Channels and Enterprise Services: The Direction of Flow

The MIF has two primary flow types, and choosing the right one is the most important architectural decision you will make.

Publish Channels move data _out_ of Maximo. A Publish Channel is bound to an Object Structure and an End Point. When a business event triggers it (a work order status change, a new asset record, a meter reading above threshold), Maximo packages the configured Object Structure and pushes it to the End Point. Enterprise Services move data _into_ Maximo. An Enterprise Service is also bound to an Object Structure and an End Point, but the End Point is _receiving_ rather than sending. The external system posts data to the End Point, Maximo applies the Object Structure mapping, validates the data, and applies it through the MBO layer with all the usual business rules.

| Direction | Component | Triggered By | Use Case |
|---|---|---|---|
| Outbound | Publish Channel | Business event, cron, manual | Sync work orders to ERP, push meter readings to analytics |
| Inbound | Enterprise Service | External system POST | Receive work requests from CRM, load asset hierarchy from GIS |

Building a Real-World Outbound Integration

Let us walk through a complete outbound integration: pushing Maximo work orders to an external ERP system when they reach a certain status. This is one of the most common MIF patterns.

Step 1: Define the Object Structure

Create a new Object Structure called `OS_WO_OUTBOUND` based on the `WORKORDER` MBO. Include only the fields the ERP needs: `WONUM`, `DESCRIPTION`, `STATUS`, `ASSETNUM`, `SCHEDSTART`, `SCHEDFINISH`, and `WORKTYPE`.

code block

Step 2: Configure the HTTP End Point

Create a new HTTP End Point for the SAP-PM service. Use environment variables for secrets and configure retry behavior. In MAS 9.1, you can attach a `Maximo Manage Secret` to the End Point so the secret never lives in plain configuration.

Step 3: Create the Publish Channel

Bind the Object Structure and the End Point into a Publish Channel. Set the processing class to `psdi.iface.omp.OmpProcessor` for standard synchronous delivery, or `psdi.iface.omp.OmpOutboundProcess` if you need queue-based asynchronous delivery.

code block

Step 4: Attach the Event Listener

The Publish Channel needs to know when to fire. In MAS 9.1, you have three options:

1. Cron task: Fire on a schedule (e.g., every 5 minutes) and pick up any records that changed since the last run. Best for high-volume, eventually-consistent flows.
2. Event Listener: Fire on a specific MBO event (e.g., `STATUS` change to `APPR`). Best for real-time, event-driven flows.
3. Script launchpoint: Fire from an Automation Script. Best for complex conditions that cannot be expressed in a simple event filter.

Step 5: Test and Monitor

Once the channel is configured, use the Integration Monitor in Maximo Manage to trace the message. MAS 9.1 introduces a redesigned Integration Monitor with structured logging, payload diffs, and one-click replay. This is a significant improvement over the old XML log viewer.

Inbound Integration: Loading Asset Hierarchies from a GIS

Inbound flows are conceptually similar but with one critical difference: the external system initiates the call. The Maximo End Point is _listening_ and the external system is _calling_.

A common pattern is loading asset hierarchies from an ESRI ArcGIS system. The GIS team owns the spatial data and pushes new or modified assets into Maximo whenever the network changes.

The flow looks like this:

1. GIS detects a change in the network model.
2. GIS calls the Maximo HTTP End Point with a JSON payload representing the asset (or hierarchy).
3. The Enterprise Service receives the call, validates the payload against the Object Structure, and applies it through the MBO layer.
4. If validation fails, Maximo returns a 4xx response with structured error details.
5. If validation succeeds, Maximo returns a 201 response with the new `ASSETNUM`.

code block

The `ES_ASSET_IN` Enterprise Service is configured with:

- A REST End Point at `/api/os/ES_ASSET_IN`
- An Object Structure that maps `GISFEATUREID` to `ASSETNUM` for idempotency
- An `Invoke Channel` action that creates the asset if `ASSETNUM` does not exist, or updates it if it does
- A response handler that returns the `ASSETNUM` and any validation errors in JSON

The MAS 9.1 Improvements You Should Use

MAS 9.1 (and the 9.1.x patch stream) brought several MIF improvements that are worth knowing about.

API Key Authentication for End Points

Historically, MIF End Points used HTTP Basic Auth with a service account user. MAS 9.1 added native API key support. You can now issue a long-lived API key from the API Keys application, scope it to specific End Points, and revoke it without rotating a password.

This is a significant security improvement. Service account credentials in configuration files have been a long-standing integration anti-pattern, and API keys close that gap.

Structured Error Responses

When an inbound Enterprise Service rejects a payload, the response now includes a structured error array with field names, error codes, and human-readable messages. This makes it much easier to debug integration failures from the calling system.

code block

Async Processing and DLQ

For high-volume Publish Channels, MAS 9.1 now supports an asynchronous processing mode backed by a JMS queue. Messages are placed on the queue, processed by a configurable pool of consumer threads, and routed to a dead-letter queue (DLQ) on terminal failure. This decouples Maximo from downstream system latency and protects the MIF from backpressure when the ERP is slow.

Error Handling and Observability in Production

The MIF has historically been opaque. When an integration failed, the only signal was a cryptic error in the Integration Monitor log, and the only way to debug was to enable verbose logging and try to reproduce the issue. MAS 9.1 has made significant improvements in this area, and adopting a few observability patterns will save hours of debugging time.

Integration Monitor Enhancements

The redesigned Integration Monitor in MAS 9.1 is the primary debugging tool. It now provides:

Structured message lifecycle. Every message has a clear lifecycle: queued, sending, awaiting response, complete, or errored. You can see exactly where a message is in the pipeline, and you can filter by status to find stuck messages. Payload diffs. When a message fails, the monitor shows the exact payload that was sent (or received) and the error response. This is enormously useful for debugging transformations and field mapping issues. Compare what you sent with what the downstream system expected. One-click replay. From the monitor, you can replay a failed message with a single click. The replay uses the original payload and the current End Point configuration, so you can test configuration changes without re-triggering the source event. This is the single biggest productivity improvement in MAS 9.1 for integration work. Searchable error codes. The monitor is now indexed by BMX error code. If you see a `BMXAA0029E` error in your logs, you can search the monitor for all messages that have produced that error, which makes it much easier to identify systematic problems versus one-off issues.

Logging Best Practices

The MIF supports several levels of logging, controlled by the `mxe.int.loglevel` system property and by per-channel settings. In production, the recommended approach is:

1. Global log level: INFO. This captures normal lifecycle events without overwhelming the log. Most production environments should never run at DEBUG globally.
2. Per-channel log level: DEBUG for new channels. While a new channel is in development, set its log level to DEBUG to capture the detailed processing information. Once the channel is stable and proven in production, drop it to INFO.
3. External log aggregation. MAS on OpenShift ships logs to stdout, which can be aggregated by ELK, Splunk, Loki, or another log management platform. Configure your log management tool to index the MIF log messages and to alert on error patterns.

code block

Common Error Patterns

Some errors repe

...