RFID and RTLS reads are not business transactions. Middleware filters raw reads into de-duplicated, direction-aware events, maps tag identifiers to the ERP asset or material key, and posts them as goods movements in SAP or Odoo, asset and location updates in Oracle, or work orders and asset custody in IBM Maximo. Every call carries an idempotency key so a repeated read never creates a second document.
Swedish Technology builds the middleware and the ERP interfaces as custom development, with a written interface contract, replay-safe messages and full event logging on both sides.
What problem does this solve?
The hardware side of an RFID project usually finishes on time. The integration is where the schedule goes. A single pallet passing a dock door produces dozens or hundreds of reads per tag; the ERP expects one goods movement. A tool that sits within range of a reader for a whole shift produces a read every second; Maximo expects a location change only when the location actually changes. Feeding raw reads into an ERP is the fastest way to generate thousands of erroneous documents and lose the confidence of the finance and operations teams.
The second issue is identity. RFID tags carry an EPC or a serial number; SAP works with material and equipment numbers, Odoo with product, lot and serial records, Maximo with asset numbers and locations, Oracle with item and asset identifiers. Someone has to own the mapping table, decide what happens when a tag is read that nobody has registered, and handle re-tagging when a damaged label is replaced. Projects that leave this to "the ERP team" discover it three weeks before go-live.
The third issue is direction and truth. If both systems can change the same field, they will eventually disagree. Which system owns the location of an asset — the RTLS, or the ERP where a technician typed it in? Which one owns stock quantity? Without a written statement of the master for each field, the interface becomes a loop where two systems overwrite each other, and reconciliation reports become a permanent job.
How the solution works
Put a middleware layer between the readers and the enterprise systems, and give it three jobs: reduce reads to events, translate identities, and guarantee that each event produces at most one document. Reduction means a de-duplication window per tag and read point, an RSSI or read-count threshold, direction logic at gates, and a state machine that only emits an event when a tag changes state — entered a zone, left a zone, arrived at a gate, was issued to a person. Translation means a tag-binding table that maps EPC to the enterprise key, with an explicit rule for unknown tags. Guarantee means an idempotency key on every outbound call, plus a persistent queue with retry, dead-letter handling and replay.
On top of that, write an interface contract for each system: which business events are sent, which document or update they create, in which direction each field is mastered, the error behaviour, and the reconciliation report that proves the two sides still agree. Swedish Technology implements this as custom development against each vendor's documented interfaces — SAP OData and IDoc/BAPI-based interfaces, Oracle REST services, the Odoo external API and Maximo REST/OSLC — and hands over the source, the mapping tables and the runbook.
- 1Input — raw reads Fixed readers, handhelds and RTLS anchors emit tag reads with reader ID, antenna, timestamp and signal strength, over LLRP, MQTT or the vendor's API, into the middleware's ingestion queue.
- 2Capture — filter and reduce Per tag and read point, apply a de-duplication window (typically 2–30 seconds), a minimum read count or RSSI threshold, and antenna-sequence or sensor-based direction logic. A tag parked in range produces one event, not thousands.
- 3Processing — resolve identity Look up the tag binding: EPC or tag ID to material, batch, serial, equipment or asset number. Unknown tags go to an exception queue with a workflow, never into the ERP as a guess.
- 4Processing — derive the business event A state machine turns location changes into business meaning: goods received at dock 3, pallet dispatched on delivery 8001, tool issued to badge 442, asset left authorised zone. Each event gets a deterministic idempotency key from read point, identity and business window.
- 5Integration — post to the enterprise system The event is posted through the target system's documented interface: SAP goods movement or equipment update, Oracle inventory transaction or asset attribute, Odoo stock move via the external API, Maximo asset location or work order. Failures go to a retry queue and then a dead-letter queue with an alert.
- 6Action — close the loop The enterprise system's response (document number, work order ID, error) is written back to the event record, so an operator can see the outcome of every read on the shop-floor screen, and exceptions get a human owner.
- 7Reporting — reconcile A scheduled reconciliation compares middleware events with posted documents and with the ERP stock or asset state, producing a difference report per day, per read point and per asset family — the evidence that the interface is healthy.
Reference architecture
Five layers, with a hard boundary between operational read data and enterprise transactions. The boundary is what keeps ERP data clean when hardware misbehaves.
| Layer | What it contains |
|---|---|
| Device layer | Fixed readers (LLRP or vendor API), handhelds with an app or web client, BLE gateways and UWB anchors. Devices are managed, monitored and time-synchronised; a reader that stops reading must raise an alarm, not silently produce zero events. |
| Ingestion & filtering | A message broker (MQTT or a queue) plus a stream processor implementing de-duplication windows, thresholds, direction logic and zone state. Raw reads are retained locally for a defined period for troubleshooting and audit. |
| Identity & master data | Tag-binding table (tag ID to enterprise key), location map (read point to plant, storage location, site or Maximo location), and cached master data replicated from the enterprise systems on a schedule. |
| Business event & integration layer | Event model, idempotency store, per-system adapters, retry and dead-letter queues, and the outbound calls to SAP, Oracle, Odoo and Maximo with credentials held in a vault. |
| Operations & exception UI | Screens for supervisors: today's events, failed postings, unknown tags, reader health, and the reconciliation report. Most day-two effort lives here, and it is what keeps the system trusted. |
| Enterprise systems | SAP MM/EWM/PM, Oracle E-Business Suite or Fusion, Odoo Inventory/Maintenance, IBM Maximo — each receiving only the documents and updates defined in its interface contract. |
Deployment options: The middleware runs on-premise next to the readers so that a WAN outage does not stop the plant; events queue locally and drain when the enterprise system returns. Cloud-hosted ERPs are reached through an outbound-only connection. Air-gapped sites run the full stack internally with a file-based or manual export where an enterprise system sits outside the enclave.
Key capabilities
Read-to-event filtering
The ERP receives a handful of meaningful events instead of thousands of reads, so documents stay correct and auditable.
custom developmentIdempotent posting
A repeated read, a retry after a timeout or a replay after an outage never creates a second goods movement or work order.
custom developmentTag binding and master-data sync
Tags map to the right material, serial, equipment or asset number, and new master data appears automatically.
custom developmentSAP goods movements and equipment updates
Receiving, transfer and dispatch postings happen from the gate read, with the document number visible to the operator.
custom developmentMaximo asset location, custody and work orders
Asset records show last-seen location and holder; exceptions raise a work order automatically.
custom developmentOdoo stock moves and cycle counts
Inventory adjustments and lot/serial movements posted through the external API without manual entry.
custom developmentOracle asset and inventory transactions
Asset register attributes and inventory transactions updated from tracking events in EBS or Fusion.
custom developmentReconciliation and exception dashboard
A daily report proving that reads, events and posted documents still agree, with a queue for the ones that do not.
custom developmentIntegrations
Direction of sync is decided field by field, not system by system. The table below shows the pattern we implement most often; the interface contract records the exact mastering rules for your landscape.
| System | Integration point & data exchanged | Direction |
|---|---|---|
| SAP MM / EWM | Inbound: material, batch, serial and storage-location master data. Outbound: goods receipts, transfer postings, dispatch confirmations and physical-inventory counts from filtered gate and handheld events, via OData services or IDoc/BAPI-based interfaces. | bi-directional |
| SAP PM / S/4HANA asset management | Inbound: equipment and functional-location master data. Outbound: equipment location and status changes, plus notifications when tracked equipment leaves an authorised area. | bi-directional |
| Oracle E-Business Suite / Fusion | Inbound: item, subinventory, locator and asset master data. Outbound: inventory transactions and asset attribute updates through Oracle's documented REST/integration services. | bi-directional |
| Odoo Inventory / Maintenance | Inbound: products, lots/serials and locations. Outbound: stock moves, inventory adjustments and maintenance requests created through the Odoo external API (XML-RPC/JSON-RPC). | bi-directional |
| IBM Maximo | Inbound: asset, location and person master data. Outbound: asset last-seen location, custody, condition-triggered work orders and inspection confirmations via Maximo REST/OSLC APIs. | bi-directional |
| RTLS and WMS platforms | MOWQIE supplies zone and geofence events; Octopus WMS receives receiving/dispatch confirmations, so warehouse execution and the ERP stay aligned. → MOWQIE ÔÇô RTLS Tracking | bi-directional |
Industry use cases
Distribution & 3PL
Dock-door reads create SAP or Odoo goods movements automatically, and the operator screen shows the posted document number before the truck leaves.
Utilities & heavy industry
Tool and instrument custody tracked into Maximo: issue, return, calibration due and an automatic work order when an asset leaves the plant boundary.
Government asset registers
Annual inventory performed with handhelds, posting count results and location changes into Oracle EBS or a custom register, with a signed variance report.
Manufacturing
Work-in-progress movements between cells recorded from zone events and posted as confirmations, replacing manual scanning at each station.
Defence and secure sites
Air-gapped middleware holding all reads locally, with controlled export of a movement summary into the enterprise system on a defined schedule.
UAE & GCC considerations
Most UAE and GCC organisations run a mixed landscape: SAP or Oracle at group level, Odoo or a local system in a subsidiary, and Maximo in operations. Government entities usually require the middleware and its raw-read store to remain on-premise or in a UAE-region private cloud even when the ERP is a vendor cloud, so the integration is designed as outbound-only from a local component, and event data does not leave the country. Arabic and English operator screens are standard, bilingual documentation is normally part of the hand-over, and procurement expects the interface specification and source code as deliverables. Swedish Technology performs this work as custom development and integration engineering; it is not an official partnership with SAP, Oracle, Odoo or IBM.
Implementation approach
- 1Integration workshop (1 day) List the business events, the documents each must create, the systems in scope and the reconciliation the business needs. Anything that does not create or change a document is reporting, and stays in the middleware.
- 2Interface contract per system Fields, directions, mastering rules, identifiers, error codes, retry policy, idempotency key definition and volumes. Signed by both the ERP owner and operations.
- 3Master data and tag-binding design How tags are bound to enterprise keys, who binds them, what happens with unknown tags, and how re-tagging and disposal are recorded.
- 4Middleware build Ingestion, filtering, state machine, event model, idempotency store, adapters, dead-letter handling and the exception UI.
- 5Test with a copy of production data Replay recorded read streams into a test ERP client; verify documents, duplicates, out-of-order events, and behaviour when the ERP is unavailable for hours.
- 6Pilot on one process One read point and one document type in production, running in parallel with the manual process and reconciled daily until the difference is stable.
- 7Rollout Add read points and document types one at a time; each addition repeats the reconciliation period before the manual process is retired.
- 8Hand-over and runbook Source code, interface contracts, mapping tables, monitoring dashboards, dead-letter procedures, replay instructions and training for the support team.
Security & deployment
Enterprise credentials live only in the middleware, in a secret store, never on a reader or a handheld. Each target system gets its own service account with least privilege — permission to post the specific document types in scope and nothing else — and every outbound call is logged with the event ID, idempotency key, response and document number. The middleware sits on a segmented network with outbound-only access to the ERP; readers cannot reach the ERP directly. Raw read data is retained for a defined troubleshooting period and then aggregated or deleted, because it reveals stock levels and movement patterns. For classified sites the whole chain runs on-premise or air-gapped, with controlled export.
Limitations & prerequisites
- The ERP defines what is possible: if SAP or Maximo has no field for last-seen location or no suitable movement type, that has to be configured by the ERP team before the interface can use it.
- Idempotency depends on a stable business key; if the same pallet legitimately passes the same gate twice in one shift, the business window must be defined carefully or a real movement will be suppressed.
- Cloud ERPs impose API rate limits and quotas; high-volume read points may need batching, and burst behaviour must be tested before go-live.
- Odoo's external API and Maximo's REST endpoints change between major versions, so upgrades require regression testing of the interface.
- Two-way mastering of the same field is not supported by design; each field must have exactly one owning system, and that decision is organisational, not technical.
- The interface cannot fix bad master data — duplicate materials, missing asset numbers or unregistered tags surface as exceptions rather than being silently corrected.
- Reconciliation reports need an owner. Without someone reviewing exceptions daily in the first months, small drifts accumulate into a loss of trust in the data.
Where to put the logic: reader, middleware or ERP
The same filtering can technically be done in three places. Only one of them survives contact with production.
| Concern | Reader / edge only | Middleware layer | Inside the ERP |
|---|---|---|---|
| De-duplication of reads | Basic, per reader, vendor-specific | Full control, per tag and read point | Possible but expensive in ERP resources |
| Direction logic at gates | Limited to antenna sequence | Combines antennas, sensors and zone state | Not practical |
| Identity mapping | Not available | Central tag-binding table with exceptions | Possible, but couples ERP to hardware IDs |
| Idempotency and retry | None | Idempotency store, queue, dead letter, replay | Depends on the interface technology |
| Behaviour during ERP outage | Reads are lost | Events queue locally and drain later | n/a |
| Change of hardware vendor | Rewrite required | Adapter change only | Rewrite required |
| Where errors are visible | Reader logs | Exception UI with business context | ERP error logs, hard for operations to read |
Edge filtering reduces traffic, and the ERP owns the document. Everything between those two — identity, direction, idempotency, retry and exceptions — belongs in the middleware.
FAQ
Technically an interface can be called from a reader or a small script, but it fails in practice: no de-duplication, no direction logic, no retry when SAP is unavailable, and no way to prevent a duplicate document. Even a lightweight middleware component with a queue and an idempotency store removes most of the operational risk.
Each business event carries a deterministic idempotency key derived from read point, identity and business window. The middleware stores the key with the resulting document number; if the same key appears again — from a repeated read, a timeout retry or a replay after an outage — the original document number is returned instead of posting again.
Master data (materials, serials, assets, locations, people) flows from the enterprise system to the middleware. Observations (movements, locations, counts, custody) flow from the middleware to the enterprise system. Fields that both sides could write are assigned a single owner in the interface contract; there is no safe way to master the same field twice.
Events queue locally with their idempotency keys and drain automatically when the system returns, in order. Operators keep working, and the shop-floor screen shows pending rather than confirmed until the document number comes back. Extended outages raise an alert with the queue depth.
The number of distinct business events and document types, the number of target systems, whether the ERP needs configuration changes, the volume and burst profile, the exception-handling UI, and the depth of testing and reconciliation required. Two document types into one system is a few weeks; a multi-system landscape with master-data sync and an exception console is several months.
No specific version, but you need documented API access and the right functional setup: movement types and storage locations in SAP, item and locator setup in Oracle, the Inventory app and external API access in Odoo, and asset, location and work-order objects in Maximo. We confirm this in the workshop before estimating.
Yes. The middleware is designed to run next to the readers on-premise; for cloud ERPs it uses an outbound-only connection. In air-gapped environments the middleware holds all events internally and exports a controlled summary on a defined schedule.
A daily reconciliation compares reads, derived events and posted documents, plus a periodic physical count for the assets or stock in scope. The report shows differences per read point and per asset family, so a drift is visible within a day rather than at year-end.
You do. Source code, interface contracts, mapping tables, deployment scripts and the runbook are handed over, with training for your integration team. Swedish Technology performs this as custom development and integration engineering; there is no certified partnership with SAP, Oracle, Odoo or IBM implied.
Reads on one side, documents on the other — the hard part is between them
Send us the systems in scope, the documents you want created and a sample of raw reads. In a one-day workshop we produce the event model, the interface contract per system, the idempotency and error-handling rules, and an effort estimate.
Request an Integration WorkshopRFID Asset Management System
Swedish Technology supplies the complete RFID stack — UHF tags, handheld and fixed readers, gates, antennas, printers and the asset management platform — with the integration and RF engineering behind it.
Request RFID Solution PricingSources & evidence
- GS1 — EPCIS and Core Business Vocabulary — standard event model for what, when, where, why
- SAP Help Portal — product documentation — OData services, IDoc and BAPI interfaces per module
- Oracle — Cloud Applications documentation — REST APIs for inventory and asset objects
- Odoo — External API documentation — XML-RPC/JSON-RPC access to models
- IBM — Maximo Manage documentation — REST/OSLC integration objects and automation scripts
Vendor and product names are trademarks of their respective owners; references are for technical context and do not imply partnership, certification or endorsement unless stated on the vendor's official pages.