Jonathan Andre is a lead ABAP developer at IT Partners. Jon has over 10 years experience with SAP, with a concentration on ECC SD, MM, and IS-OIL modules. Jon’s focus has been in the areas of ABAP OOP, ABAP Web Dynpro, and ABAP for HANA and RESTful ABAP development. He can be reached at [email protected].
The SAP Business Technology Platform (BTP) is the foundation of SAP’s cloud strategy, bringing together data management, analytics, AI, application development, and integration into one unified environment. It gives organizations the flexibility to extend their core ERP systems, modernize legacy applications, and innovate faster with a cloud-first approach.
In the previous post Demystifying the BTP (SAP Business Technology Platform) – Part 1, we explained what the BTP was and introduced some of the products it has to offer. During this month’s blog, we begin a 4 part series that introduces implementing an “enhancement” using the BTP and side-by-side extensibility. The series uses a practical example of generating tweets for sales events in SAP ERP to demonstrate key technologies and solutions.
Before we begin, I would like to take another shot at an analogy that might help conceptualize what the BTP actual is. This may be particularly helpful for those who are more familiar with SAP Enterprise Resource Planning solutions and aren’t quite sure what to make of the vastness of the BTP.
Those who have worked in the SAP space may be expecting something like the Enhancement Framework (i.e. a rigid set of steps that allows developers to enhance the SAP solution with code to meet a business requirement).
Let me be clear that the BTP is CERTAINLY not that, or anything even remotely similar. Instead, the BTP grants the ability to build business software solutions, in the broadest sense, while taking advantage of the cloud environment. The BTP allows you to deploy pre-built software solutions, stand up environments to run custom code, manage and monitor processes and system resources, and deploy services to be consumed. So, in a very loose way, the BTP can be considered as a type of cloud “operating system”.
Also like an operating system, you may pick and choose which programs and services you subscribe to, allowing you to build the exact solution you need with no wasteful overhead. Of course, BTP enabled software will be made to support development or a business requirement; don’t expect to find Solitaire or Minesweeper available to download. However, the tools available are diverse enough that it is entirely possible that two customers could be using two entirely different sets of services, even to accomplish the same overall business task!
BTP’s Hidden Complexity- Disjointed Services and Processes 
However, unlike an OS running on a single machine, the BTP has one clear hurdle that explains the infrastructure of the platform, and consequentially the design of any enhancements implemented within it.
BTP Services/Processes are Disjointed. Both from the perspective the components of our solution being isolated from the SAP system, and from the perspective of the individual components being isolated from each other (even though they reside in the same BTP instance!)
- This necessitates the need to connect components together deliberately and explicitly, vs on-prem solutions that can use system memory, function calls, the database, etc. to connect different SAP technologies.
- Communication is facilitated often through RESTful HTTP calls, both for internal BTP programs and external ones (e.g. the ERP system). To enable these connections, this means each component requires and HTTP endpoint, and an additional service to manage HTTP requests.
- Different Services/Processes require authentication to connect to each other. Integrating separate portions of an overall custom solution require an additional step of creating communication users, generating credentials, etc.
This technical challenge leads to some additional questions when replacing traditional on-premise ERP enhancements with a Cloud extensions…
Questions Raised by Cloud-Based ERP Extensions
- If the BTP is completely separate from the SAP, how can we act on business events in a timely and reliable fashion?
- Even if we receive synchronize notifications, the point of side-by-side extensibility is to enhance the OTB SAP solution. How can we do that if the data resides in SAP?
- Custom solutions require custom logic. If my ABAP environment is on the ERP system itself, how can I possibly execute any logic without an SAP environment?
- A business’ primary function is to interact with parties that are external to our software ecosystem. How can we communicate with partners if don’t have a dedicated PO/PI system?
Over the next few blogs, I hope to answer these four questions in detail, while building a simple solution that accomplishes this straightforward task:
“Every time a sale is made within our SAP ERP system, our BTP extension will generate a Tweet containing details about the sale”
While this is not the most realistic scenario, iterating through steps required to build this extension will detail how to build and integrate BTP technologies that would be useful in everyday scenarios.
Building The Solution
As a bit of a preview of what’s to come, here is an summary of exactly what technologies will be utilized in upcoming blogs to build out our solution:
Problem: 1. If the BTP is completely separate from the SAP, how can we possibly react to business events in a timely and reliable fashion?
Solution: SAP Event Mesh, and the SAP Enterprise Event Enablement
SAP Enterprise Event Enablement allows an SAP S/4HANA “Channel” to transmit messages about internal business events to the Event Mesh. A channel is a single connection to the Event Mesh that allows business event messages to be published to the cloud. It is possible to publish multiple business event types to one channel or publish multiple channels to the same Event Mesh environment.
Enterprise Events are the very same events that you would expect a business object to produce within the ERP system itself. They are transmitted via JSON and include basic information about business events. These JSONs only contain basic levels of information about the business event, such as document numbers, partners involved in the transaction, etc. This is intentional so we can keep the Event messages small and efficient. To receive the full picture, programs still need to make subsequent call to the backend to retrieve data pertinent to its process (Problem 2).
The Event Mesh is essentially a message broker that resides on the BTP that receives and distributes business event messages received. The event mesh will subscribe to a channel for S/4 HANA, then create a queue where the messages can be consumed by interested companies or, in our case, extension programs that wish to perform actions based one messages received.
These messages are placed in Queues, which allow consumers to ingest messaging either synchronously or asynchronously. There may be multiple queues for multiple consumers, and consuming a message usually means it disappears from that particular queue.
Problem 2: Even if we receive synchronous notifications, the point of side-by-side extensibility is to enhance the OTB SAP solution. How can we do that if the data resides in SAP?
Problem 3: Custom solutions require custom logic. If my ABAP system is on the ERP system itself, how can I possibly execute any logic without an SAP environment?
Solution: BTP ABAP Environment (ABAP Steampunk)
This one is a bit more straightforward and just requires the use of OData services on the SAP S/4HANA side, and consumption of those services from the BTP. This means we can address Problems 2 and Problems 3 concurrently when executing our custom logic in the cloud.
The only minor precondition is that the BTP environment be connected to the backend SAP S/4 HANA system (Cloud or On-Premise with Cloud Connector), which is a relatively simple and straightforward process for any basis team.
Once connected, we can choose from a number of execution environments in which we can run our code. For this blog series, we will be using the ABAP Cloud Environment, also known as ABAP Steampunk.
While a variety of coding languages can be used to code our custom logic, the ABAP language has the added bonus of coming with specific tools that help us integrate perfectly with the backend SAP system. Such as…
Event Consumption Model: This ABAP artifact allows us to quickly define the event consumption model and the required artifacts, and is designed solely to consume Enterprise Event Enablement events. An Event Specification AsyncAPI file, which aids in generating the correct data models, contains the service specifications that can be downloaded directly from SAP API Business Hub. Once the generation of the model is finished, developers simply need to code the correct business logic in the correct generated method, leaving connection details to the generated code. The Event Consumption model also comes with a “simulation” functionality, allowing easy testing of logic from right within the Eclipse IDE.
Service Consumption Model: Much like the Event Consumption Model, the Service Consumption Model removes much of the manual coding required to consume a service in the ABAP Environment. Instead, we can use another AsyncAPI file, which will provide metadata about the model, allowing us to simply choose which portions of the service we want to implement. This approach will obviously only work for the standard services, which is adequate in this scenario where want to retrieve Sales Orders from the backend system.
Problem 4: A business’ primary function is to interact with parties that are external to our software ecosystem. How can we communicate with partners if don’t have a PO/PI system?
Solution: Integration Suite
Whether it be vendors, customers, or even government entities, businesses need to interface with external partners who may are may not be using SAP for their own organizations. Managing interactions with partners via a PO/PI implementation used to be the standard, but with our entire solution residing in the cloud, we will obviously need another option.
The most common approach for BTP extensions, and the one I used for this particular project, is the use of the Integration Suite. For the scenario outlined above, we will be using the Integration Suite to connect our ABAP solution to Twitter. In particular, we will be using an Integration Flow, which allows us to create a API endpoint. The Integration Flow endpoint will allow us to transmit a payload to Twitter and create a post for a predefined user.
This integration handles storing the credentials, the OAuth authentication steps, and any necessary responses. It has the additional benefit of monitoring responses, so we can quickly view and diagnose any issues arising while using this integration.
Even with the components laid out in front of us, some of us used to creating enhancements directly on the ERP system may end up being intimidated by having to manually connect the separate components via HTTP. How do we keep track of the correct URL targets, credentials, parsing the HTML requests, etc?
Fortunately, connecting these pieces is made relatively easy by the user of services and service keys. Most scenarios simply require downloading a service key JSON and pasting it in the appropriate input field.
This allows us to interconnect these pieces without needing to concern ourselves with any of the technical details.
For instance, the following steps of the process will use these service keys. Other than downloading and pasting them when prompted, this required no additional effort on my part:
- Connecting SAP S/4 HANA Event Enablement to Event mesh. We create an Event mesh service and download the service key. This makes connection a one step process, as we will see in the Event Mesh Blog.
- Connecting our Eclipse environment to backend ABAP instance is also a one step process. The service key allows us to do this, although it does require reauthentication during every connection
- Connecting our ABAP instance to the Integration Suite process flow also uses a service key.
These service keys make connecting this different pieces quick, easy, and secure. So I thought I would at least mention before signing off.
Seeing it in Action
Last but not least, here is a quick preview of the functionality in action. In our SAP system, we create basic Sales Order. then, this sales order triggers events, custom logic, logging into Twitter and creation of the tweet behind the scenes.
The end result is the following Tweet:
Summary
This blog post has set the stage for a multi-part series on implementing enhancements using SAP BTP and side-by-side extensibility. We clarified the unique architecture of BTP, its cloud-native flexibility, and the deliberate integration required between its services and the SAP ERP system.
Key challenges—such as event-driven triggers, accessing backend data, executing custom logic outside the SAP environment, and integrating with external partners—were outlined with high-level solutions, including Event Mesh, ABAP Environment, and Integration Suite. The article previewed how these technologies will work together to create a seamless extension that posts sales events to Twitter, and highlighted the ease of connecting components using service keys. The next installment will dive into configuring and connecting the Event Mesh and offer troubleshooting advice.
