The sender SAP Business Connector adapter provides the option of extracting data from an external message protocol and using it to assemble the header of the XI message. This procedure is known as normalization or party conversion. The structure of the XI message header depends on the message protocol that is used.
After the XI message header is successfully built, the system searches for a sender agreement that corresponds to this XI header. The sender agreement found refers to a communication channel, which contains additional information for the processing of the message in the SAP Business Connector adapter.
Building the Message Header with Message Protocol RFC-XML with Envelope
The fields of the XI message header are built in the order in which they are specified.
The name of the RFC-enabled function module is used. This is the name of the first XML tag that follows the body tag of the RFC XML envelope. This tag has to be in the XML namespace urn:sap-com:document:sap:rfc:functions.
Since the ABAP namespace identifiers /namespace/ are not permitted in XML, the sender uses the following format in XML:
_-namespace_-
When used, this format is then switched back.
The fixed namespace urn:sap-com:document:sap:rfc:functions is used.
If the Fromfield in the RFC XML envelope contains six characters, the characters are interpreted as the SAP system ID and client. The system searches for a service without party containing this System ID and Client as adapter-specific identifiers.
More information: SAP NetWeaver Library under SAP NetWeaver Process Integration → Special Development Tasks → Applying Advanced Routing Techniques → Using Adapter-Specific Message Attributes in the Message Header
The service without party that is found is used as the sender service.
If a field contains anything other than six characters, or if the search for the service was not successful, the actual contents of the From field from the RFC XML envelope are used as sender service.
These fields are left blank.
Building the Message Header with Message Protocol IDoc-XML
The sender adapter builds the XI message header using the rules below. The following terms are used:
The fields of the XI message header are built in the order in which they are specified.
MESTYP + "." + IDOCTYP
If the field CMITYP exists, the following is added to the interface names: "." + CMITYP
The fixed namespace urn:sap-com:document:sap:idoc:messages is used here.
If the field SNDPOR contains "SAP" followed by a three-digit system ID, an attempt is made to find a service without party that contains this SAP system ID and the value of the MANDT field as the adapter-specific identifiers.
If the contents of the field SNDPOR do not start with "SAP", an attempt is made to find a service without party that contains the contents of the SNDPOR field in its adapter-specific identifiers (IDoc adapter).
The service without party that is found is used as the sender service.
If the field SNDPRT contains LS, the service is a logical system and the sender party remains blank.
If it is not a logical system, a party is determined by means of the alternative identifiers (for the communication party). The following are used as identifiers:
These values are used to search across all parties. The party that is found is used as the sender party.
This field is always left blank.
If the field RCVPRT contains LS, the service is a logical system and the receiver party remains blank.
If it is not a logical system, an attempt is made to determine a party by means of the alternative identifiers (for the communication party). The following are used as identifiers:
The party that is found is used as the receiver party.
The receiver adapter does not evaluate the header of the XI message for party conversion. The XI message payload is sent directly to the receiving SAP Business Connector. The message must therefore contain the correct IDoc-XML document, including the IDoc control record.