Architektur & Datenfluss
Vier Zonen, eine Steuerungsebene: SAP-System, BTP (oder Communication Arrangement), AWS-Datenhandler, Bilendo.
Die vier Zonen
| Zone | Was dort steht | Aufgabe |
|---|---|---|
| SAP S/4HANA | FI-AR, Geschäftspartner mit Debitorensicht, optional Kreditoren und SD-Belege | Quelle. Wird nur gelesen. |
| SAP BTP (On-Premise) bzw. Communication Arrangement (Public Cloud) | API-Management-Proxy je OData-Service, Destination + Cloud Connector | Die eine Tür ins Kundensystem. Der Tunnel des Cloud Connectors endet in BTP; die Fassade macht ihn von außen aufrufbar (OAuth 2.0 Client Credentials). In der Public Cloud entfällt sie. |
| AWS · Datenhandler je Kundenprojekt | EventBridge-Zeitplan, Step Functions, Lambda (Collector, Transform, Deliver, Report), S3 Rohdaten, DynamoDB-Wasserzeichen, Secrets Manager | Liest seitenweise, transformiert nach dem Mapping aus dem IMS, liefert Delta-Batches, meldet jeden Lauf. |
| Bilendo | Loader (API-POST oder SFTP), Debitoren, Journal Entries, Mahnläufe je Mahnbereich | Ziel. Aktualisiert bekannte Posten, mahnt und klärt. |
Die Steuerungsebene
Das Bilendo-IMS beschreibt den Datenhandler (Soll-Zustand, Zeitplan, Buchungskreise, Objekte, Secret-Namen) und sieht seine Läufe; es betreibt ihn nicht und hält keinen Zugang, sondern nur den Namen, unter dem der Zugang im Secret Store des Kunden liegt. Rollen, Zustände und die Bedeutung jeder Spalte der Lauf-Tabelle stehen einmal in Datenhandler: Steuerung & Läufe — dort auf dem Utilities-Beispiel geschrieben, hier unverändert gültig.
Ein Lauf
Soll-Zustand und Wasserzeichen lesen, Lauf-Id vergeben.
Je Objekt in fester Reihenfolge — Debitoren → Mahndaten → Posten → (Kreditoren) → (Aufträge und Rechnungen) — mit Delta-Filter seitenweise lesen; Rohdaten unverändert nach S3.
Nach dem Mapping der Variante in die Spalten der Bilendo-Header-Vorlage transformieren; Clearing- und Restposten-Regeln anwenden; Batches zu je maximal 5 000 Zeilen.
Debitoren-Batches, dann Journal-Batches liefern; jeder Teil trägt einen Idempotenzschlüssel.
Manifest ans IMS melden; Wasserzeichen nur bei bestätigter Lieferung vorrücken.
Die Reihenfolge ist Pflicht und nicht Geschmack: ein Posten braucht seinen Debitor, und die Auftragsdaten werden zu Nummern gelesen, die erst die Posten nennen.
Ein fehlgeschlagener Lauf lässt die Wasserzeichen stehen. Der nächste Lauf liefert dasselbe Fenster erneut — Bilendo aktualisiert, es entsteht kein Duplikat.
Taktung
Ein- bis dreimal täglich. Der letzte Lauf des Tages liegt vor dem Bilendo-Mahnlauf, damit eine am Vormittag in SAP gebuchte Zahlung nicht am Nachmittag gemahnt wird.