Re-Integration (Write-Back)

Rückschreibung von Mahnstufe, Rating und Kreditlimit zurück nach SAP.

Übersicht

Die Re-Integration (Write-Back) ermöglicht es Bilendo, Daten zurück in SAP zu schreiben. Im Gegensatz zur reinen Datenintegration (Lesezugriff) müssen hier Änderungen an Kreditlimit, Bonitätsrating, Dunning-Informationen und anderen Feldern konsistent und fehlersicher an SAP übermittelt werden.

Bilendo unterstützt zwei Schreibmodelle:

• Pull-Write: Bilendo ruft aktiv SAP OData PATCH/PUT-Endpoints auf

• Push-Write: SAP CPI pollt die Bilendo API und schreibt die Daten in SAP zurück

Die Rückschreibbaren Felder entsprechen der ABAP-Re-Integration und umfassen Mahnstufe, Mahndatum, Mahnsperre, Kreditlimit, Risikokategorie/Rating und Versichertes Obligo.

1. Rückschreibbare Felder

2. S/4HANA: Standard-APIs für Write-Back

2.1 Kreditmanagement (API_CREDIT_MGMT_ACCT_SRV)

Der Standard-Service API_CREDIT_MGMT_ACCT_SRV bietet einen PATCH-Endpoint für die A_CreditMgmtAccount-Entity. Über diese API können Kreditlimit und Risikokategorie direkt aktualisiert werden.

HTTP-Anfrage Beispiel:

PATCH /sap/opu/odata/sap/API_CREDIT_MGMT_ACCT_SRV/A_CreditMgmtAccount(CreditSegment='0001',BusinessPartner='0000010001')
Content-Type: application/json

{
  "CreditLimit": 50000.00,
  "CreditRiskClass": "01"
}

Wichtige Parameter:

• CreditSegment: Kreditsegment (SAP-Schlüssel)

• BusinessPartner: Kundenkennung

• CreditLimit: Neues Kreditlimit (Dezimalzahl)

• CreditRiskClass: Risikokategorie

2.2 Mahnsperre (API_BUSINESS_PARTNER)

Die Mahnsperre wird über die Standard-API API_BUSINESS_PARTNER auf der Entity A_CustomerCompany aktualisiert.

HTTP-Anfrage Beispiel:

PATCH /sap/opu/odata/sap/API_BUSINESS_PARTNER/A_CustomerCompany(Customer='0000010001',CompanyCode='1001')
Content-Type: application/json

{
  "DunningBlock": "M"
}

Gültige Werte für DunningBlock:

• " " (Leerzeichen): Mahnsperre aufgehoben

• "M": Mahnsperre aktiv

2.3 Mahnstufe und Mahndatum (Kein Standard-API)

Mahnstufe (BSEG-MANST) und Mahndatum (BSEG-MADAT) befinden sich auf Dokumentebene und haben keinen Standard-OData-Write-API. Die Aktualisierung dieser Felder erfordert spezielle Lösungen:

Optionen:

1. Custom CDS View mit @ObjectModel.updateEnabled (komplex, erfordert BOPF)

2. Custom SEGW Service mit DPC UPDATE-Methode (ruft BAPI_ACC_DOCUMENT_CHANGE auf)

3. SAP CPI iFlow mit RFC-Aufruf zu BAPI_ACC_DOCUMENT_CHANGE

Empfehlung: Verwenden Sie Ansatz 3 (CPI + BAPI) oder einen benutzerdefinierten OData-Service, da dieser wartbarer und weniger fehleranfällig ist.

3. ECC: Custom Write-Back Service

Für SAP ECC wird ein dedizierter SEGW-Service Z_BILENDO_WRITEBACK_SRV mit UPDATE_ENTITY-Methoden empfohlen.

Entity: ZBilendoCreditUpdate

METHOD zbilendocreditupdatese_update_entity.
  DATA: ls_entity TYPE zcl_z_bilendo_writeback_mpc=>ts_zbilendocreditupdate,
        ls_knkk   TYPE knkk,
        lv_return TYPE bapireturn.

  io_data_provider->read_entry_data( IMPORTING es_data = ls_entity ).

  " Kreditlimit und Rating aktualisieren via FM
  CALL FUNCTION 'BAPI_CREDITACCOUNT_CHANGE'
    EXPORTING
      creditaccount  = ls_entity-kunnr
      creditsegment  = ls_entity-kkber
      creditlimit    = ls_entity-klimk
      riskclass      = ls_entity-ctlpc
    IMPORTING
      return         = lv_return.

  IF lv_return-type = 'E'.
    CALL FUNCTION 'BAPI_TRANSACTION_ROLLBACK'.
    io_response->set_status_code( 400 ).
  ELSE.
    CALL FUNCTION 'BAPI_TRANSACTION_COMMIT'.
    io_response->set_status_code( 204 ).
  ENDIF.
ENDMETHOD.

Entity: ZBilendoDunningUpdate

Für Änderungen an Mahnstufe und Mahndatum auf Dokumentebene:

METHOD zbilendodunningupdatese_update_entity.
  DATA: ls_entity TYPE zcl_z_bilendo_writeback_mpc=>ts_zbilendodunningupdate,
        lt_header  TYPE TABLE OF bapiache09,
        lt_items   TYPE TABLE OF bapiache09it,
        lv_return  TYPE bapireturn.

  io_data_provider->read_entry_data( IMPORTING es_data = ls_entity ).

  " Mahnstufe und Mahndatum per BAPI_ACC_DOCUMENT_CHANGE aktualisieren
  CALL FUNCTION 'BAPI_ACC_DOCUMENT_CHANGE'
    EXPORTING
      documentnumber = ls_entity-belnr
      fiscalyear     = ls_entity-gjahr
      manst          = ls_entity-manst
      madat          = ls_entity-madat
    IMPORTING
      return         = lv_return.

  IF lv_return-type = 'E'.
    CALL FUNCTION 'BAPI_TRANSACTION_ROLLBACK'.
    io_response->set_status_code( 400 ).
  ELSE.
    CALL FUNCTION 'BAPI_TRANSACTION_COMMIT'.
    io_response->set_status_code( 204 ).
  ENDIF.
ENDMETHOD.

4. Push-Write via SAP CPI

Falls SAP nicht extern erreichbar ist, exportiert Bilendo Daten als CSV/JSON-Dateien. Die Integration läuft dann über SAP Cloud Platform Integration (CPI):

Bilendo Export API
        ↓
   CPI iFlow (Timer)
        ↓
   SAP Format Mapping
        ↓
   OData PATCH / BAPI RFC
        ↓
    SAP System
        ↓
  Erfolgs-/Fehlerreport

Ablauf der CPI iFlow:

1. Timer-basierte iFlow pollt die Bilendo Export API in regelmäßigen Intervallen

2. Lädt ausstehende Write-Back-Datensätze herunter

3. Mapped Felder in SAP-Format

4. Ruft SAP OData PATCH auf oder verwendet RFC-Aufruf zu BAPI

5. Meldet Erfolg/Fehler an Bilendo zurück für Tracking

Mermaid-Sequenzdiagramm für CPI Write-Back-Flow:

sequenceDiagram
    participant Timer
    participant CPI
    participant Bilendo as Bilendo API
    participant SAP as SAP System

    Timer->>CPI: Trigger iFlow
    CPI->>Bilendo: GET /export/writeback?status=pending
    Bilendo-->>CPI: [Records]
    CPI->>CPI: Map & Transform
    CPI->>SAP: PATCH /A_CreditMgmtAccount
    SAP-->>CPI: 204 No Content
    CPI->>Bilendo: POST /export/writeback/ack
    Bilendo-->>CPI: 200 OK

5. Fehlerbehandlung

Partielle Fehler

Bei Batch-Operationen können einzelne Datensätze fehlschlagen, während andere erfolgreich sind. Dies erfordert Tracking auf Datensatz-Ebene:

{
  "status": "partial_failure",
  "records": [
    {
      "customer": "0000010001",
      "field": "CreditLimit",
      "status": "success",
      "timestamp": "2026-04-09T14:32:00Z"
    },
    {
      "customer": "0000010002",
      "field": "CreditLimit",
      "status": "failure",
      "error": "Credit limit exceeds maximum permitted value",
      "timestamp": "2026-04-09T14:32:15Z"
    }
  ]
}

Idempotenz

Wiederholte Schreibvorgänge müssen zum selben Ergebnis führen. Dies wird durch Versionskontrolle und Checksummen erreicht:

• SAP ETag-Header verwenden (OData)

• Bilendo-Sequenznummer tracking implementieren

• Duplikate durch eindeutige Transaktions-IDs erkennen

Retry-Logik

Für transiente Fehler (503 Service Unavailable, 408 Request Timeout) sollten Retry-Mechanismen mit exponentieller Backoff implementiert werden:

Versuch 1: sofort
Versuch 2: nach 5 Sekunden
Versuch 3: nach 25 Sekunden
Versuch 4: nach 125 Sekunden
→ Geben Sie auf nach 4 Versuchen

6. Vergleich: OData Write-Back vs. ABAP Re-Integration

**