Technology Blogs by SAP
Learn how to extend and personalize SAP applications. Follow the SAP technology blog for insights into SAP BTP, ABAP, SAP Analytics Cloud, SAP HANA, and more.
Showing results for 
Search instead for 
Did you mean: 
Developer Advocate
Developer Advocate
**UPDATE** As of September 2022, the functionality described in this blog post is now natively available within Steampunk via the RAP/XBE framework.  Please see the following blog posts for more information on this topic.

How to Create RAP Business Events in SAP BTP, ABAP Environment

How to Consume an Event using Event Consumption Model


In this blog post, I want to show ABAP developers how they can leverage SAP Event Mesh when working in the SAP BTP, ABAP Environment(aka Steampunk).  For this, I am providing some sample code which basically abstracts the REST calls required to interact with both the SAP Event Mesh Messaging API, and the Management API.   As part of the Developer Keynote in last years SAP TechEd, SAP Event Mesh was a key player in the overall application that we built.  At that time, I wanted to explore the capabilities of SAP Event Mesh, and what better way to learn about it then building an abstraction layer over it with ABAP.  I also used this code for testing some scenarios for our Developer Keynote application as well, so it served a greater purpose in the end.

dj.adams has done quite a bit of work on this topic from the CAP perspective as well, so I’m not going to repeat the content here.  You can check out DJs content to get a better understanding of SAP Event Mesh in general and its basic functionality.  Here, we will simply take a look at the sample ABAP code which gives developers various methods to create SAP Event Mesh configuration, as well as to create and consume messages.  For more information about SAP Event Mesh, check out some videos  as well as some content on Github from DJ Adams.


Diving into messaging on SAP Cloud Platform

Graphing SAP Enterprise Messaging Artifacts

Developer Keynote - Message Bus component

SAP-samples content on GitHub:

The Message Bus component setup from the SAP TechEd 2020 Developer Keynote

The repository “Cloud - Messaging - Hands-on SAP Dev”

Now the the basic structure of the ABAP objects in this code sample is pretty simple, we have the base API abstract class called ZCL_EMS_API which contains the logic for instantiating instances of the subclasses, makes the connection to SAP Event Mesh, and handles all REST calls via a single method.  We then have the two subclasses which inherit from the ZCL_EMS_API class, the management API class, ZCL_EMS_MGNT_API, and the messaging API class, ZCL_EMS_MSG_API.  These two subclasses basically contain methods that corresponds to the operations exposed by SAP Event Mesh, one for one.  Each method is basically building out the URL string and passing this to the execute_ems_request method of the base API class.

The base API abstract class


As I mentioned earlier, the ZCL_EMS_API class handles the actual calls to the SAP Event Mesh API via REST over HTTP.  This example was created specifically for the SAP BTP ABAP Environment(aka Steampunk), so it uses the HTTP client class cl_web_http_client_manager(as well as other related objects) available there. If you wanted to use this example in an on-prem system, you would need to modify these classes to use the on-prem version of the HTTP client classes.  Again, this class is pretty simple, it contains two static methods for creating instances of the subclasses specific to the API in which you want to use, a protected instance method called execute_ems_request, and a private get_access_token method.  Also there are a number of constants here.  All of the constant values need to be supplied in order to make a connection to your SAP Event Mesh Service.  You can get these values from the service key of SAP Event Mesh service as shown here.  As stated in the API documentation, you must append URL parameters  "?grant_type=client_credentials&response_type=token" to the token URL as well.

The management API class


The ZCL_EMS_MGNT_API class contains all of the methods that are exposed by the SAP Event Mesh management API.  You can find more information about this API here.

We can use these methods to configure and manage the SAP Event Mesh.  So we can do things like creating, updating, and deleting queues and queue subscriptions.  There are also several usage and statistical type operations available, but only for certain service plans.  Each method returns the response as a string.


The messaging API class


The ZCL_EMS_MSG_API class contains all of the methods that are exposed by the SAP Event Mesh messaging API.  You can find more information about the messaging API here.

These are the methods that we use to publish messages to a queue or topic, as well as consume and acknowledge those messages.  We can also create, update and delete webhook subscriptions here as well.


The API test class


I’ve also included the ZCL_EMS_API_TESTER class which is used to test the methods of the management and messaging operations.  All of the calls to the methods in this class are commented out currently, but you can of course pick and choose which ones you would like to test out and uncomment accordingly.  You will find these classes very easy to consume, for example, if you wanted to create a queue,  just get an instance of the management API and call the method for create_update_queue and supply the queue name and some configuration parameters. That’s pretty much it for every operation of both the management and messaging API.  Again, these classes abstract away the complexities of the REST calls themselves.

So again, this simple code sample originated from my need to learn about SAP Event Mesh, do some simple prototyping, and eventually test some scenarios related to the Developer Keynote last year. Instead of just sticking it on the shelf, I figured I would clean it up a little and share it with the community. Take a look, bang it around, let me know what you think.  I have some ideas about how to make it more robust in the future, perhaps the community has some suggestions as well.