Objective
The configuration of SAP Sales Cloud and SAP Service Cloud consists of the following steps:
In the following sections, we'll cover each configuration step in more detail.
Scoping is the first step in the configuration of SAP Sales and Service Cloud. It allows enabling basic features of the system, such as integration with other systems.
Scoping can be found in the work center Business Configuration → view Implementation Projects. Changes to the system configuration are bundled in implementation projects. That's why an implementation project must be chosen before making changes. The Scoping process is divided into stages, displayed as a guided activity in the system. The two relevant stages for making changes to the integration settings are as follows:
You must activate a scoping item in order to make the questions available in the same location of the tree in the next step.
The following video demonstrates the scoping of integration features in SAP Sales and Service Cloud.
The relevant scoping elements for integrating SAP S/4HANA or SAP ERP are:
Communication and Information Exchange → Integration with External Applications and Solutions and then depending on the desired integration scope:
In the Questions stage, the following questions need to be activated for following the scenarios of this course.
For replicating master data from SAP S/4HANA to SAP Sales and Service Cloud:
Communication and Information Exchange → Integration with External Applications and Solutions → Integration of Master Data
For supporting the transactional data scenario that is mentioned in a later unit, the following questions need to be activated:
Communication and Information Exchange → Integration with External Applications and Solutions → Integration into Sales, Service, and Marketing Processes
The communication system is used to represent an external system within SAP Sales and Service Cloud. It is a combination of a logical system name (Business System ID and IDoc Logical System ID) that belongs to the target system (SAP S/4HANA for this course) and a technical hostname that belongs to the real communication partner on the network layer, which is usually the middleware (Cloud Integration for this course).
The following graphic visualizes how the systems relate to each other, from the technical and the logical perspective:
From the logical perspective, each outer system of the figure (SAP S/4HANA and SAP Sales and Service Cloud) addresses messages directly to the other counterpart.
From the technical perspective, the middleware is the first communication partner that receives messages and sends them further.
Hence, in the communication system definition, the business and logical system name (logical perspective) of the actual target system needs to be maintained, but the hostname (technical perspective) must be the middleware.
Communication systems are maintained in the work center Administrator → view General Settings → item Communication Systems.
The following screenshot shows the configuration overview screen:
As mentioned previously, the hostname relates to the Cloud Integration worker node, while the business instance entries at the bottom reflect the logical name of the target system. In order to maintain these details, a Business Instance must be added in the configuration screen. For an SAP system, it's important to activate the checkbox SAP Business Suite.
After the communication system has been created, communication arrangements can be configured. A communication arrangement defines all relevant settings to realize a specific communication scenario. For instance, the communication arrangement Replicate Business Partner from SAP Business Suite contains inbound services for receiving Business Partner business objects, Business Partner Relationship information, and Business Partner Attachments. Moreover, it offers an outbound service that can be used to send confirmation messages about received business partners to the external system.
The following screenshot shows the read-only overview screen for this communication arrangement:
The edit view consists of several tabs where the following settings can be maintained and reviewed:
Code List Mapping (CLM) group for translation of code values configured in fine tuning.
Endpoint URLs for web services with additional features like downloading WSDL files or checking if a remote service is available. While URLs for inbound services (services offered by SAP Sales/Service Cloud) are pre-defined, URLs of outbound services need to be maintained if the communication arrangement provides outbound services.
Authentication details (basic auth/client certificate) including an automatically generated technical user with all the necessary authorization for inbound calls.
The following video demonstrates how to create and configure the communication arrangements for receiving master data from SAP S/4HANA according to the scope of this course. The creation of the required communication system is also part of the demonstration. Communication Arrangements for transactional scenarios are set up in a later unit.
The following communication arrangements are configured:
When communicating with other systems, it is often necessary to translate technical codes and IDs between the communication partners. SAP Sales and Service Cloud offers code list mapping to translate code values that are maintained in fine tuning (for example, Academic Title Code, Distribution Channel Code, and so on) and ID Mapping to translate IDs of objects (like Business Partner IDs, Sales Organization IDs, and so on). ID Mapping can be created automatically when objects are replicated from another system or maintained manually by the user.
Before we have a closer look at code list mapping, let's first clarify what a code list is and how it can be maintained in SAP Sales and Service Cloud.
A code list is a set of values that consist of a code, a description, and sometimes more attributes. Code lists are typically used to provide a list of predefined options that can be adapted to the business requirements in fine tuning. In the user interface, they are often represented as dropdown fields.
The following screenshot shows the fine tuning edit screen for the code list Academic Titles, which is part of the fine tuning activity General Business Partners, as an example.
While descriptions of code lists can usually be maintained in different languages, the codes are language-independent and hence used for storing the selected value in the database or exchanging it with an external system.
Fine tuning can be reached from the Business Configuration work center, either by selecting the Implementation Projects view, selecting an implementation project, and then selecting the Open Activity List button, or by navigating to the Overview view within the Business Configuration work center. In both places, you can search for fine tuning activities, such as General Business Partners.Code List Mapping allows you to map codes that SAP Sales and Service Cloud uses internally to different external codes for the communication with other systems. However, it is important to understand that mapping codes only helps in situations where two systems have entries with the same meaning and different technical codes.
More importantly, the code lists of SAP Sales and Service Cloud and the external system must have the same amount of options. If one system has more options than the other one, mapping will not help as long as there is no matching option in the other system.
This is often overlooked, but is a very important aspect, because SAP Sales and Service Cloud comes with predefined code lists. This is very handy in a standalone scenario, but in integration scenarios where another leading system (usually an ERP system like SAP S/4HANA) is already in place, this can be counterproductive. SAP Sales and Service Cloud needs to follow the existing system and hence, code lists must be adapted.
The following screenshot shows this problem. SAP Sales and Service Cloud on the left has two entries more than SAP S/4HANA on the right. This could not be solved by simple mappings. The solution must be to remove the entries from SAP Sales and Service Cloud that do not exist in SAP S/4HANA. Otherwise, users of the cloud solution could select entries that would fail in case they need to be replicated to the on-premise system. Following this approach, code list mapping is mostly needed, because custom maintained codes must start with a prefix (in most cases, the letter "Z"), which makes mapping necessary.
The following screenshot demonstrates the solution by the example of Academic Titles. In comparison to the previous screenshot that showed the predelivered codes of SAP Sales and Service Cloud, the solution could also have been to simply remove the two values that do not exist in SAP S/4HANA. The following example shows the approach of removing all entries in SAP Sales and Service Cloud and adding all values from SAP S/4HANA as new entries with the "Z"-prefix.
Note
Code List Mapping does not only consist of mapping codes. First of all, available entries of relevant code lists must be aligned, which means that the newly integrated system needs to adapt to the existing system(s) – at least for code lists that are part of exchanged data.The following video demonstrates the procedure of code list mapping using the code list BusinessPartnerRoleCode as an example.
The following code list mapping entries are typically needed for exchanging business partners when integrating SAP Sales and Service Cloud with SAP S/4HANA (on-premise).
| Local Data Type Name | Local Code | Description | External Code |
|---|---|---|---|
| BusinessPartnerRoleCode | CRM000 | Customer | FLCU01 |
| PartyRoleCode | 1001 | Account | AG |
| PartyRoleCode | 10 | Bill-To | RE |
| PartyRoleCode | 1005 | Ship-To | WE |
| PartyRoleCode | 8 | Payer | RG |
| BusinessPartnerRelationshipCategoryCode | CRMH02 | Ship-To Party Relship | WE |
| BusinessPartnerRelationshipCategoryCode | CRMH03 | Payer | RG |
| BusinessPartnerRelationshipCategoryCode | CRMH04 | Bill-To Party Relship | RE |
Note
This list is not exhaustive and should always be cross-checked with the actual circumstances before adopting the values.In general, only code lists that are relevant for integration scenarios need to be aligned with the integration counterpart. To find out which code lists are relevant for which integration scenarios or in which business object a specific code list appears, respectively, you can refer to the Code List Usage spreadsheet attached to Knowledge Base Article 2598332.
There can be situations where SAP Sales and Service Cloud uses several different codes that only have a single representation and hence only a single code in the external system, or the other way around. Such situations can be covered with multiple mapping entries and the Inbound Default or Outbound Default flag.
Let's have a look at the example of different sales document types (code list BusinessTransactionDocumentProcessingTypeCode) that is shown in the following screenshot.
SAP Sales and Service Cloud has different sales quotes and order types maintained: TA, OR, and ZTA. In SAP S/4HANA, on the other hand, there is only one relevant code: TA.
The mapping as shown in the screenshot covers the following cases:
This is an example of the Inbound Default flag. The same can happen in the outbound direction. For this case, you can use the Outbound Default flag.
Code list mappings are bundled in Mapping Groups and when integrating a specific system, the mapping group must be selected in the communication arrangement. This allows you to have different mappings per integrated system or even per integration scenario. The default group that gets shipped with the system is SAP On Premise Integration. This can also be found in the upper table of the code list mapping activity seen in an earlier screenshot.
The situation could also have been solved with a different approach: The code pair TA-TA could be removed as described previously. Then, there are two mapping entries remaining. However, the pair ZTA-TA is only relevant for the sales quote follow-up scenario and could have been created in another mapping group that is only used for the follow-up communication arrangement.
In contrast to code list mapping and the maintenance of code lists, which both belong to the system configuration (Business Configuration / Fine Tuning), ID mapping relates to business object instances, such as sales organizations, business partners, products, sales quotes, and so on.
However, the idea of ID mapping is similar to code list mapping: When exchanging business objects with other solutions, it is assumed that they have a different ID in the other solution. ID Mapping stores these IDs, which are from the perspective of SAP Sales and Service Cloud External IDs, while local IDs are also referred to as Internal IDs. An external ID always belongs to a communication system.
All integration-relevant objects need an external ID. When an object is replicated from an external system, it gets an internal ID assigned and the ID mapping with the external ID is written automatically, for instance, business partners or products.
In case exchanged messages reference objects that have not been replicated but created locally in SAP Sales and Service Cloud, the ID mapping needs to be maintained manually. Typical examples for this case are Sales Organizations and Product Hierarchy/Categories.
ID Mappings can also be mass-maintained with the help of Microsoft Excel.
The following video demonstrates the procedure of maintaining ID mapping entries using Product Categories as an example.
This section is relevant only if you integrate with SAP ERP. Apart from that, maintenance of local number ranges is seen as an integration-independent task.
Generally speaking, number ranges are relevant for automatic assignment of IDs. There are different maintenance tasks for number ranges when working and integrating with SAP systems. Let's first gather an overview of them:
Internal IDs:
Number ranges can be defined independently in SAP Sales and Service Cloud and SAP S/4HANA for internal ID assignments, independent from integration to other systems.
Integrating Business Partners with SAP ERP requires additional configuration:
The problem:
When a new business partner is created in SAP Sales and Service Cloud and sent to SAP ERP, there is no confirmation IDoc/message. Hence, SAP Sales and Service Cloud does not get information about the assigned ERP number.
The solution:
SAP Sales and Service Cloud needs to draw an ERP customer, prospect, or contact number and write the ID mapping before replication.
The fine tuning activity Integration of Business Partner Data from Your Cloud Solution to SAP ERP is available to define the number range from where customer, prospect, or contact numbers are drawn before replication to SAP ERP. It is only available when Integration with SAP ERP is in scope.
The SAP ERP number ranges maintained in SAP Sales and Service Cloud must also be maintained in SAP ERP as an externally maintained number range, so that these numbers are not used for other purposes on the ERP side and SAP Sales and Service Cloud is the only system controlling them.
Log in to track your progress & complete quizzes