Challenge
The same alarm fires every few minutes and floods SAP with notifications.
Agnotic approach
Open notifications are checked first, and repeat alarms update the existing one instead of creating another.
SAP PM Integration
SAP PM integration services
SAP PM is going live line by line, but alarms, inspection findings and logbook entries still reach it by retyping. Agnotic Technologies builds the interfaces that turn them into notifications, orders and measurement documents, and send completed work back to the systems that raised it.
Notifications and ordersMeasurement documentsLine-by-line rolloutInterface monitoring
Trusted by global innovators
What are SAP PM integration services?
SAP PM integration services connect the systems around maintenance work, such as condition monitoring, inspection apps, shift logbooks and planning tools, to SAP Plant Maintenance. Notifications, maintenance orders, confirmations and measurement documents then move both ways without retyping. Agnotic Technologies builds and tests these interfaces for your SAP release.
This page covers the interfaces around SAP PM. Configuring SAP PM itself usually sits with your SAP team or implementation partner, and we agree the interface contract with them.
Integration map
Which SAP PM objects does each system touch?
A sample map for one production line. Your SAP team confirms the notification types, order types and fields for each row.
| Source system | What it sends or receives | SAP PM object | Direction |
|---|---|---|---|
| Condition monitoring | A confirmed alarm with the asset, likely fault and evidence | Malfunction report notification (M2) | Into SAP |
| Condition monitoring | Trend values such as vibration or bearing temperature | Measurement documents on measuring points | Into SAP |
| Operator rounds and logbooks | Abnormalities found on a round | Maintenance request notification (M1) | Into SAP |
| Inspection apps | Completed inspections and their findings | Activity report (M3) and measurement documents | Into SAP |
| Planning and shutdown tools | Ranked jobs approved for a window | Maintenance orders and operations | Into SAP |
| Planning and shutdown tools | Order status, confirmations and history | Maintenance orders and history | Out of SAP |
| Technician mobile apps | Time, findings and parts used | Order confirmations | Into SAP |
Equipment and functional locations stay mastered in SAP. Every other system reads them from SAP rather than keeping its own copy.
Line-by-line rollout
How do we roll integrations out one line at a time?
The rollout follows your SAP PM go-live, so each line gets its interfaces when its master data is ready.
Master data check
Functional locations, equipment and measuring points for the line are checked against the assets each source system knows.
Mapping
Asset IDs, fault codes and priorities in each source system are mapped to their SAP PM equivalents and agreed with your SAP team.
Test system run
Interfaces run against your SAP quality system with real alarms, rounds and inspections from the line.
Parallel run
On the live line, interfaces run beside manual entry for an agreed period so planners can compare both.
Cut over
Manual entry stops for the line, and interface monitoring alerts the right people when a message fails.
Next line
The same mappings and tests are reused, and only the line's own assets and codes are added.
Notification types
Which notification type should each event create?
The standard SAP PM types. Many plants add their own; we map to whatever your configuration uses.
| Code | Name | Typical use |
|---|---|---|
| M1 | Maintenance request | Operator rounds, logbook abnormalities and requests where nothing has failed yet |
| M2 | Malfunction report | Confirmed condition monitoring alarms and breakdowns |
| M3 | Activity report | Inspections and work already done, recorded for history |
Failure points
What breaks SAP PM integrations?
The problems we test for before a line goes live.
Challenge
Asset names in the sensor system do not match SAP equipment numbers.
Agnotic approach
A mapping table owned by maintenance, with unmapped assets held in a queue instead of being dropped.
Challenge
Two systems change the same order at once.
Agnotic approach
Updates read the order's current version first and retry on conflict, so neither change is lost silently.
Challenge
A failed message goes unnoticed for days.
Agnotic approach
Every message is logged with its status, and failures alert the interface owner.
Challenge
Integration users have more SAP authorization than they need.
Agnotic approach
One technical user per interface, limited to the objects and actions that interface uses.
What do we build for SAP PM integration?
The interfaces and the tools to run them.
Notification interfaces
Alarms, rounds and inspection findings created as SAP PM notifications with the right type, priority and object.
Order interfaces
Orders and operations created or updated from planning tools, and status sent back out.
Measurement document feeds
Readings from sensors and inspections posted to the right measuring points.
Asset and code mapping
Maintained mappings between source systems and SAP equipment, functional locations and catalog codes.
Interface monitoring
A log of every message with its status, retries and alerts for failures.
Access and security
Least-privilege technical users and encrypted connections between your network and SAP.
Notification text assist
Draft notification text from alarms and technician notes, for a planner to check before it is sent.
Middleware fit
Built on the integration layer you already run, or a small service where there is none.
Standards
Which protocols and standards do we work with?
OData V2IDoc and RFCOPC UAMQTTISA-95
Facts and sources
Facts from SAP documentation
The SAP PM objects and APIs these interfaces use, each linked to SAP's own documentation.
In SAP S/4HANA, the standard maintenance notification types are M1 for a maintenance request, M2 for a malfunction report and M3 for an activity report, each tied to a notification origin in the maintenance notification category. Companies can also define their own types in Customizing.
Source: SAP Help Portal, SAP S/4HANA: Notification TypeSAP Plant Maintenance uses the maintenance notification to describe the condition of a technical object or report a malfunction, the maintenance order to plan the work in detail, track progress and settle costs, and the maintenance history to keep the data once a notification is technically completed.
Source: SAP Help Portal, Maintenance Notifications (PM-WOC-MN)In SAP Plant Maintenance, conditions such as temperature, pressure or revolutions are recorded at measuring points as measurement readings, consumption or wear is recorded at counters as counter readings, and both are entered in the system as measurement documents.
Source: SAP Help Portal, Entering Measurement DocumentsSAP's Maintenance Order (Version 2) service, API_MAINTENANCEORDER_0002, creates, reads, updates and deletes maintenance order data over OData V2. Its predecessor, API_MaintenanceOrder, was deprecated with SAP S/4HANA Cloud 2308.
Source: SAP Help Portal, Maintenance Order (Version 2) and Maintenance Order (Deprecated)
Scope
What decides the size of an SAP PM integration?
We do not publish prices. These are the drivers we price on the scoping call.
SAP release
SAP ECC or SAP S/4HANA, on-premise or cloud, and the interfaces your release allows.
Source systems
How many systems send or receive data, and whether they have APIs.
Lines and assets
How many lines and assets, and how clean their master data is.
Direction
Into SAP only, or completed work sent back to the source systems too.
Middleware
Whether an integration platform already exists that we build on.
Testing access
Access to an SAP quality system with realistic data for testing.
Engagement
How does an SAP PM integration project run?
We start with the line going live next.
1.
Scoping call
We review your SAP PM rollout plan, the systems around maintenance and how data reaches SAP today.
Scope2.
First line
A fixed-scope first release: the agreed interfaces for one line, tested in your quality system and run in parallel.
Build3.
Remaining lines
The same interfaces extended line by line as SAP PM goes live, with support after launch.
ScaleWho it is for
Who needs SAP PM integration?
Plants where SAP PM is the system of record but not where maintenance data starts.
Plants rolling out SAP PM
Integrations timed to each line's go-live, instead of a big bang at the end.
Reliability teams with condition monitoring
Confirmed alarms and trend data in SAP, where planners already work.
Operations with paper rounds
Rounds and logbooks moved to apps whose findings land in SAP as notifications.
Shutdown and turnaround planners
Approved job lists turned into orders, with completion data coming back.
Frequently Asked Questions
Usually your SAP team or implementation partner. We build the systems and interfaces around SAP PM and agree the interface contract with them, so changes on either side are planned together.
Yes. A confirmed alarm can create a malfunction report notification with the equipment, likely fault and evidence attached, and repeat alarms update the open notification instead of creating new ones.
Yes. The interface technology differs by release, so we confirm what your system offers, such as OData services, IDocs or RFC, on the scoping call.
Yes, for readings that belong in maintenance history. High-frequency raw data stays in the monitoring system, and summarized values are posted to the right measuring points.
Yes. That is how we prefer to work: each line gets its interfaces once its master data is ready, and later lines reuse the same mappings and tests.
We do not publish prices. Your SAP release, the number of source systems, lines and assets, data direction and middleware decide the size, and we agree a fixed first release on the scoping call.