Maintaining the Integration Server

Use

This topic is based on the following scenario: A business system sends an IDoc to the Integration Server by using the IDoc adapter, and the Integration Server sends an IDoc to the receiving business system by using the IDoc adapter. This topic describes what has to be done for the inbound side (Integration Server receives IDocs) and for the outbound side (Integration Server sends IDocs).

Procedure

Perform the following steps:

Use transaction SM59 to maintain an RFC destination for the IDoc sender/receiver system. This RFC destination is used to retrieve the IDoc metadata from the sender system. The IDoc adapter needs these metadata to create the corresponding IDoc-XML message from the RFC stream.

Specify a user with the authorization to call function module RFC_READ_TABLE. Depending on the release of the system that contains the metadata, different function groups (FUGRs) have to be accessed to read this metadata, and the corresponding access authorizations have to be granted to these functions groups (Authorization Object: S_RFC, ACTVT: 16; S_IDOCDEFT, ACTVT: 03; S_TABU_DIS, ACTVT: 03).

Relevant function groups depending on SAP releases

SAP Release	Function Groups
3.1H	SDTX, EDI8, RFC1, EDIT
4.0A to 6.10	SDTX, EDIMEXT
6.20	IDXN

As of SAP Release 6.20, the role SAP_XI_IS_SERV_USER exists, which includes the authorization for function group IDXN.

Use transaction IDX1 to assign a port (RFC destination) to the system that contains the metadata of the IDoc types. This system is defined by the sender port, for example SAPSND (SAP<SID>), and the client, in the IDoc control record.

Example

An SAP system with system ID XYZ and client 300 sends an IDoc to the Integration Server. The sender port in the IDoc control header is SAPXYZ. You use transaction IDX1 on the Integration Server to maintain which RFC destination to use for IDocs with port SAPXYZ and client 300 in order to retrieve the IDoc metadata.

Note

There is a mechanism on the Integration Server that uses this RFC destination to retrieve and cache the metadata at runtime if it is not yet available on the Integration Server.

More information about IDX1: Maintaining Ports .

Note

Since IDoc metadata is cross-client, you should only assign one port for each system. If several ports are assigned, ensure that they are all working.

If you are not able to load the metadata from this system (because of administrative or security-related restrictions, for example), you can also load it from a reference system (for example, a test system) and use transaction IDX2 to assign it to your production system afterwards.

For non-SAP systems, either the ports in transaction IDX1 have to point to a reference SAP system, or you copy the metadata with transaction IDX2.

Note

When an IDoc type is sent to the Integration Server for the first time, the corresponding metadata is loaded from the source system. If metadata for an IDoc type changes, it must be deleted by executing the program IDX_RESET_METADATA (or by using transaction IDX2). The automatic mechanism described above will then ensure that metadata is reloaded as soon as an IDoc of this type is sent.

More information about IDX2: Loading, Displaying, and Deleting Metadata .
Access the System Landscape Directory (SLD) to maintain the technical systems for the sender and receiver business systems of your system landscape.

You have to define a technical system (and a client in the case of SAP systems) to which your business system belongs. When you define a client number, you also have to specify the corresponding logical system name.

Note

The technical system configuration is not required if your business system is configured as a data supplier for the SLD.
Access the Integration Directory to define your business systems as communication components without party.

Note

The IDoc adapter only uses the communication component definition (business system) together with the corresponding adapter-specific identifiers in the Integration Directory. The maintenance of your IDoc sender system in the SLD is therefore not sufficient. It is recommended that you assign your business system definition retrieved from the SLD to a communication component in the Integration Directory.

Using this information about the system ID, client, and logical system name for a specific business system, the IDoc adapter is able to specify the corresponding communication component in the XML header. Routing is then based on communication component names.

You need the
- logical system, SAP system ID, and client for an IDoc receiver SAP system
- SAP system ID and client for an SAP system
- logical system for a non-SAP system.
This means that the business systems used for the routing definitions in the IDoc-XML message header are retrieved from the adapter-specific identifiers of the communication component definitions in the Integration Directory, where for each business system client, the corresponding system ID, client, and logical system name is defined.

Recommendation

Use the import function to retrieve the adapter-specific identifiers for a communication component (business system) to avoid double maintenance in the SLD and Integration Directory.