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, class-level detail (Java class/method, 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.

Two evidence tiers, stated plainly

Every step carries a tier. Verified means the step was confirmed in a direct bytecode trace of Maximo's own classes this session — done separately for 9.0, 9.1, 9.2 and 9.3, all four agreeing on the same call order and branch structure for the outbound save path. Documented means standard, version-correct MIF/Object-Structure/Enterprise-Service architecture that was not independently re-traced in bytecode this session — this covers 7.6.1.3 and 8.x on the outbound path (only the 7.6.1.1 interim-fix jar was actually checked, not .3 itself, so .3 stays documented on direct-evidence-only grounds) and every inbound step on every release. Nothing here blurs the two.

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

  1. 1. The save registers, nothing happens yet — verified

    You save a work order and Maximo puts the change on the current transaction. Nothing is written to the database yet, and nothing has been told about it.

  2. 2. Pre-save checks run — verified

    Maximo validates the record and runs its "before save" logic first — the checks and automation that can still change or block it, before the database sees anything.

  3. 3. The row is written, but not committed — verified

    The database write happens now, inside a transaction that is still open — a failure downstream still rolls this back.

  4. 4. Post-save listeners fire — verified

    With the row written (still uncommitted), Maximo fires its post-save listeners. One of them decides whether this change gets published at all.

  5. 5. The publish filter decides: does this go anywhere? — verified

    Maximo checks the raw record against the Publish Channel's filter condition before building anything. Fail the condition and publishing stops here — no message gets built.

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

    A status the filter was not built to publish stops everything right there. No partial message, no empty JMS envelope — the publish path is never entered.

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

    The record becomes a structured message, then runs through processing rules, user exits, and an optional XSL transform, so it lands in the External System's shape, not Maximo's internal one.

  8. 7. The message is staged, not sent — verified

    The outgoing message is set aside at the same point in the save where the row was written. It has not left Maximo yet. On 9.1 it lands on 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 message goes out when the save commits — verified

    The message ships only once the database transaction commits, same moment as the row itself, so the two can never disagree. A per-record flag (queue_commit_on_save) can break that link and send it on its own commit instead.

  10. 9. The External System receives it — verified

    The message lands on the queue or topic the External System listens on, on the same thread as the save that triggered it — no background worker involved. Auth on 9.1 is API-key-only; maxauth was retired from the integration path.

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.