5).SAP XI --Integration Directory

The Integration Builder is a central java-based tool that contains the Integration Repository and the Integration Directory. Within this chapter we will focus on the Directory and its makeup. Here, the design time work done previously in the Repository is built further upon and finalized to complete the logical / technical routing details for an incoming message.

The Directory is made of the following main components:
1. Collaboration Profile
--Party
--Service without Party
--Channel
2.Collaboration Agreement
--Sender Agreement
--Receiver Agreement
3.Logical Routing
--Interface Determination
--Receiver Determination
4. Scenarios
--server

Collaboration Profile

A Collaboration Profile documents the technical options available to communication partners. Here the potential senders / receivers and the technical communication paths are specified. As seen in the Roadmap, the primary building blocks are Parties, Services, and Channels

. From Repository we have simply defined the interfaces, their relationships, mappings and structures. In the Collaboration Profile true senders and receivers are created along with the technical details of how to communicate with them.

Parties are defined to represent a business or company unit. Within a Party, Services can be defined / associated to represent technical or business sub-units. For cross-company processes, entire company units can then be specified as sender / receiver providing many services for communicating with other companies.

To create a Party, follow these steps:

1. Traverse the navigation tree within the Directory down to the Party
2. Highlight the Party row and right click. Select ‘New’
3. Enter the name and description of the Party. Alternatively, also enter the Scenario
name
4. (Optional) Associate / create the necessary Alternative Identifiers for the Party
5. Associate / create the necessary Services

Service without Party

Services define the true senders and recipients of messages within XI. As stated above, they can be associated to higher level Parties or by themselves should a Party not be available for association. They are broken into the following three sub-categories:

1. Business Service – Used in cross-company processes where the Party cannot be fully defined. They represent business or technical sub-units

2. Business Process – As a Business Process defined in the Repository are recipients of messages (for process step triggering) or can send them, they are considered a Service and modeled here

3. Business System – Business Systems as defined in the SLD (specific application system in the system landscape) are represented here in the Directory Business Systems can NOT be created in the Directory, but must exist from the SLD
Given the most popular option for basic messaging will be Business Systems (and the similarities across all three), this section will focus on that option from here forward.

To create a Business System (Service), follow these steps:

1. Traverse the navigation tree within the Directory down to the Service Without Party -> Business System
2. Highlight the Business System row and right click. Select ‘Assign Business System’
3. This will open the Business System Assistant
4. (Optional) Associate the Party for the Service and ‘Continue’
5. Select the Business System from the list Only Business Systems not yet assigned are available
6. (Optional) Select the checkbox to pre-generate related Communication Channels
that are most common. These are then shown in the Communication Channels window. Channels created are: HTTP, XI, IDoc, and RFC and are created for the Receiver only. They still require configuration to be valid.
7. In the Business System Editor, the Sender and Receiver tabs show the outbound and inbound (respectively) Message Interfaces defined in the Repository and are available to the Business System. These lists cannot be modified here.
8. In the Business System Editor, the Software Components tab shows the software components defined in the SLD related to the Business System. This list cannot be modified here.

Channel

Communication Channels define the necessary technical communication details for messages (associated adapter type, transport / message protocols, login info for receivers, etc). A Communication Channel can be defined / used for either inbound (from a sender) or outbound processing (from a receiver). It is also where the related adapter type is configured and indicates to the Integration server how to transform the message from the sender so it can be processed by the receiver (whether a system or the Integration Server). It is here that all the different sender / receiver Communication Channels for a given service are identified.

Communication Channels must be associated to a Service and assigned as a sender or receiver. In the following Collaboration Agreement configurations, these Services are configured as either senders or receivers in a message transfer, and the assigned channels have the role of either sender / receiver channels as they were defined.
Sender and Receiver Channels have significant overlap in configuration requirements. As such the steps below cover both with an indication for those items that are specific to one vs. the other.

To create a Communication Channel (sender or receiver), follow these steps:
1. Traverse the navigation tree within the Directory down to the Communication Channel under the Service of interest
2. Highlight the Communication Channel row and right click. Select ‘New’
3. (Optional) Associate the Party for the Service
4. Enter the Service
5. Enter the Communication Channel name and description
6. (Optional) Associate this to a Scenario
7. On the following Edit Communication Channel window the following tabs are available. As the Parameters tab is the most critical, it will be further described in detail below:
a. Parameters – Adapter configuration
b. Identification – Selection of alternative identifiers for the sender / receiver parties
c. Module – Defines the Module Processor, which allows the specification of generic modules that equip the adapters with additional functions
8. On the Parameters tab
a. General Configuration section – Shared across all adapter types
i. Select the Adapter Type. Each adapter type has its own unique settings available as defined below in the Specific Configuration section
ii. Set the radio button to assign the channel direction as a sender or receiver for this Service If http or IDoc is selected as the adapter type, the direction is already set to receiver. No configuration needs to be done for sender processing as the SAP Web AS settings have already been configured.
iii. Assign the Transport Protocol from the sender or to the receiver (varies with adapter type and direction selected). Only a single value may be available
iv. Assign the Message Protocol from the sender or for the receiver (varies with adapter type and direction selected). Only a single value may be available
v. Associate the Adapter Engine
b. Specific Configuration section – Unique to the adapter type and direction specified
i. Fields with an ‘*’ are required for configuration
ii. Given the number of adapter types multiplied by a sender / receiver pairing, the specific configuration requirements will not be covered in detail here. See the chapter on Adapters for more information.
9. Once complete, ‘Save’

Collaboration Agreement

Collaboration Agreements define the technical details for message processing (ex. Adapter configuration) and security settings for sender / receiver partners. The primary building blocks are Sender Agreements and Receiver Agreements.

Sender Agreement
A Sender Agreement is used to transform an incoming message so it can be processed by the Integration Engine. This allows the Integration to understand the protocol of the incoming message (via the associated Channel) to processes it as needed. Further the security settings will allow the checking of the signature of the incoming message, check the data integrity, or authorize the sender of the message. A Sender Agreement is not always required based on the Adapter Type selected Ex. XI.

To create a Sender Agreement, follow these steps:
1. Traverse the navigation tree within the Directory down to the Sender Agreement row, highlight the row and right click. Select ‘New’
2. (Optional) Associate the sender Party for the Service
3. Enter the sender Service
4. Select the outbound Message Interface and related Namespace
5. (Optional) Specify if the sender uses a Virtual Receiver
6. Enter the description
7. (Optional) Associate this to a Scenario
8. On the following editor window, select the sender Communication Channel
9. (Optional) If the Communication Channel associated is of type XI, security settings can be configured as described above

Receiver Agreement

A Receiver Agreement is used to transform an outgoing message so it can be processed by the receiver. It is here the sender service is linked to a unique receiver service / inbound Message Interface via a Communication Channel. To put it simply, the Integration Engine now knows for a message being sent to a given receiver the technical details of how to send it that partner (via the associated Channel). Further the security settings will allow the signing of a message or check the data integrity.
To create a Receiver Agreement, follow these steps:

1. Traverse the navigation tree within the Directory down to the Receiver Agreement row, highlight the row and right click. Select ‘New’
2. (Optional) Associate the sender Party for the Service
3. Enter the sender Service
4. (Optional) Associate the receiver Party for the Service
5. Enter the receiver Service
6. Select the inbound Message Interface and related Namespace
7. Enter the description
8. (Optional) Associate this to a Scenario
9. On the following editor window, select the receiver Communication Channel.
10. (Optional) In the Header Mapping section you can change the sender / receiver address fields in the message header are transformed when the message is sent to the receiver, either by fixed value or from the message payload. This can either
relate to the XI message header or to the IDoc control record (overriding the sending / receiving partner number) if the control record is generated from the IDoc Adapter.
11. (Optional) If the Communication Channel associated is of type XI, security settings can be configured as described above

Logical Routing

Logical Routing relates the previously defined Message Interfaces in the Repository to potential receivers and ultimately which Message Interfaces are specifically shared
between partners. As seen in the Roadmap, the primary building blocks are Interface
Determination and Receiver Determination.

Interface Determination

An Interface Determination allows the association of an outbound Message Interface from a sender to one or more inbound Message Interfaces of a single receiver (and the related Interface Mapping). Whereas a Receiver Determination will link all available recipients of an outbound Message Interface from a unique sender Service, the Interface Determination focuses on a single sender / receiver pair for that same outbound Message Interface and all the related inbound Message Interfaces.

To create an Interface Determination, follow these steps:
1. Traverse the navigation tree within the Directory down to the Interface Determination row, highlight the row and right click. Select ‘New’
2. (Optional) Associate the sender Party for the Service
3. Enter the sender Service
4. Select the outbound Message Interface and related Namespace
5. (Optional) Enter the receiver Party
6. Enter the receiver Service
7. Enter the description
8. (Optional) Associate this to a Scenario
9. On the following editor window, select the Inbound Message Interface and Interface Mapping

Multiple inbound Message Interfaces can be associated by using the green ‘+’ button. If more than one exists, a ‘Condition’ column appears that allows specifying under what conditions a message is forwarded to the inbound interface (via the Condition Editor)

Receiver Determination

A Receiver Determination is the final step in establishing a logical routing for a message. It allows the association of an outbound Message Interface from a sender to 1 or more receivers. Further a condition can be defined for each receiver that, based on data values in the message itself, will allow / prevent the forwarding of a message to that receiver. A Receiver Determination, then, specifies for an incoming message from a given sender all the potential receivers of that message – as well as under what conditions they will receive it.

To create a Receiver Determination, follow these steps:
1. Traverse the navigation tree within the Directory down to the Receiver Determination row, highlight the row and right click. Select ‘New’
2. (Optional) Associate the sender Party for the Service
3. Enter the sender Service
4. Select the outbound Message Interface and related Namespace
5. (Optional) Specify if the sender uses a Virtual Receiver
6. Enter the description
7. (Optional) Associate this to a Scenario
8. On the following editor window, configure the Condition (in the Condition
Editor), receiver Party (optional), and receiver Service
Multiple Condition / Party / Services can be associated by using the green ‘+’ button

A Final Check

Once all items are fully configured, the Configuration Overview for Receiver Determination displays the overall status. After ‘refreshing’ the related status for Interface Determination / Receiver agreement for each receiver Service is displayed. Items in red indicate invalid / missing objects to be corrected. This, however, does not ensure that the configurations for these objects are complete / correct.