!--a11y-->
Generische/Spezifische Definition von
Konfigurationsobjekten 
Objekte des Logischen Routing (Empfängerermittlungen, Interface-Ermittlungen) und Kommunikationsvereinbarungen (Sendervereinbarungen, Empfängervereinbarungen) können für bestimmte Teile des Objektschlüssels generisch angelegt werden. Ein Objekt generisch für ein Schlüsselattribut anzulegen bedeutet, dass das Objekt für alle Werte dieses Schlüsselattributes definiert wird.
Man spricht dann von einem generisch definierten Objekt, im Gegensatz zu einem spezifisch definierten Objekt, bei dem alle Schlüsselattribute spezifiziert sind.
Zur Laufzeit ist immer das Objekt wirksam, bei dem die meisten Schlüsselattribute ausgeprägt sind ("spezifischstes Objekt hat Vorrang").
Die generische Definition von Konfigurationsobjekten bietet die Möglichkeit, den Aufwand beim Erfassen und beim Ändern von Konfigurationsdaten zu minimieren. Insbesondere das Ändern von Konfigurationsdaten kann mit einer geringeren Fehleranfälligkeit vorgenommen werden, da Änderungen an Konfigurationsobjekten automatisch für alle Werte des maskierten Schlüsselattributes gelten.

Beachten Sie, dass aus dem generischen Anlegen von Konfigurationsobjekten auch nicht beabsichtigte Seiteneffekte resultieren können. Konfigurationsobjekte können zwar zur besseren Übersicht nach Konfigurationsszenarien gruppiert werden. Die Zuordnung zu einem Konfigurationsszenario beeinflusst aber nicht die Gültigkeit eines Konfigurationsobjektes. Zur Laufzeit ist immer das spezifischste Objekt wirksam, unabhängig von dem Konfigurationsszenario, dem es zugeordnet ist.
Sie sollten sich daher beim generischen Definieren von Konfigurationsobjekten immer darüber im Klaren sein, dass die getroffene Festlegung durch eine später vorgenommene spezifischere Definition eines Konfigurationsobjektes unwirksam gemacht werden kann.
Beachten Sie auch die speziell für die generische Definition von Interface-Ermittlungen angegebenen Einschränkungen und Empfehlungen.

Enthält beim Anlegen einer Interface-Ermittlung IE1 das Feld für den Sender-Service das Wildcard-Zeichen *, dann ist diese Interface-Ermittlung für alle Sender-Services definiert. Wenn eine weitere Interface-Ermittlung IE2 existiert, bei dem ein bestimmter Sender-Service spezifiziert ist, bei dem jedoch der übrige Teil des Objektschlüssels wie bei IE1 ausgeprägt ist, dann ist zur Laufzeit die Interface-Ermittlung IE2 wirksam. Diese Regel kann auch nicht dadurch umgangen werden, dass beide Interface-Ermittlungen unterschiedlichen Konfigurationsszenarien zugeordnet werden.
Typische Anwendungsfälle für das generische Definieren von Objekten
Objekt |
Anwendungsfall |
Lösung |
Sendervereinbarung |
Derselbe Kommunikationskanal soll für alle Interfaces des Senders gelten (z.B. in unternehmensinternen Prozessen). |
Die Sendervereinbarung, der der Kommunikationskanal zugeordnet ist, wird für das (Sender-)Interface generisch definiert. |
Empfängervereinbarung |
Es soll nur darauf ankommen, dass sich der Sender beim Empfänger-System authentifiziert, unabhängig davon, woher die Message gesendet wurde. Dies kann z.B. in unternehmensinternen Prozessen sinnvoll sein. |
Die Empfängervereinbarung, die die relevanten Sicherheitseinstellungen enthält, wird für Sender-Partner und Sender-Service generisch definiert. |
Um ein Objekt für ein Schlüsselattribut generisch zu definieren, geben Sie beim Anlegen im entsprechenden Eingabefeld das Wildcard-Zeichen * (anstatt eines bestimmten Wertes) an.

Teilmaskierung von Feldern (Beispiel: Feldwert=BUS*) wird nicht unterstützt.
Für welche Schlüsselattribute das Objekt generisch definiert werden kann, hängt vom Objekttyp ab. Eine Übersicht über die maskierbaren Schlüsselfelder finden Sie unter Objektschlüssel bei Konfigurationsobjekten.
Siehe Beispiele für Generisch/Spezifisch Definierte Interface-Ermittlungen