Transport state in compliance checks
Compliance checks are built in Acceptance to Run → Checks using the same rule builder you use for any other property. Transport properties show up in the left field picker once the agent has reported them for at least one host in your fleet. Useful patterns include:- Import queue should not pile up. A check that queue depth is below a threshold (e.g.,
import_queue_depth < 20) flags systems where transports are accumulating without being applied. - No outstanding failed imports. A check that the count of error-status transports equals zero (
failed_imports == 0) catches systems carrying unresolved import failures. - Last import succeeded. A check that the most recent import status is
success(last_import_status == "success") catches systems whose latest change broke and was never followed up. - Recent activity on production. A check that production has had no transport imports outside a maintenance window can serve as a basic change-control signal.
Filtering and grouping by transport state
The same properties are available in host group filters. Common groupings:- “Systems with a pending import” — filter on
import_queue_depth > 0. - “Systems with import errors” — filter on
failed_imports > 0. - “Quiet production” — production systems where no transport has been imported in N days.
How transport state interacts with security notes
SAP Security Notes are matched to hosts using the installed SAP components — not the transport state directly. Transport activity is still relevant during incident response in two ways:- Distinguishing applied vs queued fixes. If a security note has a recommended SAP Note (transport) and you’ve imported it, the underlying component version on the host should now reflect the fix. If a security note keeps recurring after import, that’s evidence the import failed or only partially applied.
- Correlating recent changes with new findings. If a host starts failing checks shortly after a transport import on it, the transport is a candidate root cause. The host detail page shows transport history alongside other properties for this reason.
A worked example
Suppose your QA team imports a transport that touches a custom authorization object onQAS01. A few hours later, a compliance check that validates a specific config value fails on QAS01. The host detail page shows:
- The failing check (with the expected vs actual value).
- A new transport imported in the recent activity window.
- The transport’s return code.
Limitations
A few things Luumen does not do today:- No automated import action. The agent reads transport state but does not import, release, or rollback transports.
- No tight coupling between a transport and a check failure. Luumen surfaces both on the same host timeline, but doesn’t infer causation.
- Default properties only. The properties listed in SAP transports overview are what the agent collects out of the box. If your team relies on additional transport-related signals (e.g., a custom CTS table, transport buffer content), reach out to your account team to discuss adding them as part of white-glove setup.