The SAP API Policy as an External Trigger

Figures, tables and listings

1 table · 5 code listings

Reproduced in full, in the order they appear in the published chapter. The reasoning that connects them is in the book.

Figure 14.1: The propagation chain. Each row is generated or surfaced from the row above.

apiVersion: ea.codex/v1
kind: DecisionRecord
metadata:
  id: DEC-SAP-API-001
  title: SAP API Policy Compliance as a Mandatory Gate for SAP-Bound Integrations
  status: accepted
  date: "2026-04-28"
  owner: enterprise-architecture
  relatedPrinciples:
    - INT-002          # New: SAP-Approved Data Access
    - DAT-002          # New: Vendor Policy Compliance
    - AI-008           # Existing: Tool / MCP Governance
  relatedStandards:
    - STD-SAP-INT-001  # New: SAP Integration Pattern Catalog
  relatedSpecs:
    - SPEC-PV-001      # ACME Pharma AI Triage Service spec (constrained)
  affectedFactSheetTypes:
    - Application
    - Interface
    - DataObject
    - Contract
    - AgentContract
spec:
  trigger:
    type: external-vendor-policy
    source: SAP API Policy (April 2026)
    supersedes: SAP Note 3255746 (informal predecessor)
  context: |
    SAP issued a formal API Policy in April 2026, restricting use to
    SAP Published APIs (api.sap.com) and SAP-endorsed mechanisms,
    each used only for its documented purpose. This promotes the
    Note 3255746 position from guidance into contractual surface.
    Every flow that reads SAP data into a non-SAP consumer is now
    in scope, including the ACME Pharma AI Triage Service which
    ingests adverse-event signals from SAP-backed safety systems.
  decision: |
    All integrations that read from or write to an SAP system of
    record MUST use one of:
      (a) an API published on api.sap.com, used for its documented purpose
      (b) SAP Business Data Cloud sharing for analytics / AI consumption
      (c) an SAP-delivered extraction mechanism (CDS view marked for
          extraction, SLT, Data Services) for the use case SAP documents
    Direct RFC / BAPI calls from third-party tools, ODP-via-RFC,
    and any function-module use outside its documented purpose are
    NON-COMPLIANT and require a time-boxed exception with a named
    risk owner.
  doubleCheck:
    fitnessFunctions:
      - id: FF-SAP-001
        rule: |
          Interface.target.application.vendor == "SAP"
            ⇒ Interface.attributes.apiSource ∈
              { published-api, bdc, cds-view-extraction,
                slt, data-services, exception }
        check: OPA / Rego policy in CI
      - id: FF-SAP-002
        rule: |
          AgentContract.dataSources[].system.vendor == "SAP"
            ⇒ accessMechanism ∈ allowed_sources
            OR exceptions[?id=="DEC-SAP-API-001"] exists
        check: OPA / Rego policy in CI
      - id: FF-SAP-003
        rule: DecisionRecord.exceptions[*].sunsetDate ≤ today + 12 months
        check: GitHub Actions weekly scan

Figure 14.2: DEC-SAP-API-001, the architectural decision triggered by the April 2026 SAP API Policy.

apiVersion: ea.codex/v1
kind: ArchitecturePrinciple
metadata:
  id: INT-002
  status: approved
  name: SAP-Approved Data Access
  applicability: Applications-and-AI-Agents-touching-SAP
spec:
  statement: |
    All access to SAP systems of record uses SAP Published APIs
    or SAP-endorsed mechanisms for their documented purposes.
  rationale: |
    Aligns with the SAP API Policy (April 2026). Eliminates
    hidden contractual, audit, and support risk. Centralizes
    SAP data egress on BDC as the strategic gateway.
  validationCriteria:
    - criterion: apiSource attribute populated and ∈ allowed set
      checkMethod: fitness function FF-SAP-001
      requiredValue: published-api | bdc | cds-view-extraction
                   | slt | data-services
  leanixMapping:
    factSheet: Interface
    field: customAttribute.apiSource
    autoCheck: leanix MCP query that counts interfaces with
               vendor=SAP and apiSource not set
  exceptions: |
    Granted only via DecisionRecord with sunsetDate ≤ 12 months
    and a named risk owner.
  relatedPrinciples: [INT-001, DAT-002, AI-008]

Figure 14.3: ArchitecturePrinciple INT-002, the stable anchor for repeated downstream changes.

apiVersion: ea.codex/v1
kind: TechnologyStandard
metadata:
  id: STD-SAP-INT-001
  status: approved
  name: SAP Integration Pattern Catalog
spec:
  patterns:
    - id: PAT-SAP-PUB-API
      name: SAP Published API (OData / REST)
      classification: preferred
      use: Transactional reads/writes; agent tool calls
    - id: PAT-SAP-BDC
      name: SAP Business Data Cloud share
      classification: preferred
      use: Analytics, AI training, zero-copy to lakehouses
    - id: PAT-SAP-CDS-EXT
      name: SAP-delivered CDS view (marked for extraction)
      classification: acceptable
      use: Bulk reads where Published API is insufficient
    - id: PAT-SAP-SLT
      name: SAP Landscape Transformation
      classification: acceptable-legacy
      use: Existing pipelines; not for greenfield
    - id: PAT-SAP-DS
      name: SAP Data Services
      classification: acceptable-legacy
      use: Existing pipelines; not for greenfield
    - id: PAT-SAP-RFC-DIRECT
      name: Direct RFC / BAPI from third-party
      classification: prohibited
      use: NONE (exception required)
    - id: PAT-SAP-ODP-RFC
      name: ODP framework via RFC for third-party
      classification: prohibited
      use: NONE (exception required)

Figure 14.4: TechnologyStandard STD-SAP-INT-001, the catalog of integration patterns the principle points at.

package ea.sap.api_policy
allowed_sources := {
  "published-api", "bdc", "cds-view-extraction",
  "slt", "data-services", "exception"
}
deny[msg] {
  input.kind == "Interface"
  input.target.application.vendor == "SAP"
  not allowed_sources[input.attributes.apiSource]
  msg := sprintf(
    "FF-SAP-001: interface %v has missing or invalid apiSource (got %q)",
    [input.id, input.attributes.apiSource]
  )
}
deny[msg] {
  input.kind == "AgentContract"
  some i
  input.spec.dataSources[i].system.vendor == "SAP"
  not allowed_sources[input.spec.dataSources[i].accessMechanism]
  msg := sprintf(
    "FF-SAP-002: agent contract %v dataSource %d has invalid accessMechanism",
    [input.id, i]
  )
}

Figure 14.5: FF-SAP-001 and FF-SAP-002, the minimum viable Rego policy that fails CI for any non-compliant SAP-bound interface or agent contract.

# In SPEC-PV-001 (AgentContract for AI Triage Service)
# BEFORE
spec:
  dataSources:
    - name: SAP Adverse Event Inbox
      system: SAP S/4HANA (safety module)
      # accessMechanism not specified
# AFTER (delta introduced by DEC-SAP-API-001)
spec:
  dataSources:
    - name: SAP Adverse Event Inbox
      system:
        vendor: SAP
        product: S/4HANA (safety module)
      accessMechanism: published-api          # FF-SAP-002 enforced
      apiEndpoint: api.sap.com/safety/v2/...
      complianceRefs: [DEC-SAP-API-001]
  evaluation:
    evidenceItems:
      - EVAL-PV-001#sap-egress-pattern-compliant
  roadmap:
    additions:
      - milestone: Validate SAP egress pattern compliance
        before: go-live
        ref: ROADMAP-AIAGENT-PV-001

Figure 14.6: SPEC-PV-001 delta. What the AgentContract for the AI Triage Service looks like before and after DEC-SAP-API-001.