Architektur & Integrationsvarianten

Systemlandschaft, OData-Integrationsvarianten und Verantwortlichkeiten.

Stand: 2026
Zielgruppe: SAP Architect, SAP Consultant, Integration Engineer

Einleitung

Die Bilendo-Integration mit SAP kann nach zwei fundamentalen Architekturmustern umgesetzt werden: Pull und Push. Diese Seite beschreibt beide Varianten, ihre Vor- und Nachteile, sowie die Unterschiede zwischen SAP-Plattformen (ECC vs S/4HANA).

Variante A: Pull-Pattern (Bilendo → SAP)

Konzept

Bilendo ruft SAP OData-Endpunkte aktiv ab. Die Bilendo-Plattform fungiert als Client und initiiert alle HTTP-GET-Anfragen gegen SAP.

sequenceDiagram
    participant B as Bilendo<br/>Scheduler
    participant BA as Bilendo<br/>API Client
    participant GW as SAP<br/>Gateway
    participant SRV as SAP<br/>OData Service<br/>(CDS/SEGW)
    participant DB as SAP<br/>Database

    B->>BA: Trigger Import<br/>(z.B. tägliche Nacht)
    BA->>BA: OAuth Token holen<br/>(oder Basic Auth)
    
    BA->>GW: GET /api/v1/$metadata
    GW->>SRV: Read Metadata
    SRV-->>GW: Atom+XML / JSON
    GW-->>BA: Schema der Entity-Sets
    
    BA->>GW: GET /api/v1/A_Customer?$filter=...&$top=100
    GW->>SRV: Filter & Paging
    SRV->>DB: SELECT ... WHERE ...
    DB-->>SRV: 100 Kundensätze
    SRV-->>GW: JSON Response
    GW-->>BA: Batch 1 (100 Records)
    
    BA->>BA: Parse & Transform
    BA->>BA: Store in Bilendo
    
    BA->>GW: GET /api/v1/A_Customer?$skip=100&$top=100
    GW->>SRV: Paging Iterator
    SRV->>DB: SELECT ... OFFSET 100
    DB-->>SRV: Records 101–200
    SRV-->>GW: JSON Response
    GW-->>BA: Batch 2 (100 Records)
    
    BA->>BA: Repeat bis $skip >= Total
    B-->>B: Import complete

Voraussetzungen (Pull)

• Netzwerk-Erreichbarkeit: SAP Gateway muss von Bilendo aus erreichbar sein

  • S/4HANA Cloud: über öffentliches Internet oder über Bilendo-VPN

  • S/4HANA On-Premise: über öffentliche IP, Reverse Proxy oder Cloud Connector

  • ECC: SAP Gateway Add-On (Port 443)

• Authentifizierung: Bilendo benötigt gültige SAP-Credentials

  • OAuth2 (S/4HANA Cloud bevorzugt)

  • Basic Auth (HTTP(S) Header mit Base64-kodiertem Benutzername:Passwort)

  • X.509 Client-Certificate (mTLS, für high-security Szenarien)

  • Siehe 06 - Authentication & Connectivity

• SAP-Konfiguration: Gateway muss OData-Services exposé

  • Keine zusätzliche SAP-seitige Integration nötig (nur REST-Endpoint bereistellen)

Typischer Ablauf (Pull)

1. Authentication: OAuth2-Token anfordern oder Basic-Auth-Header konstruieren

2. Metadata: GET $metadata abrufen, um Entity-Set-Struktur zu verstehen

3. Erstes Abrufen: GET Entity-Set mit $filter (z.B. ModificationDate gt 2026-04-01) und $top=1000

4. Paging-Loop:

   • Wenn @odata.nextLink enthalten → nächste Seite abrufen

   • Sonst: Paging mittels $skip=N&$top=1000

5. Transformation: JSON → Bilendo-internes Format

6. Speicherung: In Bilendo Datenbank / Data Lake

7. Monitoring: Anzahl Records, Fehlerquoten, Laufzeit loggen

Vorteile (Pull)

✅ Bilendo hat vollständige Kontrolle über Timing und Frequenz
✅ Kein SAP-seitiger Job / Scheduler nötig
✅ Bilendo kann on-demand Daten abfragen (z.B. Echtzeit-Kreditprüfung)
✅ Einfach zu debuggen (Standard REST HTTP)
✅ Weniger Komplexität auf SAP-Seite (kein CPI/BTP nötig)

Nachteile (Pull)

❌ SAP muss von außen erreichbar sein (Firewall-Regeln)
❌ Höhere Netzwerk-Last bei häufigem Polling
❌ Bilendo benötigt SAP-Credentials (Credential Management)
❌ Keine asynchrone Benachrichtigung (kein Event-Driven)

Variante B: Push-Pattern (SAP → Bilendo)

Konzept

SAP sendet Daten proaktiv an Bilendo, typischerweise via SAP Cloud Platform Integration (CPI) oder SAP BTP Integration Suite. Eine iFlow (Integration Flow) ruft periodisch (z.B. nächtlich) OData-Daten aus dem SAP-Backend ab und POSTet sie an Bilendo REST-Endpoints.

sequenceDiagram
    participant SM36 as SAP<br/>Job Scheduler<br/>(SM36)
    participant CPI as SAP CPI /<br/>BTP Integration<br/>Suite
    participant SRV as SAP<br/>OData Service<br/>(CDS/SEGW)
    participant HTTP as SAP<br/>HTTP Client<br/>(cl_http_client)
    participant B as Bilendo<br/>REST API<br/>Endpoint
    participant BD as Bilendo<br/>Data Platform

    SM36->>CPI: Trigger iFlow<br/>(z.B. 22:00 Uhr)
    CPI->>CPI: OAuth Token<br/>von SAP Backend
    
    CPI->>SRV: GET /api/v1/A_Customer<br/>$filter=ModificationDate gt ...
    SRV-->>CPI: JSON Payload<br/>(100–1000 Records)
    
    CPI->>CPI: Transform<br/>(SAP → Bilendo Format)
    CPI->>CPI: Split in Batches<br/>(ggf. je 500 Records)
    
    CPI->>B: POST /api/import/customers<br/>Content-Type: application/json<br/>[{customer_id, name, ...}]
    B->>BD: Validate & Insert
    B-->>CPI: 200 OK<br/>{ "imported": 500, "errors": 0 }
    
    CPI->>CPI: Log Success
    CPI->>CPI: Repeat für nächste Entity<br/>(Offene Posten, Aufträge, ...)
    
    SM36->>SM36: Job completed

Voraussetzungen (Push)

• SAP CPI / BTP Integration Suite: Lizenz und Deployment erforderlich

  • Oder: Alternative Middleware (z.B. MuleSoft, Dell Boomi)

  • Oder: ABAP-direkter HTTP-Client (dann ist man fast wieder beim ABAP-Ansatz)

• iFlow-Entwicklung: SAP CPI Expertise erforderlich

  • OData GET konfigurieren

  • Mapping / Transformation

  • HTTP POST an Bilendo

• SAP-Konfiguration:

  • OData-Services müssen exposé sein

  • Service-Benutzer für CPI Authentifizierung

  • SM36 Job zur iFlow-Triggerung

• Bilendo-Seite:

  • REST API Endpoint verfügbar (HTTPS)

  • API-Key oder OAuth2 Client-Credentials

  • Webhook-Handler implementiert

Typischer Ablauf (Push)

1. Scheduling: SM36 Job triggert iFlow (z.B. täglich 22:00 Uhr)

2. Authentication: CPI authentifiziert sich gegen SAP Backend

3. OData Fetch: iFlow macht GET-Request gegen OData Service mit $filter (Delta)

4. Transformation: SAP-Struktur → Bilendo JSON Format

5. Batching: Falls viele Records, in Batches (z.B. 500er-Chunks) splitten

6. HTTP POST: Jede Batch an Bilendo /api/import/{entity} posten

7. Error Handling: Retry Logic, Fehler-Logging, ggf. Re-Submittal

8. Monitoring: iFlow Execution Log ansehen, E-Mail Alert bei Fehler

Vorteile (Push)

✅ SAP muss NICHT von außen erreichbar sein
✅ Event-gesteuert möglich (bei modernen SAP-Lösungen)
✅ Integration in bestehende SAP CPI-Landschaft
✅ Bilendo braucht keine SAP-Credentials (CPI speichert diese)
✅ Höherer Durchsatz möglich (Batching optimiert)

Nachteile (Push)

❌ SAP CPI Lizenz erforderlich (Kosten)
❌ iFlow-Entwicklung und Wartung nötig
❌ Komplexere Fehlerbehandlung (CPI muss Retry-Logik haben)
❌ Schwerer zu debuggen (CPI-spezifische Tools)
❌ Latenz zwischen SAP-Änderung und Bilendo-Daten

Variante C: Hybrid-Ansatz

In Großunternehmen oft kombiniert:

• Pull für Echtzeit-Abfragen: Bilendo braucht ad-hoc Kreditprüfung oder Kundeninfos → direkt GET gegen SAP

• Push für Batch-Daten: Täglicher Stammdaten-Sync, Offene-Posten-Reconciliation → nächtliche iFlow

Beispiel Hybrid:

• 06:00 Uhr: CPI iFlow holt alle Kunden und Offenen Posten → Bilendo

• 08:00 Uhr: Bilendo Analyst fragt Echtzeit-Kreditstatus ab → Pull gegen SAP

• 22:00 Uhr: Tägliche Batch-Sync aller Änderungen → Push über CPI

Plattformvergleich: ECC 6.0 vs S/4HANA

Empfehlungen nach SAP-Version

ECC 6.0 + Gateway:

• Für Pull: Machbar, aber Gateway muss exposé sein, Custom SEGW Services nötig

• Für Push: Ideal, CPI kann einfach OData GET machen und POST an Bilendo

• Fazit: ECC ist ein klassisches Batch-System; Push wird empfohlen

S/4HANA On-Premise:

• Für Pull: Gut, da OData v2+v4 nativ vorhanden, aber externe Erreichbarkeit klären

• Für Push: Optimal, CPI integriert, viele Standard-APIs verfügbar

• Fazit: S/4HANA On-Premise: Hybrid (Pull für Echtzeit, Push für Batch) empfohlen

S/4HANA Cloud:

• Für Pull: Ideal, APIs sind Standard, OAuth2 natürlich

• Für Push: Auch möglich, BTP Integration Suite verfügbar

• Fazit: S/4HANA Cloud: Pull wird bevorzugt (einfacher, schneller)

Netzwerk & Konnektivität

S/4HANA Cloud

Szenario: Bilendo in Public Cloud, S/4HANA in SAP Cloud

Bilendo (AWS/Azure)  ←→  Internet  ←→  SAP Cloud Gateway  ←→  S/4HANA Core
                      (HTTPS, OAuth2)

• Pull ist direkt möglich (öffentliche SAP APIs)

• Keine spezielle Netzwerk-Config nötig

• Firewall-Regeln: Bilendo muss HTTPS Port 443 (zu SAP Cloud) öffnen

S/4HANA On-Premise (mit Cloud Connector)

Szenario: Bilendo in Cloud, S/4HANA lokal; Cloud Connector als Brücke

Bilendo (Cloud)  ←→  SAP Cloud Connector (On-Prem DMZ)  ←→  S/4HANA (Interior)
                   (Outbound HTTPS)

• Cloud Connector initiiert Outbound-Verbindung zu SAP Cloud

• Reverse Proxy inside ON-Prem; keine Inbound-Ports exposed

• Push (via CPI) ist ideal für dieses Szenario

• Pull möglich, aber muss durch Cloud Connector tunneled werden

S/4HANA On-Premise (mit Reverse Proxy)

Szenario: S/4HANA lokal, direkter Internet-Zugang (oder DMZ mit Reverse Proxy)

Bilendo (Cloud)  ←→  Internet  ←→  Reverse Proxy (DMZ)  ←→  SAP Gateway (Interior)

• Reverse Proxy mapped /api/sap/* → SAP Gateway (Port 443)

• Pull funktioniert direkt

• Requires Firewall-Öffnung: Internet → DMZ → Interior

• HTTPS + mTLS (X.509) empfohlen

ECC 6.0 + Gateway

Szenario: ECC lokal, Gateway Add-On läuft auf ECC

Bilendo (Cloud)  ←→  Internet  ←→  DMZ / Reverse Proxy  ←→  ECC + Gateway

• Pull: Reverse Proxy configured

• Push: SAP CPI initiiert HTTP POST an Bilendo (einfacher, kein Inbound-Port)

• Gateway läuft auf Standard HTTP(S) Port 443 oder Custom Port

• TLS 1.2+ erforderlich

graph LR
    subgraph InternetZone["Internet"]
        InternetNode["Internet<br/>(Public)"]
    end
    
    subgraph CloudBilendo["Cloud Provider<br/>(Bilendo)"]
        B["Bilendo<br/>REST API<br/>Port 443"]
    end
    
    subgraph OnPremDMZ["On-Premise DMZ"]
        RP["Reverse Proxy<br/>oder<br/>Cloud Connector"]
    end
    
    subgraph OnPremInterior["On-Premise Interior<br/>(SAP Netzwerk)"]
        SG["SAP Gateway<br/>Port 443"]
        DB["SAP DB<br/>Port 3600"]
    end
    
    CloudBilendo -->|HTTPS| InternetZone
    InternetZone -->|HTTPS| OnPremDMZ
    OnPremDMZ -->|HTTP/HTTPS<br/>Internal| OnPremInterior
    OnPremInterior -->|SQL| DB
    
    style CloudBilendo fill:#e8f8e8
    style OnPremDMZ fill:#fef9e7
    style OnPremInterior fill:#e8f4f8

Datentypen und OData-Zuordnung

Entscheidungsbaum: Pull oder Push?

┌─────────────────────────────────────────────┐
│ SAP-Version?                                │
└─────────────────────────────────────────────┘
         │
    ┌────┴────┬──────────────┬──────────────┐
    │          │              │              │
   ECC       S/4 On-Prem    S/4 Cloud
    │          │              │
    │          │              │
    ▼          ▼              ▼
┌─────────┐ ┌──────────┐ ┌─────────────┐
│ Push    │ │ Hybrid   │ │  Pull       │
│(CPI)    │ │(Pull+    │ │ (preferred) │
│         │ │Push)     │ │ (OAuth2)    │
│         │ │          │ │             │
└─────────┘ └──────────┘ └─────────────┘


Additional Factors:

├─ SAP extern. erreichbar?
│  ├─ JA → Pull ist OK
│  └─ NEIN → Push bevorzugt
│
├─ CPI / BTP verfügbar?
│  ├─ JA → Push ist Option
│  └─ NEIN → Pull möglich
│
└─ Echtzeit-Anforderung?
   ├─ JA → Pull (on-demand)
   └─ NEIN (Batch OK) → Push (effizienter)

Fazit

Nächste Schritte: Siehe 02 - OData Service-Definitionen für die konkrete Implementierung.

**