Skip to Content
Product Information

Getting Started with SAP Enterprise Messaging

Regardless of your line of business or geographic location, all businesses today have one overriding thing in common: to be a success you must be a digital business.

The rewards of digital business are considerable, but the initial transition can be challenging.  New innovations are required to connect hundreds and thousands of devices, applications, and systems in an enterprise world.

Any Enterprise system mostly deals with lot of heterogeneous systems, each one catering to a specific requirement of the overall ecosystem. In such a complex environment with diverse technologies, integration between components becomes very complicated because of business data of diverse formats. Moreover, the complexity increases many fold because of the possibility of high load, need of secure & reliable communication, making sure the systems are loosely coupled. And also in today’s world, one of the obvious demand of digital business is to be able to build a flexible, innovative cloud based solution so that, the system can capitalize on new connections between devices, applications and systems.

So, in short, to digitize and integrate your business in an enterprise world, you require a messaging infrastructure which

  • Supports high volume, high-speed communication between applications and systems.
  • Decouples communication using standard asynchronous messaging patterns.
  • Provides reliable data transmission for mission critical scenarios to ensure guaranteed message delivery.
  • Handles peak loads.
  • Supports open protocols for effective decoupling of devices and applications.
  • Facilitates event-driven architectures to consume system events in the Cloud.

SAP Enterprise Messaging has been designed and developed as a tool to provide such features under the Integration capability umbrella of cloud foundry based SAP Cloud Platform. Added to that, SAP Enterprise Messaging provides the feature in serverless way and is fully managed by the provider. Thus taking most of the burdens from the developer.

 

This blog tries to provide an introduction of SAP Enterprise Messaging. This of course shall be followed with blogs which will speak in detail about each aspect of SAP Enterprise Messaging.

New serverless offering on SAP Cloud Platform

  • Messaging as a service: SAP Cloud Platform Enterprise Messaging (generally available)
  • Functions as a service: SAP Cloud Platform Functions (beta)
  • Backend as a service: SAP Cloud Platform Backend service (beta)

These services run in a serverless environment, meaning it is SAP as cloud provider (and not you) who is responsible for managing and dynamically scaling the resources required for your applications. Resource utilization is closely monitored and caters for micro-billing meaning you pay only for the resources your applications use. Pay-per-use details are published with global availability of each service and do not apply to beta releases.

SAP Enterprise Messaging service allows you to send and receive messages reliably using open standards and protocols. You can decouple application logic, develop micro services and support event-driven architecture.

Salient capabilities of SAP Enterprise Messaging include

  • Connect applications and services seamlessly
  • Communicate reliably at large scale
  • Send and receive high number of messages in real-time
  • Enable event-driven applications

Salient benefits of SAP Enterprise Messaging include

  • Easy consumption Client Libraries
  • Out-of-box event enablement for S/4 HANA and other applications in future
  • Easy Management of Queues and Topics through Dashboard
  • High throughput, low latency
  • High availability clusters and elastic scalability
  • Decoupled application logic, develop micro services

Getting Started

SAP Enterprise Messaging falls under SAP Cloud Platform (Cloud Foundry) Integrations capabilities. To be able to access the SAP Enterprising Messaging as a pre-requisite, a user should already have a space in a Cloud Foundry sub-account.

Once the pre-requisite is satisfied, basic steps to create an Enterprise Messaging application includes

  • Create an Enterprise Messaging service instance
  • Configure Enterprise Messaging service instance
    • Queue
    • Queue Subscription
    • Application Configuration
  • Build an Application using Enterprise Messaging service instance

Create an Enterprise Messaging service instance

  1. Navigate to Spaces in CF and choose

                     Services > Service Marketplace >Enterprise Messaging Service

  1. Select a Service Plan (Lite or dev) and chose Next

  1. Parameters 

Specify parameters as below

emname : enterprise messaging instance name

management: true implies REST APIs for management

Enter instance name and choose Finish.

An instance of SAP Enterprise Messaging service can also be created from Cloud Foundry Command Line Interface.

So now you have an instance of SAP Enterprise Messaging service available for you to be able to work on it.

This blog has provided a brief introduction on SAP Enterprise Messaging service and it’s capabilities. As mentioned above, we shall come up with several other blogs which shall provide in detail on HOW TO WORK WITH SAP Enterprise Messaging.

References:

9 Comments
You must be Logged on to comment or reply to a post.
  • Very good document Pradreep.

    It is mentioned that Enterprise Messaging can be used in conjunction with the out-of-box event enablement for S/4 HANA. Is there any documentation in this regard describing how to set up S4HANA for forwarding events to Enterprise Messaging and which is the scope of bussines entities?

    Many thanks,

    Regards,

    C.

  • Hi Pradeep,

    Many thanks for your support.

    I have been playing in my CF Trial account with the REST API and everything looks very promising 🙂

    I have a few doubts and I would be very grateful if you could assist me for clarification.

    – Monitoring capabilities are minimum, basically reduced to seeing the number of messages in the queue and the overall size. Is this because I am using a trial account or because they are the only monitoring and tracing capabilities provided?

    – When retrieving a message from a queue with QoS = 1 an ACK call is needed to confirm the reception of the message and delete the message from the queue. How long does the message remain in the queue unavailable for other retrieval requests (maybe with an status “Retrieved but not confirmed”) if the message has been retrieved but no ACK is received?

    – For configuring a publish and subscribe scenario based on topics with N receivers I have done the following:

    1. Create N queues for the N receivers.
    2. Create N queue subscriptions for the queues created above and assign them to the same topic name.

    After this, If I pus a message to the topic,  the message is automatically pushed  to the N queues.

    Is this the correct way to configure publish and subscribe scenarios based on topics?

    – Is there any way to restrict the access to a queue by for example Service Key?

    Many thanks for your support.

    C.

    • – Monitoring capabilities are minimum, basically reduced to seeing the number of messages in the queue and the overall size. Is this because I am using a trial account or because they are the only monitoring and tracing capabilities provided?

      [Now that the basic building blocks of the EM is ready, we are working on extensive monitoring backlog items in the upcoming takts and you will start getting new monitoring features soon]

      – When retrieving a message from a queue with QoS = 1 an ACK call is needed to confirm the reception of the message and delete the message from the queue. How long does the message remain in the queue unavailable for other retrieval requests (maybe with an status “Retrieved but not confirmed”) if the message has been retrieved but no ACK is received?

      [If a message is in unacknowledged state, it will not be delivered to any other consumer. If the consumer of the message takes too long to ack the message, there is a possibility that the message becomes available for consumption again. QoS 1 does not guarantee exactly once delivery. It’s possible a message is delivered more than once if not acknowledged soon enough.]

      – For configuring a publish and subscribe scenario based on topics with N receivers I have done the following:

      1. Create N queues for the N receivers.
      2. Create N queue subscriptions for the queues created above and assign them to the same topic name.

      Is this the correct way to configure publish and subscribe scenarios based on topics?

      [This is the correct way if the consumer does not want to lose any message published to the topic (because queues retain every message while the consumer is offline). If the published messages are of less importance, or if you are not interested in old messages (e.g. temperature, stock price etc.), you may directly consume from topic. While you are offline, you’ll lose all the messages. But as soon as you come back online, you’ll start receiving the messages.]

      – Is there any way to restrict the access to a queue by for example Service Key?

      With the new EM delivery (message bus) planned for Q1 release, this will be possible. You’ll be able to define ACL for a client, e.g. which queue/topic the client can publish to / consume from.

      If you still have any query, please let us know.

      regards

      Pradeep