Generic/Specific Definition of Configuration
Objects
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”).

Note the additional notes for this rule when defining sender agreements.
The 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 for all values of the masked key attributes.

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, but this 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, you must always be aware when defining configuration objects generically that the definition you make may be made redundant by a more specific definition of a configuration object at a later date.
In particular, note the restrictions and recommendations for the generic definition of interface determinations.

If, when you create an interface determination ID1, you enter a wildcard character (*) for the sender service, then this interface determination is defined for all sender services. If another interface determination ID2 exists, for which a particular sender service 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.
Typical Application Cases for Generic Definition of Objects
Object |
Application 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 service. |
To define an object generically for a key attribute, when creating the object, enter the wildcard character (*) in the relevant field in place of a specific value.

Part masking of fields (for example, field value=BUS*) is not supported.
The object type determines the key attributes for which the object can be generically defined. For an overview of the maskable key fields, see Object Key in Configuration Objects.
See Examples of Generic/Specific Definition of Interface Determinations