Introducing the Integration of SAP Sales Cloud and SAP Service Cloud Version 2 with SAP S/4HANA

Preparing Technical System Settings

Preparing Functional Dependencies in SAP Sales Cloud and SAP Service Cloud Version 2

Setting Up and Running Product Replication from SAP S/4HANA to SAP Sales Cloud and SAP Service Cloud Version 2

Setting Up and Running Business Partner Replication from SAP S/4HANA to SAP Sales Cloud and SAP Service Cloud Version 2

Monitoring Messages and Troubleshooting

Configuring SAP S/4HANA for Business Partner Replication

Objective

After completing this lesson, you will be able to configure service groups and the data replication framework in SAP S/4HANA for business partner replication

Configure SAP S/4HANA for Business Partner Replication

This lesson covers the configuration steps in SAP S/4HANA to activate business partner replication.

Compared to setting up product replication, the business partner scenario will be used to illustrate additional principles and integration concepts.

The steps are:

Set up the Data Replication Framework in transaction DRFIMG
Set up Data Replication Filters in transaction DRFF
Set up outbound web services in transaction SOAMANAGER via:
- Consumer Proxy when messages must be sent to a single endpoint.
- Service Groups when messages must be sent to multiple endpoints.
  (will be covered in this lesson)
Enable automatic replication
Filter reflexive partner functions

Set up Data Replication Framework for Business Partners

The basic setup of the Data Replication Framework for business partners follows the same steps as for products:

Define Business System
Define Replication Model

The only difference will be that the parameters for the business object and outbound implementation will, of course, relate to the business partner.

If you haven’t yet created the business system and the replication model, you need to create those entries instead of editing existing ones. For more details, please refer to the preparation unit earlier in this course.

The Data Replication Framework can be configured with transaction DRFIMG. The following two sections outline the necessary parameters.

If you would like to watch a video demonstration of these tasks, please refer to the product replication lesson.

Business System

Open the following customizing activity: Define Custom Settings for Data Replication→Define Technical Settings→Define Technical Settings for Business Systems

Select your business system entry and add the following details:

Define Business Objects:
- BO Type: 986 – Business Partner including Relationships
- System Filter: Active
- Output Mode: D - Direct Output
Define Communication Channel:
- Channel: Replication via Services

DRF – Business System with BP-related settings

Replication Model

Open the following customizing activity: Define Custom Settings for Data Replication→Define Replication Models

Select your replication model entry and add the following details:

Assign Outbound Implementation:
- Outbound Implementation: 986_3– Outbound Impl. for BP/REL via Services
Assign Target Systems:
- Business System: Select your SAP Sales and Service Cloud Version 2 system ID here.
Assign Outbound Parameters:
- Outbound Parameter: PACK_SIZE_BULK
- Value: Enter a number to indicate how many Business Partners can be included in a single message.
After adding the entries above, activate the replication model again:
- Go back to the root of the tree structure on the left so that you can see the Define Replication Model table. Make sure your replication model is selected and activate it using the Activate button in the upper right corner.

DRF – Replication Model with BP-related settings

Define Data Replication Filter Settings in DRFF

When exchanging data with other systems, there is often a need to filter out records or parts of records because they are not relevant to the target system or could cause errors when the target system tries to process them. In other cases, data might be confidential and therefore must not leave the source system.

The Data Replication Framework offers filter settings for requirements like this, as demonstrated during product replication with manual filter criteria in transaction DRFOUT.

This lesson focuses on filter settings for automatic data replication when records are created or modified. Those filters can be maintained in transaction DRFF. We will define some for the business partner scenario as an example.

Transaction DRFF opens in a browser window, similar to the SOA Manager, and displays all available Replication Models on the initial screen, as shown in the following screen capture.

After selecting a replication model and the desired business object (such as a business partner), you can use the buttons above the table to create, modify, or view filters. The last columns of the table show how many segment and predefined filters exist that can be maintained, and the Filter Criteria column indicates whether you have maintained filters.

The following graphic displays two screenshots of the filter settings for the Business Partner object.

Besides the predefined filter at the top, which will not be discussed in this course, the relevant filter settings in the middle and at the bottom are highlighted and used as follows:

Segment Filters: Used to filter specific nodes of business partners that are being replicated.
1. List of available segment filters
2. Sample of the Segment Filter for the Business Partner Role to include or exclude individual roles without affecting whether the business partner itself is sent or not. The captions "Filter Criteria to Include/Exclude Business Objects" might be confusing here, as the filters on this screen refer to segments.
Business Object Filters: Used to filter entire object instances based on the content of specific fields.

Note

Filters defined in DRFF are not taken into account when replicating data using manual filter criteria in transaction DRFOUT.

Example: Business Partner Role

For SAP Sales and Service Cloud Version 2, only Customers and Contact Persons are relevant. Therefore, we define an object filter that includes only:

FLCU01 (Customer)
BUP001 (Contact Person)

Since business partners can have multiple roles, we also need to define these roles as segment filters to ensure that, for example, customers who are both FI Customers (role FLCU00) and "sales" Customers (role FLCU01) are only sent with the role FLCU01.

Let’s briefly explain what happened if you only maintained one filter type:

Segment Filter Only: This ensures that irrelevant roles are filtered out. However, if the object filter is missing, this could cause business partners to be sent to the cloud CRM without any role. Since the cloud CRM wouldn’t know how to handle such business partners, it would result in an error.
Object Filter Only: While this would prevent sending business partners without the correct role, it would not prevent sending business partners who have multiple roles, of which only one is relevant.

So, we can summarize that both object and segment filters are important for filtering data correctly.

Example: Sales Organization / Sales Area

The Sales Area is a similar example. Remember that the sales area refers to the combination of the Sales Organization, the Distribution Channel, and the Division. For simplicity, we’ll only consider sales organizations in this example. However, you can define filters for all three fields. The segment filter is called Cust Sales Area Seg.

If the cloud CRM only has a subset of the organizational model, you must ensure that only customers belonging to sales organizations present in the cloud CRM are replicated. Therefore, you follow the same two steps as for the business partner role:

Use segment filters to ensure that customers are only sent with sales organization assignments that exist in the cloud CRM.
Use object filters to ensure that only customers are sent who belong to at least one of the sales organizations in the cloud CRM.

Unlike the business partner role, customers can be replicated and processed successfully without any sales area assignment. Whether this is a valid use case depends on the requirements. Based on that, you may or may not set object filters.

Example: Business Partner Address Usage

The Business Partner Address Usage segment filter is a required segment filter for the integration with SAP Sales and Service Cloud Version 2 because the cloud CRM only supports a subset of SAP S/4HANA’s address usage types.

The following three address usage types are valid:

XXDEFAULT
SHIP_TO
POST_TO

Video: Defining Data Replication Framework Filter Settings for Business Partner Replication

The following video demonstrates how to define filters for business partners in transaction DRFF, using examples of business partner roles and address usage types.

Enable Filtering of Reflexive Partner Functions for Business Partners

Partner Functions and Reflexive Partner Functions

Partner Functions
- Define specific roles and responsibilities of business partners in a transaction or business process
- Common Examples: Sales Employee, Ship-To Party
Reflexive Partner Functions
- Reference the same business partner for whom they are defined
- Common Examples: Sold-To, Bill-To, Ship-To Party and Payer
SAP Sales and Service Cloud Version 2 doesn't use reflexive partner functions.
SAP S/4HANA provides special logic to handle this.

Partner Functions are used to define specific roles and responsibilities of business partners in a transaction or business process. They are maintained at the sales area level. Typical examples are: Sold-To Party and Ship-To Party, or Sales Employee.

While the sales employee function references an employee, as the name suggests, the sold-to and ship-to parties often reference the same business partner where they are maintained. Therefore, those self-referencing partner functions are called Reflexive Partner Functions.

Partner Function maintenance for a customer in SAP S/4HANA.

Filter Reflexive Partner Functions

Since SAP Sales and Service Cloud Version 2 does not support reflexive partner functions, a special processing logic must be activated in SAP S/4HANA to ensure these partner functions are filtered out when sending business partners to and not removed when receiving data from the cloud CRM.

To activate this processing logic, maintain the table view MDGV_BP_SYS_PAR using SM30 for your business system and activate the Filter Reflexive Partner Functions and the C4C Specific Processing (CTIs) flags.

Table view to activate filter logic for reflexive partner functions.

Configure Automatic Transfer of Business Partners

To distribute newly created or modified business partners, you must ensure that the function module MDG_BS_BP_OUTBOUND_DRF is active in your system. To verify or change this setting, do as follows:

Open transaction SPRO
Go to SAP Reference IMG→Cross-Application-Components→SAP Business Partner→Data Distribution→Activate Function Modules
Activate the function module MDG_BS_BP_OUTBOUND_DRF:
- Event: BPOUT – Business Partner Outbound
- Object: BUPX – Business Partner and BP Relationship
- Item: 5000001
- Function Module: MDG_BS_BP_OUTBOUND_DRF
Save the changes.

Since this setting is transport-relevant, you will be prompted to select a transport request if you change and save it.

Set Up Service Groups for Outbound Web Service Communication

During the product replication setup, a logical port for the web service’s consumer proxy was manually configured using transaction SOAMANAGER, where the relevant transport details, such as the target endpoint and credentials, were maintained. With the business partners setup, we use a different approach to demonstrate the setup with Service Groups.

Service Groups are needed when you have to send messages for a specific object to multiple recipients. This is useful when you have multiple target systems in your environment that require updates on business partners, products, or other data. We’ll use business partners as an example.

The following screenshot shows that the consumer proxy for business partners, which is CO_MDG_BP_RPLCTRQ, is already in use in our demo environment. Therefore, we need to set up a service group.

SOAMANAGER – Consumer Proxy for Business Partner *before* Service Group Setup

You can verify this as follows:

Open transaction SOAMANAGER
Navigate to Web Service Configuration
Search for Object Name CO_MDG_BP_RPLCTRQ

If an active logical port already exists that does not point to your desired target system, you need to use service groups. The entry in the previous screenshot was also created based on a service group. This is indicated in the column Creation Type, which shows Created based on profile...

Unlike the manual configuration of a logical port for the consumer proxy, the configuration via service groups is more complex. It consists of the following steps, all carried out in the SOA Manager.

Steps to set up a Service Group:

Create a Profile
Create Logon Data
Prepare and Upload WSDLs
Publish WSDLs to the Service Registry
Create a Provider System
Configure a Local Integration Scenario

The steps are shown in a video later in this lesson. The extra preparation tasks for the third step are explained in the next section.

Note

Configuring the web service based on service groups is a complex task that is actually beyond the scope of this beginner training. However, it’s often required in projects because of existing replication scenarios. Therefore, it's mentioned here.

Prepare WSDL Files

Service groups require uploading WSDL files for the services you want to use. Each WSDL file must be prepared with the endpoint URL of the deployed integration flow where messages are sent.

Since the replication of business partners and relationships uses separate services, you must prepare two WSDL files, one file per service.

Business Partner
- Consumer Proxy: CO_MDG_BP_RPLCTRQ
- Message: BusinessPartnerSUITEBulkReplicateRequest
Business Partner Relationships
- Consumer Proxy: CO_MDG_BP_RELATIONSHIP_OUT
- Message: BusinessPartnerRelationshipSUITEBulkReplicateRequest

For the business partner scenario, you can download the WSDL files from the SAP Knowledge Base Article 2987243. You can also obtain WSDL files directly from the system, which is not discussed further here. The WSDL files must contain the service section with the address location, as shown in the following screenshot.

Once you have the WSDL files, update the URL in the address location field to the correct target endpoint, which is the deployed integration flow for business partners in the example. Then, you can begin configuring the service group, as described in the following section.

Video: Setting up Service Groups for Business Partner Replication in SAP S/4HANA

The following video shows how to set up business partner replication using service groups with the WSDL files prepared earlier.

Depending on the system environment and other requirements, not all service group-related tasks need to be performed on each target system. Some of the configured elements can likely be shared, for example, when all connections pass through the same middleware.

Steps that might be shared for multiple target systems:

Profile:
Contains transport-relevant details, such as protocol and proxy.
Logon Data:
Contains credentials for the middleware or the respective direct communication partner.
Local Integration Scenario:
Joins the settings for several systems and services.

Steps that must be carried out per system:

Prepare and Upload WSDLs:
Each WSDL needs the corresponding endpoint
Publish WSDLs to the Service Registry:
Each WSDL must be published.
Create a Provider System:
Must correspond to the business system as defined in DRFIMG

The following screenshot displays the list of logical ports for the two consumer proxies for business partners (1) and relationships (2) after the service groups. You can see the new entries, which are set up based on service groups.

SOAMANAGER – Consumer Proxy for Business Partner *after* Service Group Setup

You can find further information about service groups in the following SAP Community blog post: Configuring Service Group in SOAMANAGER using Integration Scenarios

Enable DRFOUT for using Service Groups

Finally, to send data to other systems with the transaction DRFOUT, using service groups, you must activate the Support for Point2Point Communication:

Call transaction SPRO
Go to SAP Reference IMG→Cross-Application Components→Processes and Tools for Enterprise Applications→Enterprise Services→Point-to-point Enablement for Asynchronous Enterprise Services→Activate Support for Point2Point Communication.
Make sure that the activate checkbox is selected.

Next lesson