Messaging as a Gateway to a Clean and Pristine Core?
Things are about to get interesting for customers using S/4 HANA and SAP Cloud Platform. The idea that you can ‘loosely couple’ all major systems together is an elusive goal, if not a pipe dream, for many organizations. But why would you want to loosely couple? To what end? The obvious answer is of course to reduce the risk of changes in one system creating unanticipated changes in other systems or applications but, for me, the most interesting aspect of this architecture design principle is the idea that you could abstract your ERP system completely, with the goal of maintaining a pristine, clean core. Unfortunately, this would likely be impossible to achieve but we are in a position to get closer to that ideal.
Have I got your attention yet? Although I like to think in big swatches of color and enjoy using generalizations to help explain topics, it’s hard to make everything fit perfectly. So, let’s dig into this topic of loose coupling by focusing on the role the Cloud Platform can play in maintaining as clean a core as possible by using extensions delivered via SCP as opposed to directly within the core. So how does one truly abstract an extension? The answer to this lies in the type of extension—mobile, Fiori, IoT, UI5, messaging or predictive for example—and for this blog, I will zoom in on messaging. Let’s examine why I think messaging extensions can play a vital role in a journey toward what I call ‘lightly abstracted,’ a useful expression that I’m coining as my own!
Before we proceed, let me quickly define pub-sub methodology. In the world of ‘publish and subscribe,’ source systems and target systems are not tightly coupled. In fact, when a source system publishes a message (for example, an event that describes the status of the production order), it has no idea what other systems, services or applications will subscribe to or benefit from that event, so it’s a 1:many scenario. The source system is decoupled from the target systems, such as a CRM service, web portal or application, that subscribe to these events. As can be seen in the following diagram, the sender “publishes” a message to the message queue. From there, 1 or many subscribers can now use the Production Order message however they see fit. If one of those consumer systems shuts down or becomes available, it does not affect the other two consumer systems.
Let’s look at two messaging scenarios:
Scenario 1: A customer would like to be notified when their brand-new car rolls off the production line. (I’ve borrowed this example from the recent Las Vegas TechEd keynote.)
The scenario is not far-fetched: high-end car manufacturers offer a truly immersive customer experience by providing regular updates on the status of a new car purchase. It’s a great example of how customers can benefit when organizations go digital.
The age-old, antiquated approach to make this immersive experience a reality would be to customize the manufacturing system and create a connection between the supply chain system and the end-customer system. A second connection would connect the end-customer system with a mobile application and/or website the customer can access. It’s a messy approach—even when using your favorite integration technology, like SAP Process Integration—since the source and target systems are typically linked, creating a ‘tight coupling’ scenario with a 1:1 integration relationship that is difficult to reuse.
Enter the world of messaging where a pub-sub architecture using SAP Cloud Platform Enterprise Messaging (yes, SCP provides messaging in the cloud!) can be easily introduced. Instead of customized connections, the manufacturing system can create triggers that publish production order events, status updates, etc. Once an event is published, the only limitation is your imagination since the source and target systems are no longer tightly coupled. Any language that supports subscription to these events can be alerted to access the published information. So, if a customer application is running on a mobile device, these published events trigger the device to call APIs on the source system to retrieve the relevant details of the new car.
It’s important to note that the mobile application is not polling but is notified of the status change. It is essentially “poked” to retrieve the relevant details. The APIs used to retrieve the event details are essentially the digital building blocks of the core system and can be called by any application and are not specifically built or tied to the mobile application which of course encourages re-use. (In case you want more details on creating APIs with SCP, check out my Garage Series, Episode 3).
Wow—a completely decoupled scenario using Enterprise Messaging!
Pushing the boundaries of this example, what if I wanted to update another major system about the changes in the status of the product order—perhaps I would like to inform the sales rep so he could phone the customer? Again, given the loosely coupled scenario, the CRM system or application would subscribe to receive alerts while the publishing, or source, system remains completely oblivious.
Scenario 2. An organization wishes to create a custom application for sales reps who need real-time access to sales leads.
Most applications are not based on pub-sub architecture. In fact, the majority of applications that I see today are built using push-pull architecture—we push new records into databases, and we pull records out when we want to see them on demand. CRM systems are typically set up this way, with mobile applications providing access to CRM objects like customer information, sales orders, and lead information. So, in our example, a sales rep would open their lead application, then pull down the information they want to see, which results in a significant lag—the sales reps won’t see the new leads until they think to open the application and check for notifications.
Using the messaging paradigm however, allows for an interesting approach. Creating a simple sales lead application using SCP Enterprise Messaging and Fiori 2.0, which has a notifications panel that uses Web Sockets under the covers, can easily and quickly provide near-real time lead notifications to the sales by reacting to a published event. How? It’s simple. When a new lead is created in the CRM system, a new lead event is published and a trigger—based on a subscription—is pushed to the notifications panel within the application.
This innovative subscription messaging approach is relevant across a wide spectrum of communications—from work orders that need to be sent to technicians, to safety inspectors that need to be alerted of health and safety events, to engineers that need notifications of equipment line errors.
Moving in the Right Direction
There you have it—two examples of ‘lightly abstracted’ extensions using Enterprise Messaging that allow the core to remain as clean as possible. Will it guarantee that holy grail—the pristine, spotless core? Unfortunately, we’re still waiting for that magic bullet, but until we find it, Enterprise Messaging is definitely a step in the right direction.
If you have other scenarios that are of interest in the messaging area, I would enjoy hearing from you here or monthly in the virtual SAP Cloud Platform learning garage!
Have a great day.
Things are about to get interesting for customers using S/4 HANA and SAP Cloud Platform. The idea that you can ‘loosely couple’ all major systems together is an elusive goal, if not a pipe dream, for many organizations. But why would you want to loosely couple? To what end? The obvious answer is of course to reduce the risk of changes in one system creating unanticipated changes in other systems or applications but, for me, the most interesting aspect of this architecture design principle is the idea that you could abstract your ERP system completely, with the goal of maintaining a pristine, clean core. Unfortunately, this would likely be impossible to achieve but we are in a position to get closer to that ideal.
Have I got your attention yet? Although I like to think in big swatches of color and enjoy using generalizations to help explain topics, it’s hard to make everything fit perfectly. So, let’s dig into this topic of loose coupling by focusing on the role the Cloud Platform can play in maintaining as clean a core as possible by using extensions delivered via SCP as opposed to directly within the core. So how does one truly abstract an extension? The answer to this lies in the type of extension—mobile, Fiori, IoT, UI5, messaging or predictive for example—and for this blog, I will zoom in on messaging. Let’s examine why I think messaging extensions can play a vital role in a journey toward what I call ‘lightly abstracted,’ a useful expression that I’m coining as my own!
Before we proceed, let me quickly define pub-sub methodology. In the world of ‘publish and subscribe,’ source systems and target systems are not tightly coupled. In fact, when a source system publishes a message (for example, an event that describes the status of the production order), it has no idea what other systems, services or applications will subscribe to or benefit from that event, so it’s a 1:many scenario. The source system is decoupled from the target systems, such as a CRM service, web portal or application, that subscribe to these events. As can be seen in the following diagram, the sender “publishes” a message to the message queue. From there, 1 or many subscribers can now use the Production Order message however they see fit. If one of those consumer systems shuts down or becomes available, it does not affect the other two consumer systems.
Let’s look at two messaging scenarios:
Scenario 1: A customer would like to be notified when their brand-new car rolls off the production line. (I’ve borrowed this example from the recent Las Vegas TechEd keynote.)
The scenario is not far-fetched: high-end car manufacturers offer a truly immersive customer experience by providing regular updates on the status of a new car purchase. It’s a great example of how customers can benefit when organizations go digital.
The age-old, antiquated approach to make this immersive experience a reality would be to customize the manufacturing system and create a connection between the supply chain system and the end-customer system. A second connection would connect the end-customer system with a mobile application and/or website the customer can access. It’s a messy approach—even when using your favorite integration technology, like SAP Process Integration—since the source and target systems are typically linked, creating a ‘tight coupling’ scenario with a 1:1 integration relationship that is difficult to reuse.
Enter the world of messaging where a pub-sub architecture using SAP Cloud Platform Enterprise Messaging (yes, SCP provides messaging in the cloud!) can be easily introduced. Instead of customized connections, the manufacturing system can create triggers that publish production order events, status updates, etc. Once an event is published, the only limitation is your imagination since the source and target systems are no longer tightly coupled. Any language that supports subscription to these events can be alerted to access the published information. So, if a customer application is running on a mobile device, these published events trigger the device to call APIs on the source system to retrieve the relevant details of the new car.
It’s important to note that the mobile application is not polling but is notified of the status change. It is essentially “poked” to retrieve the relevant details. The APIs used to retrieve the event details are essentially the digital building blocks of the core system and can be called by any application and are not specifically built or tied to the mobile application which of course encourages re-use. (In case you want more details on creating APIs with SCP, check out my Garage Series, Episode 3).
Wow—a completely decoupled scenario using Enterprise Messaging!
Pushing the boundaries of this example, what if I wanted to update another major system about the changes in the status of the product order—perhaps I would like to inform the sales rep so he could phone the customer? Again, given the loosely coupled scenario, the CRM system or application would subscribe to receive alerts while the publishing, or source, system remains completely oblivious.
Scenario 2. An organization wishes to create a custom application for sales reps who need real-time access to sales leads.
Most applications are not based on pub-sub architecture. In fact, the majority of applications that I see today are built using push-pull architecture—we push new records into databases, and we pull records out when we want to see them on demand. CRM systems are typically set up this way, with mobile applications providing access to CRM objects like customer information, sales orders, and lead information. So, in our example, a sales rep would open their lead application, then pull down the information they want to see, which results in a significant lag—the sales reps won’t see the new leads until they think to open the application and check for notifications.
Using the messaging paradigm however, allows for an interesting approach. Creating a simple sales lead application using SCP Enterprise Messaging and Fiori 2.0, which has a notifications panel that uses Web Sockets under the covers, can easily and quickly provide near-real time lead notifications to the sales by reacting to a published event. How? It’s simple. When a new lead is created in the CRM system, a new lead event is published and a trigger—based on a subscription—is pushed to the notifications panel within the application.
This innovative subscription messaging approach is relevant across a wide spectrum of communications—from work orders that need to be sent to technicians, to safety inspectors that need to be alerted of health and safety events, to engineers that need notifications of equipment line errors.
Moving in the Right Direction
There you have it—two examples of ‘lightly abstracted’ extensions using Enterprise Messaging that allow the core to remain as clean as possible. Will it guarantee that holy grail—the pristine, spotless core? Unfortunately, we’re still waiting for that magic bullet, but until we find it, Enterprise Messaging is definitely a step in the right direction.
If you have other scenarios that are of interest in the messaging area, I would enjoy hearing from you here or monthly in the virtual SAP Cloud Platform learning garage!
Have a great day.
- SAP Managed Tags:
7 Comments
