SAP transport auto-sync — and why drift is recorded, not blocked
How a SAP transport request becomes a change in TENSOR, what the auto-create switch does, and why TENSOR records a mismatch instead of stopping SAP.
When the SAP connector agent reports a transport request, TENSOR turns it into a change record and keeps that record in step with the transport as it moves through your landscape. You configure this on the Transports page of the SAP settings (/settings/sap/transports), which is not yet linked in navigation — open it by its address.
What happens to a new transport
A transport request first seen in a development system becomes a normal change, automatically. Three things decide whether that happens:
- The system is known. TENSOR reads the system's role — development, QA, production — from its configuration item in the CMDB, which the connector agent populates when it reports inventory. A system that has never reported inventory has no role, so nothing is created for it.
- The system is a development system. A transport observed in QA or production is not the transport's origin, so it never creates a change.
- Auto-create is on. This is the one switch on the page. It is on by default.
The new change is credited to the platform user mapped to the SAP transport owner. If that SAP account is not mapped to anyone, the change is credited to the platform's system actor and the audit record says so explicitly — TENSOR never guesses a person.
What happens as the transport moves
Release and import events keep the change record current: the release timestamp, the QA import, the production import. Importing to production closes the change and writes a sealing entry into the tamper-evident audit log.
Position tracking is not affected by the auto-create switch. A transport that has already moved in SAP is a fact; refusing to record it would only make TENSOR quietly wrong.
Why drift is recorded instead of blocked
TENSOR reads from SAP; it does not write back. It therefore cannot stop a transport from being released or imported — and pretending otherwise would be worse than admitting it. So when SAP moves further than the change record allowed, TENSOR ingests the event anyway and records the gap:
- Released before the change was approved. The transport left the development system before your approval gate ran.
- Imported without a linked change. An import arrived for a transport TENSOR holds no change record for.
- Imported to production while the change was still open. The transport is live in production and the change record is not closed.
- Position update refused by the separation-of-duties rule. The change's developer is also one of its approvers, so the BAIT §7/§8 rule blocked the update. The rule is not relaxed for automated updates.
Each of these appears in three places: the drift list on the Transports page (/settings/sap/transports), a warning on the affected change, and the integration health timeline. Every one is also an audit entry, so the gap is evidence rather than a footnote.
Who can do this
Reading the setting and the drift list needs the integration read permission; changing the switch needs the integration manage permission. The whole surface is behind the SAP integration capability toggle — with it off, none of it is reachable or visible.