Assetize

Integration Flow Explorer

See exactly what happens when a record leaves — or enters — Maximo.

Step through a real Publish Channel or Enterprise Service flow, stage by stage, across every release from 7.6.1.3 to 9.3 — plain language first, configuration detail (the application, the payload at each stage, auth, queue/topic) on request.

Two scenarios, six releases

Outbound — a WORKORDER save reaches a Publish Channel and goes out to an External System. Inbound — an External System calls in through an Enterprise Service and lands as a saved Mbo. Both scenarios run across 7.6.1.3, 8.x (8.9–8.11), 9.0, 9.1, 9.2 and 9.3, and the auth model, transport and platform notes change per version: maxauth integration users and JMS-only on 7.6.1.3, a transitional mix on 8.x as MAS is adopted, API-key-only auth with JMS and Kafka/Event Streams both available from 9.0 onward.

Where every step comes from

Every step is documented: standard, version-correct integration-framework architecture (Publish Channels, event filters, processing rules, user exits, XSL maps, queues and endpoint handlers) from IBM's published documentation. Nothing on this page is derived from IBM's compiled code.

Outbound, MAS 9.1 — a WORKORDER save, step by step

  1. 1. The work order is saved — documented

    You save a work order, from the UI, an automation script or an API call. Every route goes through the same business-object save.

  2. 2. Validation and before-save logic run — documented

    Maximo validates the record and runs its before-save logic, including any automation scripts on a save launch point. Any of these can still change or block the save.

  3. 3. The record is written — documented

    The change is written to the database as part of the save transaction.

  4. 4. The Publish Channel hears the event — documented

    A Publish Channel with its event listener enabled is told about the change. If the listener is off, nothing is published.

  5. 5. The event filter decides: does this go anywhere? — documented

    The channel's event filter and processing rules decide whether this change is worth publishing. If they skip it, publishing stops here and no message is built.

  6. 5a. When the filter says stop — documented

    A status the filter was not set up to publish stops the publish there. No message is built and nothing reaches the queue.

  7. 6. The message is built and shaped for the receiver — documented

    The record becomes an Object Structure message, then runs through processing rules, a user exit class and an optional XSL map, so it lands in the External System's shape, not Maximo's.

  8. 7. The message is written to the outbound queue — documented

    The message goes onto the External System's outbound queue. It has not left Maximo yet. On 9.1 that is JMS queue MEAOUTQUEUE, or a Kafka topic (mas.manage.workorder.publish, keyed on WONUM) if the External System is Event Streams-backed.

  9. 8. The External System receives it — documented

    A queue consumer picks the message up and the External System's endpoint handler delivers it: HTTP, web service, JMS, a flat file or another handler you configure. Auth on 9.1 is API-key-only.

Inbound, MAS 9.1 — an External System calling in

  1. 1. The External System calls in — documented

    An outside system calls Maximo's integration endpoint (/maximo/oslc/os/mxwo) to create or update a record, authenticating with an API key on 9.1.

  2. 2. The Enterprise Service takes the request — documented

    Maximo confirms the request names a real Enterprise Service and a real action, then hands the payload off to be interpreted.

  3. 3. Fields are mapped onto Maximo's data model — documented

    The incoming field names get matched to Maximo's attribute names and reshaped from the External System's naming to Maximo's, per the Object Structure's field map.

  4. 4. Inbound processing rules and user exits run — documented

    Any extra business logic configured for inbound messages on this Object Structure gets a chance to adjust or reject the record before it saves.

  5. 5. The record is saved — documented

    The mapped, validated data is written to the database through the same save path as a save made from inside Maximo's own UI.

  6. 6. The transaction commits — documented

    The save completes without errors and the change becomes permanent.

  7. 7. Maximo replies — documented

    The caller learns whether it worked — a response on the same call for synchronous REST, an acknowledgement message for an asynchronous queue or topic call.