Defining Configuration Objects Generically/Specifically 
You can create logical routing objects (receiver determinations, interface determinations) and collaboration agreements (sender agreements, receiver agreements) generically for certain parts of the object key. Creating an object for a key attribute generically means that the object is defined for all values of this key attribute.
Therefore, a generically-defined object is different to a specifically-defined object, in which all key attributes have been specified.
At runtime, the object with the most specific key attributes takes precedence (rule: most specific object has priority).
Caution
See the additional notes for this rule when defining sender agreements.
More information: Defining Sender Agreements
Generic definition of configuration objects enables you to minimize the work effort required when creating and changing configuration data. In particular, the likelihood of errors occurring when changing configuration data is greatly reduced because changes to configuration objects automatically apply to all values of the masked key attributes.
To define an object generically for a key attribute, when you create the object, enter the wildcard character (*) in the relevant field in place of a specific value.
Caution
Part-masking of fields (for example, Field value=BUS*) is not supported.
Note that creating configuration objects generically can also result in unintended side-effects. You can group configuration objects according to configuration scenarios to give you a better overview. Assigning configuration objects to a configuration scenario does not affect their validity. At runtime, it is always the most specific object that takes precedence, regardless of the configuration scenario that it is assigned to.
Therefore, when defining configuration objects generically, you must always be aware that the definition you make may be made redundant by a more specific definition of a configuration object at a later date.
Note the special restrictions and recommendations for interface determinations.
More information: Examples of Generically/Specifically Defined Interface Determinations
Example
If, when you create an interface determination ID1, you enter a wildcard character (*) for the sender communication component, this interface determination is defined for all sender communication components. If another interface determination ID2 exists, for which a particular sender communication component has been specified, but the rest of the object key is the same as for ID1, then it is ID2 that is used at runtime. You cannot circumvent this rule by assigning both interface determinations to different configuration scenarios.
More examples: Examples of Generically/Specifically Defined Interface Determinations
Object |
Use Case |
Solution |
|---|---|---|
Sender agreement |
The same communication channel must be valid for all interfaces of the sender (for example, in internal company processes). |
Define the sender agreement that the communication channel is assigned to generically for the (sender) interface. |
Receiver agreement |
The sender must only authenticate itself in the receiver system, regardless of where the message was sent from. This is recommended for internal company processes, for example. |
Define the receiver agreement that contains the relevant security settings generically for the sender party and sender communication component. |
The object type determines which key attributes the object can be generically defined for.