Reference · built on requestConnectorField service & CMMS

IBM Maximo Manage

Work orders, assets, locations, inventory, and purchase orders from IBM Maximo Manage through its object structure APIs.

Request accessPricing ↗

About

IBM Maximo Manage is the enterprise asset management application in IBM Maximo Application Suite. Its APIs, rooted at /oslc or /api, expose business objects through object structures such as mxapiwodetail, mxapiasset, and mxapipo as JSON, sharing a code base with the OSLC APIs used by Maximo mobile clients. Queries select attributes with dot notation, filter with oslc.where, sort with oslc.orderBy, and page with oslc.pageSize.

An operator on Fibric reads work orders, assets, and inventory, then proposes a new work order or a status change through an action such as wsmethod:changeStatus, for your approval and with a receipt.

This is a reference listing. It documents what Fibric would read from IBM Maximo Manage and what it could propose, based on the vendor's published interfaces. Fibric builds it under a managed deployment when you request it; selecting it here installs nothing.

Inputs

  • Work orders through mxapiwodetail, with child objects such as INVRESERVE reservations and related asset attributes
  • Assets through mxapiasset, with location, status, and open work order relations
  • Purchase orders through mxapipo, with vendor details from the companies object
  • Any object structure's JSON schema from /oslc/jsonschemas/{objectstructure}, or inline with addschema=1
  • Saved queries, for example a list of approved work orders, and distinct or grouped result sets
  • The actions a record allows, read with oslc.select=allowedactions

Proposed actions

  • Target capability: propose creating a work order or asset record with POST on its object structure
  • Target capability: propose a status change through POST ...?action=wsmethod:changeStatus with x-method-override: PATCH
  • Target capability: propose a field update through PATCH, with a transactionid header so a retried request is not applied twice
  • Target capability: propose starting a workflow on a record through action=workflow:{workflowName}

Proposed actions are target capabilities. Every action runs propose-first and needs a validated deployment and the appropriate permissions.

What you can build

  • Rank the backlog by asset criticality

    Read open work orders with their asset and location attributes, and propose a priority order the planner can accept in one pass.

    With Backlog Priority, Work Order Aging

  • Open a work order from a sensor fault

    When a connected asset trips, read its mxapiasset record and open work, then propose a new work order against it.

    With Predictive Maintenance

  • Reserve and reorder spares

    Read INVRESERVE reservations on planned work and propose a purchase order draft when reserved quantity exceeds stock.

    With Spares Reorder, Purchase Order Draft

  • Keep calibration work orders on schedule

    Query work orders by status and scheduled date with oslc.where and propose status changes for overdue calibration jobs.

    With Calibration Due

Requirements

  • A Maximo Manage instance reachable at its /oslc or /api root
  • A Maximo user whose security groups cover the object structures the operator reads and writes; the key acts as that user
  • One API key for that user, since each user may hold only one
  • The wsmethod, script, or workflow actions enabled on the object structures you plan to call
Authentication
An API key sent in the apikey request header, created with POST /oslc/apitoken/create or by an administrator through /oslc/os/mxapiapikey; native, LDAP, BASIC, and FORM authentication also apply.

Limits

  • Page size is capped by mxe.oslc.maxpagesize, or per object structure by mxe.oslc.{objectstructure}.maxpagesize
  • Stable paging (stablepaging=1) holds a server-side set that expires after five idle minutes and cannot page backward
  • Sorting applies only to persistent attributes of the main object, not related objects
  • Overloaded web methods cannot be called as actions

Access and pricing

Reference listing. Fibric builds the connector under a managed deployment when you request it. Your quote covers the build, capabilities, usage, and support.

Request IBM Maximo Manage ↗

Questions and answers

How do filters and sorting work?
oslc.where takes comparisons such as status="APPR", priority>=1, and location in ["A","B"], with % wildcards and "*" for not-null checks. oslc.orderBy lists attributes prefixed + or -; there is no default order. lean=1 returns JSON without namespaces.
How are API keys managed?
A user creates a key with POST /oslc/apitoken/create, passing an expiration where -1 never expires. An administrator creates keys for others through POST /oslc/os/mxapiapikey. Keys create no MAXSESSION entries and need no logout. They are encrypted by default in Maximo 7.6.12 and later.
How is a status change invoked?
POST to the record's URI with ?action=wsmethod:changeStatus and the header x-method-override: PATCH. Scripted actions use action={scriptName} and workflows action=workflow:{workflowName}. Add a properties header to receive the changed resource in the response.
Ask about IBM Maximo Manage

Ask about the capabilities and requirements in this listing.

For project-specific requirements, contact Fibric.

This connector listing is developed, published, and supported by Fibric. It describes integration with IBM Maximo Manage through published interfaces. Third-party names and logos identify the systems an integration connects to; they are the property of their respective owners, who are not affiliated with Fibric and do not sponsor or endorse this listing. Trademark policy