Implementation of Remote Business Events in SAP S/4HANA Public Cloud

By - Visalini

Introduction

In SAP S/4HANA Public Cloud, businesses often need to react when a Purchase Order is created—for example, to trigger integrations, notifications, or follow-up actions. However, the SAP S/4HANA Public Cloud model does not offer local events in initiate follow up actions.

This blog explains how remote business events, combined with SAP Business Technology Platform (BTP)-Event Mesh, can be used to execute required business logic without modifying the core Purchase Order process.

Business Need

The requirement is to execute custom business logic to update Sales Order line items when a Purchase Order is created in SAP S/4HANA Public Cloud. Since the Purchase Order business object does not provide local events or in-app extensibility options, this logic cannot be implemented directly within the core system.

To address this, the solution is to use released remote business events, which allow SAP S/4HANA Public Cloud to trigger SAP BTP Event Mesh which in turn forward the same to a custom consumption method inside SAP S/4HANA Public Cloud. This method utilizes SAP Business Object Interface of Sales Order Item to update the information.

Prerequisite: SAP Event Mesh

To enable event-based communication, an active SAP Event Mesh subscription is required on SAP BTP. The Event Mesh instance must be configured with the necessary queues and subscriptions to receive events published from SAP S/4HANA Public Cloud.

The consuming application or service must also have the appropriate role collections and authorizations to reliably subscribe to and process these events.

Purchase Order Lifecycle Events

Purchase Order Lifecycle Events List

SAP S/4HANA Public Cloud provides released lifecycle events for Purchase Orders, representing key moments such as:

  • Purchase Order creation
  • Header-level changes
  • Approval and rejection status changes
  • Item-level creation, changes, or deletion
  • Item blocking and unblocking

Each of these events can be independently enabled, published to SAP Event Mesh, and selectively consumed on SAP BTP. This allows the business to react to specific lifecycle changes without relying on local enhancement points.

The same event-driven concept can also be applied to other standard business objects that support remote events, as listed in the SAP Accelerator Hub.

Solution 

The objective is not to change the Purchase Order, but to respond after it is created. Because SAP S/4HANA Public Cloud does not allow synchronous enhancements or core modifications for this scenario, the logic must be decoupled from the transactional process.

Event Flow

Event Flow Diagram

  1. Purchase Order Creation
    A Purchase Order is created through standard business processing in SAP S/4HANA Public Cloud. No custom logic is executed at this stage.
  2. Business Event Triggered
    After successful creation, SAP S/4HANA Public Cloud publishes a released Purchase Order creation event containing key identifiers such as PO number and organizational details.
  3. Event Published to SAP Event Mesh
    The event is sent to SAP Event Mesh, which acts as a reliable message broker. It stores, routes, and decouples the event from downstream processing.
  4. Event Consumption on SAP BTP
    An event consumption function written in SAP S/4HANA Public Cloud subscribes to the event, processes the payload, and executes the required decision logic to update Sales Order Item. Based on this logic, further supported actions can be triggered in SAP S/4HANA Public Cloud.

Purchase Order Screen

SAP BTP Event Mesh

Sales Order Screen

Event Consumption ABAP Code:

Snippet ⧉ Copy Code 
"Event Type: sap.s4.beh.purchaseorder.v1.PurchaseOrder.Created.v1
DATA ls_business_data TYPE STRUCTURE FOR HIERARCHY z_purchaseorder_created_v_48d0.
*
*

"DATA lt_unique_inso TYPE TABLE OF i_purchaseorderitemtp_2.
DATA lv_msg TYPE string.

DATA wa TYPE zeventpo.
ls_business_data = io_event->get_business_data( ).

wa-payload = ls_business_data-purchaseorder.
DATA(purchaseorder) = ls_business_data-purchaseorder.
DATA(sydatum)       = cl_abap_context_info=>get_system_date( ).
DATA(sytime)        = cl_abap_context_info=>get_system_time( ).

wa-recorddate = sydatum.
wa-recordtime = sytime.

SELECT FROM i_purchaseorderitemtp_2
       FIELDS yy1_soinpodoc_pdi,
              yy1_soinpodocit_pdi,
              purchaseorder,
              purchaseorderitem
       WHERE purchaseorder = @purchaseorder
       INTO TABLE @DATA(lt_unique_inso).

LOOP AT lt_unique_inso INTO DATA(lv_po_val).

  IF lv_po_val-yy1_soinpodoc_pdi IS NOT INITIAL.

    SELECT FROM I_SalesOrderItemTP
           FIELDS yy1_poinsodoc_sdi,
                  yy1_poinsodocit_sdi,
                  SDProcessStatus
           WHERE SalesOrder = @lv_po_val-yy1_soinpodoc_pdi AND
                 yy1_poinsodoc_sdi IS INITIAL AND
                 yy1_poinsodocit_sdi IS INITIAL
           INTO TABLE @DATA(lt_so_it).

    LOOP AT lt_so_it INTO DATA(lw_so_it).

      IF lw_so_it-SDProcessStatus = 'A'
         OR lw_so_it-SDProcessStatus = 'B'.

        MODIFY ENTITIES OF i_salesordertp
          ENTITY salesorderitem
          UPDATE
          FIELDS ( yy1_poinsodoc_sdi
                   yy1_poinsodocit_sdi )
          WITH VALUE #(
            (
              %key-salesorder     = lv_po_val-yy1_soinpodoc_pdi
              %key-salesorderitem = lv_po_val-yy1_soinpodocit_pdi
              yy1_poinsodoc_sdi   = lv_po_val-purchaseorder
              yy1_poinsodocit_sdi = lv_po_val-purchaseorderitem
            )
          )
          FAILED   DATA(ls_failed)
          MAPPED   DATA(ls_mapped)
          REPORTED DATA(ls_reported).

        IF ls_reported-salesorder IS NOT INITIAL.
          LOOP AT ls_reported-salesorder INTO DATA(lwa_salesorder_log).
            IF lwa_salesorder_log-%key IS NOT INITIAL.
              lv_msg = lwa_salesorder_log-%msg->if_message~get_text( ).
              wa-msg = lv_msg.
            ENDIF.
          ENDLOOP.
        ENDIF.

        IF ls_failed-salesorder IS NOT INITIAL.
          wa-msg = 'MODIFY failed'.
        ENDIF.

        COMMIT ENTITIES
          BEGIN RESPONSE OF i_salesordertp
            FAILED   DATA(ls_soit)
            REPORTED DATA(ls_rsoit).
        COMMIT ENTITIES END.

        INSERT zeventpo FROM @wa.

      ENDIF.

    ENDLOOP.

  ENDIF.

ENDLOOP.

Benefits

  • No impact on core processes
    • Purchase Orders are created using standard SAP processes without interference.
  • Works without local enhancements
    Business requirements can be fulfilled even when in-app extensibility options are not available.
  • Clean-core and upgrade-safe
    All custom logic runs outside the SAP S/4HANA Public Cloud core, ensuring compatibility with future upgrades.
  • Flexible business logic
    Changes or extensions can be implemented on SAP BTP without modifying the core system.
  • Asynchronous and reliable
    Event-based processing ensures that failures in custom logic do not block business transactions.

Conclusion

In SAP S/4HANA Public Cloud, released business events provide a practical and supported way to react to Purchase Order creation/updation when local enhancements are not available. By publishing these events to SAP Event Mesh and consuming them, businesses can execute additional logic without impacting core processes. This event-driven approach ensures clean-core compliance, flexibility, and long-term scalability.

For further reference, SAP provides official documentation on released business events and their consumption in SAP S/4HANA Public Cloud:

https://api.sap.com/products/SAPS4HANACloud/events/events

Visalini

Visalini

Categories -
SAP S/4HANA Public Cloud
Tags -
SAP S/4HANA Public Cloud SAP Business Technology Platform