B2B Configuration
Many integration scenarios are configured based on the assumption that the integration only involves business applications that span parts of one and the same company. In such cases, the system landscape typically is described in one System Landscape Directory. Typically, in such a situation the complete system landscape is known to the integration expert who performs the configuration tasks. The integration expert then typically puts a communication component on the same level as a business system.
As soon as different companies share the same business process (in other words, in a B2B scenario), additional considerations come into play. Typically, in a B2B scenario, the configuration of the integration is a task that is distributed among integration experts from the involved companies or organizations. Each integration expert will only configure one “side” of the communication, and, in doing so, each expert knows only “his” part of the system landscape.
The next figure illustrates this fact schematically. It illustrates communication with an external business partner (business partner 2); in this case, the integration expert at business partner 1 does not know any details of the part of the system landscape hosted by business partner 2:
The integration expert at business partner 1 only knows the part of the system landscape that is hosted by business partner 1. The complementary part of the system landscape hosted by business partner 2 is typically not known to him or her, since companies and organizations do not usually expose internal system names or server addresses to external partners. This part of the system landscape is a “black box” to him.
For an integration expert working for business partner 2, the reverse is true (assuming for simplicity that only two business partners share the business process).
There are additional configuration concepts to handle these B2B-specific constraints (implemented as object types or object attributes in the Integration Directory).
Communication Party
Since B2B scenarios typically involve whole enterprises interacting with each other, you use a communication party to identify a company or an organization that takes part in the business process. The communication party is an optional key field for receiver determinations, interface determinations, sender and receiver agreements. A party groups together those communication components that belong to the corresponding company or organization.
To accommodate the fact that B2B integration spans areas of responsibility that are separated from each other (as illustrated in the figure above), an additional concept is implemented: where you use an internal name to identify a company or a business partner during configuration, you have the option to map this internal name to a unique globally-recognized identifier that identifies the company unambiguously (for example, a D & B D-U-N-S number issued by the agency Dun & Bradstreet ). In every communication with an external partner, the internal party name is then transformed to the globally-recognized identifier. Conversely, when a message is received from an external business partner, the identifier can first be mapped to the internal party name during inbound processing.
More information:
Business Component
In external communications (B2B interactions), business system names cannot be used as addressing entities since they are not exposed externally. Therefore, communication components based on business systems in the SLD are not suitable. Instead, messages involved in a B2B interaction use a different communication component type, called a business component. A business component merely represents an abstract entity for addressing the senders and receivers of messages in B2B communications.
More information: Business Component
Masking Internal Details in Outbound Messages (Header Mapping)
A message sent out to a receiver system in a company-internal interaction carries the information of the sender (the name of the sender system) in the message header. In an external or B2B communication, the internal system names should be hidden and not show up in the message header when the message arrives at the external business partner. To make sure that internal system names are masked in message headers, a header mapping can be applied. With a header mapping, you define a transformation from the internal (sender) system name to an externally exposed business component name. You configure the header mapping in a receiver agreement (in other words: when you specify the outbound processing).
The following figure illustrates how header mapping works:
Routing Messages from an External Business Partner to an Internal System
If we consider the other direction of B2B message exchange, a message sent by an external business partner (2) cannot be addressed directly to a system of the internal landscape hosted by business partner 1. Instead, the external business partner addresses the message to a virtual receiver by using a business component name to address the receiver of the message. This business component name is the name you (business partner 1) have communicated to the external business partner beforehand. To route the message from the external business partner to the right system in your (business partner 1) internal landscape (whose name the external business partner does not know), you use a receiver-dependent receiver determination.
A receiver-dependent receiver determination is illustrated in the following figure:
The figure illustrates how a receiver-dependent receiver determination routes a message sent by the external business partner to the (externally exposed) business component BookService, to the internal system ABC.