quarta-feira, 18 de fevereiro de 2026

Event Driven TM in S/4HANA Public Cloud: Update Delivery Data When a Freight Order is created

 

1. Overview 

If you repeat simple updates in Transportation Management, such as setting general data on every Freight Order, it is time to automate them. When the decision is straightforward and the action is always the same, automation saves time and avoids errors. 

This series shows you how to build a small, event-driven extension in SAP S/4HANA Cloud, public edition. In our example, when a Freight Order is created, a local event handler updates static header data automatically. 

1.1 Why this pattern 

  • Cuts manual effort for routine Freight Order updates 
  • Uses released cloud APIs (usage type C1) and ABAP logic 
  • Upgrade-safe and simple to maintain 

Example we will build 

  • Trigger: Freight Order created 
  • Action: Update general header data with predefined values 
  • Result: Each Freight Order starts with consistent, ready-to-use data 

 1.2. Prerequisites  

  • Developer Extensibility (3-system landscape) is enabled 
  • The required view or API is released for ABAP Cloud (usage type C1) 
  • ABAP Development Tools (ADT) are installed and connected to your system 
  • You have a development package in the customer namespace. 
  • You have access to create classes your development environment.

 1.3 Links 

 

 1.4 Alternatives 

There is more than one way to automate routine tasks in Transportation Management. The local event consumption approach is ideal for simple, immediate updates. For more complex needs, consider: 

  • Job scheduling: periodic, time based updates or high volume corrections 
  • BAdIs: governed logic at standard enhancement points during process steps 

Choose the option that best fits your timing, volume, and control requirements. 

2. Implementation Steps 

2.1 Find relevant event in ADT 

You need the behavior-enabled object for Freight Order, not just a read-only CDS view. The correct BDEF for this example is I_FreightOrderTP. 

Why I_FreightOrderTP? 

  • TP stands for transactional processing. TP interface views are behavior-enabled. 
  • Events, actions, validations, and determinations are defined in the RAP behavior definition (BDEF) behind the TP view. 

Plain interface views such as I_TransportationOrder_2 are read-only and do not expose events. 

Finding the BDEF in ADT 

  • In ADT, use ABAP Repository Search to open the BDEF entity I_FreightOrderTP. 
  • In the BDEF, look for ‘use event‘ declarations. 
  • You subscribe to the alias. In our exampe ‘Created’ 
    Jule_0-1768316265284.png

2.2 Create the Implementation Class 

2.2.1 Global Class 

  • Create a new ABAP class in the customer namespace. 
  • In the class definition, declare the relevant business event using the FOR EVENTS OF keyword so the class can receive the event. 
  • Do not implement business logic in the global class.

    Jule_0-1768316389042.png

2.2.2 Local Class Implementation 

  • Go to the tab ‘Local Types’ tab. 
  • Create a local handler that receives the event data and performs the update. 
  • Use EML to update the Freight Order entity. Keep the update focused and transactional. 
    Jule_0-1768316652913.png
  •  

2.2.3 Example: Enrich the Freight Order 

In this example, you update: 

  • Purchasing Organization 
  • Purchasing Group 
  • Carrier 

Use static data to start. This proves the flow endtoend quickly. Once validated, introduce simple business rules. For example: 

  • Derive Carrier based on Shipping Point (e.g., map shipping points to preferred carriers). 
  • Apply fallback logic if no match is found (e.g., set a default carrier and log a warning). 

2.2.4 What’s Next 

  • Next, test the event flow endtoend: trigger the event, verify the updates via EML, and confirm the business outcome in the Freight Order. 

2.2.5 Tips and Pitfalls

  • Business events run as separate transaction, asynchronously after the main transaction. It might be necessary to refresh the UI to reflect the changes. If you need to make changes withing the main LUW, consider using BADI instead.
  • Consistency: Use correct business terms (“Freight Order,” “Purchasing Organization,” “Purchasing Group,” “Carrier”). 
  • Robustness: Validate event payloads, and handle missing or inconsistent data 
  • Performance: Keep event processing light; avoid longrunning operations in the handler. 
  • Testability: Write unit tests for the local handler logic where possible. 

 

3. Code Snippet: Event Handler to Default Carrier and Purchasing Data 

3.1 What this does 

  • Listens to the “Freight Order created” event and defaults carrier, purchasing organization and purchasing group.
  • Uses local business event consumption and EML updates against released RAP business objects.

3.2 Before you start 

  • This sample is provided asis. Use at your own risk and verify in a test tenant. 
  • Adapt constants and namespaces to your customer namespace. 
  • Only use C1 released objects. 
  • Verify which attributes you can use to differentiate which freight orders should be processed . 

3.3 Global Class

Create a global class in the customer namespace without any method implementations.

CLASS <classname_customer_namespace> DEFINITION PUBLIC ABSTRACT FINAL FOR EVENTS OF I_FreightOrderTP.
   PUBLIC SECTION.
   PROTECTED SECTION.
   PRIVATE SECTION.
ENDCLASS.

CLASS <classname_customer_namespace> IMPLEMENTATION.
ENDCLASS.

 

3.4 Local Class

Open tab local types and create the class implementation. Keep in mind, this is only a template and the coding needs to be adjusted to match your organisations requirements.

CLASS lhe_<classname_customer_namespace> DEFINITION INHERITING FROM cl_abap_behavior_event_handler.

  PRIVATE SECTION.
    METHODS on_created FOR ENTITY EVENT newlycreatedfreightorder FOR freightorder~created.
ENDCLASS.


CLASS lhe_<classname_customer_namespace> IMPLEMENTATION.

  METHOD on_created.
    CONSTANTS lc_purchasing_organization TYPE /scmtms/vdm_pur_org_ext_id VALUE <purchase_org>.
    CONSTANTS lc_purchasing_group TYPE /scmtms/vdm_pur_grp_ext_id VALUE <purchase_group>.
    CONSTANTS lc_carrier_uuid TYPE /scmtms/vdm_carrier_party_key VALUE <carrier_uuid>.

    LOOP AT newlycreatedfreightorder ASSIGNING FIELD-SYMBOL(<singlefreightorder>).
      IF <singlefreightorder>-Carrier IS NOT INITIAL.
        CONTINUE.
      ENDIF.

    MODIFY ENTITY i_freightordertp
      UPDATE FROM VALUE #( ( %key-TransportationOrderUUID = <singlefreightorder>-   TransportationOrderUUID
        TranspPurgOrgExtID = lc_purchasing_organization
        TranspPurgGroupExtID = lc_purchasing_group
        CarrierUUID = lc_carrier_uuid
        %control-TranspPurgOrgExtID = cl_abap_behv=>flag_changed
        %control-TranspPurgGroupExtID = cl_abap_behv=>flag_changed
        %control-CarrierUUID = cl_abap_behv=>flag_changed ) )
      FAILED DATA(ls_create_failed)
      REPORTED DATA(ls_create_reported).
    ENDLOOP.
  ENDMETHOD.
ENDCLASS.

 

3.5 Risk Reduction Checklist for Productive Usage

  • Validate before update: Ensure the Freight Order exists and is updatable before issuing EML.
  • Handle errors: Catch and log EML failures with clear message categories; surface actionable context.
  • Consider BRFR+ tables instead of hard-coding any values
  • Keep it light. Consider job processing or BADI implementation for more complex logic.

4. Conclusion

 

Thanks to my co-author @Slava_Aliakseyevets

Source: https://community.sap.com/t5/supply-chain-management-blog-posts-by-sap/event-driven-tm-in-s-4hana-public-cloud-update-delivery-data-when-a-freight/ba-p/14306637

Postado por às

Nenhum comentário:

Postar um comentário

Assinar: Postar comentários (Atom)