SAP Community - SAP Event Mesh

Consume SAP RAP Business Events in Google Cloud Pub/Sub

2024-01-04T09:22:10+01:00

Introduction to SAP Business Events

Enterprises running SAP often need to send changes in SAP business data to external systems. For example, when a material description is changed in SAP, an external system may want the updated description to change a label. In SAP terminology, these are called “Business Events”.

Over the years, SAP has changed the way how Business Events are raised and how these events can be consumed.

One option that has been around for a very long time is Business Transaction Events (BTE) where events can be be consumed using function modules. Here’s an example of BTE in S/4HANA.

Another option that is still relevant in S/4HANA is Business Workflow Events, which allows configuring of a function module (using SWE_TEMPLATE_REC_FB as a template) or a class (that implements interface BI_EVENT_HANDLER_STATIC to consume the business event.

Most recently, SAP introduced RAP Business Events as the primary eventing mechanism for ABAP RESTful Application Programming Model (RAP). Majority of RAP based applications on both S/4HANA Cloud and S/4HANA On-Prem support RAP Business Events.

Google Cloud Pub/Sub as an event messaging platform

Pub/Sub works as a messaging middleware for traditional service integration or a simple communication medium for modern microservices. ABAP SDK for Google Cloud provides client library classes that allow SAP applications to natively call over 55 Google APIs including Pub/Sub.

While an external system can use pull subscription to read messages published to a Pub/Sub topic, a push subscription can deliver events to serverless webhooks on Cloud Functions, App Engine, Cloud Run, or Application Integration. This versatility makes Pub/Sub an ideal choice for sending SAP Business Events to external systems.

In this blog post, I will show how you can send a RAP Business Event to a Pub/Sub topic.

Anatomy of RAP Business Events

Let’s first understand how RAP Business Events work and how these events can be handled by RAP event handler class.

Using demo CDS entity demo_rap_event_m (available in newer S/4HANA systems) as an example:

RAP Business Event created is defined in the Behavior definition demo_rap_event_m.

The event is raised in the local implementation (CCIMP) of behavior implementation class bp_demo_rap_event_m when a new entry is created.

Handling RAP Business Events

Business Events can be handled in a RAP Event handler class. For example, class cl_demo_rap_event_handler handles events of entity demo_rap_event_m

CLASS cl_demo_rap_event_handler 

      DEFINITION PUBLIC ABSTRACT FINAL 

      FOR EVENTS OF demo_rap_event_m.

...

ENDCLASS.

The implementation of the event handler methods is done in CCIMP include by defining a local class that inherits from CL_ABAP_BEHAVIOR_EVENT_HANDLER.

CLASS lhe_event DEFINITION INHERITING FROM cl_abap_behavior_event_handler.    

  PRIVATE SECTION.    

  METHODS on_created FOR ENTITY EVENT created FOR demo_rap_event_m~created.

....

ENDCLASS.

You can run class cl_demo_rap_events to see the event handler in action.

Key Notes / Observations:

Event handlers are executed using bgRFC, which requires setup of default destination BGPF and a supervisor destination (note https://me.sap.com/notes/0003099088)

You can define multiple event handler classes for the same CDS entity.

Send message to Pub/Sub using RAP Event Handler

Now that we know how to create handlers for RAP events, let’s create one to send the event information to a Pub/Sub topic using ABAP SDK.

If you are new to ABAP SDK for Google Cloud, please use public documentation links to set up ABAP SDK and Pub/Sub resources. We will use the following values to publish messages to Pub/Sub topic:

Client Key ‘PUBSUB’

Pub/Sub topic ‘SAP_DEMO_RAP_EVENT’.

Lets create an event handler class zcl_event_handler_pubsub for the CDS entity demo_rap_event_m

CLASS zcl_event_handler_pubsub 

      DEFINITION PUBLIC ABSTRACT FINAL 

      FOR EVENTS OF demo_rap_event_m.

...

ENDCLASS.

In the local types (CCIMP include) of zcl_event_handler_pubsub, add the below logic to publish the message to Pub/Sub topic using ABAP SDK for Google Cloud.

CLASS lhe_event DEFINITION INHERITING FROM cl_abap_behavior_event_handler.



  PRIVATE SECTION.



    METHODS on_created FOR ENTITY EVENT

       created FOR DEMO_RAP_EVENT_M~created.



ENDCLASS.



CLASS lhe_event IMPLEMENTATION.



  METHOD on_created.



   TRY.

     DATA(lo_pubsub) = NEW /goog/cl_pubsub_v1( iv_key_name  = 'PUBSUB' ).



     DATA(ls_input) = VALUE /goog/cl_pubsub_v1=>ty_023( ).



     LOOP at created ASSIGNING FIELD-SYMBOL(<ls_created>).



       APPEND VALUE #(

          data = cl_web_http_utility=>encode_base64(

                  /ui2/cl_json=>serialize( data = <ls_created> ) ) )

          to ls_input-messages.

     ENDLOOP.



     lo_pubsub->publish_topics(

      EXPORTING

         iv_p_projects_id = CONV string( lo_pubsub->gv_project_id )

         iv_p_topics_id   = 'SAP_DEMO_RAP_EVENT'

         is_input         = ls_input

       IMPORTING

         ev_ret_code      = DATA(lv_ret_code)

         ev_err_text      = DATA(lv_err_text)

         es_err_resp      = DATA(ls_err_resp) ).



     CATCH /goog/cx_sdk INTO data(lo_sdk_error).

   ENDTRY.



   "Add error handling logic



  ENDMETHOD.



ENDCLASS.

By running class CL_DEMO_RAP_EVENTS, our event handler class zcl_event_handler_pubsub is triggered and the message is published to the Pub/Sub topic

These messages can now be consumed by external systems using pull / push subscriptions.

Applying the approach to standard RAP Events

As SAP is adopting RAP for all newer applications built on S/4HANA On-Prem and Public Cloud, the above approach can be used to stream SAP business events to external applications.

Finding Standard RAP Events

You can find standard RAP Events by looking at the behavior definitions in ADT. You can search behavior definitions using the Property Filter type:bdef in the ADT search bar.

List of Behavior Definitions in S/4HANA On-Prem System

When you open the behavior definition, you can find the events which can be handled using the event handler.

Extending behavior definitions to implement your own events

What if a standard behavior does not have an event? Behavior Extensions to the rescue!

As long as the standard behavior definition is marked as extensible, you can :

Create a Behavior Extension for the Behavior and implement your own events.

Inherit system class cl_abap_behavior_saver and write logic to raise the event within CCIMP include of RAP behavior implementation class

Handle the event using the same approach as above

Conclusion and Next Steps

As you can see, by using RAP Business Events along with ABAP SDK for Google Cloud & Pub/Sub, you can build modern, scalable event-driven integration between SAP and external systems.

Happy to answer any questions. Happy Learning and Innovating !

Advanced Event Mesh - Partitioned Queues : One Queue for All

2024-01-30T12:11:56.326000+01:00

"Load Balancing and Context-Aware Auto-Scaling are effortlessly handled by the Advanced Event Mesh, enabling a performant event broker in various use cases, along with flexible configuration to reduce operational overhead. In this blog, I will showcase one such feature: Partitioned Queues."

Partitioned Queue (Source and Consumer Applications)

Advanced Event Mesh provides different capabilities for different use-cases. One of the latest features that is provided recently is the “Partitioned Queues”

As you might already know + certain blogs & articles already mentioned; there are different types of queues in AEM in terms of access type:

Exclusive queue where only one consumer (first binded) can receive a message at any one time, while additional consumers may be connected as standby. (do not process messages actively)

Non-exclusive queue, where multiple consumers can bind to the queue actively. This enables load balancing because the broker delivers messages to the consumers in a round-robin fashion.(randomly)

This mechanism is quite flexible and advantageous, particularly in cases where the order and processing of messages do not matter.

However there might be cases where you want the same kind of / related messages handled by the same application (consumer). For instance the very same order or lets say the same order type is to be handled by the same application: In a round robin fashion it’s not guaranteed as the second message is received about the order (i.e when order is updated) might be handled by another consumer which is “more” available at that time.

Another way to ensure this is by having exclusive queues, which tightly couples the consumer to a predetermined queue. This might become complicated as the number of variations increases.

For these kind of use-cases, Advanced Event Mesh has a subset of non-exclusive queue : Partitioned Queue where each partition within one-queue maps one and only one consumer application which guarantees the messages in the same partition to be handled by the same application. Depending on the number of partitions, one consumer application might be binded to multiple partitions, though.

Then let’s say based on the load, you increase the number of consumer services. Then the magic happens.. The broker re-balances the partitions with the consumer applications keeping the base principle the same “one partition binded to at most one consumer”.

Detailed information regarding queues (partitioned queues) can be found here in this link

This is “kind of” Solace’s/SAP's answer to Kafka Consumer Groups (in fact with more flexibility/easiness). The feature included in AEM comes with no extra cost and supported by different APIs and different protocols (JCSMP, JMS, CCSMP, Python, Golang, .NET, and JS APIs as well as standard REST/HTTP, MQTT 5.0, and AMQP etc.) similar to regular queues. (for variations/restrictions please check the documentation).

The differentiator here is the partition key set by the publisher causing the consumers to be organized flexibly, which behind the scenes handled by the event broker(AEM).

Via this mechanism, you have context aware load balancing with autoscaling. (Similar messages, depending on the context, are routed to the same consumer. Meanwhile, the number of consumers can increase with the number of partitions, and the broker manages the reorganization of this matching to ensure consistency.).

Enough theory, let’s have a working example reflecting these things:

SCENARIO

Imagine a simplified use case where sales orders are published to Advanced Event Mesh, where we want the same order handled by the same consumer(updates for instance) but within one queue configured and in an automated way.

For this we have initiated 3 consumer services, processing the sales orders from one queue. Then in year end the frequency of the orders increases, therefore we need more services and added one more binded to the same sales order queue. (but still want the remaining orders already processed, would be processed with the same consumer microservice.)

Assume that our order numbers are in format 90000XXXX. If I create an order with number 900004057; then make subsequent updates to the same order, I would like Consumer X to handle the messages related to that order.

For this the only thing I should do is having this ID in the Partition ID of the message, which is JMSXGroupID (if you use REST, it’s Solace-User-Property-JMSXGroupID) and make the necessary configurations like below for the queue and subscription.

STEP 1- Create the queue as partitioned queue

Create Queue

I simply named it q/par1

STEP 2- Make it non exclusive and set number of partitions to 3.

Queue Details

Count: The count of partitions of the queue. Only relevant for queues with an access type of non-exclusive. When zero, bound clients receive messages round-robin. Otherwise, bound clients receive messages from individually assigned partitions.
You can have a lot more, but keep it in mind that the idea is to align with number of consumers you have)
Rebalance Max Handoff Time is the maximum time (in seconds) to wait before handing off a partition while rebalancing.
Rebalance Delay is the delay (in seconds) before a partition rebalance is started once needed.

So the end result would be, we’ll have 3 partitions in our queue with no binding.

Partitions' Statuses

STEP 3- Assigning a subscription to the queue as usual

Subscriptions

I assigned bb/salesorder/> (for handling bb/salesorder/created, bb/salesorder/changed etc.) to route all sales order from my source system (let’s say S/4HANA) to the same queue. (q/par1)

Now the fun parts..

Publisher and the Subscribers(Consumers)

Publisher part is simulated by a REST call to the broker from Postman. (Please refer to my old blogs below for publishing to a topic via REST)

Publishing messages from Postman

As STEP 4, we need to publish multiple messages by putting the order number to the JMSXGroupID header(you can do this via a script or a publisher application generating random messages)

As STEP 5, for the Subscribers, I create 3 instances of the same subscriber application(as consumers). Thanks to Aaron Lee and Solace Team for the samples. I am using a little bit of modified version of the subscriber code provided in the code samples (Solace Labs) to demonstrate the behaviour of 3 consumers.

In fact, the code samples provided include a lot more than simple consumers and publishers; rather, they encompass many aspects related to partitioned queues and include artifacts and utilities for demo purposes. I strongly recommend that you take a closer look at the code samples in detail.

Consumer Applications binding to the Queue

Now these applications are binded to the same partitioned queue that we have created in the previous steps, they look like as below from the broker.

From AEM Perspective - Clients binded to the Queue

Now we can see that we have 3 consumers binded to 3 different partitions for our queue.

In fact I have created one more consumer but as there is no partition to bind, now it’s in stand-by position(inactive).

Consumers ( 4 for 3 partitions)

Now that we have our consumers expecting messages; as in STEP 6, I will send some messages to the broker, with different order numbers to see its effect. (See the messages in brown color)

Consumed messages by consumers 1,2,3,4

I have sent 6 messages. Consumer#1 receives 1 message, Consumer#2 receives 2, and Consumer#3 receives 3.(Interesting coincidence:) Obviously with high frequency, it will be more “normally” distributed. The last one (Consumer#4) doesn’t receive any as it is not connected to a partition (there are only 3 partitions created, remember).

Now as STEP 7, I will increase the number of partitions to 5, still keeping the number of consumers at 4; and expecting the broker to rebalance the partitions with the consumers.

Status of Partitions / Clients after 5 partitions

As you can see one consumer(ending with 53e5) is now binded to 2 partitions, while the others are binded one-to-one to the remaining partitions.

After I sent couple of more messages; below is the status of the consumer applications:

Status after new re-balancing

Now as the last STEP; I will send 2 updates to the order 900000723 and expect to see it is consumed by Consumer#1(as Consumer#1 processed the initial creation of 900000723) , and 2 updates for 900002474 and expect it to be received by the Consumer#3.

Similar order related messages are consumed by the same consumer microservice.

"Voilà!"
Updates to the created orders are handled with the same microservice as you can see from the monitor."

Although it’s a very simple demonstration of partitioned queues, I think it’s enough to prove how powerful and flexible Advanced Event Mesh is to load-balance & re-balance its clients and the partitions for handling the “context-awareness” without much effort.

You can apply the same pattern to multiple scenarios, such as tickets, order types, employee related scenarios, accounts, transactions etc and scale-up easily at the same time.

You can find great blogs and demo videos created by the Solace team and navigate to the documentation if you need more details regarding partitioned queues and its usage.

Below you can also find the previous blogs I mentioned about other very usable features of Advanced Event Mesh.

Automating Advanced Event Mesh Broker Creation

2024-02-08T09:07:53.387000+01:00

Introduction

The need to reduce costs associated with operating and maintaining an active message broker led to the creation of a tool that automates the generation and configuration any time the need for asynchronous event-based messages arises.

This article will showcase a method of creating an event broker in Advanced Event Mesh by leveraging the REST endpoints provided by Solace and SEMP configuration. The solution will allow the system to request a broker creation, monitor the status, re-generate the queues and topics and extract the endpoints for sending or receiving data. Besides that, a UI has been set up that simplifies the broker configuration and allows users to persist or modify configurations.

Scenario Overview

All the necessary steps for broker creation are done in SAP Integration Suite using multiple iFlow artifacts for each process step, JMS Queues for handling connection errors, timeouts and message routing, Datastore for saving broker configurations and a main page that acts as a user interface for setting up everything.

Architecture Overview

Picture 1 - Architecture Overview

UI Configuration Page

Picture 2 - UI Configuration Page

The configuration page is a HTML page exposed as a REST endpoint, containing multiple sections that allow the user to generate new configurations, use existing ones and even check the status of the already-deployed broker creation jobs.

Picture 3 - Deployment Page

On this page, we can see the status of the active or pending brokers on the cluster. I also added the ability to delete the broker on demand.

Technical Setup

The process of creating an event broker has been detailed in the Managing Services with the SAP Integration Suite, Advanced Event Mesh REST API section and it consists of several REST calls in order to create a broker, get the connection details and check the creation status.

The most important parameters that allow us to continue with the next steps are :

serviceId - the id of the service cluster generated
msgVpnName - the internal id of the broker
defaultManagementHostname - the hostname that will be used for queue, topic and rest delivery point creation

In order to create an event broker :

HTTP POST https://api.solace.cloud/api/v0/services

{
   "name": "Broker Name",
   "datacenterId": "<Data Center Id>",
   "serviceClassId":"developer",
   "serviceTypeId": "developer",
   "adminState": "start"
}

The authentication for this endpoint is made via an authorization token generated in the Cluster Manager.

Picture 4 - API Token Management

In order to create a queue object :

HTTP POST https://<defaultManagementHostname>/SEMP/v2/config/msgVpns/<msgVpnId>/queues

{
"accessType": "exclusive",
"egressEnabled": true,
"ingressEnabled": true,
"msgVpnName": "<msgVpnId>",
"owner": "all",
"permission": "consume",
"queueName": "<queue-name>"
}

In order to create a topic subscription object :

HTTP POST https://<defaultManagementHostname>/SEMP/v2/config/msgVpns/<msgVpnId>/queues/<queue-name>/subscriptions

{
"msgVpnName": "<msgVpnId>",
"queueName": "<queue-name>",
"subscriptionTopic": "<topic/name>"
}

In order to create a rest delivery point object :

HTTP POST https://<defaultManagementHostname>/SEMP/v2/config/msgVpns/<msgVpnId>/restDeliveryPoints

{
    "clientProfileName": "default",
    "enabled": true,
    "msgVpnName": "<msgVpnNameId>",
    "restDeliveryPointName": "<restDeliveryPointId>"
}

If everything is correctly triggered, we should be able to see in the Cluster Manager our newly created broker, and as well in the broker console the queues and topics.

Picture 5 - Cluster Manager

Picture 6 - Queues

Picture 7 - Topics subscribed to a queue

Adapter for inserting/consuming events

By using the recently published adapter for Advanced Event Mesh integrations, we can insert and consume events from our brokers. Below is a sample iFlow artifact that connects to a specific topic and consumes messages from there.

Picture 8 - iFlow artifact for topic message consumption

Conclusions

Using the SAP Help documentation was the key behind the success, because the product is rather new on the market and we did not really heard of other use cases yet. By following the steps we were able to easily connect two Business Technology Platform products and we were able to leverage event-based integration far more powerful than the traditional SAP Event Mesh.

For any questions or suggestions, feel free to post here or in the special Q&A Section.

Thank you!

What's New for SAP Integration Suite - January 2024

2024-02-12T12:43:09.193000+01:00

The new year has started already with big steps, and it is time to present the January highlights of SAP Integration Suite. Detailed presentations and a Q&A section with helpful questions by you, you find in the recording of our Monthly Updates webinar that happened last week.

SAP Integration Suite highlights are:

AdvancedEventMesh adapter for event mediation
Simply search for a flow step in complex integration flows
Manual configuration of proxy settings for some adapters in Edge runtime
Reminder: Upgrade to new version of third-party connectors before March 2024
Simplified mass-maintenance in TPM via extended agreement template configuration
Support for custom SOA messages in Integration Advisor
New Tradacoms message standard
New rules for Migration Assessment
Message mapping and function library integration in migration tool
Virtual host information as part of the API for Edge Integration Cell
New pre-built integration content by our partners

Cloud Integration

AdvancedEventMesh adapter for event mediation

We have recently published the AdvancedEventMesh adapter connecting the Cloud Integration with advanced event mesh brokers through the Solace message format (SMF) message protocol. You may consume in Cloud Integration guaranteed messages from queues or non-persistent messages using a topic subscription. And you can send messages to queues or topics. The adapter is designed to handle large-scale event processing, making it suitable for enterprise-level applications. It is available with the SAP Integration Suite, standard and premium editions. See the initial version of the sender and receiver adapters at the SAP Business Accelerator Hub and check the details within the documentation.

Simply search for a flow step in complex integration flows

The integration flow editor in Cloud Integration has been extended offering you a search for an existing flow step. Within the palette you can search the step by its type, name, or ID. This search is also available for deployed integration flows and accessible from the runtime views (Monitor and Inspect). This extremely helpful feature helps you e.g., to easily identify a step causing an issue like memory exhaustion as you can copy a step ID in Inspect and navigate to the flow view. Refer to the documentation.

Manual configuration of proxy settings for some adapters in Edge runtime

We have enabled the following adapters to support the proxy type manual in case you have set the Edge Integration Cell as runtime profile. With this setting you can configure the proxy host and port by yourself. Supported are the adapters ELSTER receiver, SFTP sender, SFTP receiver, and SFTP sender adapter used with the poll enrich step.

Reminder: Upgrade to new version of third-party connectors before March 2024

As per SAP note 3001980 the following previous adapter versions are deprecated since end of 2020: Salesforce, Amazon Web Services, Microsoft Dynamics, SugarCRM. There haven't been any new features or enhancements for these previous adapter versions. As of March 1st, 2024, the previous adapter versions will no longer run.

Action is urgently required from the customer side. Please either migrate to updated new adapter versions and benefit from new features (request access to migration documentation by annemarie.kiefer@sap.com) or purchase new Advantco adapter versions from Advantco with support from Advantco only. Additionally, you must delete integration flows using the adapters that are no longer in use and undeploy the adapters.

B2B Integration

Simplified mass-maintenance in TPM via extended agreement template configuration

Minimize the efforts required to establish trading partner scenario by reusing a common mapping across multiple agreements. Additional to copying an agreement from a template it is also possible now to create a new trading partner agreement by referencing to the template. With this new option you may change the common mapping and do a refresh for all bound trading partner agreements. For more information refer to the documentation.

Support for custom SOA messages in Integration Advisor

We are more and more extending the set of supported a third custom type system. It is already possible to upload custom messages as XSDs or custom IDocs (refer to recently published blog post). Now you may upload also proprietary or modified SAP S/4HANA SOA messages as a WSDL file. With this new feature you may add new nodes or reorder nodes in standard SAP S/4HANA SOA messages or create your own SOA messages. Migration of existing standard message MIGs to a custom message MIG is supported. And the proposal service of the Integration Advisor will use MIGs based on these messages and enrich its knowledge graph. For more information refer to our documentation.

New Tradacoms message standard

The new message standard Tradacoms has been introduced in December already. GS1 Tradacoms was the core message standard from early days in Retails for EDI. Therefore, important to have it in the Cloud now. A new blogpost has been published detailing out how to use it.

API Management

Edge Integration Cell API shows virtual host information

When using the wizard for designing an API for the Edge Integration Cell runtime, the selected runtime profile now shows the virtual host information for this API. For more information, see the documentation pages create an API artifact using URL and create an API using an imported API definition.

Migration Assessment and migration tool

New rules for Migration Assessment

We have released a couple of new rules for improving the assessment results of the Migration Assessment capability that is used to assess the effort and the feasibility of the migration of SAP Process Integration / SAP Process Orchestration scenarios to the Cloud Integration capability of SAP Integration Suite.

Message mapping and function library integration in migration tool

Customers moving their integration projects to SAP Integration Suite can now import Integrated Configuration Object (ICOs) that contain message mapping objects with dependent resources such as function library objects. In Cloud Integration, reusable message mapping artifacts are created. Within the migration wizard you have also the option to import only supported message mapping objects and skip the unsupported ones.

Additionally, new migration templates such as for multicast and for recipient list with order at runtime have been shipped. And an AS2 adapter with preset parameters is now generated in Cloud Integration if you have a scenario with AS2 adapter in SAP Process Orchestration.

SAP Business Accelerator Hub

New pre-built integration content has been published by our partners to our public central content catalog, the SAP Business Accelerator Hub. For customers from the B2B sector, PROCLANE has published Salesforce and PAYONE adapters. Effective People A/S offers an event-driven integration to generate employee initials within the SAP SuccessFactors EC. Pricefx comes with new integrations with SAP S/4HANA and Degreed with SAP SuccessFactors integration packs. Check out the blogpost New partner content on SAP Business Accelerator Hub (Q4 ’23) and access the partner listing on SAP Business Accelerator Hub that is going along with all published content. In case you are interested in partnering with us see the details of our partner program.

How to stay tuned on recent and upcoming innovations?

The SAP Road Map Explorer is your one-stop shop for all SAP Integration Suite innovations. You can easily check out the latest innovations and follow what is planned for the following quarters. All recent innovations also cover under the tab Features further links to blogposts or documentation.

We also refer to the complete list of new releases in our documentation: What’s New in SAP Integration Suite.

And if you have not heard of our monthly webinars, I suggest you sign up to get an invitation to the upcoming ones. Our team of Product Management experts host these webinars to showcase the latest and greatest updates regarding all SAP Integration Suite capabilities. The webinars are hosted on the last Tuesday of every month and the next one is already scheduled for February 27th.

In case you have missed our last monthly webinar, don’t worry. Visit 2024 Learning Sessions for SAP User Groups on SAP Integration Suite for all recordings, presentations, and Q&As.

Are you aware of the Release Navigator for SAP BTP? It consolidates release information across SAP BTP products and services easing you the way to find product release related notes, blogposts, and webpages. For your convenience use the direct link to the SAP Integration Suite section of the Release Navigator.

Advanced Event Mesh Adapter : BTP and Integration Suite now features tighter integration with AEM

2024-02-13T09:53:23.135000+01:00

"Recently, SAP released a new Integration Suite adapter for Advanced Event Mesh. This adapter enables Integration Suite developers to manage connectivity and integration flow scenarios more effectively, facilitating tighter integration with Advanced Event Mesh than was previously possible."

You can configure the adapter for sending and receiving messages to and from Advanced Event Mesh:

Sender Adapter for receiving messages from Advanced Event Mesh.
Receiver Adapter for sending messages to Advanced Event Mesh.

While there is already an AMQP Adapter available for Integration Suite, which you can use to employ AMQP as a protocol, the AEM Adapter is specifically tailored to the Advanced Event Mesh Broker.
This adapter utilizes the Solace Message Format (SMF) as the specific message protocol for Solace.

According to the documentation, the main features include the following:

Sender:

Consume Guaranteed (persistent) messages from an advanced event mesh queue
Consume Direct (non-persistent) messages using a Topic Subscription
Number of Parallel Consumers
Choice of Acknowledgement Mode
Adapter-level message retry properties

Receiver:

Publish Guaranteed (persistent) messages to a Topic (recommended) or Queue in advanced event mesh
Publish Direct (non-persistent) messages to a Topic in advanced event mesh
Destination can be dynamically set at runtime via header or property expression
Support for multiple message payload types: Text, Byte, Map message types
Turn publish into a request/reply “Requestor” that send a message to the Destination, sets ReplyToAddress and CorrelationID, and synchronously waits for a response
Set User Properties on outgoing message
Set SMF message properties such as Priority, DMQ Eligible, and CorrelationId on outgoing message

Connection with advanced event mesh broker:

Connect to any broker
Support for various authentication modes such as Basic, Client Certificate, OAuth2
Support for setting less common connection properties

Additional details about the Advanced Event Mesh adapter for SAP Integration Suite are available on the help pages, which can serve as a more detailed reference.

I think this information is sufficient enough to start with, therefore, we can proceed with a practical example both explaining and demonstrating some of these features.

SCENARIO

We will create an Integration Flow both receiving and sending messages from and to Advanced Event Mesh.
The Integration Flow will consume messages through a Queue (guaranteed message) from Advanced Event Mesh and it will be publishing the same message (of course you have the option to modify payload and everything) to a topic endpoint of Advanced Event Mesh again.
We will demonstrate the retry capabilities of the adapter, therefore we will simulate an error case to trigger the retry attempts.

THE INTEGRATION FLOW

Below you can see the Integration Flow in general, including only the necessary simple steps to demonstrate the behaviour and logic.

AEM Adapter Demo iFlow

SENDER ADAPTER DETAILS

For the sender adapter connection & processing details are as follows:

Sender Adapter - Connection Details

Sender adapter processing details

Except the connection details; below parameters are the ones that I found worth going into details

Authentication Type: We use the Basic Authentication for simplicity. We can make use of the secure store for password to keep as Secure Parameter. Other than Basic Authentication, you have the option to use Client certificate and OAuth2 Authentication.
Consumer Mode : Direct for non-persistent messages and Guaranteed for persistent messages
Retry Parameters:
- Maximum Message Processing Attempts determines how many times the adapter tries to process the message. In our case we set it 3 to allow iFlow to try x3 times.
- Retry Interval (in ms) : When using more than 1 maximum message processing attempts, Integration Flow will try in these intervals (depending on the Exponential Backoff Multiplier it determines the next timing of the retry)
- Exponential Backoff Multiplier The multiplier to apply to the current time interval delay after every subsequent retry of a message. 1 means fixed delay.

In our current setup, we will receive and consume persistent messages from the queue using basic authentication. The password has been stored securely in Cloud Integration secure store. For retry attempts, the first attempt will occur within 3 seconds, followed by a second attempt within 6 seconds after the first. The timing of these attempts is like below.

Timing of the failed/retried attempts

RECEIVER ADAPTER DETAILS

For the receiver adapter connection & processing details are as follows:

Receiver Adapter- Connection DetailsReceiver Adapter- Processing DetailsReceiver Adapter- Message Properties Details

There are similar parameters in the receiver adapter. Additional ones we have used are as follows:

Application Message ID: We can use this ID for tracking purposes. It's a string for an application-specific message identifier
Sender ID : For identifying the sender (tracking purposes for end-to-end messaging)
User Properties : You can also set additional parameters (User Properties), which are basicly key-value pair header values. These user properties to be carried in the message separate from the payload.

As per our current setup, I put "SENDER-CIS_AEM_ADAPTER_DEMO_FLOW" as sender ID and use Integration Suite, Cloud Integration to generate a ApplicationMessageID. This ID includes a timestamp in order to make it unique. I am expecting these values to be present while monitoring of the messages.

IFLOW PROCESSING STEPS' DETAILS

In the iFlow, in order to simulate an error situation, I send a header value (bberror) from Postman (which will eventually be attached as a property to my message from Sender Adapter / Queue)
If this value is true (meaning I will simulate error case), the iFlow retries receiving the message based on the retry parameters provided. After multiple retries; it fails again in our case and Advanced Event Mesh moves the message to a DMQ for further processing.
For the inbound message to the iFlow, I also generate a MessageID from Postman and send it to AEM in order to track the messages since the first one. The same ID will also be assigned as the correlationID for the rest of the steps.

Postman - AEM Inbound Message HeaderSetting up properties to use in the flowRouting (for Error or Success case)

After all these are done, eventually the results will be as follows:

Successful path (when bberror is set to false): iFlow will receive the message from AEM adapter and publish the same message to a topic (which leads to a queue in my case)
Successful Message To iFlow-PayloadSuccessful Message To iFlow-Properties

Successful Message from iFlow (Properties)
Error path (when bberror is set to true): iFlow tries to process the message 3x attemps in different intervals(based on the configuration), and finally the message is moved to a dead message queue for further processing.
Error Message in DMQ (Properties)Error (retry attempts)

"SAP Integration Suite adapters provide a means to connect various systems, applications, and data sources within an organization's landscape. They facilitate interoperability and seamless communication between different technologies and systems. While Advanced Event Mesh could be connected via various generic protocols/methods including AMQP, REST, etc., for which Cloud Integration already has adapters, the release of the Advanced Event Mesh adapter for SAP Integration Suite enhances the connectivity and communication capabilities between these two solutions. This enables both SAP and non-SAP ecosystem to benefit from tighter integration and improved communication in multiple Event-Driven and Hybrid Integration use cases."

I hope the information and samples provided will guide you in using the Advanced Event Mesh Adapter and exploring a variety of event-driven scenarios. Below, you can also find links to my other blogs, mentioning other useful features and capabilities of SAP Advanced Event Mesh.

SAP Recognized as a Leader in 2024 Gartner® Magic Quadrant™ for iPaaS

2024-02-29T05:15:00.020000+01:00

We are proud to announce that Gartner has recognized SAP as a Leader in the Gartner Magic Quadrant for Integration Platform as a Service (iPaaS) worldwide. SAP’s Integration Suite was evaluated and based on various factors including reviews of current users of our service. We were recognized as a Leader for the fourth consecutive time. We believe we have received this recognition for the targeted efforts to deliver a customer-centric service with a strong focus on innovation and being future-ready.

Built as a single, comprehensive integration platform, SAP Integration Suite empowers you to integrate and automate processes with speed and confidence across SAP and third-party landscapes. You can leverage our pre-built integrations, APIs, connectors and best practices to design end-to-end automated business processes and deliver innovations that can set you apart from your competition. You can learn more about it here.

SAP is recognized for its ability to execute, we believe this validates our customer-centric approach to product development and evolution. Our innovations which include new integration patterns and artificial intelligence-based features that enhance developer productivity, were rated highly.

We offer a strong commercial and product support presence across all geographical regions. This makes Integration Suite one of the few truly global managed iPaaS offerings suitable for all market segments. We also offer deployment flexibility with our service’s ability to be deployed on client data centers, data centers for regulated industries and private cloud regions.

It gives us immense satisfaction to see that 97% of our customers strongly recommend SAP Integration Suite on Gartner® Peer Insights™. We feel this is an indicator of our customer-focused execution and a shot in the arm for our teams to double down on our roadmap and continue to deliver innovations. Customers also reported that their trust in our roadmap and vision is 4.5% higher than the market average reported by We focus on ensuring that our customers have an enterprise-grade feature set that can help them remain competitive in a market that continues to evolve at a rapid pace, while also ensuring that their investments in SAP Integration Suite is protected for the foreseeable future.

What makes Integration Suite a Leader in the iPaaS Market?

SAP Integration Suite is an AI-assisted integration platform as a service (iPaaS). With this single solution, you can connect applications from SAP and third parties, whether they run on-premise or across clouds. You can use a combination of integration modes to address specific use cases and run your integrations on major public clouds for greater flexibility.

Robust functionality in SAP Integration Suite means you can confidently integrate and manage your mission-critical processes across SAP and third-party applications in complex and distributed landscapes.

Here are some of the key value propositions that we believe set SAP Integration Suite apart from the competition:

Third-Party Connectivity: SAP Integration Suite is a general-purpose iPaaS that can easily integrate with third-party applications as well. We offer 250+ third-party application connectors in addition to protocol-based connectors that can be used to connect with different systems. We also have a strong roadmap to increase the number of non-SAP connectors, further demonstrating our intent to be an excellent all-purpose iPaaS.
Runtime Deployment Flexibility: Depending on your needs and security constraints, you can choose to deploy our runtime in the public cloud, private cloud, within your private data centres, or employ a hybrid setup with runtimes in both public and private regions.
Power of Artificial Intelligence: We at SAP are committed to leveraging artificial intelligence in the Integration Suite to boost developer productivity and insights via behavioural patterns that include mapping proposals, industry-based inter selection and scenario generation. This is a priority topic for us and we are investing continuously to offer a true next-gen integration platform.
Enterprise Automation: We at SAP believe that Process Automation is the key to any digital transformation and our endeavour is to equip you with the tools necessary to build end-to-end intelligent business and IT processes. In combination with SAP Signavio and SAP Build, we offer the perfect enterprise trifecta for Enterprise Automation.
API and Event-Driven Integration: Support for modern integration patterns is a critical aspect of any future-proof iPaaS. Integration Suite supports and offers best practices for both API-centric and event-driven integrations. We offer out-of-the-box 600+ business events and ~4000 APIs on the SAP Business Accelerator Hub, with the number growing at a rapid pace as more SAP LoBs publish their content on the hub.
SAP Process Orchestration Move: We are very cognizant of the fact that many of our customers have significant investments in SAP Process Orchestration, and we are fully committed to helping them transition to Integration Suite with the least business disruption and maximum reusability while staying true to the digital transformation objective. Our migration tools and special programs like Migration Factory focused on migration help customers craft a strategic journey that will ensure the lowest TCO and highest value in their transition from the on-premise SAP Process Orchestration to the hybrid SAP Integration Suite.
Business Integration Content: Getting started quickly by using integration packages infused with business expertise and best-in-class industry experience on the SAP Business Accelerator hub has been one of our unique offerings for our customers. We engage our vibrant community to develop content in a collaborative model and offer it to our customer base. As of today, SAP offers 3400+ pre-packaged Integrations including SAP and third-party integration scenarios.

Summary

We are very grateful for the vote of confidence from our customers, partners, and analysts that has culminated in SAP. We are happy to be recognized as a Leader in Gartner Magic Quadrant for Enterprise iPaaS. We feel, this is validation and it has boosted our confidence that we are heading in the right direction and will further energize us to deliver more customer-centric features and innovations while staying true to our core principles of high developer productivity, happy user experience, and optimized total cost of ownership (TCO).

Where Can I Learn More?

GARTNER is a registered trademark and service mark of Gartner and Magic Quadrant and Peer Insights are a registered trademark, of Gartner, Inc. and/or its affiliates in the U.S. and internationally and are used herein with permission. All rights reserved.

Gartner Peer Insights content consists of the opinions of individual end-users based on their own experiences with the vendors listed on the platform, should not be construed as statements of fact, nor do they represent the views of Gartner or its affiliates. Gartner does not endorse any vendor, product or service depicted in this content nor makes any warranties, expressed or implied, with respect to this content, about its accuracy or completeness, including any warranties of merchantability or fitness for a particular purpose.

Gartner does not endorse any vendor, product or service depicted in its research publications and does not advise technology users to select only those vendors with the highest ratings or other designation. Gartner research publications consist of the opinions of Gartner’s research organization and should not be construed as statements of fact. Gartner disclaims all warranties, expressed or implied, with respect to this research, including any warranties of merchantability or fitness for a particular purpose.

This graphic was published by Gartner, Inc. as part of a larger research document and should be evaluated in the context of the entire document. The Gartner document is available upon request from SAP.

CloudEvents at SAP 🌁

2024-03-04T07:13:27.857000+01:00

TLDR; SAP is an active contributor to the CloudEvents specification and it has adopted the specification for describing event data in common formats to provide interoperability across its services/applications/systems. In the SAP Business Accelerator Hub, you can find all the events exposed by a total of 17 different SAP services that publish events following the specification, including its flagship ERP products, SAP S/4HANA Cloud public edition and SAP S/4HANA, exposing more than 600+ events combined. To enable seamless event-based integrations between SAP applications, SAP applications must conform to the CloudEvents specification. SAP also offers three services, part of the SAP Business Technology Platform (SAP BTP), that can help customers embrace event-driven architectures, these are: SAP Event Broker for SAP cloud applications, SAP Event Mesh, and SAP Integration Suite, advanced event mesh.

Before we dive into how CloudEvents have been adopted within SAP, we might need to talk a bit about what an Event-Driven architecture is and what a CloudEvent is as well. Let's get started.

📢A new Developer Challenge will be announced later this week. The challenge will focus on CloudEvents and Event-driven architectures. Stay tuned for more 📺.

Event-Driven Architectures

Long gone are the days when a system (aka target system) will constantly poll to check if there are any changes in another system, e.g. a new customer created in a master data system. Traditionally, the target system will only know this by programming a routine that will poll a file share and check for any files produced by this system or a web service exposed in the source system, every X minutes/hours/days. The expectation nowadays is that systems are integrated and that the data exchanged between these systems will be immediately available in the target system(s) if any data is created/changed in the source system. Enter Event-Driven architectures.

An Event-Driven Architecture is a software architecture paradigm concerning the production and consumption of events. An event can be defined as a significant change in the state of an object within a system[1]. For example, when a customer/supplier/employee (business object) is created/updated/deleted ( action) in a system. Translating this to the SAP world, when a Business Partner is created/changed in SAP S/4HANA (source system), SAP S/4HANA can notify that there was a change in a business object and target system(s) interested in the Business Partner object can then react and trigger follow-up activities in their systems.

How do source and target systems communicate?

Now, if the source system lets other systems know of any changes happening in its business objects, it will not be sustainable to create a new programming routine within the source system every time we want to notify a new target system of any changes. Traditionally we would have some form of middleware, e.g. SAP Cloud Integration, and configure our source system, an SAP S/4HANA system, to send notifications of these events to the middleware and then use the middleware to distribute these messages, e.g. we would add target system(s) as needed. Now, we are moving the problem from the source system to a sort of middleware but ideally, there will be a way for the source system to notify others without the need to make any changes. Enter the event broker.

An event broker is message-oriented middleware that enables the transmission of events between different components of a system, acting as a mediator between publishers and subscribers. It is the cornerstone of event-driven architecture, and all event-driven applications use some form of event broker to send and receive information[2].

By introducing an event broker in our landscapes, we can configure our source systems to publish their events to this message-oriented middleware. The source system will specify the class of the message (aka topic). Then, systems interested in the changes happening, e.g. in a particular business object in the source system, can subscribe to the event(s), via the event broker, by specifying the topic they are interested (topic-based filtering) in or it can also be based on the content of the message (content-based filtering). There are two keywords important here, publish and subscribe (PubSub), this is a well-known messaging pattern used to decouple systems/applications and allow asynchronous communication between them.

What is the PubSub messaging pattern?

Publish-subscribe is a communication pattern that is defined by the decoupling of applications, where applications publish messages to an intermediary broker rather than communicating directly with consumers (as in point-to-point)[3]. In a way, publishers and consumers do not need to know each other; they simply publish (produce) or consume (receive) the events. When following this messaging pattern we move from the traditional polling mechanism to know if there have been any changes in the source system to reacting to real-time events (notifications) the moment something happens in the source system.

A subscriber (consumer), is generally only interested in a subset of the messages published. Normally, a message-oriented middleware will provide subscribers with a mechanism to set filters on the data that they want to receive. There are two common ways of filtering: topic-based and content-based[4].

Topic-based filtering

We mentioned before how target systems can subscribe to events by specifying a topic they are interested in.... some event brokers will allow subscribers to subscribe to topics by using wildcards (*) and they will be able to receive only the events they are interested in, which can be for different topics. For example, let's assume we have an SAP S/4HANA with the name S4D and it publishes the Business Partner create and change on the following topics: sap/S4HANAOD/S4D/ce/sap/s4/beh/businesspartner/v1/BusinessPartner/Created/v1 and sap/S4HANAOD/S4D/ce/sap/s4/beh/businesspartner/v1/BusinessPartner/Changed/v1. A subscriber system could subscribe to both topics using a wildcard, e.g. sap/S4HANAOD/S4D/ce/sap/s4/beh/businesspartner/v1/BusinessPartner/*/v1 and receive the messages for both event types. In this case, we are filtering the message by topics.

Content-based filtering

In some other cases, the event broker will allow the subscriber to specify which messages they want to receive, based on the attributes or content of the message. For example, the message sent to the event broker can contain attributes that describe the message and we can do some filtering based on the values of those attributes. Note: An example is shared later, on how attributes in a message (CloudEvent) can be used to define filters.

SAP offers different services that can act as event brokers. We will discuss this further in the SAP's event-driven portfolio section.

With many systems in our landscapes and each one being developed by different vendors/teams, it would be good if there was a standard way of structuring these events to simplify how systems create/handle/process these messages right? Enter CloudEvents.

What is CloudEvents?

Today's system landscapes are very complex and we need to deal with many systems communicating with each other, ideally as close to real-time as possible. Nowadays, a system can publish events to notify other systems of the changes happening within the objects of their system. Given that we are talking of many systems, ideally, there will be a common way of describing the data produced by these systems. The CloudEvents specification can help us with this. We can leverage it to provide a consistent way for how our systems can communicate with others about these events.

As mentioned on the CloudEvents website... CloudEvents is a specification for describing event data in a common way. It's goal is to simplify event declaration and delivery across services, platforms and beyond! The specification is now under the Cloud Native Computing Foundation.

Below is an example of what a CloudEvent message will look like:

{
  "specversion": "1.0",
  "type": "com.github.pull_request.opened",
  "source": "https://github.com/cloudevents/spec/pull",
  "subject": "123",
  "id": "A234-1234-1234",
  "time": "2018-04-05T17:31:00Z",
  "comexampleextension1": "value",
  "comexampleothervalue": 5,
  "datacontenttype": "text/xml",
  "data": "<much wow=\"xml\"/>"
}

You'll notice that the example above is composed of many attributes, the event context. The context describes the event and is independent of the event data. Meaning that we can somehow process/inspect the event without needing to process its data. Now, let's dive a bit into the message itself.

For more information on the history, development and design rationale behind the specification, see the CloudEvents Primer document.

CloudEvents message format

A CloudEvent message is mainly composed of context attributes and data.

Context Attributes

A number of attributes can be included within the message, these attributes are known as Context Attributes and the idea is that these context attributes can be used to describe the event. We can think of these context attributes as the header information of our event that can be used for filtering and routing. Let's explore some of the attributes available.

Name	Required	Description	Example
id	✅	Identifies the event. Producers MUST ensure that source + id is unique for each distinct event.	63d6a150-c6a1-4c5b-bcc3-27d90c07941c
source	✅	Identifies the context in which an event happened.	/default/sap.s4.beh/244572008
specversion	✅	The version of the CloudEvents specification which the event uses.	1.0
type	✅	Describes the type of the event	sap.s4.beh.businesspartner.v1.BusinessPartner.Changed.v1
datacontenttype		Content type of the value in data.	application/json

Extension Context Attributes

A CloudEvent message may also include additional context attributes, which are not defined as part of the specification. These additional attributes are known as "extension attributes" and can be used by the producer systems or intermediaries to include additional metadata to an event, similar to how we can use HTTP custom headers.

For example, in the SAP Digital Vehicle Hub Business Events package, we can see that the event raised when a vehicle changes - sap.dmo.dvh.Vehicle.Changed.v1, contains the extension context attribute sappassport, which is an SAP specific tracing identifier.

{
  "specversion": "1.0",
  "type": "sap.dmo.dvh.Vehicle.Changed.v1",
  "source": "/eu10/sap.dmo.dvh",
  "subject": "808E6E30B65149978A443429B29FB300",
  "id": "a823e884-5edc-4194-a81a-f3a3632417ee",
  "time": "2018-04-08 08:31:00",
  "datacontenttype": "application/json",
  "sappassport": "string",
  ....
}

Data

A CloudEvent message may include a payload but this is not required. If included it will be in the format specified in the datacontenttype context attribute. Although it is not required, we will generally have a payload in messages. Below we can see an example of an event message that contains a payload. In this case, a Business Partner changed event generated by an SAP S/4HANA Cloud Public Edition.

{
    "type": "sap.s4.beh.businesspartner.v1.BusinessPartner.Changed.v1",
    "specversion": "1.0",
    "source": "/default/sap.s4.beh/244572008",
    "id": "63d6a150-c6a1-4c5b-bcc3-27d90c07941c",
    "time": "2024-02-26T10:53:06Z",
    "datacontenttype": "application/json",
    "data": {
        "BusinessPartner": "1000667"
    }
}

Check out the Business Partner changed event in the SAP Business Accelerator Hub - https://hub.sap.com/event/CE_BUSINESSPARTNEREVENTS/resource.

SAP's adoption of CloudEvents

SAP is an active contributor to the CloudEvents specification and one of its many adopters. Evidence of that is the different products (event packages) that we can find documented in the SAP Business Accelerator Hub > Events category.

The products listed below document their events in the form of event packages in the SAP Business Accelerator Hub. All their events follow the CloudEvents specification:

SAP Agricultural Origination Portal
SAP Batch Release Hub for Life Sciences
SAP Cell and Gene Therapy Orchestration
SAP Cloud for Utilities Foundation
SAP Digital Vehicle Hub
SAP GRC Cloud - Issue Management and Remediation Service
SAP Industry Process Framework
SAP Intelligent Clinical Supply Management for Operations
SAP Intelligent Clinical Supply Management for Planning
SAP Landscape Management Cloud
SAP Marketing Cloud
SAP Order Management Foundation
SAP S/4HANA
SAP S/4HANA Cloud Public Edition
SAP S/4HANA Utilities for Customer Engagement
SAP S/4HANA for Procurement Planning Cloud
SAP Subscription Billing

SAP's flagship ERP products, SAP S/4HANA Cloud Public edition and SAP S/4HANA, expose more than 600+ events combined. As you might have noticed from the events that we use as examples above, these events follow the CloudEvents specification. Below we can see the BusinessPartner Created event generated by an SAP S/4HANA Cloud Public Edition and we can see how it follows the CloudEvents specification.

{
    "type": "sap.s4.beh.businesspartner.v1.BusinessPartner.Created.v1",
    "specversion": "1.0",
    "source": "/default/sap.s4.beh/244572008",
    "id": "194780e0-b5db-1ede-b58a-4550178dff9e",
    "time": "2024-02-26T09:50:00Z",
    "datacontenttype": "application/json",
    "data": {
        "BusinessPartner": "1000667"
    }
}

Kyma

Kyma contains an Eventing module, which provides functionality to publish and subscribe to CloudEvents. It follows the PubSub messaging pattern and all events in Kyma conform to the CloudEvents specification[5]. At the moment, NATS (provided by the NATS module) and SAP Event Mesh are supported as backends for eventing and it is recommended to use the CloudEvents specification for sending and receiving events. Even the legacy events are automatically converted to CloudEvents.

SAP's event-driven portfolio

SAP offers various services that can help customers embrace event-driven architectures. The different offerings can meet customers where they are in their EDA adoption/implementation journey. These are:

SAP Event Broker for SAP cloud applications
SAP Event Mesh
SAP Integration Suite, advanced event mesh

SAP Event Broker for SAP cloud applications

SAP Event Broker is the latest service released by SAP that focuses on event-driven architecture and it supports event-based integration between SAP cloud and BTP-based applications. It is a fully managed cloud service that allows SAP cloud applications to communicate asynchronously through events. Meaning it can be used to distribute events between SAP cloud applications. For example, this service can be leveraged to enable seamless integration between SAP S/4HANA Cloud public edition and SAP Subscription Billing. When an integration scenario leverages SAP Event Broker, it eliminates having to configure an event storage or infrastructure such as customer-defined topics or queues to enable the event-based integration between systems.

Integration between SAP S/4HANA Cloud and SAP Subscription Billing

CloudEvents are first-class citizens in SAP Event Broker, as events that are distributed between SAP cloud applications using SAP Event Broker all conform to the CloudEvent Specification[6]. Evidence of this is how we can filter SAP event subscriptions by defining filters based on the CloudEvent context attributes, e.g. by filter by type, subject, or extension context attribute. Note: This is an example of content-based filtering taking place in the message-oriented middleware.

If all your event needs are within the SAP cloud world, e.g. exchange events between SAP cloud applications and SAP BTP, this service can fulfill your needs.

SAP Event Mesh

SAP Event Mesh allows applications to communicate through asynchronous events. It can be used to publish and consume business events from SAP and non-SAP sources across hybrid landscapes from the digital core (ERP products, e.g. SAP S/4HANA Cloud public edition and SAP S/4HANA) to extension applications through event-driven architecture. It is a fully managed centralised event-oriented service part of SAP BTP.

The service supports the use of REST APIs for Events, for publishing and consuming events that are compliant with the CloudEvents specification. Related to event-based integrations, events that flow through SAP Event Mesh between SAP applications must all conform to the CloudEvents specification.

You can check out how to enable the consumption of SAP S/4HANA Cloud public edition events in your SAP BTP account - https://youtu.be/4LspIL3NxqQ

SAP Integration Suite, advanced event mesh (AEM)

SAP Integration Suite, advanced event mesh (AEM) is a complete event streaming, event management, and monitoring platform that incorporates best practices, expertise, and technology for event-driven architecture (EDA) on a single platform. With AEM you can deploy event broker services, create event meshes, and optimise and monitor your event-driven system.

AEM offers these categories of services:

Event Streaming: It provides event streaming services and gives you access to event broker services that provide advanced features like the publish-subscribe messaging pattern, queuing, streaming, replay, and request-reply, while doing all the heavy lifting to dynamically deploy, upgrade, patch, and operate the service. It extends beyond the cloud and supports infrastructure and EDAs across hybrid cloud solutions and your on-premises deployments.
Event brokers can be deployed to: public clouds administered by SAP (Public Regions or Dedicated Regions) and customer's own regions in the cloud or on-premises (Customer-Controlled Regions)
Event Management: It provides event management services. The Event Portal provides powerful tools to create, design, share, and manage various aspects of your EDA based on event brokers or other streaming technologies. It fully supports the AsyncAPI 2.0.0 specification so that you can generate code, documentation, validate events, and apply API management policies for applications in your EDA.
You might have noticed that some event specification in the SAP Business Accelerator Hub are documented using the AsyncAPI specification, e.g. Marketing Campaign Events part of SAP Marketing Cloud.
Event Monitoring and Insights: Availability out-of-the-box of dashboards and easy-to-understand visualizations based on historical and real-time metrics, and timely notifications about the event broker services deployed.

Similar to SAP Event Mesh, it can be used to publish and consume business events from SAP and non-SAP sources across hybrid landscapes. Meaning, if your event data needs to exit the SAP cloud world, you can use any of these two services.

Thanks for making it this far, we've covered a lot in this blog post and I hope it gives you a general understanding of CloudEvents, its importance in the SAP world, how it can enable integration across SAP applications and the different SAP offerings that can enable your EDA journey.

Special thanks to Klaus Deissner (@klaus_deissner) for reviewing and contributing to this blog post.

Event-Driven architecture: link ↩️
What is an event broker?: link ↩️
What is the publish-subscribe messaging pattern?: link ↩️
Publish-subscribe pattern - Message filtering: link ↩️
Eventing module in Kyma: link ↩️
SAP Event-Driven integrations: link ↩️

Originally published at ajmaradiaga.com.

Unleashing Connectivity & Efficiency:Explore the Potential of SAP Event Mesh & Connectivity with CPI

2024-03-06T09:40:04.614000+01:00

Introduction: In the present hyper-connected digital landscape, seamless communication and data exchange are paramount for business success. Event Mesh is a transformative solution designed to revolutionize event-driven architectures and streamline integration processes across hybrid cloud environments. In this blog post, we will explore the capabilities and benefits of Event Mesh, and how it empowers organizations to unlock new levels of connectivity, efficiency, and agility.

Understanding Event Mesh: Event Mesh represents the next frontier in event-driven architecture, offering a distributed messaging backbone that enables real-time communication between applications, services, and systems. By decoupling producers and consumers of events and providing reliable, asynchronous messaging capabilities, Event Mesh makes the way for seamless integration and makes complex thing easier to integrate, helps with the distributed environments.

Features:

Lets Explore few features of Event mesh which priors it in the application world of event-driven architecture.

Publish Business Events

This feature of Event mesh can publish the business events from SAP and non-SAP through event-driven architecture across the hybrid landscapes from the digital core to extension applications.

Connect seamlessly

Seamless data transmission can be obtained for the extension and integration scenarios through decoupled communication

Consume business events

Consumes all the business events from SAP and non-SAP where it includes SAP Extension suite, SAP Integration suite etc. throughout SAP's event-driven ecosystem.

Benefits of Event Mesh:

Decoupled Architecture: Decoupled Architecture enhances agility, flexibility and Innovation, Event mesh promotes Decoupling between the systems and applications enabling independent and disrupting overall functionality.

Scalability: Event mesh provides scalable and resilient event-driven communication it increases the workload demands, It supports vertical and horizontal scaling to accomplish changing business requirements

Real-Time Data Processing: Event mesh enables organizations respond and process the critical events and data in Real-Time. Also supports the agile decision making, improve operations efficiency and enhance customer experiences.

Reliability and Resilience: Event mesh ensures the reliable message delivery and fault tolerance it enhances system reliability and availability.

Now lets explore a little about Advances event mesh.

Advanced event mesh : Advanced event mesh for SAP Integration Suite is a complete event streaming, event management, and monitoring platform that incorporates best practices, expertise, and technology for event-driven architecture (EDA) on a single platform.

Lets learn more about Event mesh and Comparison of Event Mesh and Advance Event Mesh.

Feature	Event Mesh	Advanced Event Mesh
Functionality	It has Basic Capabilities for event-driven communication	It has enhanced capability that's been build upon event mesh
Scalability	Provides certain scalability	Provides the Optimized scalability for enterprise deployments
Performance	It may have limitations to handle high volume of event data	Delivers the Optimized performance for handling massive event traffic
Resilience	It has Impactful Fault tolerance and message delivery	Effective with its enhanced resilience with features fault recovery and message persistence
Management and Monitoring	Has basic management and Monitoring capabilities	Has Advance Analytics, dashboards and alerting mechanisms
Integration support	Supports integrating different systems, applications and protocols	Extends integration capabilities with different protocols

Basic Set up / Connectivity of Event Mesh with AMQP receiver Adapter:

Step-1:

In BTP cockpit account, go to service marketplace search and select Event Mesh.

Step -2:

Create and subscribe to Event mesh.

After going into event mesh tile, there is an option to create it, once you create as below it will be subscribed

Step-3:

After the Event mesh is subscribed you need to create an Instance named as enterprise message, and also the User Groups, Role collection and assign the role collection.

Note: The Instance cannot be created in trial account can be created only in the Tenant account as the service is no longer available.

While creating an Instance, it is required configure namespace in either JSON or form with required details.

Step-4:

Once the the above configurations are done, the event mesh is enabled, where you can have different functionalities to work on.

Now lets see the Connectivity of Event Mesh with Integration suite. Here we can discuss how can we connect to event mesh from Integration using AMQP Adapter.

Step-5:

In the integration suite, the basic sender receiver connectivity between integration and event mesh we can obtain by providing the destination details as per your event mesh details maintained. And in the connection you can give the details of Host, port and path and then we can save, execute.

we can observe the connectivity established.

we can also explore by connecting the receiver adapter with open connectors to integrate it with other SAP/Non-SAP systems for the wide business requirements.

Thanks! for reading through my Blog, please share your feedback and Insights which helps to make the content even better. I will be sharing more detailed blogs on Advanced Event mesh and Integration suite.

Have a Great Day!

The State of Integration – Research from ASUG and SAP

2024-03-07T21:19:30.312000+01:00

Integration is not only a technological investment, but also strategically imperative across organizations to thrive in today’s digital economy. Through the research conducted by ASUG, we know that the integration topic is highly relevant for ASUG members with almost all being actively involved in integration projects. The study also highlighted how SAP Integration Suite is being used today.

ASUG discovered that many customers use a wide range of connections with SAP applications including SAP SuccessFactors and SAP S/4HANA, but they are also connecting with a multitude of other non-SAP application types and in their landscapes. The ASUG research shows our customers growing diversity in their application landscape confirming the need for seamless integration across all application types. We have seen more customers connecting with non-SAP applications and these results validate what we have seen across our customer base. There are an equal number of integrations between SAP to SAP applications and SAP to 3rd party applications. Interestingly, over half of those surveyed are connecting non-SAP to non-SAP which speaks to the comprehensive set of features we have in Integration Suite.

The ASUG study also noted that 90% of respondents face challenges with integrations, with a wide array of issues experienced such as lack of internal skills/resources, data inconsistencies, and budget constraints top the list. However, many benefits can be realized from integrating data, processes, and/or applications. They include:

Improved use of data and analytics
Streamlined business processes
Better application adoption and use.

More than 1/3 of users also find realized value by using intelligence to drive business decisions and to collaborate with others.

Listen to this webcast to learn more about how customers see having an integration strategy is critical, the benefits of implementing an integration strategy, the types of landscapes and applications they are integrating, what capabilities are most used, and what common challenges users experience with integration. Here’s a synopsis of the study.

SAP Enterprise Architecture: Positioning Blockchain Database as an Enterprise Technology Standard 🚀

2024-03-08T19:19:41.200000+01:00

This blog, which follows on from the previous one in the series, "Why I love SAP and Blockchain Databases and why you should too 🚀", will deliver an approach to positioning Blockchain Technology as a Technology Standard in our Companies.

The goal of the previous blog in this series was to get us thinking about Blockchain Databases in our Companies, in the Enterprise, and the goal of this blog is to get us thinking about how to position an Enterprise Blockchain Platform as a Technology Standard in our SAP Enterprise Architecture.

Why do we need to do this ? Why does Blockchain need to be a Technology Standard within the Enterprise Architecture in our Companies ?

In our SAP Enterprise Architecture we use Technology Standards as a way of framing where we use what software applications and why, what is the purpose of that software application.

So for each Technology that we have in the house, we have a box which describes what that Technology and do, what it's strengths are, and therefore where we should use it.

This all sounds very formal, but in our personal lives we do this at home every day. We possibly have more than one pair of shoes, perhaps one pair for going to the office and one pair for going running. I don't really want to get in to a debate about how many pairs of shoes people have and which ones they use for what but I imagine that you get the point.

Some shoes are more suited to different activities than others. Some have a hard sole some have a soft sole. These are capabilities of the shoe, soft sole leans towards capability for sport, thanks to this soft sole capability the shoe is more appropriate to be used for, to be applied to sport, You get the point.

And it's the same with software, some software is more suited to different activities than others, these are capabilities. And by keeping a list of what software we have in the company and what the capabilities of the software are, and where the software is encouraged to be used, helps to ensure that in our SAP Enterprise Architecture decision making processes we more consistently use the different types of software that we have for the purposes in which they are intended based upon what they can do.

To be more formal, there is a very nice description of Technology Standards here, 'At the most basic level, technology standards establish boundaries for technology usage, specifying technology to be used (acceptable use) and restricting access to technology that is deemed "non-standard"'.

If we agree that to be able to consistently, repeatedly use Enterprise Blockchain Databases in our Companies we need to classify where we should use the Enterprise Blockchain Databases and why, then the first step is to write down all of the things that Enterprise Blockchain Databases is good for, what it can do, where it is strong, what the capabilities are.

Capabilities means what is it good for what is it good at ? What can it do ? Let's try to group the capabilities together where it makes sense. The most important capabilities and enablers of Enterprise Blockchain Databases and on a wider scale the Enterprise Blockchain Platforms, from the high level view, revolve around Data across the dimensions of:

Security / Privacy

Availability / Resilience

Collaboration / Sharing

Orchestration

Web3 / Tokenization / Wallet / SDK / Smart Contracts

Mobility / Edge

Integrations / Connectivity / Blockchain Bridges and Bridging

Types of Blockchain

Artificial Intelligence

Let's go through these capabilities one by one and think of all of the words we can around the dimension and picture what it actually means.

Enterprise Blockchain Database Capability - Security & Privacy

Capability/Enabler: Secure, Immutable, Trust, Cannot be modified, Tamperproof, Protect, Safe, Proof, Auditable, Confidentiality, Integrity, Originality, Transparency, Privacy

Why are Blockchain Databases so strong in this: As we discussed in the previous Blog in this series, Blockchain Databases have four special characteristics that make them a Blockchain Database, and those are, Immutable, Hash Mechanism, Distributed/Decentralised, Consensus Mechanism.

Regarding the Security & Privacy capability, it is the Immutable and Hash Mechanism and Consensus Mechanism which make the Blockchain Database so natively security hardened out of the box and in fact security hardened natively out of the box to a level which most conventional databases are not.

In terms of the NIST CIA Triad for Data Security, Criticality, Integrity, Availability, Enterprise Blockchain Databases comes in Very High across all three classifications.

Blockchain Security SAP NIST Triad atkrypto.io

Enterprise Blockchain Database Capability - Availability & Resilience

Capability/Enabler: Resilience, Distributed Multi Region, Distributed, Decentralised, Network Database, High Availability, Disaster Recovery, Business Continuity Planning

Why are Blockchain Databases so strong in this: Again, as we discussed in the previous Blog in this series, Blockchain Databases have four special characteristics that make them a Blockchain Database, and those are, Immutable, Hash Mechanism, Distributed/Decentralised, Consensus Mechanism.

Regarding the Availability & Resilience capability, it is the Distributed & Decentralised characteristics which make the Blockchain Database so natively resilient out of the box and in fact resilient natively out of the box to a level which most conventional databases are not.

An Enterprise Blockchain Database is a Network Database. When one of the Servers is down, the other Servers are up, A Server can go down and when it comes back up it will automatically synchronise with the rest of the Enterprise Blockchain Database Network. This is really suited to Business Continuity Planning.

Blockchain for BCP Business Continuity Planning atkrypto.io

Enterprise Blockchain Database Capability - Collaboration / Sharing

Capability/Enabler: Single Source of Truth, Shared Single Source of Truth, Multi-Party Collaboration, 3rd Party Collaboration, Common Store of Data, Sharing, Collaboration, Master Data Store, Distributed Data, Network Database, Track and Trace, Traceability, Audit, Auditability

Regarding the Collaboration / Sharing capability, it is the Distributed & Decentralised characteristics which make the Blockchain Database so natively supporting Collaboration / Sharing out of the box and in fact supporting Collaboration / Sharing natively out of the box to a level which most conventional databases do not and can not, without additonal Clustering and Networking software.

An Enterprise Blockchain Database is a Network Database. This means the Database is running active on multiple Servers in multiple locations. As was described in the previous blog, McKinsey & Company, in their December 2023 Featured Insights Publication, gave a beautiful description of what is unique and special about Blockchain, "Blockchain is a secure database shared across a network of participants, where up-to-date information is available to all participants at the same time".

And this is what is so important and so special. When we install the Blockchain Database Server in two different Company's DataCenters (or as Blockchain as a Service in the Cloud) and establish a Database Ledger on the Servers we enable the two Company's to share Master and Transactional Data while knowing that neither can modify the Data which has been shared. This is really suited to sharing Data across the Enterprise or across Enterprises.

Blockchain as a Shared Single Source of Truth atkrypto.io

Enterprise Blockchain Database Capability - Orchestration

Capability/Enabler: Data Orchestration, Data Integration, Network Database, Instructions Communication, Data Delivery, Sending Data, Data Transfer, Data Connection

Regarding the Data Orchestration, it is again the Distributed & Decentralised characteristics which make the Blockchain Database so natively supporting Data Orchestration out of the box and in fact supporting Data Orchestration natively out of the box to a level which most conventional databases do not and can not, without additonal Clustering and Networking software and all of the extra effort that that brings. An Enterprise Blockchain Database is a Network Database.

This means the Database is running active on multiple Servers in multiple locations. As was described in the previous blog, McKinsey & Company, in their December 2023 Featured Insights Publication, gave a beautiful description of what is unique and special about Blockchain, "Blockchain is a secure database shared across a network of participants, where up-to-date information is available to all participants at the same time". And this is what is so important and so special.

When we install the Blockchain Database Server in two different locations / DataCenters (or as Blockchain as a Service in the Cloud) and establish a Blockchain Database Ledger on the two or more locations' Servers we enable a situation where one Datacenter can put data onto the Blockchain, which is in fact an instruction for an action from an Application which is reading from the Blockchain in the other Datacenter. What this leads to is Data Integration at a level which is not possible with End to End Encryption and Encryption of Data at Rest alone.

Today Companies send Data to each other, with Blockchain Companies will write to and read from the same Blockchain Database Table. This is really suited to Orchestrating Data across the Enterprise or across Enterprises. In the following example we see how instructions to a Third Party Logistics company can be orchestrated across the Enterprise Blockchain running between the two companies.

SAP Master Data Integration and Orchestration with Blockchain atkrypto.io

Enterprise Blockchain Database Capability - Web3 / Tokenization / Wallet / SDK / Smart Contracts

Capability/Enabler: Web3 Foundation, Digital Asset Tokenization, Digital Wallet, Software Development Kit, Smart Contracts, Business Logic, Extension, Programming, Customisation

Tokenization is a combination of all of the Blockchain characteristics in one. Tokenization is the action of creating a Block on the Blockchain which is a Digital Token. The Digital Token is the digital representation of the information which has been stored on to the Blockchain.

With Tokenization comes a Wallet to store the Tokens in, it can be argued that the Wallet is not a classic capability of the Blockchain, but rather a capability of the Blockchain Platform.

A Software Development Kit is also not a classical characteristic or capability of the Blockchain, but rather a capability of the Enterprise Blockchain Platform. The SDK enables Developers to develop Decentralized Applications which run on top of the Blockchain.

And Web3 is the culmination or the whole of all of these capabilities and some more. The capabilities listed here go a long way to making up the core foundation of Web3. There is a nice overview of Web3 here in the SAP Community, including the following drawing:

Enterprise Blockchain Database Capability - Mobility / Edge

Capability/Enabler: Mobile, Mobility, Edge, IoT, Wireless, Move, Industry 4.0, Smart Everything, Connected Everything

The Distributed/Decentralised characteristic of the Blockchain Database Technology is what is so special here. As discussed above the Distributed characteristic of the Blockchain enables us to have a database which is networked between two locations.

It's this network database, and another fact which make Blockchain Databases so interesting for Edge/IoT/Mobile.

The other fact is the anologue to digital transformation of Things and the network getting closer to the Things at the Edge.

In the past Data was pretty much centralised to the DataCenter.

Things like Thermometers (in Pharmaceutical and Food Production), Maps & Compasses in Delivery Vehicles, Instructions on Paper, Locks on Doors, Photographs and Video, all of these Things were analogue. And now, all of these Things are going through a digital transformation, in two aspects, they are able to create digital representation of facts, and they are connected to the Network, and in some cases they even have larger computational power and can do business/processing logic and therefore are Smart Things. Thermometers are now connected to the Network, same for Maps and Compasses in Delivery Vehicles (GPS Location and navigation), Paper based Instructions are now electronic, Locks on Doors are now electronically monitored and controlled from the Network, Photographs and Video are now digital and connected to the network. And all of things Things are connected to the Network,the Edge of the Network, because they are the final point of the Network and together they make up the Internet of Things.

And so all of these Things are producing Data at the Edge of the Network. And this is where Blockchain comes in, Blockchain, for all of the reasons above is natively out of the box the most security hardened and resilient Database for protecting the integrity and confidentiality and originality of Data from the Edge.

The Capability and Enabler, Mobile / Edge / IoT comes in to play regarding having a Enterprise Blockchain Platform Server Node as close to the Edge as there is computational power, eg, on the Device, in the Connected Vehicle, or in the 5G Network IoT Gateway.

Do we take the Data from the Edge to the Blockchain or do we take the Blockchain to the Data at the Edge.

The most elegant is to take the Blockchain Mobile and to the Data at the Edge.

Surely the most secure way, is to protect the originality, integrity, confidentiality of the Data, at the Source, at the Edge, or as close to the Source as there is enough computational power to run a light Blockchain Database Server Node ? We will discuss this in detail in subsequent blogs.

Enterprise Blockchain SAP IoT Edge Mobile Vehicle to Insights Connected Everything atkrypto.io

Enterprise Blockchain Database Capability - Integrations / Connectivity / Blockchain Bridges and Bridging

Capability/Enabler: Integration, Integrator, Connection, Connectivity, Connector, Bridge, Blockchain Bridge, Bridging

This capability mainly revolves around the Distributed/Decentralised characteristic of the Blockchain.

This capability has a several different dimensions:

Getting Data in to the Blockchain

There are basically two clear leading options for getting Data in to the Enterprise Blockchain Platform, and those are:

API's

API's, there is nothing wrong with API's and there must always be API access to the Blockchain, for writing and for reading. For writing I see the API as more reactive than real time, and for reading data from the Blockchain API is the obvious choice.

There is a very nice blog in the SAP Community which favours Events over API's and personally I also lean that way for the majority of cases for writing data to the Blockchain. The blog is here: APIs: our flawed legacy from 1960’s thinking.[thanks to my friend Thomas Kaiser for finding that one]

Events

For me the biggest reason for using the Enterprise Blockchain Platform is the incredibly high level of security hardening and Data protection that it natively brings.

If we agree we will be more often positioning the Enterprise Blockchain Platform because of its security strengths, then next dimension is to write Data to the Enterprise Blockchain Platform as close to the source of that Data as possible no matter where the Data is, Edge or DataCenter.

The next dimension is that in the majority of cases, we will want to write the Data to the Enterprise Blockchain Platform as early as we can in the lifetime of the Data, ie, as soon as the Data was created.

If we want to write Data to an Enterprise Blockchain Platform as soon as the Data is created then the obvious technology for getting the Data to the Enterprise Blockchain Platform is Events, Event Driven Blockchain. I will be discussing this in detail in the later blogs which will deep dive in to individual use cases and reference architecture.

The Blockchain as a Data Integrator across the Organisation or Organisations

This capability crosses over with the Data Sharing capability. Basically the Enterprise Blockchain Platform becomes a Data Integrator within the Enterprise.

In a number of use cases the Enterprise Blockchain Platform could replace classical API based Integrations. In scenarios where there are Data Integrations between Applications, for example between Salesforce and SAP S/4HANA, instead of doing an API based Integration and only have security and protection to the level End to End Encryption, there could be an Enterprise Blockchain where Salesforce writes to the Enterprise Blockchain and SAP S/4HANA reads from the Enterprise Blockchain. This will be discussed in subsequent blogs which will deep dive in to use cases and reference architecture.

Bridging between Blockchains

This is a very important capability of Enterprise Blockchain Platforms and enables that Data can be bridged between Blockchains.

SAP S4HANA BTP Blockchain Web3 Reference Architecture Example atkrypto.io

Enterprise Blockchain Database Capability - Types of Blockchain

Capability/Enabler: Public, Private, Semi-Private, Consortium, Bridge

This capability mainly revolves around Layer 0 of the Blockchain Architecture, which is the Blockchain Network. An Enterprise Blockchain Platform which enables the Customer to create their own Blockchain Network will most likely have the best capability to enable the Customer create the Blockchain of their choice.

The main classifications of Blockchain Database are nicely described in this article from SAP, What is blockchain technology?.

SAP Article What is Blockchain Types of Blockchains atkrypto.io

Enterprise Blockchain Database Capability - Artificial Intelligence

Capability/Enabler: Integrity, Auditability, Traceability, Originality, Confidentiality, Protection, Safe, Treasure, Surety, Certainty, UnCompromised, Intelligent Technologies, Smart Technologies

This capability mainly revolves around Security characteristics of the Blockchain Platform and Database.

For Artificial Intelligence outcomes to be trustworthy, it must be certain that the Data used for the Artificial Intelligence can not have been altered.

That's it, it's as simple as that, if we want to trust what AI is telling us, then we need surety and certainty that the integrity and originality of the Data which the AI used cannot be or have been compromised.

Intelligent Technologies, for Intelligent Technologies to be intelligent, they cannot depend on stupid Data !

Smart Technologies, for Smart Technologies to be smart, they cannot depend on stupid Data !

That's where the Blockchain comes in.

SAP What is an Intelligent Sustainable Enterprise atkrypto.io

Now that we have elaborated on all of the capabilities and enablers of Enterprise Blockchain Databases and Enterprise Blockchain Platforms, let's get back to the goal of positioning Enterprise Blockchain Database and Platform as an Enterprise Technology Standard.

Before we do that, let's recap on the capabilities and enablers and summarise them:

Enterprise Blockchain Platform Capability Layers Map courtesy of Jan Tuma (TOGAF Certified SAP Enterprise Technical Architect) - atkrypto.io

In SAP Enterprise Architecture there is only one place to run the Enterprise Blockchain Platform, and that is, right next to the Digital Core S/4HANA in the "enabler", the SAP Business Technology Platform.

Why place the Enterprise Blockchain Platform in the SAP BTP ?

It's very very simple....

Proximity to the Data (of the Digital Core)

Ethnicity of the Data (in the Digital Core)

Proximity to the Process(es) (in the Digital Core)

Proximity to the Technology (of the Digital Core)

To wrap up, what we've done in this blog is identify all of the capabilities and enablers of Enterprise Blockchain Databases and the Enterprise Blockchain Platform, we've discussed why these capabilities are so important, and consequently how to position an Enterprise Blockchain Platform in the SAP Enterprise Architecture Technology Standards, where we use what and why.

We have also looked at where the Enterprise Blockchain Platform should reside, and the conclusion is in the "enabler", the SAP Business Technology Platform BTP, right next to the Digital Core S/4HANA, and enabling and leveraging all of the other Services in the SAP BTP and the native integration to the SAP Product Portfolio and other Enterprise Applications.

The good news is, as we discussed in the previous blog, this is no longer hype, we can do all of this today, and now, within the SAP Partner Edge Open EcoSystem there are enabling technology Blockchain Products designed and built by SAP Experts specifically for the needs of SAP Customers to make doing Blockchain and SAP easy, and so you can do SAP and Blockchain, today it's real and there's nothing stopping you.

So what are we waiting for ? Oh yeah, use cases, ok, that will be the next blog 😀 🚀

What do you think, are the words Blockchain, Web3, Distributed Ledger Technology, starting to appear in your Company's visions and technology visions ? What use cases are you looking at ? Let's chat about it in the comments.

For now, over and out.

Andy Silvey.

Independent SAP Technical Architect and CEO of atkrypto.io

Author Bio:

Andy Silvey is a 25 years SAP Technology veteran [15 years SAP Basis and 10 years SAP Tech Arch including Tech, Integration, Security, Data from 3.1H to S/4HANA PCE on RISE and the BTP and everything in between, and former SCN Moderator and Mentor alumni].

Andy is also co-Founder of atkrypto inc, an startup whose ambition is to make Blockchain easy for Enterprise.

atkrypto.io's flagship product is the atkrypto Enterprise Blockchain Platform for SAP, and atkrypto.io is a SAP Partner Edge Open EcoSystem Partner.

The atkrypto Enterprise Blockchain Platform for SAP has been designed by SAP Independent Experts for the needs of SAP Customers and to be deployed on the SAP BTP Kyma Runtime Service and leverage native integration to SAP Products.

atkrypto Enterprise Blockchain Platform for SAP has a number of unique qualities, including being the only Blockchain software in the world which has a DataCenter version and a light mobile version which can run on Edge/IoT/Mobile devices and enables data to be written to the Blockchain at the Edge where that same Blockchain is running on a Server in the DataCenter, protecting the integrity and originality of data from the Edge to Insights. Taking Blockchain to the Data at the Edge instead of taking the Data to the Blockchain.

What’s New for SAP Integration Suite – February 2024

2024-03-12T09:22:05.281000+01:00

Before going into the highlights of our innovations, we are thrilled to inform you that SAP Integration Suite has been recognized as a Leader in the latest Gartner Magic Quadrant for Integration Platform-as-a-Service (iPaaS) for the fourth consecutive time. We are convinced that we have been received this recognition for our commitments to deliver a top-tier customer-centric integration solution, the ability to accelerate business outcomes through prebuilt content, ongoing innovation, the global geographic strategy, and readiness for the future. And a big thanks also goes to you in supporting us with all your great feedback. For more details checkout the blogpost and the SAP News article.

SAP Integration Suite highlights are:

JMS receiver adapter: property to identify sending integration flow
Inspect resource consumption through SAP Cloud ALM/SAP Focused Run
Call to action: Upgrade to new version of third-party connectors
Duplicate nodes on target side in a MAG
Definition of more complex code value mapping scenarios
Add metadata for OData-based API artifacts deployed on Edge Integration Cell
Enhancement of security standards in API Management
Policy templates in API Management
Distributed tracing in advanced event mesh
Direct consumption of SAP S/4HANA Cloud events in advanced event mesh

Cloud Integration

JMS receiver adapter: property to identify sending integration flow

We have extended the JMS receiver adapter by storing a new SAP_IntegrationFlowID property. It contains the ID of the integration flow that has sent the message through the JMS receiver adapter. The JMS consumer can use this property to define steps depending on the sending integration flow ID. Refer the documentation.

Inspect resource consumption through SAP Cloud ALM/SAP Focused Run

Inspection of your resource consumption has been available since the middle of last year. Now you may analyze the utilization of database and system resources through the health monitoring application of SAP Cloud ALM and SAP Focused Run. For troubleshooting bottlenecks caused by integration flows you may jump directly to the Inspect section of the Cloud Integration monitor.

Call to action: Upgrade to new version of third-party connectors

As per SAP note 3001980 the following previous adapter versions are deprecated since end of 2020: Salesforce, Amazon Web Services, Microsoft Dynamics, SugarCRM. There haven't been any new features or enhancements for these previous adapter versions. After the upcoming Apache Camel upgrade, the adapter versions will no longer run.

Action is required from the customer's side. Check all your tenants to see whether you have any kind of the above adapters still deployed. Please undeploy and delete the adapters. In case of question reach out to annemarie.kiefer@sap.com.

B2B Integration

We have extended the mapping functionality of the Integration Advisor capability to offer you more flexibility.

Duplicate nodes on target side in a MAG

When designing B2B integration scenarios you may have situations where certain information within the source structure needs to be mapped to only one node in the target structure. Now the mapping guidelines editor of the Integration Advisor capability enables you to duplicate group or leave nodes and map each source alternative to one of the reproductions. Refer to the documentation.

Definition of more complex code value mapping scenarios

You are now able to define local or global mappings of multiple code values at the source side to one code value at the target side. The value function now supports N:1 cardinality code value mapping ease e.g., situations where you have to map multiple partners or currencies.

API Management

Add metadata for OData-based API artifacts deployed on Edge Integration Cell

You can now supply an EDMX specification for API artifacts (API-led integration flows for deployment on Edge Integration Cell), that are based on OData APIs. This allows you to easily specify additional integration steps based on the resources of this API. See the detailed documentation.

Enhancement of security standards

As always, our intention is to offer the highest security standards to avoid attack vulnerabilities. Therefore, we encourage you to use strong certificates, and will no longer accept uploads to the Trust Store of weak customer-owned self-signed certificates or certificate chains used for mTLS handshakes. Consequently, the OpenSSL security level has been increased to level 2. See a comprehensive definition of security level 2 published on the OpenSLL site. For additional details please see note -3418201.

Policy templates

We have filled a small gap when applying policy templates to an API proxy. Default fault rules or post-client flows available within a policy template will now also be appended to the API proxy. Refer to the documentation.

Event-driven Integration

We have news regarding SAP Integration Suite, advanced event mesh our offering for distributed network of event brokers and sophisticated features.

Distributed tracing

We have extended SAP Integration Suite, advanced event mesh with a distributed tracing capability. Now you are able to trace the the lifecycle of events through OpenTelemetry, from the producing application across one or multiple event brokers to the receiving application.

Direct consumption of SAP S/4HANA Cloud events

We have an update regarding the event sources. We have enabled the direct consumption of SAP S/4HANA Cloud events into SAP Integration Suite, advanced event mesh without any intermediate hops. SAP S/4HANA Cloud customers may leverage SAP Integration Suite, advanced event mesh for very large projects, where performance is crucial. Read the documentation.

How to stay tuned to recent and upcoming innovations?

We also refer to the complete list of new releases in our documentation: What’s New in SAP Integration Suite.

In case you have missed our last monthly webinar, don’t worry. Visit 2024 Learning Sessions for SAP User Groups on SAP Integration Suite for all recordings, presentations, and Q&As.

10+ ways to reshape your SAP landscape with SAP Business Technology Platform – Blog Series

2024-03-19T16:26:59.370000+01:00

Blog 2: The role of Business Technology Platform as an extension and innovation platform

This blog is part of the “10+ ways to reshape your SAP landscape with SAP Business Technology Platform Blog Series”

Summary: In this blog series we will look at the role of the SAP Business Technology Platform to reshape your SAP landscape including SAP and Non-SAP systems. In this second blog we discuss SAP Business Technology Platform capabilities around process automation, application development, enterprise integration, and AI. And how these capabilities support the most demanding businesses.

What does Mercedes AMG Petronas Formula One have in common with SAP Business Technology Platform? -- Tons of it.

Just like any other sophisticated business, Mercedes-AMG PETRONAS Formula One is in the cutthroat business of racing. And it competes in one of the most challenging environments in global sports. Combining elite teamwork, modern technologies, high-performance management, and exceptional driving skills, Formula One is a technologically innovative form of motorsport, where incremental gains yield significant results and can be the difference between winning and losing.

So what is common with Business Technology Platform?

The Formula One team has to compete in 22-24 different race tracks during a season. Each race track presents a different set of challenges, which can only be mastered when all the data is well understood. Data is what drives strategy in Formula One. Strategy is based on a set of decisions made by track engineers, drivers, and strategists to try to maximize the result in the race and qualifying by optimizing the tools at their disposal to make important calls such as tire decisions, the timing and amount of pit stops, and the management of the cars in the race. And all the decisions for each of the scenarios require intensive data analysis. We will cover data management and analytics in Blog 11: The role of Data & Analytics in the transformation by Wolfgang Epting.

The challenges above are similar to those experienced by our customers where they have to navigate changing market situations and customer demands, and analyse and respond to dynamic requirements, all while managing quality, cost, navigating through processes, and time to market.

In this blog, I want to emphasize the Business Technology Platform, which brings cutting-edge cloud services around application development, process automation, enterprise integration, analytics, and AI, all of which should help IT deliver fully integrated rapid enhancements. The value of AI and Gen AI for business increases exponentially when combined with industry-specific data and deep process knowledge, and this is exactly what SAP does. Joule, the generative AI assistant, revolutionizes how you interact with SAP business systems, making every touchpoint count and every task simpler. More on AI later from Mark on Blog 4: The Role of AI in the transformation. Stay tuned for that.

With the switch to S/4HANA, business can build their competitive car on a new chassis. The focus is on cloud first strategy and clean core, i.e. a largely untouched SAP core. BTP is used to develop, provide, and scale new applications in the cloud. Add-on solutions on the BTP can therefore be easily connected to SAP S/4HANA, while the SAP system remains 100% clean.

Let us look at some specific areas.

Formula One has long had active aero on cars – the rear-wing-opening overtaking aid, DRS, for instance. This is part of the aero package. Obviously, the extremes would be Monza/Spa for low downforce, and Monaco/Hungary for highest. With Silverstone as maybe the ultimate “compromise” setup on the less draggy side but also needs good high-speed downforce, especially for Copse/Maggotts/Becketts where the driver experiences lateral forces upto 6Gs during acceleration, braking and cornering.

Quite the same way, SAP Business Technology Platform, is the best path to rapidly build and enhance enterprise applications, processes, and experiences on top of the S/HANA chassis for various industry and internal business requirements. The prime idea is to build competition-beating processes and application enhancements quickly and deliver them to business. An example is building intuitive applications for field staff that provide necessary data points and actions intending to reduce paperwork. Or using AI to generate work orders with necessary steps which allows planners to execute orders faster. A clean core enables you to become future-proof by ensuring faster deployment with smooth upgrades – all while using BTP allowing you to innovate at market speed.

Think about this as developing the rear wing of the car and delivering upgrades during the season. Teams have to find the sweet spot between elements such as endplates, flaps, gurney flaps, and DRS. Teams can make changes to optimize the car's performance on different tracks.

From a business perspective, this is where we employ SAP Business Technology Platform BUILD capabilities. This allows you to:

Simplify your cloud application development to get more value and ignite innovation
Deliver agile process automation to automate and optimize processes and tasks
Connect people, data, and processes with engaging experiences

Approach it from a business angle. SAP Build is SAP’s low-code offering, designed to empower users of all skills to easily create and augment their SAP and non-SAP business applications with visual drag-and-drop, without requiring programming skills.

An example here is a shipping and logistics company that has built a Mobile App within 3 weeks, to allow drivers to capture damages to their vehicles. This app has greatly reduced tons of paperwork. This has been coupled with automation to help fleet managers plan required repairs and/or schedule them for a later date based on spare parts availability.

SAP Build brings together SAP Build Apps, SAP Build Process Automation, SAP Build Work Zone and SAP Build Code with generative AI-based code development into a unified development experience with new innovations to rapidly build apps, automate processes, and create business websites. These "four carriages" work together to help users accelerate application development and process automation, empowering every employee in the organization:

Build visually: Rapidly create enterprise apps, automate processes, and design business sites.

Integrate seamlessly: Accelerate development with prebuilt connectors and lines of business-specific content for SAP and non-SAP systems.

Collaborate securely: Foster collaboration between business and development teams with built-in governance and lifecycle management.

In addition, SAP Build Code, generative AI-based code development with Joule copilot, will provide optimized Java and JavaScript application development abilities, providing a turn-key environment for coding, testing, integrations, and application lifecycle management.

SAP Build Code brings:

Generative AI-based code development with Joule copilot - uses AI to generate app logic, data models, and test scripts.
Tailored for SAP development – helps you connect seamlessly with prebuilt integrations and APIs.
Enhanced fusion development – helps you drive collaboration between professional developers and business experts.

Each Formula One car is made up of around 14,500 individual components. Each element such as chassis, power unit, gearbox, aero package, braking systems, battery, cooling systems, telemetry, radio communications, tires, driver, etc. have to be truly well integrated to ensure the car is ready to race, is reliable and will win.

Similarly, in business, systems in isolation will never work and provide a full picture of business. They have to be integrated with core systems, and external applications, leverage 3rd party data and provide all of these integrated insights to business race engineers, and enable them to make race-winning decisions.

Hence SAP Integration Suite is essential to integrate on-premises and cloud-based processes, services, applications, events, and data and provide them securely to all stakeholders to consume and process information. This is where we offer SAP BTP Integration Suite which addresses hybrid integration strategies.

The strategy to support innovation is clear.

Accelerate innovation and integrate without obstacles
Speed connectivity and realize value faster
Connect customers and workers to automated processes
Conquer process fragmentation and drive productivity
Streamline workflows and improve the employee experience
Connect with partner systems and improve collaboration

Top nine ways SAP Integration Suite drives innovation

BTP Integration Suite therefore offers:

Prebuilt integrations managed and updated by SAP
Harmonized access to popular third-party cloud applications
Tools for designing, publishing, and managing APIs
AI-assisted development and integration optimization
Tools-based, guided approach to define, document, and govern your integration strategy
Edge Integration Cell to run integration scenarios within customer-managed private landscapes for on-prem to on-prem workloads.

The new world of innovation through Generative AI via the SAP perspective.

I would equate the race engineer to Gen AI today. Simply because today, race engineers are crucial assets in every Formula One team, as they are the intelligence who ensure drivers and their vehicles are attuned to put on a show on the track. They analyze and call on all data points. I would use the parallels where the car is business applications, drivers as users, track and weather data is external data, car data is business data, custom setups during races as Gen AI content and radio communications as prompts for business users.

SAP Business AI is aimed at making our business applications more intelligent, infusing AI technologies into our applications. Furthermore, we provide business process-specific AI services that our customers can adapt to their workflow, e.g., business document processing, data attribute recommendation, RPA, etc.

Building data understanding is essential for the success of business AI. SAP has access to business data covering finance, supply chain, human resources, travel, and tons of external data relevant for business.

To make business AI successful, we continue to build the best technology and leverage the best tools on the market.

This includes strategic partnerships with others in the industry, such as Open AI, AWS Bedrock, Aleph Alpha Luminous, Meta Llama 2, Falcon, etc.
Embed their tech into our products such as SuccessFactors, S4, CX and Spend Manegement.
Enable customers to build custom ML models on SAP data easily and securely.

To conclude SAP Business Technology Platform (SAP BTP) is the platform of choice to modernize, upgrade, and drive innovations in your applications. It allows you to extend and personalize SAP applications, integrate and connect landscapes, and unleash business users to connect processes and experiences, make decisions with confidence, and drive business innovation.

Let’s get out there and win every race.

The Blog Series 10+ ways to reshape your SAP landscape with SAP Business Technology Platform will be published regularly and the newest blogs can be found here: Video & Blog Series - SAP BTP MEE Overview (brandcast.io)

To get more insights, please also visit one of our BTP Innovation Days:

Innovation Day Vienna: Vienna 04-Apr-24 SAP BTP Innovation Day Vienna
Innovation Day Switzerland: Bern 14-May-24 SAP | SAP BTP Innovation Day Switzerland
Innovation Day Germany Essen 16-May-24 SAP | SAP BTP Innovation Day

Advanced Event Mesh Connectors and Easy Event-Driven Example of S/4HANA with Amazon S3 Integration

2024-03-21T15:18:41.091000+01:00

What is an Advanced Event Mesh (Solace) Connector

"Advanced Event Mesh(AEM) Connectors are assets that enable integration between AEM event brokers and various external systems, applications, and cloud services."

Acting as a bridge between the broker and other systems, the connectors facilitate the integration of AEM messaging capabilities into different environments, such as cloud-native applications, IoT platforms, microservices architectures, and traditional enterprise systems while providing a standardized way to connect the messaging platform with these environments, ensuring interoperability and ease of use. The role is crucial as it enables seamless integration and communication between AEM event brokers and diverse environments, in development and building of scalable, event-driven architectures and distributed systems.

If you're familiar with SAP BTP Cloud Integration, you can consider them to have a similar mentality as SAP BTP Integration Suite Open Connectors.

There are different types of connectors in terms of where they operate, based on who developed/distributed them etc.(Solace, 3rd party).

You also have the flexibility to develop your own connectors.

Roughly there are rich set of connectors including connectors already integrated within the broker itself communicating to and from target systems via standard protocols, connectors for other event brokers, connectors to/from analytics-stream processing platform, iPaaS providers on top of SAP BTP Cloud Integration as Mulesoft Anypoint, Dell Boomi or connectors deployed to the source/target systems such as ASAPIO.

For a list of growing number of connectors and their details you can visit

https://solace.com/integration-hub/

SCENARIO

In this blog post, we are going to simulate a scenario via Advanced Event Mesh Connectors, particularly Amazon S3 Producer, to showcase how easy it is to connect the AEM event broker to an Amazon S3 Bucket and simulate S/4HANA as the source system.

For simplicity's sake and to focus on the main purpose of the blog post, we are going to refer to S/4HANA as the source system. However, we will simulate the S/4HANA event publishing part using Postman. This simulation will yield the same inbound results from an Advanced Event Mesh perspective as if they were published from S/4HANA. (Different variations of S/4HANA's event publishing to Advanced Event Mesh are described in different blog posts, which you can find in the community.)

ARCHITECTURE

Below architecture will be used end-to-end.

Architecture and Flow

Along with showcasing AEM Connectors, this architecture is practical and could potentially serve as a solution to modernize legacy architectures characterized by point-to-point or file-based integrations. For example, in use cases where S/4HANA needs to integrate with third-party applications via SFTP/File-based interfaces, which are often associated with potential problems.

With the implementation of Event-Driven Architecture via AEM and connectors like this, and by leveraging the numerous advantages offered by cloud-based object stores (e.g., AWS S3), customers can realize both immediate and strategic benefits for future use cases, both directly and indirectly.

As a result this kind of architecture with tools like connectors provides much greater flexibility and easiness.

Very high level, below architecture represents the flow where;

A source system (like S/4HANA) publishes new customers via events.
SAP BTP, Advanced Event Mesh via connectors connects to the AWS S3 Bucket and puts the content(file) in the bucket.

Then a third party system of your preference can consume this object(file) in a standardized and secure way.

CONFIGURATION STEPS

For the configuration of this scenario below steps will be applied.

Configuration of AWS S3 Bucket

Very simply you need to have an AWS S3 Service enabled and an S3 Bucket configured for this purpose.

I have created one and named it as bb-s4-store-s4hana

Amazon S3 Bucket

You also need to configure AWS IAM Service for a user to access the bucket and access key to be used.

This key will later be used in the configuration of Advanced Event Mesh S3 Bucket Connector.

Access Key for the Bucket

Configuration of Advanced Event Mesh Connector: S3 Bucket Provider

From the left side menu of the broker manager, (Connectors link) you can access connectors that Advanced Event Mesh (Solace) provides out-of-the box.

Initial Settings

Add a new one and choose Amazon AWS > AWS S3

Connectors for AWS, Azure, Google Cloud

AWS Connectors

Use the access key and bucket information that is being configured in the first step

Wizard -Authentication

Next step for client profile and Amazon S3 Host (you can use the defaults for demo)

Wizard- Connection information

Configuring the file name and subscription

File Name Mapping Function

This is the part that is the core of the configuration.

The filename mapping function determines the object name in S3 bucket (which eventually becomes your file name). The good thing here that Advanced Event Mesh Connector (eventually RDP) allows you is the functions and variables you can use, so that you make your file name dynamic and informative. You can use Substitution Expressions which is a Solace-specific expression language used to replace specific text attributes (request targets, request headers, etc.) with system generated output.

More information can be found from the below link.

https://docs.solace.com/Messaging/Substitution-Expressions-Overview.htm

As I wanted my filename to be

customer-created-XXXXXXXXXXXX.csv

with a timestamp therefore I utilize below expressions/functions in the naming of the object:

unixTime(): Returns the number of seconds since midnight, January 1, 1970 UTC for the specified timestamp, ignoring leap seconds which is known as unix time or epoch time. This will allow uniqueness of the file name and be informative about file creation time.
topic(N) :Returns part or all of the message topic. I used the first and second segments of the topic in the file name which are “customer” and “created”.

Subscriptions

These are the topics to which my queue(generated) is subscribed, triggering the creation of objects to be pushed to S3 when an event related to these topics is published. Specifically, I want the object(file) to be created when a 'customer/created' event is published.

My final result of File Name and Subscriptions would be as follows.

Wizard- File Name Mapping and Subscriptions

As a summary, AEM Connector Wizard informs that the following objects to be created.

Result – Assets (Artifacts) created

Technically behind the scenes, the connector with a very quick 2-3 step process creates an RDP Client with REST Consumer, Queue and Queue Binding and attaches related subscriptions that we should do when we configure everything manually. Within the auto-configuration of these assets it also configures the AWS Authentication, schemes, remote call details.

As mentioned, this could also be done with different manual steps. The details of how you can manually set RDP and substitution expressions for this and other purposes could be found in my other post below

https://community.sap.com/t5/technology-blogs-by-members/advanced-event-mesh-dynamically-publishing-messages-from-source/ba-p/13576391

"As a result; all this setup is done within seconds, it's up and running.."

Resulting AEM Artifacts Created

TESTING

We will be using Postman to simulate S/4HANA event creation making a direct REST call to Advanced Event Mesh.

Payload

The message payload will be a CSV where there is the customer name and a guid in each line.(with the below header line)

“Customer Name”;”GUID”

Topic

Our topic will be customer/created for simplicity.

Postman REST Call

And Voilà! When we check AWS S3 Bucket after publishing 2 events, there are two objects(files)

Result - Files(objects) in the bucket for consumer / target system

And the content of a sample file which is basically the event message payload is as follows:

File Content

Once you have this in the S3 Bucket, you can reach the file/ download this file securely from a third party application.

FINAL WORDS & TAKE AWAYS

With a very quick and simple scenario and with the help of Advanced Event Mesh Connectors, we demonstrate how to easily set up an end-to-end use case with modern event driven implementation.

At the same time with event-enabling our scenario, we seamlessly connected our broker to Amazon S3.

Imagine the need to publish the same information to Azure Functions as well. All that is required is configuring the Azure Functions Connector specific to that purpose and nothing else needs to be changed to extend overall scenario. The use case can be further extended by calling other custom REST endpoints(RDPs) or you can subscribe to the same topic with different types of consumers and receive the same event and process it.. Still without affecting either the publisher and other subscribers.

The possibilities with these kinds of setups are almost “limitless”. They are easy to maintain once properly established and straightforward to configure with the connectors and event-driven architecture.

You can find my other blogs from the below links:

S/4Hana Cloud Event Trigger an Iflow in Sap Integration Suite

2024-03-23T09:48:17.400000+01:00

In SAP S/4Hana Cloud, when event for some business object happened like sales order created, some additional logic need to be triggered, for example additional information should be put for this sales order. We can utilized SAP Event Mesh and SAP Integration Suite to realized such kinds of requirements .

The following is solution example .

Prerequisites:

SAP S/4Hana Cloud has gone alive or in implementation.
Have subscribed SAP Event Mesh in Sap Business Application Platform
and finished the initial settings. You have the Event Mesh instance Service Key which will be used in step 1 .
Have subscribed SAP Integration Suite in Sap Business Application Platform and finished the initial settings .
Realizing Steps:
Step 1: Create communication user and create communication arrangement for scenario SAP_COM_0092 in SAP S/4Hana Cloud .
Step 2: Create communication arrangement for sales order in SAP S/4Hana Cloud .
Step 3: Bind sales order created topic to event channel in SAP S/4Hana Cloud .
Step 4: Create event queue for sales order in SAP Event Mesh Subscription in SAP Business Technology Platform.
Now the event queue can receive events of sales order created from S/4Hana Cloud .
Step 5: Create and Deploy Iflow in SAP Integration Suite .
Create Oauth2 Client Credential base on Event Mesh service key and Basic User account for Sales Order API Inbound user in SAP Integration Suite.
Create and Deploy Iflow.

 import com.sap.gateway.ip.core.customdev.util.Message;
import java.util.HashMap;
import groovy.json.JsonSlurper;
def Message processData(Message message) {
    def body = message.getBody(java.lang.String)
    
    def jsonObject = new JsonSlurper().parseText(body)
    def salesOrder = jsonObject.data.SalesOrder
    message.setHeader('salesOrder', salesOrder)
    
    def messageLog = messageLogFactory.getMessageLog(message)
    if (messageLog != null) {
        messageLog.addAttachmentAsString('event', body, 'application/json')
    }
    return message
}

import com.sap.gateway.ip.core.customdev.util.Message;
import java.util.HashMap;
def Message processData(Message message) {
    def body = message.getBody(java.lang.String)
    def messageLog = messageLogFactory.getMessageLog(message)
    if (messageLog != null) {
        messageLog.addAttachmentAsString('SalesOrder', body, 'application/xml')
    }
    return message
}

Step 6: Test - Create Sales Order in S/4Hana Cloud and Check result in SAP Integration Suite .

The End

Thanks for your time!

Jacky Liu

Unleash the Power of Real-Time Business Insights with SAP Advanced Event Mesh

2024-03-26T03:57:44.968000+01:00

Unleash the Power of Real-Time Business Insights with SAP Advanced Event Mesh

In today's ever-changing business landscape, being able to respond quickly is crucial. SAP Business Technology Platform (BTP) lays the groundwork for this agility by providing a comprehensive integration platform. But what if you could harness the power of instant reactions to every customer interaction? That's where SAP Advanced Event Mesh (AEM) comes in - a revolutionary tool that unlocks the true potential of SAP BTP. By utilizing the event-driven architecture championed by SAP BTP, AEM empowers businesses to make real-time, data-driven decisions - a vital capability in today's fast-paced environment.

Imagine a world where every customer interaction triggers an immediate response, enabling businesses to make informed choices in real-time. This is the power of SAP Advanced Event Mesh (AEM), a revolutionary tool that transforms how businesses react to events and unlock hidden opportunities .

(Image Source: SAP)

The Grocery Store Scenario: A Glimpse into the Future of Inventory Management

Consider a grocery store where every purchase instantly triggers an event that is relayed to a central system. This eliminates the need for traditional end-of-day reports, allowing for immediate insights into:

Product popularity: Identify fast-selling items and ensure they are always in stock.
Inventory optimization: Replenish stock as soon as it runs low, preventing lost sales and customer frustration.

This is just one example of how AEM streamlines business processes and enables proactive decision-making across various industries.

Key Features of SAP AEM:

Event-driven communication: Respond to events as they happen, creating a dynamic and responsive system.
Scalability and flexibility: Easily adapt to changing business needs and data volumes.
Unified event management: Gain centralized control and visibility over all events within your SAP landscape.
Seamless integration: Integrate seamlessly with SAP and Non-SAP solutions.

Components of SAP AEM:

Mission Control: Easily deploy and manage event brokers, monitor their performance, and visualize your event-driven architecture.

Event Portal: Design your event-driven setup using a full set of tools, including an overview, designer, catalog, and event manager for running events.

Insights: Get real-time insights into the health and performance of your event network, ensuring your applications work well.

Deployment Options:

You can choose from different deployment options for SAP AEM:

Public Regions: This allows you to use the infrastructure managed by SAP, which is simple and easy to use.
Dedicated Regions: This gives you more control and isolation within a dedicated SAP cloud environment.
Customer-Controlled Regions: This lets you deploy AEM on your own Kubernetes cluster, giving you ultimate customization and control

Security:

SAP AEM takes security very seriously at every level, with features like:

Secure cloud architecture with various deployment options.
VPC/VNet isolation for keeping data segregated securely.
Multi-factor authentication and authorization to have comprehensive access control.

Step by Step process to publish standard Business events from S/4 Hana to Event Mesh

2024-03-27T10:04:35.331000+01:00

Hi All,

This blog explains Outbound Configuration to send events from S/4 Hana on premise to Event Mesh and test the same.

You need to have below roles

1. SAP_IWXBE_RT_XBE_ADM

2. SAP_IWXBE_RT_XBE_BUSI

3. SAP_IWXBE_RT_XBE_MDT

In S/4 system, please follow below steps.

Create a Channel using T-code “/n/IWXBE/CONFIG”.

Click on “Via Service key”.

Enter Channel name and Description. Get the Event mesh instance key from Basis team. Copy and paste the service key of event mesh as shown below.

select the channel and activate it.

Once it is activated, click on Check connection. You will get the below message if connection successfull.

To Create Outbound binding, please select channel and click on outbound bindings.

Click on create and then F4.

Select the topic from F4 and save it. If you don't find topics in F4 help, you need to implement note "3346777".

Now, you need to create a Queue in Event Mesh and subscribe the topic.

Open Event Mesh and click on Create Queue.

Provide some name and click on create

Once the Queue is created, click on highlighted button and select Queue Subscriptions.

Enter Topic name along with the namespace and click on add button to subscribe to the topic.

Configuration is done in S/4 Hana system and in the BTP Event Mesh.

To test the messages,

Trigger Standard Business Partner Events by creating a business partner using T-Code BP.

Click on Person.

Enter First name and last name and then save it.

Message has been sent to Event Mesh.

Check the payload after consuming the message in CPI by integration team.

Message number decreased to zero in Event Mesh after consuming the message in CPI.

Happy to hear the feedback 🙂

March Developer Challenge - CloudEvents: It's a wrap!

2024-04-01T06:08:23.211000+02:00

Yesterday, we concluded March's developer challenge in the SAP Community - All about CloudEvents and event-driven architectures. Thanks to everyone who took part in it :-). I hope you had as much fun participating in the challenge as I had preparing it.

In case you missed the developer challenge but you are interested in knowing what it was all about... you can get started here: March Developer Challenge - CloudEvents: Week 1.

If you want to learn more about CloudEvents and event-driven integrations, I would recommend keeping an eye on the content of the Event-driven integration CodeJam - https://github.com/SAP-samples/events-driven-integrations-codejam, which is now close to being finalised :-). Also, remember that you can request/host an SAP CodeJam event in your city or company, and we will be happy to help you run it - https://community.sap.com/t5/sap-codejam-blog-posts/so-you-want-to-host-a-codejam-everything-you-need-to-know/ba-p/221415.

Are you wondering about what will be April's Developer challenge? It is live now 🚀... April (Citizen) Developer Challenge – SAP Build Apps: Task 0 - https://community.sap.com/t5/sap-builders-discussions/april-citizen-developer-challenge-sap-build-apps-task-0/m-p/13654312

Now, some cool stats on community members' participation:

A total of 36 SAP Community members took part in the challenge.
Unique SAP community members participation per week:
Week Total submissions
Week 1 31
Week 2 26
Week 3 23
Week 4 16
Total 96
Total submissions per week. Note: In week 2 a couple of participants submitted more than one solution and in weeks 3 and 4, I'm counting as valid submissions any valid message received. Many participants submitted more than one message.
Week Total submissions
Week 1 31
Week 2 28
Week 3 70
Week 4 98
Total 227
Last but certainly not least... a special mention to all the SAP Community members who completed the challenge every single week 🎉
@Alpesa1990
@MatLakaemper
@MioYasutake
@Nagarajan-K
@PriyankaChak
@Ruthiel
@ajos
@emiliocampo
@geek
@pamoli_banerjee
@r00k13d3v
@saitgunacorel
@spirit2681
@xavisanse

If you are interested in the event-driven integrations/architectures topic.... 📺 stay tuned as there is way more coming later this year in this space.

10+ ways to reshape your SAP landscape with SAP Business Technology Platform - Blog 5

2024-04-18T11:57:49.712000+02:00

Blog 5: How hybrid Integration upholds the role of Clean Core

Summary: In this blog series we will look at the role of the SAP Business Technology Platform in reshaping your SAP landscape including SAP and Non-SAP systems. In this seventh blog we’ll look into the important role of integration in terms of clean core and the overall transformation journey.

We’ve learned about the The Central Role of Clean Core in the first issue of this blog series. The concept of a clean core refers to keeping the core ERP such as SAP S/4HANA as up to date, unmodified, documented, consistent, efficient, and cloud compliant as possible. And while extensions - either as in-app or side-by-side - probably come to mind right away when talking about these topics, it’s imperative to apply the same guiding principles to integration.

Being Aware: A Broader Perspective

Some of the more severe technical debts in terms of integration include an existing, oftentimes rich SAP Process Orchestration (SAP PO) landscape, which is going to be out of mainstream maintenance until 2027, along with the Business Suite 7. On top of that there’s usually a multitude of non-SAP Adapters and Connectors, probably collected from multiple vendors and solutions over the last decade(s), which have created not only duplications, but also technical-, as well as commercial- and knowledge lifecycles. The Assessment-, Migration and ISA-M- Tooling as well as the SAP Edge Integration Cell will make this transitions as plannable and digestible as possible and are all included with the SAP Integration Suite.

The significance of integration extends far beyond the migration and modernization phase.
APIs have become ubiquitous across the technological landscapes, forming the backbone of communication and service delivery and must be centrally secured, monitored and documented. But modern API-Management is not just about managing technology - it's about managing business outcomes. It enables organizations to leverage the full potential of their digital assets, create expansive ecosystems, and deliver exceptional user experiences while achieving and maintaining security, compliance, and performance.

Decoupling for Flexibility and Agility

Staying as close as possible to the standard through decoupling go hand in hand with the SAP Business Technology Platform (BTP). In terms of integration the hybrid PaaS/on-prem runtime SAP Integration Suite covers all kinds of cloud-to-any as well as ground-to-ground integration needs.

With its comprehensive integration capabilities, the SAP Integration Suite provides the following contributions and qualities:

“Standard” in terms of integration

In the ongoingly updated SAP Integration Strategy Paper Christian Klein, Juergen Mueller and Thomas Saueressig have outlined the SAP road map towards an integrated intelligent suite and declared SAP Integration Suite as SAP’s strategic standard. Check out the updates regularly and learn about the most recent integration highlights.

Documentation and Consistency

Documentation: ISA-M is an invaluable open framework and toolset included even with the free plans of Integration Suite and helps in defining and standardizing integration strategies,
-styles and -practices. By providing a clear structure and methodology for SAP as well as non-SAP requirements and technologies, it ensures that all processes like integration governance, integration quality assurance- and responsibilities are defined and documented consistently and are backed by corresponding best practices and reference architectures.
Consistency, Governance and Monitoring: an integrated and complete suite of tools for centralized connection, mapping, transformation, management, monitoring and governance of integrations, providing a single pane that helps maintaining all styles of integrations and keep consistency across the enterprise landscape.

Efficiency and Cloud Compliance

Instead of just providing templates (which is the industry standard), the SAP Integration Suite provides curated out of the box content, for example in the form of more than 3’400 integration process flows. Let’s say you’re using one of those standard iFlows to easily filing your companies annual tax returns to the government and said government changes/adds requirements - either from a technical and/or compliance point of view, SAP is usually going to adapt to these changes and will refactor/change, test and update that iFlow at no additional cost.

Cloud-Native Integration: As a cloud-native solution, the suite facilitates modern cloud principles, ensuring that the core system is efficiently integrated with cloud services without requiring any modifications to the core. The Edge Integration Cell follows the same design principles and provides an on-prem runtime, usually at no additional cost

Keeping the Core Clean

Get started quickly with predefined process integrations for the most commonly used scenarios, including APIs, events, and well-documented integration flows to integrate SAP applications as well as third-party applications with minimal effort. Benefit from aligned domain models to synchronize master data objects between different LoB’s
Graph: Extending traditional API Management, Graph enables you to abstract the landscape, share data by removing and/or extending data sets for different use cases, connect all major SAP business objects out of the box while hiding the landscape complexity (replicated, distributed, or shared data).
Decoupling Extensions: By allowing businesses to build extensions and custom applications outside the core ERP side by side on the BTP, the suite ensures that the core remains unmodified, which is a key aspect of the clean core concept.

Conclusion

Preparing for the Future

The combination of cloud computing, a clean core strategy, and the move to SAP Integration Suite as one central, hybrid iPaaS positions businesses for future growth, market dynamics and innovation. It lays the groundwork for quickly adopting emerging technologies like AI, machine learning or event driven architectures as well as the next big thing to stay ahead in the digital race!

Links:

Your success is our mission. You are wondering when, what, and how to transform to be well equipped for your changing business needs? SAP is here to guide you through your transformation and to support you along the way. Download the Document

SAP Integration Solution Advisory Methodology (ISA-M)

Integration Software | SAP Integration Suite

Integration Assessment provided by SAP BTP

SAP Business Accelerator Hub.

Events

To get more insights, please also visit one of our BTP Innovation Days:

Innovation Day Switzerland: Bern 14-May-24 SAP | SAP BTP Innovation Day Switzerland
Innovation Day Germany Essen 16-May-24 SAP | SAP BTP Innovation Day

Integrating SAP S/4HANA with Kafka via SAP Advanced Event Mesh: Part1 – Outbound connection

2024-05-14T16:23:10.601000+02:00

Introduction

In today's fast-paced business world, the ability to seamlessly communicate and exchange data between different systems is crucial. SAP Advanced Event Mesh (AEM) offers a robust solution for real-time event-driven communication across various SAP systems and external services. In this blog post, we'll explore how to integrate S/4HANA with Kafka using SAP AEM for data streaming and event-driven architecture.

If you’re new to SAP AEM, I highly recommend checking out this blog series to understand the fundamentals.

Step-by-Step Guide

Let's break down the connection process between S/4 HANA and Kafka using SAP AEM into 6 sections, each explaining a key part of the connection setup to help you easily understand and implement the process.

1. Login and Setup SAP AEM Service

First, log in to your BTP subaccount and create a subscription for AEM ensuring your user has the required roles. Please note that I've skipped the steps on how to create an AEM subscription, but you may refer to this blog for detailed steps. Once subscribed, log in to your SAP AEM tenant and navigate to Cluster Manager to create an Event Broker service. This service enables applications to publish or consume events. Below is the start page of SAP AEM after logging in.

Create an Event Broker Service by clicking on ‘Create Service’.

Provide a meaningful name for the service e.g. – ‘AEM_SERVICE_DEV’, select the service type, and choose the region. Click on "Create Service".

After the service is activated, you'll see the page.

Navigate to "Manage" and then "Authentication". Enable Client Certificate Authentication.

2. Establishing Trust between S/4 HANA and AEM

To implement client certificate-based authentication, you need to establish trust between S/4 HANA and the AEM service broker. In your S/4 HANA system, execute the STRUST transaction to open the Trust Manager. Export the certificates from SSL client (Standard) and upload them into AEM in the next step.

Go to "Manage" and then "Certificate Authorities". Upload the exported certificates by clicking on "Add Client Certificate Authority".

Once done, all the certificates will be displayed as shown below.

Now, import the certificate chain of the SAP AEM service broker host and BTP-IS Subaccount host in the SSL client (Standard) in the STRUST transaction code.

3. Broker Manager Configuration in AEM

Click on "Open Broker Manager" and log in using the "Management Editor Username" and "Management Editor Password". You can find these access details under the "Status" section of the broker service.

Once logged into Broker Manager, create a Queue which will serve as a storage mechanism for messages received by SAP AEM. When S/4HANA will generate any events or messages, they will be placed in the queue before being processed and forwarded to Kafka.

Provide a meaningful name for the Queue e.g. – ‘AEM_DEV’.
Assign a Subscription to the Queue. By creating a subscription, we ensure that our SAP AEM instance is subscribed to the relevant topics or events generated by S/4 HANA.

Go to "Access Control" and create a Client Username with the hostname from the leaf certificate maintained in SSL Client (Standard) in the STRUST.

4. Configure AEM to Kafka connection through Kafka Sender Bridge

The Kafka Sender Bridge is required to facilitate communication between AEM and the target Kafka cluster by converting AEM messages into Kafka events and propagating them to the remote Kafka cluster.
To establish client certificate authentication between AEM and the Kafka cluster, you'll need .jks files of the Keystore and Truststore from your target Kafka broker.
Open the command prompt and use the command 'keytool' to convert the .jks files into .p12 files. Here's how:

keytool -importkeystore -srckeystore C:\OpenSSL\<keystorefilename>.jks -destkeystore C:\OpenSSL\keystore.p12 -srcstoretype jks -deststoretype pkcs12

keytool -importkeystore -srckeystore C:\OpenSSL\<truststorefilename>.jks -destkeystore C:\OpenSSL\truststore.p12 -srcstoretype jks -deststoretype pkcs12

Once converted, copy these .p12 files to the OpenSSL -> Bin folder.
Now, navigate to the 'OpenSSL' directory and convert these .p12 files to .pem files using the commands below:

openssl pkcs12 -in keystore.p12 -out keystore.pem

openssl pkcs12 -in truststore.p12 -out truststore.pem

You'll need to set a passphrase during this process. Note: Remember this passphrase, as you'll need it for client certificate authentication.
From the ‘truststore.pem’ file, copy the content of root and the leaf certificates and save it as .cer files. Add those in our service broker under "Manage" -> "Certificate Authorities" -> "Domain Certificate Authorities".

Now, navigate inside Broker Manager to "Kafka Bridges" and create a "Kafka Sender".

Add the Kafka Broker Host and Port details in the ‘Bootstrap Address List’ and copy the contents of the 'keystore.pem' file and paste them under Client Certificate Authentication - > Content as shown below. Additionally, include the passphrase that we entered while converting the .p12 file to .pem in the ‘Password’.

Once the Kafka Sender is created, go inside, and click on "Queue Binding".

Select our queue – ‘AEM_DEV’ created in section 3.

Go inside the Queue Binding created in earlier step and add the topic name of the target Kafka cluster in the "Remote Topic".

Confirm whether the Kafka connection is up and running.

5. Configure S/4 HANA to SAP AEM connection

Now to establish a connection from S/4 HANA to AEM go to transaction code SM59, create a type-G RFC destination and enter the host and port of the SAP AEM service broker.

In transaction code /IWXBE/CONFIG, create Channel configuration in the S/4 HANA system by clicking on ‘via Service Key -> Advanced’ and assign the RFC destination created in the earlier step. In the ‘Service Key’ section enter the JSON content of the service key created using ‘aem-validation-service-plan’ instance in BTP cockpit. Please refer this blog on how to create a service key.

Save the above changes and activate the channel.
Create an outbound binding and assign any standard topic. For example, select "Business Partner". So whenever a Business Partner is newly created or modified, a standard event will be raised through this outbound channel.

6. Testing the end-to-end connection

To test the end-to-end connection, go to transaction code BP and create a Business Partner. Click on save.

Once saved, an event should be raised. You can check this by going to transaction code /IWXBE/EEE_SUPPORT and then to /IWXBE/R_EVENT_MONITOR.

Select your AEM channel.
You will find a list of all events that were raised and sent to AEM.

Now, go to AEM. In the Kafka sender, you can see the message count in the sent section has increased. This means that the message was successfully received by AEM and then pushed to the Kafka cluster. Additionally, verify the message at the Kafka end.

You can also navigate to the 'Try-Me' section where you can set up the sender and receiver connection. Subsequently, you can subscribe to our topic at the receiver end and observe the incoming message from S/4 HANA as shown below.

Conclusion

Through this blog, we've demonstrated the process of sending an event from SAP S/4HANA to Kafka via SAP AEM. Now, enterprises can leverage the power of event-driven architectures to drive innovation and efficiency in their operations.

Stay tuned for my next blog, where we'll explore how to establish an inbound connection from Kafka to S/4 HANA via SAP AEM, completing the full event-driven communication loop.

References

https://community.sap.com/t5/technology-blogs-by-sap/advanced-event-mesh-create-your-first-event-broker/ba-p/13571945

https://community.sap.com/t5/enterprise-resource-planning-blogs-by-sap/sap-s-4hana-integration-with-sap-integration-suite-advanced-event-mesh/ba-p/13577271

https://community.sap.com/t5/technology-blogs-by-sap/video-tutorial-sap-s-4hana-and-sap-integration-suite-advanced-event-mesh/ba-p/13575193

https://help.pubsub.em.services.cloud.sap/Cloud/cloud-lp.htm

https://help.pubsub.em.services.cloud.sap/Cloud/Broker-Manager/config-kafka-bridge.htm

SAP Tech Bytes: SAP S/4HANA Cloud + SAP Integration Suite, AEM + SAP Build Process Automation

2024-05-20T13:25:58.571000+02:00

In this blog post, I share a couple of SAP Tech Bytes on how to enable eventing between SAP S/4HANA Cloud and SAP Build Process Automation via SAP Integration Suite, advanced event mesh. We will configure and trigger events from SAP S/4HANA Cloud, which will then be received by SAP Integration Suite, advanced event mesh, and finally forwarded to SAP Build Process Automation.

Enabling the end-to-end event-driven integration scenario between SAP S/4HANA Cloud and SAP Build Process Automation involves many steps and requires extensive documentation. Sometimes, it might be best to process all that information in video format.

If you're interested in learning how to enable the same scenario using SAP Event Mesh, check out this blog post: https://community.sap.com/t5/technology-blogs-by-sap/sap-tech-bytes-deliver-events-from-sap-eventmesh-to-sap-build-process/ba-p/13574547.

SAP Tech Bytes: Configuring SAP S/4HANA Cloud and SAP Integration Suite, advanced event mesh

Steps shown in the video:

Now that we've configured the communication between SAP S/4HANA Cloud and SAP Integration Suite, advanced event mesh, we can proceed to configure the delivery of events to SAP Build Process Automation.

SAP Tech Bytes: Delivering events from SAP S/4HANA Cloud to SAP Build Process Automation via AEM

Steps shown in the video:

In this SAP Tech Bytes, we’ve seen what’s required to configure eventing between SAP S/4HANA Cloud and SAP Integration Suite, advanced event mesh. Also, we created and configured a REST Delivery Point in AEM in order to forward events to SAP Build Process Automation. The REST Delivery Point functionality is not limited to SAP Build Process Automation; you can also deliver events to other systems that expose an HTTP endpoint to receive them. I hope you enjoy this video on event-driven integration, as there is more to come on this topic in the near future….

Happy eventing!

Week	Total submissions
Week 1	31
Week 2	26
Week 3	23
Week 4	16
*Total*	96