SAP RAP Business Event Consumption & Ingestion Architecture

1. The Clean Core Event Consumption Philosophy

When external events arrive from SAP BTP, Kafka, or third-party SaaS platforms, developers from the classic ECC era often attempt to insert or update database tables directly using ABAP SQL statements (UPDATE db_table SET ...).

Under ABAP Cloud Clean Core, incoming events must strictly interact with the business entity via Entity Manipulation Language (EML): MODIFY ENTITIES OF root_entity.

2. Handling Idempotency & At-Least-Once Delivery

Message brokers (such as SAP Event Mesh, Azure Event Grid, and AWS EventBridge) operate with at-least-once delivery guarantees. This means network timeouts or broker reconnections will inevitably deliver duplicate events.

Every CloudEvent includes a unique identifier in the ce-id header. The inbound consumer MUST:

• Query the ZT_EVENT_IDEMPOTENCY table before executing any business logic.
• If ce-id is found, immediately return HTTP 200 OK to acknowledge the message without re-executing the transaction.
• If ce-id is new, execute the EML modification and record the ID in the idempotency log.

3. Transactional Flow via RAP EML

MODIFY ENTITIES OF ZR_SalesOrderTP
  ENTITY ZR_SalesOrderTP
  UPDATE FIELDS ( DeliveryStatus )
  WITH VALUE #(
    ( %key-SalesOrderID = ls_event_data-order_id
      DeliveryStatus    = ls_event_data-status_code )
  )
  FAILED DATA(lt_failed)
  REPORTED DATA(lt_reported).

IF lt_failed IS INITIAL.
  COMMIT ENTITIES
    RESPONSE OF ZR_SalesOrderTP
    FAILED DATA(lt_commit_failed).
ENDIF.

4. HTTP Status Code Signaling for Broker Retries