Hi, I’m Middleware!
Not really, but this is something that I go through in my daily schedule. I stay in a shared accommodation where-in I share it with a friend of mine who doesn’t understand Hindi language but can communicate in English. We have a hired cook who doesn’t understand English and can communicate in Hindi only. Now this leads to a situation where my friend cannot communicate with each other since they don’t speak a common language. That’s where I step in. I can communicate in both Hindi and English. I’m the middleware between my friend and the cook where I receive information in one language and supply the same info in another language so that the information is successfully processed.
Middleware, as would be clear by now, is nothing but the mechanism which helps two different systems to interact with each other irrespective of the format of information. So if we consider my friend and the cook to be two different systems who speak different languages, I play the role of the middleware enabling them to interact with each other.
This blog is going to talk about the middleware and it’s journey from on-premise era to cloud era.
The real Middleware…
Let’s get to the systems now. Being a SAP CX Consultant, the middleware is something that you need to get to every now and then. As specified earlier, it is the mechanism which is used to exchange information between the two systems and it is an inbuilt component of SAP CRM. It enables the SAP CRM system to communicate with various other SAP systems like ERP, BW, APO and also third party Non-SAP systems.
Data Exchange between the SAP Systems and Non-SAP Systems is done by the use of Adapters. Adapter is a bridge between the systems which maps and converts the data into various formats.
Let us understand the concepts of CRM Middleware with the simple diagram:
There are multiple Objects in SAP System like Master Data, Products, Accounts and Account Hierarchy etc. that may need to be transferred from one SAP System to another. From the above diagram we can see that ERP system sends the customer information to CRM by triggering function module in ECC system which will send the data to CRM through Outbound Queue of ERP and CRM receives the information through inbound queue of CRM and then trigger the function Module in CRM to store the data into respective/mapped tables. It is a bi-directional process and same flow will be followed in the reverse direction through the respective Outbound and Inbound Queues.
Mr Outbound and Ms Inbound
Inbound Queue (SMQ2): Whenever there is information coming from an external system, the inbound queue checks and controls the data flow into CRM System.
Outbound Queue (SMQ1): Whenever we need to pass the information to external system, the Outbound Queue will check and control the data to flow out of CRM System.
Conceptually when we execute the Transactions SMQ2 or SMQ1, we see multiple queues executing. If the queue name starts with R3 it signifies that the data is being sent to or received from ERP System and if the queue names starts with BW it means data is being exchanged with BW System.
Loading of the various objects can happen between a source and a target system. Here we have source system e.g. ERP and a target system e.g. CRM or vice-versa. We have two different types of Loads. Below picture depicts the Loading concept in SAP CRM Middleware including both Initial and Delta Loads:
The travelers of integration:
1.) Business Objects: These are the standard objects and cannot be changed. We can see the objects using the transaction code R3AC1.
2.) Customizing Objects: These are the custom (customer specific) objects which are customized and are created/developed according to the customer requirement.
3.) Condition Objects: These objects are used for Pricing which is mostly maintained in SAP SD (ERP) system. So to replicate the pricing conditions, tax conditions and condition tables we can use these condition objects.
Meet BDocs. They do the talking…
B-doc stands for Business Document which is used for transferring and processing the actual data in SAP CRM System. Going back my daily routine example, B-docs is basically the language that SAP CRM speaks. A B-docs is a single unit or block of information which carries information from multiple tables which as a whole forms one instance of an object. This helps in transferring the complete info on an object instance instead of passing table-wise info. We have two different types of B-docs:
- M-BDocs (Messaging B-doc): used for the communication between SAP CRM and other SAP Systems like ERP
- S-BDocs (Synchronization B-Doc): used for the communication between the Mobile Clients.
Basically we are using B-docs as a single entity for the communication between the SAP Systems which contains data from many tables. We can monitor the status of B-docs in SAP CRM by using Transaction code SMW01 (Display B-docs) or SMW03 (Unprocessed B-doc Messages) and check whether the data has been replicated successfully into the target SAP System or not.
So, we can easily infer that Middleware is the backbone of all interaction with a SAP CRM System because we need always one communication mechanism to pass the information from one system to another system.
Now, with the advent of cloud, technologies have change and there has been a paradigm shift between how systems interact. Let’s take a brief look at how systems integrate in the cloud era.
The Middleware Cloud-ified…
Today, more and more organizations are moving their systems landscapes to cloud systems. A hybrid model is seen to be more rampant where the on-premise systems are augmented with the cloud systems so as to provide more flexibility and mobility to the users. The cloud version of SAP CRM is SAP Cloud for Customer system. Let’s assume a scenario where information on Accounts, Contacts, Pricing, Material Information etc. is stored in the back-end on-premise SAP CRM/ERP system. These details from SAP CRM/ERP System are needed whenever we are creating transactions like opportunities, quotes, sales orders etc. in SAP Cloud for Customer where most of the information are replicated from SAP CRM/ERP system. Now, the integration between cloud and on-premise systems brings into action the below use-cases:
- Upgrading to SAP Cloud for Customer solution helps sales representative to provide better customer experience making SAP CRM/ERP systems as back-end for supporting the key master data like accounts, contacts, pricing, products etc.
- Enabling Organizations that have existing investments in on-premise systems to extend their solution to SAP Cloud for Customer i.e. SAP Customer Experience. In this scenario we use integration with SAP CRM/ERP system for replication of existing information including master data as well as transaction data.
- Implementing an enterprise level solution for all business functions viz. sales, service, and marketing.
SAP provides three integration options offered as pre-packaged integrations with cloud solutions. Here is a quick look at these:
- SAP HANA Cloud Integration: This one is basically SAP’s Cloud middleware that can be used for integration. It is an option for the customers who do not want to have any integration middleware over the on-premise side of the system. It is a real time process integration as well as data integration which ensures information accuracy and enables better customer experience.
- SAP PI/PO: It is an Integration platform which provides seamless integration between SAP Systems and Non SAP Applications within the organization or even outside the organization. It offers better monitoring features like messages, performance, component monitoring to track and rectify the errors.
- Third Party Middleware: We have various middleware tools which includes MuleSoft, EAI (Enterprise Application Interface) etc. which make it easy for the systems to communicate.
Middleware can be considered the glue that holds together applications, making seamless connectivity possible without requiring the two applications to communicate directly.
Hope you enjoyed reading this blog and found it useful.