Integration

Interfaces break silently. A field added to an IDoc is never distributed because no change pointer is written for it; a consumer calls an API version that is deprecated in the next release.

• Change Pointer Coverage Auditor

  BD21/BD52 change pointer config & event trigger validation

  CHANGE_POINTER_COVERAGE_AUDITOR

• API Change Guard

  OData, SOAP, RFC compatibility & deprecation impact scanner

  API_CHANGE_GUARD

• Fields required by receivers but not covered by change pointer configuration
• Message types without active change pointers or processing
• Use of deprecated or changed OData, SOAP and RFC interfaces

• Change pointers and BD52: why master data changes are not distributed

  How ALE change pointers work end to end — global activation, message type activation, BD52 field assignment and BD21 processing — and the configuration gaps that silently stop IDoc distribution.

Which engines does the Integration preflight run?

Integration runs 2 deterministic engines: Change Pointer Coverage Auditor and API Change Guard. Each engine documents its rules and input contract in the engine catalog.

Which files do I need for Integration?

The engines in this area accept these file formats: CSV, JSON, TEXT, and XML. You create the exports in SAP and upload them; no direct connection to your SAP system is needed. The outbound-only local agent is optional.

Are the findings produced by AI?

No. Findings come from deterministic rules: identical exports produce identical findings. Where AI helps with explanations, the confidence of that content is capped at INFERRED and marked as such.

How is each finding backed?

Findings reference evidence in the uploaded file: its path, the line and column where the format has them, a redacted snippet and the SHA-256 hash of the file. Each finding carries a confidence class (VERIFIED, RULE_DERIVED, INFERRED or UNKNOWN); findings without verifiable evidence are demoted to UNKNOWN.