Introduction

With the introduction of ABAP Cloud we now have a new, modern ABAP development model to build cloud-ready business apps, services, and extensions. If you are not yet familiar with this innovation, I highly recommend having a look at this introduction and this architectural overview.

A common requirement when developing business applications is the ability to execute certain logic asynchronously. This may be due to a number of reasons. Maybe a large amount of data must be processed, which takes a long time, and the business process shall continue while that takes place. Maybe there is the need for a recurring mass activity that shall run in the background. In any case, asynchronous processing is crucial.

In this blog post I want to lay out the different possibilities that are available with ABAP Cloud. Currently we have three different approaches:

1. Background Processing Framework (bgPF)
2. Application Jobs
3. Eventing

Each option has its own merits and advantages, and it will be up to you to identify which one is the most appropriate for your use case.

A short reminder on the availability of ABAP Cloud: it is enforced on SAP BTP ABAP Environment and SAP S/4HANA Cloud, public edition (Developer Extensibility is available in the 3-system landscape starting with release 2208) and it is available on SAP S/4HANA Cloud, private edition & on-premise (starting with release 2022).

Background Processing Framework

The newest of the features presented in this blog is the background processing framework (bgPF). This provides a simple and straight-forward way to execute custom logic asynchronously, without any configuration overhead. Developers can even decide whether to enforce transactional control for the asynchronously executed logic.

The first step is to create a class that implements either the if_bgmc_op_single (enforcing transactional consistency) or if_bgmc_op_single_tx_uncontr (unontrolled – no enforcement of transactional consistency) interface. The execute method of either interface should contain the logic that shall be executed asynchronously:

Background process implementation

The second step is to simply call the logic in question at the desired point in your business process. This is achieved using the previously created custom class and the standard class cl_bgmc_process_factory:

Background process consumption

Depending on the context, you may have to trigger the execution with a COMMIT WORK statement. This is not required if the process is triggered from within the RAP runtime, as the framework will trigger the commit.

This feature was initially released with release 2308 for SAP BTP, ABAP environment and SAP S/4HANA Cloud, public edition and with release 2023 for SAP S/4HANA Cloud, private edition and on-premise. Keep in mind that further improvements are planned and will be delivered with future releases.

Application Jobs

Another option for decoupling parts of your code are custom application jobs. Alongside the standard jobs delivered by SAP, you can create your own jobs containing custom code. These can then be scheduled through different means:

1. Manually by a business user in the corresponding Fiori app (Application Jobs).
2. Programatically, directly from your custom ABAP code.

An application job is defined by a job catalog entry, a job template and a handler class containing the custom code to be executed. The handler class implements interfaces if_apj_dt_exec_object (for design-time) and if_apj_rt_exec_object (for runtime). Most importantly, the if_apj_rt_exec_object~execute method contains the logic that shall be executed asynchronously:

Application Job Implementation

We then need to make sure that this application job is scheduled. In cases where the business application shall take care of this automatically, it makes sense to make use of the released class cl_apj_rt_api. The code should look something like:

Application Job Scheduling

Finally, we can just call the schedule method as required to trigger some asynchronous processing. You can find a nice tutorial from my colleague Andre Fischer here.

Eventing

As of release 2208, RAP supports the usage of custom RAP events. Such events are easily defined in any custom behavior definition and can then be raised during the save sequence. By executing the relevant business logic everytime the event is raised we can achieve the desired asynchrony.

Events can be consumed locally with minimal configuration effort. They can also be consumed remotely, which requires integration with the eventing infrastructure provided by SAP Event Mesh on SAP BTP (see for example the integration documentation for SAP S/4HANA Cloud, public edition). You will require entitlements for the corresponding BTP services and will need to perform the  corresponding connectivity setup (check out this tutorial for a great guide for SAP BTP ABAP Environment).

Event definition

Define an event by declaring it in your behavior definition as shown below. You will also need to define an additional save method:

Behavior Definition

This custom event should now be raised in the implementation of the additional save method:

Behavior Implementation

PUBLISH FOR LOCAL CONSUMPTION

If you are going to consume the event in the same system, then the implementation is already done!

PUBLISH FOR REMOTE CONSUMPTION

If you want to expose the event to the SAP BTP Event Mesh service, you will additionally need to create an event binding in ADT and expose the event to the eventing infrastructure. This will allow consumption of the event from external systems.

For more information, see Business Events.

Event publishing

LOCAL CONSUMPTION

If you are consuming an event locally, in the same system, then you only require an event handler class. This class inherits from cl_abap_behavior_event_handler and can contain handler methods for different events:

Event handler class

REMOTE CONSUMPTION

If you are consuming an event from SAP Event Mesh, you instead need to create an event consumption model:

Event Consumption Model

Along with the event consumption model itself, several additional objects are automatically created. The generated handler class (zcl_newevent in the screenshot) contains the event handler methods:

Event handler implementation

With that, you can execute some of your business logic asynchronously, either in the original system or in remote systems. For more information, see Business Event Consumption. 

Summary

You now have 3 different ways of executing code asynchronously when developing with ABAP Cloud. You should analyze your use case and determine which of these options is the best for you.

Feel free to share any interesting use cases that you have encountered and, of course, do not hesitate to post any questions that you may have. We are always happy to help all ABAP developers out there to make the journey into the cloud!