This post helps you to get jump started with Enterprise Messaging and learn about the basics. So what is Enterprise Messaging?
Enterprise Messaging consist of two main elements:
Okay this one is easy. Message brokers are already out in the wide oceans since decades. Messaging is:
So instead of sending messages directly to receivers (clients) we rather send them to a messaging broker, who then forwards the message. Using a middleware has (among others) the following benefits:
By now we know that with a message broker we are not using a point-to-point communication model. Rather we build a message-oriented architecture which can use the following message concepts:
Publishers send their message to a queue. A receiver can subscribe to the queue in order to receive the message. It’s only possible to “take out” the message from the queue exactly once. That’s why we typically have a 1:1 relationship between a queue and a client.
There are exceptions for example when we want to implement a Round Robin technique. Then multiple clients can subscribe to a queue. Messages entering the queue are evenly distributed to the clients, in order to e.g. balance load.
The messages in a queue are retained until consumed by a client.
Publishers send their message to a topic. We typically have a 1:N relationship between a topic and clients. This concept is used when each message shall be send to several receivers.
The messages send to topics are not retained. Receivers need to be active.
Queues and topics can also be combined. The messages which are send to a topic are directly send to a corresponding queue. Event notifications from an event source like the S/4HANA system can only be sent to a topic and in case you want to support receivers which can be temporarily offline you can use the queue subscription concept.
What is an event? An event is a significant change in state (of an object in an enterprise system). So, whenever a change in state happens the responsible event publisher who observes the object sents an event notification to inform other systems, microservices, and applications of the change. A business event is an event happening in an enterprise system and the content of the event notification can be structured based on a specification, e.g. Cloud Events. Cloud Events are a specification for describing event data in a common way. This is needed as event publishers tend to describe events differently.
Event data based on cloud events look like the following (version 0.2):
Hold on! Where is the data? Business partner and supplier ID… that’s it? Yes, that’s it! Basically, you can put into the message whatever you want (keeping max. message size in mind). As a best practice you only put the ID of the object which had changed. As a publisher you usually don’t know every client which e.g. has subscribed to a queue/topic and therefore you don’t know if the receiver is allowed to read the actual data. That’s why you only send the ID ore more precisely inform the client about only which object(s) has changed (but not what). It’s then up to the client to request the actual data via an authenticated request so that authorization checks etc. can happen. There might be scenarios where the above is not true and under different circumstances it might make sense to put the actual data into the event notification itself, e.g. when no authorization checks have to happen, etc. But sending only the ID and letting the client request the actual data (in order to perform authorization checks) is definitely one common way of working with events in business processes.
Having understood the fundamentals, one might ask how does this look like at SAP? SAP Cloud Platform Enterprise Messaging is a fully-managed cloud service running on Cloud Foundry. SAP as the provider is responsible for managing and dynamically scaling the resources required for your applications. It can also just be used as a message broker without the business event part. In general Enterprise Messaging allows systems, applications and services across different platforms and technologies to communicate with each other in an asynchronous way. You can extend your digital core by developing cloud native applications which participate in event-driven business processes and makes use of greater agility and scalability.
Event sources at SAP are (e.g.):
Events at SAP are a change in state of a business object. The plan is to support as much business objects as possible (preferably all) including custom business objects. However, this is not true yet. Lists for supported business objects are available for S/4HANA Cloud and SAP Marketing Cloud.
The configuration to receive events from an SAP event source might be some work until you get everything up and running. SAP understands that their products must integrate smooth and easily. That’s why they developed the extension factory. With the extension factory (system tab in the cockpit on SAP Cloud Platform) it possible to easily setup up a scenario such with Enterprise Messaging within a few clicks. You can find out more information here. This is only possible with the new service plan ‘Default’ – see here.
“People don't care about what you say, they care about what you build.” - Mark Zuckerberg
With Enterprise Messaging we can build great things. Think about a dashboard application based on web sockets showing you the latest data about a business object all without pulling! Think about business events triggering an iFlow on SAP CPI! Think about combining serverless functions with enterprise messaging. Think about….
You get my point and now it’s your turn. Start building great things with SAP Cloud Platform Enterprise Messaging. Happy Coding.
Enterprise Messaging consist of two main elements:
- Message Broker
- Business Events
Message Broker
Okay this one is easy. Message brokers are already out in the wide oceans since decades. Messaging is:
“In programming, messaging is the exchange of messages (specially-formatted data describing events, requests, and replies) to a messaging server, which acts as a message exchange program for client programs.”
“Messaging also makes it easier for programs to communicate across different programming environments (languages, compilers, and operating systems) since the only thing that each environment needs to understand is the common messaging format and protocol.”
Source: http://whatis.techtarget.com/definition/messaging
So instead of sending messages directly to receivers (clients) we rather send them to a messaging broker, who then forwards the message. Using a middleware has (among others) the following benefits:
- We don’t need to know any client specific protocols or interfaces, as we never talk to the clients directly. Rather we all agree on specific languages/protocols (usually AMQP or MQTT) and only need to be able to talk to the middleware, which is our message broker. Source code, libraries and complexity are drastically reduced, because only the message brokers protocol is used.
- Applications on different technology and platforms can exchange data, if they can implement a protocol like AMQP or MQTT.
- It’s possible to temporarily persist messages in queues until they have been delivered reliably to receiving clients. Even if the receivers are temporarily offline, the message can get buffered and is delivered when the receiver is back online. Developers don’t have to take care of buffering messages, etc. This is all done by the message broker.
- Asynchronous (non-blocking) communication between senders and receivers. Just fire your message out to the message broker and continue with processing your logic. Again, when the message broker receives the messages, he takes care of delivering it to the receivers.
- Your applications get’s smaller because the task of message delivery is delegated to a dedicated message broker. This also means that your applications get easier to read, maintain, test and performance increases.
- By using a message broker, we enable distributed systems to communicate with each other. In this setup you are loosely coupled so you can switch seamlessly between architectures when environment changes.
By now we know that with a message broker we are not using a point-to-point communication model. Rather we build a message-oriented architecture which can use the following message concepts:
Queues
Publishers send their message to a queue. A receiver can subscribe to the queue in order to receive the message. It’s only possible to “take out” the message from the queue exactly once. That’s why we typically have a 1:1 relationship between a queue and a client.
There are exceptions for example when we want to implement a Round Robin technique. Then multiple clients can subscribe to a queue. Messages entering the queue are evenly distributed to the clients, in order to e.g. balance load.
The messages in a queue are retained until consumed by a client.
Topics
Publishers send their message to a topic. We typically have a 1:N relationship between a topic and clients. This concept is used when each message shall be send to several receivers.
The messages send to topics are not retained. Receivers need to be active.
Queue Subscriptions
Queues and topics can also be combined. The messages which are send to a topic are directly send to a corresponding queue. Event notifications from an event source like the S/4HANA system can only be sent to a topic and in case you want to support receivers which can be temporarily offline you can use the queue subscription concept.
Business Events
What is an event? An event is a significant change in state (of an object in an enterprise system). So, whenever a change in state happens the responsible event publisher who observes the object sents an event notification to inform other systems, microservices, and applications of the change. A business event is an event happening in an enterprise system and the content of the event notification can be structured based on a specification, e.g. Cloud Events. Cloud Events are a specification for describing event data in a common way. This is needed as event publishers tend to describe events differently.
Event data based on cloud events look like the following (version 0.2):
Hold on! Where is the data? Business partner and supplier ID… that’s it? Yes, that’s it! Basically, you can put into the message whatever you want (keeping max. message size in mind). As a best practice you only put the ID of the object which had changed. As a publisher you usually don’t know every client which e.g. has subscribed to a queue/topic and therefore you don’t know if the receiver is allowed to read the actual data. That’s why you only send the ID ore more precisely inform the client about only which object(s) has changed (but not what). It’s then up to the client to request the actual data via an authenticated request so that authorization checks etc. can happen. There might be scenarios where the above is not true and under different circumstances it might make sense to put the actual data into the event notification itself, e.g. when no authorization checks have to happen, etc. But sending only the ID and letting the client request the actual data (in order to perform authorization checks) is definitely one common way of working with events in business processes.
SAP context
Having understood the fundamentals, one might ask how does this look like at SAP? SAP Cloud Platform Enterprise Messaging is a fully-managed cloud service running on Cloud Foundry. SAP as the provider is responsible for managing and dynamically scaling the resources required for your applications. It can also just be used as a message broker without the business event part. In general Enterprise Messaging allows systems, applications and services across different platforms and technologies to communicate with each other in an asynchronous way. You can extend your digital core by developing cloud native applications which participate in event-driven business processes and makes use of greater agility and scalability.
Event sources at SAP are (e.g.):
- SAP Business Suite System
- SAP S/4HANA (Cloud or On-premises)
- SAP SuccessFactors
- SAP Concur
- SAP Cloud for Customer
- SAP Marketing Cloud
Events at SAP are a change in state of a business object. The plan is to support as much business objects as possible (preferably all) including custom business objects. However, this is not true yet. Lists for supported business objects are available for S/4HANA Cloud and SAP Marketing Cloud.
The configuration to receive events from an SAP event source might be some work until you get everything up and running. SAP understands that their products must integrate smooth and easily. That’s why they developed the extension factory. With the extension factory (system tab in the cockpit on SAP Cloud Platform) it possible to easily setup up a scenario such with Enterprise Messaging within a few clicks. You can find out more information here. This is only possible with the new service plan ‘Default’ – see here.
Motivation
“People don't care about what you say, they care about what you build.” - Mark Zuckerberg
With Enterprise Messaging we can build great things. Think about a dashboard application based on web sockets showing you the latest data about a business object all without pulling! Think about business events triggering an iFlow on SAP CPI! Think about combining serverless functions with enterprise messaging. Think about….
You get my point and now it’s your turn. Start building great things with SAP Cloud Platform Enterprise Messaging. Happy Coding.
- SAP Managed Tags:
2 Comments
