For EAM / GIS Technical Leads

Another planning tool that wants a copy of your master data? No.

You've spent years getting functional locations, equipment records and GIS features to something like agreement. The last thing you need is a fourth system of record. AIPP is clean-core by architecture, not by brochure: released APIs, destination-based connectivity, and a federated mode where S/4 stays the master.

Technical deep-dive session →Architecture ↓

"Every vendor says 'seamless SAP integration'. Then you read the spec and it's a nightly CSV into their proprietary store, a custom RFC they want installed in the core, and a data model with no keys back to your functional locations. Six months later you own two registers that disagree."

— The integration review you've done a dozen times. Here's how ours reads differently.

The architecture, stated precisely

stackSAP CAP (Node.js) on BTP Cloud Foundry · SAP HANA Cloud (HDI) · SAPUI5 + Fiori Elements · standalone approuter. No core modifications. No RFCs. Nothing installed in your S/4.

apisConsumes released OData APIs only: API_FUNCTIONAL_LOCATION_SRV, API_EQUIPMENT, API_MEASUREMENTDOCUMENT, API_FIXEDASSET_MANAGEMENT, API_MAINTENANCEORDER — over the BTP Destination service with principal propagation. 13/13 on our automated clean-core conformance check.

data modesFederate or replicate — your call, per source. In federated mode S/4 master attributes are never stored: AIPP keeps only the key, its own condition inputs and its outputs, and composes master data live on read. Read the mode flag on every record.

modelAsset master + a JSON attribute document + flat computed KPI columns (score, DQ, RUL, value) — queryable by anything that speaks SQL or OData. External keys are yours: functional location, equipment ID or GIS asset ID.

gisWKT point geometry (EPSG:4326) on every located asset, a spatial hazard engine (bushfire/flood/coastal overlays, network single-point-of-failure), and an outbound Esri ArcGIS Feature Layer push with 4326→3857 transform for your existing maps.

securityXSUAA OAuth2, scoped roles, tenant row-level security, project/contract-level RLS, soft-delete only, change-log on every write, CSP/HSTS headers. Rate-limited OData. The audit interceptor writes field-level deltas.

degradationNo destination configured? The action returns a clean 424 with activation instructions and the product keeps working on uploaded data. If S/4 is unreachable, federated reads fall back to the stored link. Failure modes are designed, not discovered.

⚖

Straight answers to the questions you'll ask: SAP certification — ICC submission prepared, 13/13 technical conformance verified, certificate pending SAP's review. Write-back to S/4 — deliberately not in v1; AIPP reads, plans and exports, and delivery integration (PM/PS work order handoff) is on the published roadmap. Load ceiling — in-memory optimisation is guarded at 50k assets per scope; DB push-down beyond that is roadmap.

In the demo

What you'd actually inspect

connect

The federate switch

Connect / Load Data → Direct S/4 with the federate checkbox. Then read a federated record and verify the master attributes aren't persisted. Bring your own scepticism.

inspect

$metadata and the model

The full OData model is yours to walk — entities, keys, the flat KPI columns, the change-log. No black-box tables.

break it

Failure modes live

Point it at a missing destination, feed it dirty CSV, watch the 424s, the DQ flags and the auto-heal normalisation do their jobs.

Bring your integration checklist

A 60-minute technical session: architecture, data model, security posture, failure modes — with the product live, not slides.

Book the deep-dive →Read: SAP & the AIP market