MAS 9 Integration Architecture: From MIF to API-First

If you have been running Maximo 7.6 for years, your integration architecture probably looks familiar: the Maximo Integration Framework (MIF) handling SOAP web services, JMS queues pumping messages between systems, Interface Tables for batch loads, and a tangle of custom automation scripts gluing it all together. It works. It has worked for a decade. But it is not where IBM is investing anymore.

MAS 9 is a rearchitecture, not an upgrade. The integration layer has been rebuilt around three principles: JSON APIs, Kafka event streaming, and API Key authentication. If you are planning a migration, or already in the middle of one, understanding the new architecture is not optional. It is the difference between a clean transition and months of retrofitting legacy patterns onto a platform that no longer supports them well.

This guide breaks down the old versus the new, the specific integration patterns that changed, and the concrete migration path for the most common scenario: Maximo-to-ERP integration with SAP and Oracle.

The Old Guard: Maximo Integration Framework

The Maximo Integration Framework has been the backbone of Maximo integrations since version 7.x. It is organized around four core concepts that every Maximo integration developer knows by heart: Object Structures, Publish Channels, Enterprise Services, and End Points.

Object Structures define the data schema that Maximo exposes externally. Each Object Structure maps a set of Maximo application objects (WORKORDER, PO, ASSET, and so on) and their fields to a named external schema. Object Structures control which fields are included in integration messages, which fields are required, and which Maximo business rules apply when data enters through the integration layer. They are reused across both inbound and outbound integrations. The MXWO Object Structure, for example, can publish work order status updates to an external system and also receive work order creation requests from a field service platform. Pre-built Object Structures exist for all major Maximo business objects, and custom structures can be created for specialized use cases.

Publish Channels define outbound integration flows from Maximo to external systems. When a qualifying event occurs in Maximo (a work order status changes, a purchase order is approved, an asset is decommissioned), the Publish Channel generates an XML or JSON message and delivers it to the configured End Point. Publish Channels are triggered by Publish Channel exits, which are Java classes or automation scripts that evaluate whether a specific record change should generate an outbound message. Most standard integrations use IBM's pre-built exits, but custom exit logic can be configured to implement conditional publishing. For example, you might only publish purchase orders above a certain value to the external procurement system.

Enterprise Services define inbound integration flows from external systems into Maximo. An external system posts an XML or JSON message to the Enterprise Service URL, and the MIF processes it, validates it against the Object Structure, and creates or updates the corresponding Maximo record. Enterprise Services can invoke Maximo business rules (validation, required field checks, workflow initiation) just as if the record had been created through the Maximo UI.

End Points define the external destinations for Publish Channel messages. End Point types include HTTP (REST or SOAP web service calls), JMS message queues (for asynchronous reliable delivery), and flat file (for batch integrations). Maximo 7.6 exposes its MIF interfaces as SOAP web services in addition to the HTTP and JMS endpoints. MAS retains SOAP support for backward compatibility but strongly favors REST for new integrations.

A typical MIF integration flow looks like this: an external ERP system posts an XML message containing purchase order data to an Enterprise Service URL. The Enterprise Service validates the message against the MXPO Object Structure, checks that required fields are present, and creates the PO record in Maximo. If the PO is approved in Maximo, a Publish Channel fires and sends the approval status back to the ERP system via an HTTP End Point. If the End Point is unreachable, the message is queued for retry. The entire flow is configured in the Maximo Integration application, with no code required for standard patterns. Custom logic is added through automation scripts or Java exits when the standard configuration is not sufficient.

The MIF also supports Interface Tables, which are database tables that act as staging areas for batch integrations. External systems write records to an Interface Table, and a cron task processes them into Maximo. This pattern is common for legacy integrations where the external system can only output flat files or database records. Interface Tables are still supported in MAS 9, but the REST API data import/export capability is the modern replacement. If you are building new batch integrations, use the REST API with bulk JSON payloads instead of Interface Tables.

The MIF is not gone in MAS 9. It still exists for backward compatibility. But IBM is not enhancing it. All new integration capability is being built into the REST API layer and the Kafka event streaming framework. If you are starting fresh on MAS 9, you should not be building new MIF-based integrations.

The New Architecture: JSON API, Kafka, and API Keys

MAS 9 introduces a fundamentally different integration architecture. The shift can be summarized in a comparison table:

The JSON API is the recommended integration mechanism for all new work in MAS 9. The endpoint pattern is straightforward:

https://<host>/api/os/<objectstructure>

HTTP methods follow standard RESTful conventions. Use GET to retrieve records with OSLC query syntax for filtering. Use POST to create new records with a JSON body. Use PATCH for partial updates on existing records. Use DELETE to remove records (rarely used in production integrations). The _bulkid parameter enables batch creation or update of multiple records in a single API call, which dramatically reduces the overhead of creating hundreds of work orders or assets individually.

Authentication in MAS 9 uses API Keys and OAuth 2.0 tokens. Clients obtain an OAuth token by posting credentials to the token endpoint, then include the bearer token in all subsequent API calls. This is a significant security improvement over Maximo 7.6's basic authentication over HTTPS. The lean=1 parameter strips metadata from JSON responses, reducing payload size for high-volume integrations.

The new REST API also supports advanced query capabilities that were difficult or impossible with the legacy REST endpoint. Subselects allow you to query related objects in a single call. Related object queries let you traverse relationships (work order to asset to location to parent location) without multiple API calls. Multi-attribute text search enables full-text search across multiple fields simultaneously. Custom queries can be defined using automation scripts, giving you programmable query logic that runs server-side. The API also supports group by queries, dynamic query views, and integration with Maximo formulas and federated MBOs.

Kafka replaces JMS as the messaging backbone. MAS 9 uses Apache Kafka for event streaming, which means outbound integration events can be consumed by multiple downstream systems simultaneously. Instead of point-to-point JMS queues where each integration requires its own listener, Kafka topics allow multiple consumers to subscribe to the same event stream. A work order status change can trigger downstream notifications to an ERP system, a reporting platform, and a mobile alert service, all from the same Kafka topic, without duplicating the message.

Kafka also brings partition-based parallelism. If you have a high volume of integration events, Kafka partitions allow multiple consumers to process messages in parallel, scaling throughput horizontally. With JMS, a single consumer typically processes messages sequentially from a queue. With Kafka, a consumer group can distribute message processing across multiple instances. This is particularly valuable for organizations with thousands of assets generating frequent condition monitoring events.

RMI, the old Java remote method invocation protocol for direct MBO access, is deprecated in MAS 9 and will be removed in a future release. Every RMI integration needs a REST API rewrite. If you have RMI-based integrations, you should plan and budget for that rewrite now.

Here is a concrete example of creating a work order through the MAS 9 REST API using Python:

import requests
import json
from datetime import datetime

# MAS 9 REST API endpoint
base_url = "https://mas-host.company.com"
api_url = f"{base_url}/api/os/mxwo"

# OAuth 2.0 token (obtained from MAS token endpoint)
headers = {
    "Authorization": "Bearer eyJhbGciOiJSUzI1NiIs...",
    "Content-Type": "application/json",
    "Accept": "application/json"
}

# Create a new work order with related labor and materials
work_order_data = {
    "wonum": "WO-2026-0451",
    "description": "Replace bearing on pump P-101",
    "siteid": "BEDFORD",
    "status": "WAPPR",
    "wopriority": 2,
    "worktype": "PM",
    "assetnum": "P-101",
    "location": "PLANT-A-BLDG-2",
    "estdur": 4.0,
    "supervisor": "SUP002",
    # Related labor lines
    "wolabor": [
        {
            "laborcode": "TECH001",
            "laborhrs": 3.5,
            "craft": "MECHANIC",
            "rate": 85.00
        },
        {
            "laborcode": "TECH002",
            "laborhrs": 0.5,
            "craft": "ELECTRICIAN",
            "rate": 92.00
        }
    ],
    # Related material lines
    "womaterial": [
        {
            "itemnum": "BRG-6205",
            "description": "Bearings - 6205",
            "quantity": 2,
            "unitcost": 145.00,
            "storeloc": "CENTRAL"
        }
    ]
}

response = requests.post(api_url, headers=headers, json=work_order_data)

if response.status_code == 201:
    created_wo = response.json()
    print(f"Work order created: {created_wo.get('wonum')}")
    print(f"Record ID: {created_wo.get('_id')}")
    print(f"Status: {created_wo.get('status')}")
else:
    print(f"Failed: {response.status_code}")
    print(response.text)

And here is how you query work orders with OSLC filtering, retrieving only the fields you need:

# Query approved high-priority work orders
query_url = f"{api_url}?oslc.where=status=\"APPR\" and wopriority<=2"
query_url += "&oslc.select=wonum,description,assetnum,status,wopriority,scheduledate"
query_url += "&_maxitems=100&lean=1"

response = requests.get(query_url, headers=headers)

if response.status_code == 200:
    data = response.json()
    work_orders = data.get("member", [])
    print(f"Found {len(work_orders)} work orders")
    for wo in work_orders:
        print(f"  {wo.get('wonum')}: {wo.get('description')}")
        print(f"    Asset: {wo.get('assetnum')}, Priority: {wo.get('wopriority')}")
        print(f"    Scheduled: {wo.get('scheduledate')}")

Here is a Node.js example for subscribing to Kafka events from MAS 9:

const { Kafka } = require('kafkajs');

const kafka = new Kafka({
  clientId: 'maximo-erp-bridge',
  brokers: ['mas-kafka-host:9092']
});

const consumer = kafka.consumer({ groupId: 'erp-integration-group' });

async function consumeMaximoEvents() {
  await consumer.connect();
  await consumer.subscribe({ topic: 'maximo-workorder-events', fromBeginning: false });

  await consumer.run({
    eachMessage: async ({ topic, partition, message }) => {
      const event = JSON.parse(message.value.toString());
      console.log(`Received WO event: ${event.wonum} - ${event.status}`);

      // Route to ERP based on event type
      if (event.status === 'COMP') {
        // Post actual costs to SAP/Oracle financial module
        await postCostsToERP(event);
      } else if (event.status === 'APPR') {
        // Notify procurement system of approved work order
        await notifyProcurement(event);
      }
    }
  });
}

consumeMaximoEvents().catch(console.error);

SAP Integration: The Modernized Connector

SAP integration is the most complex and most common enterprise integration requirement for Maximo deployments. IBM released an updated Maximo Connector for SAP in March 2026 that now supports SAP Cloud Platform Integration (SAP CPI) as the middleware layer, replacing the older SAP PI/PO middleware. This update aligns the connector with SAP's current cloud integration architecture while preserving all existing Maximo-SAP integration patterns, mappings, and functional behavior. The connector supports MAS 9.1 and all forward MAS versions, with production readiness planned for MAS 9.2 GA.

The primary SAP integration patterns remain consistent. Financial posting sends work order actual costs (labor, materials, contractor costs) to SAP CO (Controlling) as actual costs against internal orders, cost centers, or WBS elements. When a work order is completed in Maximo, the MIF Publish Channel (or in MAS 9, the Kafka event stream) triggers the financial posting message. The middleware transforms the Maximo cost data into the SAP CO posting format, calling the appropriate BAPI or OData service in S/4HANA.

Purchase order synchronization routes POs between Maximo and SAP MM (Materials Management) depending on which system owns the procurement process. In organizations where Maximo manages MRO procurement, POs created and approved in Maximo are transmitted to SAP MM for vendor communication and invoice matching. Alternatively, some organizations create POs in SAP and publish them to Maximo for goods receipt and inventory update. The direction depends on where the procurement team primarily works.

Master data synchronization keeps GL accounts, cost centers, WBS elements, and asset master data aligned between both systems through nightly batch exchanges. Asset master data created during commissioning in SAP Plant Maintenance may need to flow to Maximo as asset records. This bidirectional master data sync is typically implemented as a nightly batch exchange using flat files or a message broker.

The modernized connector shifts the middleware from SAP PI/PO to SAP CPI, but the integration logic at the Maximo end remains the same. The difference is in how the message gets to SAP. Instead of routing through SAP PI/PO's BAPI/RFC interfaces, the message now flows through SAP CPI, which exposes REST-based integration flows. All existing interface logic remains unchanged, which means the migration is primarily a middleware configuration exercise rather than a full integration rewrite.

For organizations migrating to SAP S/4HANA, the recommended integration pattern is API-mediated:

MAS REST API → Middleware (App Connect or SAP Integration Suite) → S/4HANA OData API
S/4HANA OData API → Middleware → MAS REST API (or Kafka → MAS)

The middleware layer is not optional. If there is one lesson from two decades of ERP integration, it is this: never connect Maximo directly to your ERP without a middleware layer. Not even with modern REST APIs. Not even when both systems speak JSON. The middleware handles message transformation, retry logic, error handling, and audit logging. Without it, you end up reimplementing all of those capabilities inside Maximo automation scripts, which is where legacy integrations go to become unmaintainable.

Oracle Integration: ORDS and the Modern Path

Oracle EBS integration historically used the Maximo Enterprise Adapter for Oracle Applications, which customized the MIF for Oracle E-Business Suite business flows. The adapter wrapped Oracle's PL/SQL API packages (for PO, AP, and GL) in MIF-compatible interfaces.

For organizations staying on Oracle EBS (not migrating to Oracle Cloud), the modernization path uses Oracle REST Data Services (ORDS) to expose EBS data and operations as REST APIs. ORDS sits on top of the Oracle database and exposes PL/SQL procedures, SQL queries, and table operations as RESTful endpoints. You can create custom ORDS modules that wrap Oracle's standard API packages in REST interfaces, then connect MAS 9 directly to those ORDS endpoints through App Connect or another middleware platform.

Here is an example of creating an ORDS module to expose Oracle EBS PO data to MAS 9:

-- Create ORDS module for PO data exchange with Maximo
BEGIN
  ORDS.DEFINE_MODULE(
    p_module_name    => 'maximo_po_sync',
    p_base_path      => '/maximo/po/',
    p_items_per_page => 100
  );

  -- Endpoint to retrieve approved POs for Maximo
  ORDS.DEFINE_TEMPLATE(
    p_module_name => 'maximo_po_sync',
    p_pattern     => 'approved/'
  );

  ORDS.DEFINE_HANDLER(
    p_module_name    => 'maximo_po_sync',
    p_pattern        => 'approved/',
    p_method         => 'GET',
    p_source_type    => ORDS.source_type_query,
    p_source         => 'SELECT po_header_id, segment1 as po_number, vendor_id,
                                creation_date, authorization_status,
                                type_lookup_code, comments
                         FROM po_headers_all
                         WHERE authorization_status = ''APPROVED''
                         AND creation_date >= SYSDATE - 1'
  );

  -- Endpoint for Maximo to post goods receipt
  ORDS.DEFINE_TEMPLATE(
    p_module_name => 'maximo_po_sync',
    p_pattern     => 'receipt/'
  );

  ORDS.DEFINE_HANDLER(
    p_module_name    => 'maximo_po_sync',
    p_pattern        => 'receipt/',
    p_method         => 'POST',
    p_source_type    => ORDS.source_type_plsql,
    p_source        => 'BEGIN
                          po_receipt_maximo_pkg.create_receipt(
                            p_po_number     => :po_number,
                            p_item_id       => :item_id,
                            p_quantity      => :quantity,
                            p_receipt_date  => :receipt_date
                          );
                        END;'
  );
END;
/

For Oracle Cloud ERP or Oracle Fusion, the path is simpler. Oracle Fusion provides REST APIs natively, which means the integration pattern looks identical to the SAP S/4HANA pattern:

MAS REST API → Middleware (App Connect) → Oracle Cloud REST API
Oracle Cloud REST API → Middleware → MAS REST API

Oracle's REST APIs are generally easier to work with than SAP's BAPI/RFC interfaces, which makes Oracle integrations somewhat simpler to implement on the MAS REST API. But the middleware requirement still holds. The complexity is in the business logic, not the transport protocol.

Migration Strategy: What to Keep, What to Rewrite, What to Retire

When migrating from Maximo 7.6 to MAS 9, you need to classify every existing integration into one of three buckets.

Keep as-is (for now): MIF-based integrations that are working well and not causing maintenance pain can remain on the MIF in MAS 9. The MIF is still supported for backward compatibility. You do not need to rewrite everything on day one. Prioritize based on business criticality and maintenance burden. A stable financial posting integration that has been running for five years without issues is a lower priority than a custom integration that breaks every patch cycle.

Rewrite for REST API: Any integration using RMI must be rewritten. RMI is deprecated and will be removed. Any integration using /maxrest/rest with basic auth should be rewritten to use the JSON API with API Key auth. Any integration that is difficult to maintain (complex automation scripts, custom Java exits, fragile point-to-point connections) is a candidate for rewrite. High-volume integrations benefit from the REST API's bulk operations and the lean=1 parameter for smaller payloads.

Retire and replace: JMS-based integrations should be evaluated for replacement with Kafka event streams. This is not urgent, but it is the direction IBM is moving. If you are building new integrations, use Kafka. If your JMS integrations are stable, they can continue running, but plan for eventual migration. Interface Table-based batch integrations should be evaluated for replacement with REST API bulk import.

The migration sequence should be:

1. Inventory all existing integrations and classify them by type, volume, and maintenance burden
2. Rewrite RMI integrations first (they will break when RMI is removed)
3. Move high-volume, high-frequency integrations to the REST API with bulk operations
4. Evaluate JMS-to-Kafka migration for event-driven integrations
5. Leave stable, low-maintenance MIF integrations for last
6. Document every integration with its new endpoint, authentication method, and error handling approach

Practical Implications

For integration developers, the shift to MAS 9 means learning new skills. JSON and REST are straightforward if you have any web development background. Kafka is more complex, particularly if you are used to JMS point-to-point messaging. The consumer group model, partitioning, and offset management require a different mental model. IBM App Connect is the recommended middleware for Maximo integrations, and it is worth investing in App Connect expertise if you do not have it in-house. The OSLC query syntax for filtering and selecting fields is powerful but has a learning curve. Practice with the API using tools like Postman before building production integrations.

For architects, the key decision is middleware strategy. You need a middleware layer between Maximo and every external system. The question is whether to standardize on IBM App Connect, SAP Integration Suite (for SAP integrations), or a general-purpose platform like MuleSoft or Apache Camel. The answer depends on your existing middleware investments and your integration team's skills. If you are an SAP shop, SAP Integration Suite is the natural choice for SAP integrations. If you have diverse integration targets, App Connect provides the broadest connector coverage for Maximo-specific patterns. Consider the total cost of ownership: middleware licenses, development time, maintenance overhead, and the availability of skills in your market.

For IT leaders, the budget conversation is important. MAS 9 migration is not just an application upgrade. It is an integration architecture transformation. Every custom integration needs to be evaluated, and many need to be rewritten. Budget for integration work, not just for the MAS license and infrastructure. A typical mid-size Maximo deployment with 15-20 integrations should plan for 6-12 months of integration migration work, with 2-3 integration developers dedicated to the effort. Larger deployments with 30+ integrations may need 12-18 months. The good news is that once the migration is complete, the new architecture is significantly easier to maintain, extend, and monitor.

Bottom Line

MAS 9's integration architecture is a clean break from the MIF era. JSON APIs, Kafka event streaming, and API Key authentication are the foundation. The MIF still works for backward compatibility, but it is a legacy layer. New integrations should use the REST API exclusively. RMI integrations must be rewritten. ERP integrations need middleware, regardless of whether you are connecting to SAP, Oracle, or any other system. The modernized SAP connector with CPI support makes SAP integration more future-proof, but the migration from PI/PO to CPI is a project that needs its own timeline. Plan your integration migration with the same rigor you plan your application upgrade, because the integration layer is where most migration projects stall.