Technology Blogs by Members
Explore a vibrant mix of technical expertise, industry insights, and tech buzz in member blogs covering SAP products, technology, and events. Get in the mix!
cancel
Turn on suggestions
Auto-suggest helps you quickly narrow down your search results by suggesting possible matches as you type.
Showing results for 
Search instead for 
Did you mean: 

Building Integration Architecture for the Omni-channel Commerce

stevang
Active Participant
‎12-17-2023 2:05 PM


We live in the global village… Looks like we are so much connected, and yet we are always seeking for more and better ways to integrate…

At the core of the Omni-channel (and Channel-less as well) Commerce is, integration, integration and more integration…

In this article, I am covering:

From Multi-channel to Omni-channel Commerce


What is Multi-channel Commerce?

While Customer has multiple options to learn about the Brand and Products – Customer uses its preferred Channel to (re)search and make purchases. Each Channel essentially works on its own – pretty much independent from other Channel(s). We may also say, each Channel works in its best interests trying to “increase” its sales, but not necessarily in the best interest of the Customer experience – this may lead to the “competition” of different Channels working against each other, even at the cost of the overall sales to the Customer.

What is then Omni-channel Commerce[1]?

This is Customer centric approach. Here, all Channels work together to increase Customer awareness of the Brand and Products; increase overall engagement with the Customer, and thus increase overall sales. Channels do not compete, but “complement” each other – leaving to the Customer to chose most suitable Channel at any point of time.


Figure 1. Multi-channel and Omni-channel Commerce


To unlock the potential of the Omni-channel Commerce, we need to build the seamless integration between backend Core (Master) Systems and Client Systems – working and Commerce Channels.

How to do that?

The starting point would be – setting the Integration Strategy and the Integration Architecture for the Intelligent Enterprise – this is the foundation layer (Integration Architecture Part 1 and Part 2). After we have built the foundation, we can start building our network of integration “roads” (Integration Architecture Part 3) – meeting the specific business demands – in this case, Omni-channel Commerce.

Building integrations in phases


Let’s go through practical example of building a solution for the Omni-channel (or Channel-less) Commerce, with S/4HANA as a backed core for the Order Fulfilment process.

Integrating your first System(s)


Popular joke says: When Alexander Graham Bell built his first telephone, this was really something – but the real revolution started when he built the second one…

If we want to implement our Order Fulfillment in S/4HANA and connect first Order Taking Channel(s) – it is not enough to enable (or build) APIs on S/4HANA side – we also need to enable (or build) APIs on the “other” side. Of course, at latter stage, for adding (or subscribing) other Channels, we will leverage those APIs by publishing them to the other System(s) – this is the “order of the day”. Pls note, while some APIs will behave like PubSub Event messaging (i.e. DRF will publish “full” payload on change pointer Event), this “lite” PubSub approach is still far away from the “real” Event-Driven Architecture. At the end-state, our Integration Architecture should move more-and-more to the ”real” Event-Driven Architecture – of course, for those services where Even messaging and Event topics are possible.

But first we must build, test and prove the initial concept.

Let’s say, we are connecting “Sales App” which will be used as a primary Channel for the Customer Engagement (Lead-2-Cash) and Customer 360 in general.


Figure 2. Setting the first integrations


In the example, we have enabled standard Integration Services in S/4HANA:

  • DRF SOAP Business Partner Replication and Business Partner Relationship Replication – using PUSH for the bi-directional synchronization of the Account/Customer and Contact data;

  • IDoc MATMAS Material Replication – using PUSH for sending Product data;

  • DRF SOAP Sales Organization Replication – using PUSH for sending Sales Organization data;

  • OData API_SALES_QUOTATION_SRV Sales Quotation (A2X) for inbound Offer requests – using POST, PATCH and GET methods for creating, updating and reading Offers;

  • OData API_SALES_ORDER_SIMULATION_SRV Sales Order Simulation (A2X) for inbound ATP Check (incl. checking only ATP for one or more items), Price Check (incl. checking only unit/total price for one or more items) and Order Checkout (full Order Simulation) – using POST method only;

  • OData API_SALES_ORDER_SRV Sales Order (A2X) for inbound Order Taking requests– using only POST and PATCH methods for creating and updating Orders;

  • DRF SOAP Sales Order Replication (A2A)– using PUSH for sending Sales Order data;

  • OData API_BILLING_DOCUMENT_SRV Billing Document request – using only GET method for reading Invoices.


For this example, we use Replication Integration Function for Customer data and Sales Order data.

Why replicating data, why not sending Data Events?

We could, but we would have to create multiple Event topics, basically for each entity within Customer data and Sales Order data. Also, for the Customer data, all Data Events would have to be bi-directional (outbound, but also inbound to S/4HANA). We could also use SAP Master Data Integration and/or SAP Master Data Governance solutions in our landscape – but is this scenario we will stay with the basic approach (let’s start with the “small steps”).

In this scenario, “Sales App” is our main Customer 360 Channel – producing various Customer Attributes, include Marketing Attributes, Segmentation etc. For that, we sync “full” Customer data model between S/4HANA and “Sales App”, as well as “all” Sales Orders from S/4HANA to “Sales App” (i.e. Sales Order could be created/updated in S/4HANA directly). Of course, this is just an example with closely coupled Customer 360 capability in one app, but it could be detached, processed, and integrated within set of apps.

Also, please note, in this example I have used IDoc MATMAS for enabling Material Replication – however other approaches for integrating Material/Product data could be also used depending of the S/4HANA version e.g. DRF SOAP Product Replication to PUSH or OData API_PRODUCT_SRV Product Master (A2X) to PULL data.

Reuse of integrations for the next System(s)


Now that we have enabled key Integration Services in our backend System – let’s start reusing it by subscribing additional Systems(s) …

Let’s imagine, we are extending our commercial activities to the new “Web Shop” Channel.


Figure 3. Reusing the integrations


In the example, we are re-using already published Integration Services from S/4HANA:

  • DRF SOAP Business Partner Replication and Business Partner Relationship Replication – using PUSH for the bi-directional synchronization of the Account/Customer and Contact data; enabling self-service registration from the “Web Shop”; replicating only relevant subset of Customers and Customer Attributes from S/4HANA

  • IDoc MATMAS Material Replication – using PUSH for sending Product data;

  • DRF SOAP Sales Organization Replication – using PUSH for sending Sales Organization data; this would be option – depending if Customers assigned to multiple Sales Organizations could use this Channel;

  • OData API_SALES_ORDER_SIMULATION_SRV Sales Order Simulation (A2X) for inbound ATP Check (incl. checking only ATP for one or more items), Price Check (incl. checking only unit/total price for one or more items) and Order Checkout (full Order Simulation) – using POST method only;

  • OData API_SALES_ORDER_SRV Sales Order (A2X) for inbound Order Taking requests– using POST, PATCH and GET methods for creating, updating and reading Orders;

  • OData API_BILLING_DOCUMENT_SRV Billing Document request – using only GET method for reading Invoices.


Here things become a bit more interesting:

  1. There is always one flow between S/4HANA and SAP Integration Suite; we use SAP Integration Suite as a “focal” point for all inbound and outbound Integration Services – of course new Channel(s) do not need to subscribe to all Integration Services;

  2. For inbound Integration Services, we are re-using already developed and deployed APIs, by exposing endpoints to the subscribed Channel(s);

  3. For outbound Integration Services, we are also reusing already developed and deployed APIs, by multicasting payloads to the subscribed Channel(s);

  4. Within IFlow in SAP Integration Suite we may filter-out some data (e.g. not all Customers are being replicated to all Channels), we may filter out data sets (e.g. not all Customer Attributes are being replicated to all Channels)

  5. Adding “new” methods – e.g. in OData API_SALES_ORDER_SRV Sales Order (A2X) we have used GET method as well for reading Order History.


So, reuse is the key “word” here…

Example with SAP Commerce Cloud


In the previous example for the “Web Shop” I have evaluate rather general Architecture. Now, let me present an integration concept which could be used for SAP Commerce Cloud – of course, just as a high-level Architecture.


Figure 4.a. Integrating SAP Commerce Cloud


In the example, we are also re-using already published Integration Services from S/4HANA:

  • DRF SOAP Business Partner Replication and Business Partner Relationship Replication – using PUSH for the bi-directional synchronization of the Account/Customer and Contact data; enabling self-service registration from SAP Commerce Cloud; replicating only relevant subset of Customers and Customer Attributes from S/4HANA;

  • IDoc MATMAS Material Replication – using PUSH for sending Product data;

  • DRF SOAP Sales Organization Replication – using PUSH for sending Sales Organization data; this would be option – depending if Customers assigned to multiple Sales Organizations, could use this Channel;

  • OData API_SALES_ORDER_SIMULATION_SRV Sales Order Simulation (A2X) for inbound ATP Check (incl. checking only ATP for one or more items), Price Check (incl. checking only unit/total price for one or more items) and Order Checkout (full Order Simulation) – using POST method only;

  • OData API_SALES_ORDER_SRV Sales Order (A2X) for inbound Order Taking requests– using POST, PATCH and GET methods for creating, updating and reading Orders;

  • OData API_BILLING_DOCUMENT_SRV Billing Document request – using only GET method for reading Invoices.


In general, no major differences as per S/4HANA enabled APIs, but there are some specifics…

What are those specifics?

  1. Using SAP Customer Data Cloud to ensure Customer Consent is captured, and Customer Identity is being verified with connected Enterprise identification and SSO services, either using Replicate Business Partner from SAP S4HANA to SAP Customer Data Cloud as Approved Organization standard Integration Package and IFlow[2] or using existing Customer/Account Integration Servies with necessary adjustments in the Integration Suite;

  2. Based on the current version of SAP Commerce Cloud, Integration Extension Pack[3] order process is based on standard Sync OData APIs. There are no more “prescribed” integration packages for IDocs etc. In fact, for Order APIs, it is foreseen to use direct integration between SAP Commerce Cloud and S/4HANA, without any use of SAP Integration Suite.



Figure 4.b. Integrating SAP Commerce Cloud using CSRF token


Let me evaluate further this Architecture…

SAP Customer Data Cloud can be used as an Enterprise tool even if we are using SAP Commerce Cloud as a Web Shop (or Web Portal) app. Also, it can be used for other Channels as well – e.g. even Customer is created/registered in CRM, we may still need to ask the Customer to provide its Consent… So, SAP Customer Data Cloud can be part of our Omni-channel Integration Architecture, disregarding which apps we use overall.

Standard integration scenario for SAP Commerce Cloud foresees direct integration with S/4HANA OData APIs, using CSRF token, after Customer login. However, I do not see this as an obligatory approach. We may still decide to use SAP Integration Suite as a “focal” point for all Integration Services, for all subscribed Channels. Of course, in this case SAP Commerce Could Order APIs would have to be adjusted to use (e.g.) OAuth authentication when connecting with SAP Integration Suite endpoint.

SAP Integration Suite, when properly designed and configured, does provide only minimum latency, but provides unified orchestration and clear observability, for all included Integration Services, and all in one place.

Each Enterprise will make its own decision and adjust Reference Integration Architecture into its own Enterprise Integration Architecture

Extend further by subscribing new Channels


When building Omni-channel Commerce, we would probably not go “big-bang” all apps (for all Channels) at once. With introduction of every new app (or System in general terms), we are leveraging the knowledge and experience of the previous integration(s). The choice of apps, an order in which they will be integrated in the environment etc. this would always be specific for each Enterprise or Organization – based on its own business needs.

I have started with the “Sales App” (or main CRM system) and “Web Shop”. Now, let’s go further with few more “usual” examples…

Example with the Field sales


In some cases, we will have to extend the scope of the initially built Integration Services. For the Field sales, beside the mobility component, we might also need partial off-line capability. What does this mean?

  1. We cannot rely fully on online APIs to “prepare” for Order Taking – i.e. we cannot use Sales Order Simulation (A2X) to perform ATP Check (check Product availability) and Price Check (acquire Product price);

  2. Relevant data for Order Taking will be preloaded on the device while it is online;

  3. Online Order Checkout (full Order Simulation) may still be an option if device is online;

  4. Order Taking can be done in offline mode (new Orders created) and synchronized when device is online.


To enable this kind of service, we need to provide replication, not only of Master Data (Customers, Products etc.), but also:

  • Inventory – to enable checking Product availability offline;

  • Price and Promotion – to enable calculate Order price offline;



Figure 5. Extending integrations for the Field sales


In this example, we have enables additional Integration Services:

  • IDoc LOISTD for Material Master requirements/stock list – using PUSH for sending Stock data; alternatively other approaches for Stock data could be also used e.g. OData API_MATERIAL_STOCK_SRV Material Stock - Read to PULL data.

  • For Price and Promotion we can use at minimum OData API_SLSPRICINGCONDITIONTYPE_SRV Condition Type for Pricing in Sales, OData API_SLSPRICINGCONDITIONRECORD_SRV Condition Record for Pricing in Sales, and OData API_SLSPRICINGPROCEDURE_SRV Pricing Procedure in Sales – using GET method for reading Price and Promotion data; depending of the S/4HANA version e.g. other APIs[4] as well as IDoc COND_A approach could be used;


However, offline use, does come with some limitations:

  1. LOISTD for Material Master requirements/stock list is based on MRP (Material Requirement Planning), which is not (or may not be) the same as ATP (Available-To-Promise). MRP is actually based on the Availability Check – e.g. if the desire quantity can be met on the requested delivery date or not. In the Customizing we can set if the Availability Check is based on ATP or against planning, where ATP itself represents = Total Warehouse Stock + Planned receipts (Incoming Stock) - Planned Issues (Outgoing stock).

  2. Complex pricing, especially promotions, might be difficult to recreate in the Client System. It is necessary that Client System understand relevant Condition Types as a “Master Data” for pricing, then to use relevant Condition Records as per Pricing Procedure.


How to overcome those limitations?

In fact, for offline use, LOISTD can do just fine. Just to be on the safe side, we still have to keep Order Checkout (full Order Simulation) as a “security” mechanism to be executed prior Order Taking – assuming device is online. The other “security” mechanism is the Order Taking itself – Order is confirmed on the device only once it is being successfully synchronized with the backend and order confirmed by S/4HANA.

Indirect sales


In the Indirect sales, our Business is serving Customers through 3rd Parties. The overall Order Fulfillment process is split between our Enterprise and 3rd Parties – let’s not confuse this with B2B Trading Partner scenario, as this is not exactly the same.

As far as Order Taking process, we can have multiple scenarios:

  1. We receive Orders through our Commerce Channels (e.g. Sales App), Orders are processed and sent to the 3rd Party to finalize Order Fulfillment. In this scenario Customer is (usually) invoiced through our Channels

  2. Orders are taken by the 3rd Party, based on our Customer and Product Master data, and based on our Price and Promotion Order Fulfillment is executed by the 3rd Party. Usually, the actual 3rd Party will be Bill-to Party (party which is invoiced) and/or Payer (party which is actually paying invoiced amount), not Customer itself – however, this all depends on the specific Business Processes we are implementing.

  3. Combined case of the first two scenarios, where 3rd Party can both, receive and take Orders as well.


As per 3rd Party relationship, we can have multiple scenarios as well:

  1. “Exclusive” – e.g. Wholesaler selling and distributing only our own Product portfolio. An example would be a dealer or franchiser authorized to cover specific region or subset of Product portfolio in the specific region.

  2. “Non-exclusive” – e.g. 3rd Party marketplace connecting existing marketplaces from various Businesses (Companies or Brands) into single “look-and-feel” marketplace. The Order Taking experience is managed by the 3rd Party marketplace, fully transparent for the Customer, where in the background 3rd Party marketplace is aggregating marketplaces from the various Businesses (Companies or Brands) – communicating with each marketplace based on predefined integration protocol. An example would be e.g. Wholesale who is dealing different Product portfolios, from various Businesses (Companies or Brands), mixing them into “one” End Customer Order, while taking individual Orders from each Business (Company or Brand).


Depending on the particular scenario, to enable this kind of service, we need to provide bi-directional replication:

  • Inventory – we might need to have an information of 3rd Party Stock data (of our Product portfolio), just as 3rd Party might needs to have an information of our Stock data (to be able to take Orders) – depending on the particular scenario;

  • Price and Promotion – in the specific cases we might need to have an information on 3rd Party Price and Promotion data (specific for this 3rd Party, but for our Product portfolio), as well 3rd Party might needs to have an information of our Price and Promotion data (to be able to take Orders) – again depending on the particular scenario.



Figure 6. Extending integrations for the Indirect sales


For the Indirect sales,

  • Integration might require some additional re-mapping of our Customer and Product Master data. If we operate with multiple Sales Organization (or Sales Areas in general), re-mapping with our Organizational data would be needed as well.

  • When we receive Orders and “forward” it to the 3rd Party, beside setting clear Business Rules; we might need to record relevant Stock data from the 3rd Party – PUSH data from the 3rd Party into our ERP special Warehouse or Storage Location. Also, there could be some specific Price and Promotion applicable when Order Fulfilment is executed by the (selected) 3rd Party – again PUSH data from the 3rd Party into our ERP special Conditions.

  • When Orders are taken by the 3rd Party, beside setting clear Business Rules; 3rd Party needs to have an information of our Stock , Price and Promotion data, so Order Taking can be performed via 3rd Party Commercial Channels.


While all (re-)mapping can be performer also in SAP Integration Suite within Value Mapping, or in some cases we might go for B2B Trading Partner scenarios – but for large scale operations (working with multiple 3rd Parties, in multiple regions/countries), engaging “Unified Translation” Middleware Services could be more prudent choice.

Some 3rd Party marketplaces also provide natural integration with Web Shops – e.g. Mirakle marketplace connecting with, or managing, SAP Commerce Cloud[5][6]. Obviously, in this scenario, there is no need for any additional “Unified Translation” Middleware Services.

EDI


When we talk about EDI (Electronic Data Interchange), we are talking about B2B (Business to Business) communication. Both parties exchanging messages can be providing or purchasing Products or Services – i.e. from one side an Order is a Purchase Order, while for the other side it is a Sales Order.

SAP Business Accelerator Hub provides EDI Integration Templates for SAP Integration Advisor[7]. This package provides the template for both, inbound and outbound integration flows for the processing of UN/EDIFACT (incl. UN/EDIFACT subsets-like GS1 EANCOM or Odette EDIFACT), ODETTE, ASC X12 or cXML interchange to SAP IDoc, SAP SOAP or vice versa.


Figure 7. B2B Trading Partner integration scenario


More details on B2B Trading Partner integration approach can be found in blogs[8], TechEd on-demand videos[9], as well as in few openSAP free learning courses[10][11]. I suggest visiting these references – which  cover all relevant details about the Integrations Advisor (IA), Message Implementation Guidelines (MIG), Mapping Guidelines (MAG), as well as key entities of the Trading Partner Management – like Company Profiles, Trading Partner Profiles, Agreement Templates and Agreements itself.

Buster agility beyond initial Architecture


Standard S/4HANA OData APIs provide many out-of-the-box features – fostering flexibility and agility in the ways of integrating Client System(s). Let’s cover few of them…

Promotion calculated in the Client System(s)


In the above examples, Promotion is calculated in S/4HANA. However, standard OData APIs for Sales Order Simulation (A2X) and Sales Order (A2X) support sending (POST) calculated Condition Records. Those Condition Records can hold Promotion calculated in the Client System(s). Condition Records must be based on the Manual Condition Types previously created in S/4HANA System.


Figure 8. Promotion calculated in the Client System


In this scenario, Client System is sending one or more PricingElement on the Item level:

  • PricingElement JSON sub-structure contains calculated Condition Record value – linked with the appropriate Manual Condition Type – where “Manual” means S/4HANA will allow Condition Record value to be appended into Pricing Procedure (value itself is not calculated within Pricing Procedure).


Delivery in the Client System(s)


We have already covered scenarios with the Indirect sales, where 3rd Party can manage Delivery of the Goods. Using the same principle, we can also design our own Enterprise Business Process and allow Delivery part of the Order Fulfillment is manages by the Client System(s).


Figure 9. Delivery in the Client System


In this scenario we will not use bi-directional Stock replication, but we could use Material Movement Document:

  • OData API_MATERIAL_DOCUMENT Material Movement Document for inbound requests– using POST and GET methods for creating and retrieving Material Documents;


In this approach, S/4HANA is ”issuing” Goods to the Client System(s), where all further logistic will be happening. Such Material Documents, could be created either by the Client System(s) in S/4HANA, or could be created in S/4HANA and retrieved by the Client System(s).

Using SAP ISA-M and API Business Accelerator Hub


The power of SAP ISA-M[12] and API Business Accelerator Hub[13] is, among other things, in a vast number of well documented and easy deployable integration artifacts – from standard and easy configurable APIs (OData, SOAPs) – to huge number of predefined integration packages for the SAP Integration Suite (available for both, SAP and non-SAP integration scenarios). This makes things fast, really fast, in bringing “new” Integration Services to the integration domain…

But, it becomes even more interesting with Events and Event-Driven Architecture…

In this scenario I have used standard DRF SOAP Sales Order Replication (A2A) for sending status notifications to the subscribed Systems about order status – but it could be done much better using some of the standard Sales Order Events[14] together with SAP Event Mesh[15] or SAP Integration Suite, Advance Event Mesh[16].

And if standard Events are not enough (e.g. only few available for Customer), we can always build custom Events – e.g. very realistic scenario of changing some Customer Marketing Attributes – why should we replicate huge Business Partner payload to all subscribed Systems? Furthermore, not all Systems are even interested in all changes of Customer data – with Events, individual Systems can be subscribed to only some (specific) Events which are business relevant to the subscribed System…

… These are only few, very simple (and very realistic) examples – how SAP ISA-M (as an umbrella), with the associated tools, can accelerate our integration journey.

Why building in phases?


Remember, scope of integration is always End-2-End, but how to deliver it – this is completely different question:

In the context of integration delivery approach, Publish & Subscribe does not refer (only) to specific Event style or so (i.e. usually referred as “PubSub”), but rather on the approach where we build and publish Integration Services from the Core (Master) Systems – and then we connect subscribed Client System – this is the main concept of reusability.


Figure 10. Publish and Subscribe integration delivery approach


Why do we not start immediately with only publishing APIs from the Core System(s) and connecting subscribed client System(s)?

Initially when we were building our ways into proper governance models, we needed to apply End-2-End integration delivery approach – we needed to invest high to build the network of integration “roads”. In order our Business Process to flow seamlessly (and this is the ultimate goal, right?) it was necessary to implement beyond the Middleware, sometimes it was necessary to provide delivery of the APIs on both (or all) endpoints, as we do need to “prove” the Solution Concept.

But at the end, this is not the target delivery model we want.

Now, that we have proven the Solution Concept, in the matured delivery model, we can Publish APIs to the Client System(s) who will just Subscribe to the specific Integration Service(s) and/or Event Topic(s), based on the particular integration needs.

Here, PubSub (Publish-subscribe pattern)[17] as a pattern for the EDA (Event-driven architecture)[18], is basically encapsulated in the new delivery approach – Publish & Subscribe integration delivery approach.

Conclusions


The flexibility of standard S/4HANA APIs and capabilities of SAP Integration Suite are enabling us to “promptly” integrate “any” Commerce Channels – creating unified Omni-channel experience and architecture. Under “any”, I really do mean “any” – SAP or non-SAP…

The use of "OData". "REST". "SOAP" etc. on the Client sides – this is only indicative, as it may differ from the System to System, we are connecting.

This article covers some basic concepts, and concepts only – how to build Integration Architecture – which will enable building “Customer 360” journey and “Order360” visibility in the Enterprise. Of course, through practical (architectural) examples it covers only some Integration Services – but there are much more… In the similar fashion, S/4HANA and API Business Accelerator Hub can help us integrate Customer Return, Service Ticket (part of the Case Management), Shipment (and Delivery) etc.

Finally, as said, this article is describing only a Solution Concept – not any particular Solution itself. As always, it is up to any Enterprise or Organization to choose and build its own Solution. For sure, S/4HANA and API Business Accelerator Hub can provide a lot of options how to do that…

I am inviting you to keep following relevant blogs and community resources, post and answer questions, and read other posts on the integration topic.

And of course, share your thoughts and comments on my article, in the comments section.

Acknowledgment


*) Intro photo by NASA on Unsplash

**) This article uses SAP Business Technology Platform Solution Diagrams & Icons as per SAP Terms of Use governing the use of these SAP Materials (please note, newer version of the Solution Diagrams & Icons, as well as Terms of Use, might be in place after the publication of this article).

More guidelines on Solution Diagrams & Icons can be found in this article by bertram.ganz (@bertram.ganz).

References


[1] Omnichannel - Wikipedia

[2] SAP Customer Data Cloud | SAP Help Portal

[3]SAP S/4HANA Order Management Integration Module | SAP Help Portal

[4] Condition Type for Pricing in Sales – Read | SAP Help Portal

[5] Integrating the Mirakl Marketplace Platform with SAP Commerce

[6] SAP Commerce Marketplace Management l Digital Online Marketplace

[7[ Overview | EDI Integration Templates for SAP Integration Advisor | SAP Business Accelerator Hub

[8] What’s New for SAP Integration Suite – October & November 2023 | SAP Blogs

[9] Learn about SAP Integration Suite at SAP TechEd 2023, ASUG Tech Connect 2023, and SAPinsider EMEA 20...

[10] Modernize Integration with SAP Integration Suite | openSAP

[11] Manage B2B Scenarios Effectively with SAP Integration Suite | openSAP

[12] SAP ISA-M: Integration Methodology | Services and Support

[13] SAP Business Accelerator Hub

[14] Sales Order Events | SAP Help Portal

[15] What Is SAP Event Mesh? | SAP Help Portal

[16] SAP Integration Suite, Advanced Event Mesh (cloud.sap)

[17] PubSub: Publish–subscribe pattern - Wikipedia

[18} EDA: Event-driven architecture - Wikipedia

 
7 Comments
SRodriguez
Participant
‎12-18-2023 3:34 AM
Nice Integration Architecture Blog Goran 💪!! Thanks for share 😃!!
chelseafair01
Explorer
‎12-18-2023 9:26 AM

This is a helpful blog I am really impressed with your work, keep it up the good working

Thank you so much for dedicating your time to share with the community!

SergioFerrariIt
Participant
‎12-18-2023 1:39 PM
Fantastic work, Goran!

I believe you described a very common scenario that encompasses a wide range of integration objects and flows, addressing the current state-of-the-art technology.

Thank you so much for dedicating your time to share with the community!

 
stevang
Active Participant
‎12-18-2023 8:24 PM
0 Kudos
sergio_ferrari thank you!

I hope in the next period I will be able to go a further, and provide some integration concepts about Channel-less Commerce as well...
Summitt12
Participant
‎12-19-2023 8:42 AM
0 Kudos
Great Blog

Would like to add some "real" life learnings, as we currently going through this journey

  1. Most of the Customer registration doesn't start from CRM or S4, but from Commerce or CDC

  2. Unfortunately, most of the OOTB CX integration packages in CPI is still Point to Point integration rather than Event hub based(Pub/Sub)

  3. Small steps don’t work for Integration decisions. It is important to decide the "Orchestration layer" in the very beginning of your CX Integration journey. S4 can’t orchestrate the Customer replication, and MDI or MDG become relevant. Again, adding further costs

  4. SAP systems doesn’t allow to replicate data from System A  to System B to System C.


 
Summitt12
Participant
‎12-19-2023 8:42 AM
0 Kudos
Great Blog

Would like to add some "real" life learnings, as we currently going through this journey

  1. Most of the Customer registration doesn't start from CRM or S4, but from Commerce or CDC

  2. Unfortunately, most of the OOTB CX integration packages in CPI is still Point to Point integration rather than Event hub based(Pub/Sub)

  3. Small steps don’t work for Integration decisions. It is important to decide the "Orchestration layer" in the very beginning of your CX Integration journey. S4 can’t orchestrate the Customer replication, and MDI or MDG become relevant. Again, adding further costs

  4. SAP systems doesn’t allow to replicate data from System A à to System B --to System C.

stevang
Active Participant
‎12-19-2023 10:52 AM
0 Kudos
Thanks!

Let me try to answer some of the questions...

  1. Indeed, but I do believe CDC (or similar app) managing Customer Consent (as well as Customer Identity) - is really needed even if we do not register Customers on Commerce Cloud.

  2. Just as for Commerce Cloud - but here we do not have to comply with product OOTB integration recommendations Let's note, up to last year reference Integration Architecture for Commerce Cloud with S4 was with IDocs - that dud not stop me envisioning OData APIs and CPI...

  3. This is why we really do need CPI to orchestrate - even if current produce reference integrations does not foresees it - we build our our Integration Strategy and Integration Architecture, in a way it fits our needs. Furthermore, using JMS queues, CPI can provide queue capability as well (for Async approach, retries etc.).

  4. Again, using CPI we should multicast from System A to both System B and C in parallel (in case A is publisher, and B and C are subscribed Systems)


Pls note, while this i sonly a concept - it was "inspired" with my own practical experiences...
Labels in this area
Popular Blog Posts