Default Procedure 

It is possible to define mapping relations, end points, and logon data for a specific sender (business system, interface) and receiver (business system, interface) combination. This gives you a large degree of flexibility during the configuration phase. However, if you restrict the definition of these configuration objects it can make creating and changing these objects a more lengthy process. You can counteract this problem if you define an end point for all interfaces instead of just one special interface for a receiver, for example. Also, when editing objects you can use placeholders (wildcards) that (in short, the default procedure) do the following:

You must also make the following specifications when you create the three configuration objects:

·        Specify the outbound and inbound interface for mapping relations

·        Specify the receiver business system for end points and logon data

The other fields can however have placeholders. A placeholder is represented by *.

Part masking of fields (for example, Field value= BUS*) is not supported.

The specific definition that exists for an object is then searched for at runtime and evaluated.

If when you create an end point the field for the name of the receiver contains the value *, then the definition of this end point applies for all receivers. However, if this field contains an actual name, then this value has precedence. This means that this object just applies for this interface.

The advantages of placeholders are as follows:

·        Work effort when creating and changing objects is minimized. If an end point is defined for all receiver interfaces, then any changes you make to the attributes of the end point also apply for all interfaces.

·        Changes to configuration objects are less prone to errors because they are performed generically and not manually.

This enables you to find a suitable comprise between maintaining the largest degree of flexibility when defining the configuration objects and the assuring the least amount of work effort when creating and changing them.

Note that negative effects can occur when using placeholders, for example changes are active when they should not be.

The default procedure for mapping relations, end points, and logon data varies.

Mapping Relations

You can enter a placeholder (*) when defining mapping relations for sender or receiver business systems instead of a specific name.

The following definitions for two mapping relations are not permitted, however:

Mapping Relation	Sender business system	Outbound Interface	Receiver business system	Inbound Interface
MR1	A	OIF	*	IIF
MR2	*	OIF	B	IIF

In this case, the following situation can arise when a message is processed:

Sender Business System=A and Receiver Business System=B

This case applies for the definition of both mapping relations. Therefore, the unique assignment of a mapping is no longer guaranteed.

Example

Placeholders are used as follows when defining mapping relations:

Defining Mapping Relations

Mapping Relation	Sender business system	Outbound Interface	Receiver business system	Inbound Interface	Mapping
MR1	*	OIF	*	IIF	M1
MR2	A	OIF	*	IIF	M2
MR3	B	OIF	C	IIF	M3

Triggering at Runtime

·        Message 1:

Sender Business System=A and Receiver Business System=B

In this case, mapping M2 is mapped.

·        Message 2:

Sender Business System=B and Receiver Business System=C

In this case, mapping M3 is mapped.

·        Message 3:

Sender Business System=B and Receiver Business System=D

In this case, mapping M1 is mapped.

End Points

You can use placeholders when defining end points

·        for the interface namespace

·        for the interface name

Note the following:

·        You must always specify the business system

Since an end point contains the technical access information for a receiver business system, the configuration object End Point must refer to a particular business system.

·        The combination (interface namespace with placeholder) and (interface name without placeholder) is not permitted. If the interface namespace uses a placeholder, then the interface name must also use one.

If the interface namespace uses a placeholder, it is recommended that you do not specify the interface name since the interface is not unique if you do not specify the interface namespace. However, if a placeholder is used for the interface name but a specific interface namespace is specified, this means that the end point is defined for all interfaces in this namespace.

·        * applies for all message interfaces and not RFCs or IDocs.

Example

Defining an End Point for an RFC Adapter

Receiver business system	Receiver interface name	Receiver interface namespace
AIR	*	urn.sap-com:document:sap:rfc:functions

This end point type is defined when the RFC namespace is specified.

Logon Data

·        The same applies here as for end points.

Note the following:

·        When defining logon data it is possible to specify the fields for business system and interface in both the receiver and sender systems.

The background behind this is that in principle, business processes are possible in which the logon data for a receiver depends on who sent the message.

Example

In this example for the definition of logon data for a receiver business system (AIR), the key fields are completed as follows:

Example for the Specification of Key Fields for Logon Data

Field	Value
Sender business system	*
Sender interface name	*
Sender interface namespace	*
Receiver business system	AIR
Receiver interface name	*
Receiver interface namespace	*

The definition of the logon data refers to the receiver business system AIR and applies to all sender business systems, sender interfaces, and receiver interfaces.

If the logon data is only to be used for an end point for an RFC adapter, then the RFC namespace ( urn:sap-com:document:sap:rfc:functions) must be entered in the receiver interface namespace.

Also see:

For more information about the default procedure for creating logon data, see: Example for an End Point (RFC adapter) and Example for an End Point (Integration Engine).