Name: Replication of Business Partner Data in Business Partner SOAP Service - SAP S/4HANA Technology Topics
Uploaded: 2020-8-25
Duration: 713 s
Description: In this video you will learn how to use the service to replicate business partner data. You will understand the structure, get to know the mandatory attributes and see some sample payloads

Share feedback

<p><u><strong>Planned maintenance of Practice Systems</strong></u></p>

Planned maintenance of Practice Systems

Why create an SAP account?

Enhance your learning experience

SAP Learning

Choose your subscription

Manage your subscription

Live Sessions

Hands-on Practice

Certification

My Learning

Ready to start learning?

<div><div><div>In this video you will learn how to use the service to replicate business partner data. You will understand the structure, get to know the mandatory attributes and see some sample payloads<br></div></div></div>

Replication of Business Partner Data in Business Partner SOAP Service - SAP S/4HANA Technology Topics

Hello and welcome. My name is Pankaj and I work in the business  partners master data team. In this microlearning, I will give you an overview  of the business partner SOAP service. This service is used to replicate business  partner data between the S/4HANA system and client. The client can be another S/4HANA system or supported non-S/4HANA system. In the learning, I will take you through the  structure of SOAP messages, talk about a few essential attributes, and show  you a few sample payloads. There's another service which replicates business partner relationship data - it is covered  in a separate microlearning. This learning unit is meant for integration  architects, technical and functional consultants who are  concerned with replicating business partner data between  S/4HANA and clients. The learning will explore the structure of business partner request and confirmation  messages. It will cover both inbound and outbound  messages. However, this learning is not about functional description of every field or  segmenting payload. I'll talk about only important fields and  segments. Then we will go through a few sample payloads  and understand their composition. Let's go through the request messages. BusinessPartnerSUITEBulkReplicateRequest_O ut is the outbound request message, and BusinessPartnerSUITEBulkReplicateRequest_In  is the inbound request message. The outbound request message replicates business partner data from the S/4HANA  system to the client, and the inbound request message replicates data from client to S/4HANA. Both the request messages are bulk messages. It means that they are capable of carrying multiple request messages in a single payload. Inbound and outbound messages have similar  structures. They contain MessageHeader and BusinessPartnerSUITEReplicateRequestMessa ge nodes. MessageHeader contains technical information  about the payload, and BusinessPartnerSUITEReplicateRequestMessa ge is a collection of individual request messages. Each single request message within BusinessPartnerSUITEReplicateRequestMessa ge contains MessageHeader and  BusinessPartner  nodes. MessageHeader within the single request  message contains technical information of the particular  request message, and the BusinessPartner node contains the actual functional data that requires  application. We will talk about message headers later. Let's explore the BusinessPartner node first. This node has a few attributes and several child nodes, like Customer, Supplier,  Bank, Address, Role, and so on. The child nodes have their own attributes, and in some cases they have their own child  nodes. Let's talk about a few important attributes at  business partner level. UUID is the business partner, and InternalID is the business partner number. And these two IDs are the IDs of business  partner in sender system. ReceiverUUID and ReceiverInternalID are the corresponding IDs in the recipient  system. The IDs in sender and receiver systems may  differ and a mapping between them is established using the key mapping concept. During the create scenario, you don't need to pass the receiver IDs in  payload. They are generated in the receiving system during inbound processing of the request  message. During a build scenario, the receiver IDs should  be passed in the payload. Category Code tells the business partner type, that is, whether the business partner is an  organization, person, or group. NumberRangeIntervalBusinessPartnerGroupCod e corresponds to business partner grouping. If grouping corresponds to internal number  generation, a new BP number will be generated during  inbound request processing. For external number generation, the number passed in InternalID will be used. These attributes are kind of mandatory  attributes. For a few of them, if you don't pass them in the  payload, there are default behaviors defined in assessing  logic, but we strongly recommend that these attributes are always passed in the payload. Coming to child nodes, Customer and Supplier  nodes carry Customer and Supplier role-specific data. MultipleAsignment node carries data of  additional customers and suppliers present in a business partner. AddressInformation contains address and communication data of a business  partner. BankDetails contains bank account information  of a business partner. PaymentCardDetails contains payment card  information. Common contains business partner general data  information. Role carries information about which roles are  present in a business partner. Please note that it contains only role  information, such as role name, validity, and so on. The service does not support replication of role-specific data for all supported roles. Replication of role-specific data is supported  only for business partner, customer, supplier, and credit management  roles. Then there are several other nodes, like Identification, IndustrySector, TaxNumber, and a  few financial services datasets. Let's talk about confirmation messages. BusinessPartnerSUITEBulkReplicateConfirmatio n_Out is the outbound confirmation message, BusinessPartnerSUITEBulkReplicateConfirmatio n_In is the inbound confirmation message. Both are bulk messages. A single payload can contain multiple  confirmations. Confirmation messages are mandatory for  business partner SOAP service. They inform the sender about the status of  replication in the recipient system. In addition, they carry the IDs of business  partner, customer, and supplier, which are created in recipient during inbound  processing of request message. Inbound and outbound confirmation messages  have similar structures. They contain MessageHeader and BusinessPartnerSUITEReplicateConfirmationMe ssage nodes. BusinessPartnerSUITEReplicateConfirmationMe ssage is a collection of individual confirmation  messages. Each single message contains MessageHeader, BusinessPartner, and Log nodes. BusinessPartner and the child nodes Customer, Supplier, and MultipleAssignment  carry IDs of respective objects created in the recipient system against the IDs  coming from the sender system. If you follow the naming convention, all the IDs starting with Receiver are IDs of  objects in the receiver system. InternalID and UUID are the IDs coming from  sender. Let's a few basic payloads to understand  payload composition. I have taken a simple payload which creates an organization business partner  in Customer role. The business partner has only name and  address information, hence only a few segments are present in the  payload. Apart from essential attributes at business  partner level, it has Customer, AddressInformation, Common,  and Role segments. Let's select the MessageHeader first. Message headers contain technical information  like ID and UUID to uniquely identify the entire payload or to  identify the single request message. It contains CreationDateTime and  SenderBusinessSystemID. The MessageHeader at payload level uniquely  identifies the payload, and the message headers within a single  message uniquely identify the request message. Sender and recipient system information are  important. A wrong sender system means that the  confirmation message cannot be sent. In that case, inbound request message may fail. Coming to the BusinessPartner node, since this payload is for create scenario, it  contains only InternalID and UUID fields, which are coming from sender system. The receiver IDs are not present in the payload. This is because they don't exist yet. They will be created during inbound processing  of this payload. In the payloads for a build scenario, the receiver  object IDs will be present. CategoryCode 2 means that the business  partner is of type Organization, and NumberRangeIntervalBusinessPartnerGroupCod e BP02 means that the BP will be created using internal  numbered generation. And a very important attribute to note is  changeOrdinalNumberValue. During create, its value is 1. During every subsequent update for this BP, the  sequence of this number will increase. Now this is a payload for updating the business partner which was created earlier. I modified the name of a business partner and  triggered its replication. Name information is within Common node, which is collapsed in the screenshot and hence  you cannot see the modification. The interesting thing here is the  ReceiverInternalID and ReceiverUUID fields. These fields were missing and create payload,  but during update they are present. Also, if you observe, the ReceiverInternalID is  different as compared to InternalID. This is because in the receiving system, business partner was generated using internal  numbered generation. If I had added a new role, say the supplier role, or a new segment like Bank or ID, the additional segments would have been part of  the payload. Here I did not do it to keep the payload simple. Now observe the changeOrdinalNumberValue. During create it was 1, now it is 2. The sequence must increase during every  subsequent update. This slide shows a snapshot of a confirmation  message. The confirmation message was for create  scenario, as can be seen from log information. The MessageHeader and in confirmation  message has ReferenceID and ReferenceUUID fields, In addition to other fields which you already  know. The reference fields point to the ID and UUID of corresponding request  messages. The BusinessPartner node contains the IDs and UUIDs of replicated objects in  sender and receiver system. This sample shows IDs of BusinessPartner and  Customer only. If supplier object had been replicated or if  MultipleAssignment was replicated, the payload would contain IDs of those objects  also. This is a confirmation message for a build  scenario. It's almost the same as it was during create, only log information is different. So to wrap up, the key takeaways of this  session are that now you are familiar with business  partner SOAP service. You have a high-level understanding of fields and segments which are important for  replication. To learn more, check the openSAP platform for other  microlearnings on SAP S/4HANA Master Data Management. The session on Business Partner SOAP  Overview gives an overview of available services from  business partner area. The microlearning Business Partner  Relationship SOAP Service explores business partner relationships of  service in detail. And there is one more microlearning on  Reduced Data Model Handling. Thank you and goodbye.