Building Integration Architecture for the Omni-channel Commerce

Building Integration Architecture for the Omni-channel Commerce
2023-12-17 22:5:39 Author: blogs.sap.com(查看原文) 阅读量:12 收藏

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%201.%20Multi-channel%20and%20Omni-channel%20Commerce

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%202.%20Setting%20the%20first%20integrations

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%203.%20Reusing%20the%20integrations

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:

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;
For inbound Integration Services, we are re-using already developed and deployed APIs, by exposing endpoints to the subscribed Channel(s);
For outbound Integration Services, we are also reusing already developed and deployed APIs, by multicasting payloads to the subscribed Channel(s);
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)
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%204.a.%20Integrating%20SAP%20Commerce%20Cloud

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?

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;
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%204.b.%20Integrating%20SAP%20Commerce%20Cloud%20using%20CSRF%20token

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?

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);
Relevant data for Order Taking will be preloaded on the device while it is online;
Online Order Checkout (full Order Simulation) may still be an option if device is online;
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%205.%20Extending%20integrations%20for%20the%20Field%20sales

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:

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).
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 3^rd Parties. The overall Order Fulfillment process is split between our Enterprise and 3^rd 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:

We receive Orders through our Commerce Channels (e.g. Sales App), Orders are processed and sent to the 3^rd Party to finalize Order Fulfillment. In this scenario Customer is (usually) invoiced through our Channels
Orders are taken by the 3^rd Party, based on our Customer and Product Master data, and based on our Price and Promotion Order Fulfillment is executed by the 3^rd Party. Usually, the actual 3^rd 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.
Combined case of the first two scenarios, where 3^rd Party can both, receive and take Orders as well.

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

“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.
“Non-exclusive” – e.g. 3^rd 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 3^rd Party marketplace, fully transparent for the Customer, where in the background 3^rd 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 3^rd Party Stock data (of our Product portfolio), just as 3^rd 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 3^rd Party Price and Promotion data (specific for this 3^rd Party, but for our Product portfolio), as well 3^rd 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%206.%20Extending%20integrations%20for%20the%20Indirect%20sales

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 3^rd Party, beside setting clear Business Rules; we might need to record relevant Stock data from the 3^rd Party – PUSH data from the 3^rd 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) 3^rd Party – again PUSH data from the 3^rd Party into our ERP special Conditions.
When Orders are taken by the 3^rd Party, beside setting clear Business Rules; 3^rd Party needs to have an information of our Stock , Price and Promotion data, so Order Taking can be performed via 3^rd 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 3^rd Parties, in multiple regions/countries), engaging “Unified Translation” Middleware Services could be more prudent choice.

Some 3^rd 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%207.%20B2B%20Trading%20Partner%20integration%20scenario

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%208.%20Promotion%20calculated%20in%20the%20Client%20System

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 3^rd 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%209.%20Delivery%20in%20the%20Client%20System

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:

Scope of integration – this is End-2-End integration (as described in the article Part 2: How to build an Integration Architecture for the Intelligent Enterprise)
Integration delivery approach – this is how we organize delivery of the integration (briefly mentioned in the article Part 3: Next steps in building the Integration Architecture for the Intelligent Enterprise)

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%2010.%20Publish%20and%20Subscribe%20integration%20delivery%20approach

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.