Examples of Generic/Specific Definition of Interface
Determinations
The following interface determination 1 can be applied at runtime to all messages that are sent from A, B, myOutbound, and http://example to any receiver parties and receiver services.
Example of an Interface Determination
Key Attributes |
Key Attribute Values for Interface Determination 1 |
Sender Party |
A |
Sender Service |
B |
Interface Name |
myOutbound |
Interface Namespace |
http://example |
Receiver Party |
* |
Receiver Service |
* |
By using wildcard characters, you are able to apply multiple interface determinations to a message at runtime. In a situation such as this, the most specific interface determination is always used.
At runtime, a message is sent from A, B, myOutbound, http://example to the receiver (party: C, service: D). You can use both interface determination 1 and 2:
Example of Two Interface Determinations
Key Attributes |
Message |
Values for Interface Determination 1 |
Values for Interface Determination 2 |
Sender Party |
A |
A |
A |
Sender Service |
B |
B |
B |
Outbound Interface |
myOutbound |
myOutbound |
myOutbound |
Inbound Interface |
http://example |
http://example |
http://example |
Receiver Party |
C |
* |
C |
Receiver Service |
D |
* |
* |
Interface determination 2 is actually used in this case because it is more specific than interface determination 1.
There must always be a most-specific interface determination for each message. For this reason, it is not possible to simultaneously activate some interface determinations that use the wildcard character.
The following two interface determinations 2 and 3 cannot be active simultaneously.
Example of Two Interface Determinations
Key Attributes |
Values for Interface Determination 2 |
Values for Interface Determination 3 |
Sender Party |
A |
* |
Sender Service |
B |
* |
Outbound Interface |
myOutbound |
myOutbound |
Inbound Interface |
http://example |
http://example |
Receiver Party |
C |
C |
Receiver Service |
* |
D |
Both interface determinations can be used to process a message from A, B, myOutbound, http://example to the receiver (party C, service D). However, neither is more specific than the other. In this case, no most-specific interface determination exists for the message.

Note that when you define an interface determination generically, you must be aware that if you then later define an interface determination specifically (so it has some key attributes that are the same as the key attributes of the generically defined interface determination); any configuration data you created previously may be made obsolete at runtime.
Therefore, you must always be aware when using the wildcard character (*) that the definition you make may be made obsolete by a more specific definition of an interface determination at a later date.

If you use the wildcard character for the receiver service when creating an interface determination, define this interface determination (with a particular interface mapping /M1) as valid for all receiver services. This generic interface determination is used for a particular integration process and is therefore assigned to a particular configuration scenario S_1.
A more specific interface determination (for example, for a particular sender/receiver service pair), is then created for the same interfaces, for example, for another integration process. This interface determination is therefore assigned to a second configuration scenario S_2. This interface determination might reference another interface mapping (IM2), for example. In this case, the definition of the interface mapping IM1 (runtime perspective) made in the generic definition is now obsolete for the specified sender/receiver service pair. In this way, a more specific definition of an interface determination at runtime can have an affect on the configuration data grouped together in configuration scenario S_1.