Validierungen und Ableitungen definieren

Mit dieser Web-Dynpro-Anwendung (USMD_RULE) können Sie Validierungs- und Ableitungsregeln für ein spezifisches Datenmodell der Stammdaten-Governance definieren. Ableitungsregeln dienen dazu, die Eingabe von Stammdaten zu vereinfachen, während Validierungsregeln die Konsistenz der eingegebenen Stammdaten gewährleisten.

Integration

Nachdem Sie ein Datenmodell angegeben haben, ruft diese Web-Dynpro-Anwendung die Workbench des Business Rule Framework plus (BRFplus) auf. Weitere Informationen finden Sie unter Business Rule Framework plus (nur in englischer Sprache verfügbar).

Voraussetzungen

Sie haben das Datenmodell, auf das sich die zu definierenden Ableitungen und Validierungen beziehen, erstellt.

Funktionsumfang

Trigger-Funktionen

Sie können den folgenden Ereignissen Trigger-Funktionen zuordnen, um Stammdatenänderungen zu validieren:

CHECK_ENTITY (Entität prüfen): Das System führt die Funktion, die diesem Ereignis zugeordnet ist, bei der Validierung von Entitätswerten während der Einzel- oder Sammelbearbeitung, der Massenänderung oder dem Upload aus.
CHECK_CHANGE_REQUEST (Änderungsantrag prüfen): Das System führt die Funktion, die diesem Ereignis zugeordnet ist, bei der Prüfung eines Änderungsantrags aus. Außerdem führt das System die Funktion vor der Bereitstellung eines Änderungsantrags zur abschließenden Prüfung aus.
CHECK_EDITION (Edition prüfen): Das System führt die Funktion, die diesem Ereignis zugeordnet ist, vor der Freigabe einer Edition aus.
CHECK_ENTITY_HRY (Hierarchieinformation einer Entität prüfen): Das System führt die Funktion, die diesem Ereignis zugeordnet ist, nach der Änderung der Hierarchie eines Entitätstyps aus.
CHECK_CHANGE_REQUEST_HRY (Hierarchieinformation eines Änderungsantrags prüfen): Das System führt die Funktion, die diesem Ereignis zugeordnet ist, gleichzeitig mit CHECK_CHANGE_REQUEST aus. Die Funktion, die dem Ereignis CHECK_CHANGE_REQUEST_HRY zugeordnet ist, dient dazu, die Hierarchieinformation zu prüfen.
CHECK_EDITION_HRY (Hierarchieinformation einer Edition prüfen): Das System führt die Funktion, die diesem Ereignis zugeordnet ist, gleichzeitig mit CHECK_EDITION aus. Die Funktion, die dem Ereignis CHECK_EDITION_HRY zugeordnet ist, dient dazu, die Hierarchieinformation zu prüfen.
DERIVATION (Ableitung): Das System führt die Funktion, die diesem Ereignis zugeordnet ist, bei der Eingabe von Daten während der Einzelbearbeitung oder dem Upload aus.

Bei der Regeldefinition für CHECK-Ereignisse können Sie eine entsprechende Aktion zur Ausgabe einer Meldung verwenden und dann aufgrund des Meldungstyps die weitere Bearbeitung in der Stammdaten-Governance steuern.

Bei der Regeldefinition für das DERIVATION-Ereignis können Sie die Aktion Change Context verwenden, um die Attributswerte des Entitätstyps zu ändern.

Sie können außerdem andere Aktionen (z. B. mit Hilfe einer statischen Methode) anstoßen und auch andere Informationen in die Berechnung mit einbinden.

Für jeden Entitätstyp des Datenmodells mit der Ablage- und Verwendungsart 1 oder 4 generiert das System ein Strukturtyp-Datenobjekt, wenn Sie diese Web-Dynpro-Anwendung zum ersten Mal starten. Jedes Mal, wenn Sie danach eine Änderung des Datenmodells aktivieren, generiert das System beim nächsten Start der Web-Dynpro-Anwendung die Datenobjekte erneut.

BRF+-Strukturgenerierung:

Wenn Entitätstyp 1 und Entitätstyp 4 die Kardinalität 1:N haben, fügt das System in der BRFplus-Kataloggenerierung die Felder des Entitätstyps 4 zu den Feldern des Entitätstyps 1 nicht hinzu.

Wenn Entitätstyp 1 und Entitätstyp 4 die Kardinalität 1:1 haben, behandelt das System im BRFplus sowohl bei der Strukturgenerierung als auch bei der Ableitungsfunktion den Entitätstyp 4 als Erweiterung des Entitätstyps 1.

Wenn Entitätstyp 1 und Entitätstyp 4 die Kardinalität 1:1 haben, fügt das System in der BRFplus-Kataloggenerierung die Felder des Entitätstyps 4 zu den Feldern des Entitätstyps 1 hinzu.

Hinweis Hinweis

Wenn Entitätstyp 1 und Entitätstyp 4 die Kardinalität 1:1 haben, ruft das System nicht die Ableitungsfunktion des Entitätstyps 4, sondern des Entitätstyps 1 auf.

Ende des Hinweises

Namenskonventionen

Es gelten folgende Namenskonventionen für die relevanten Knoten, Objekte, Anwendungen und Kataloge:

Trigger-Funktionsknoten in der Katalogstruktur
Die Namenskonvention für validierungsbezogene Trigger-Funktionsknoten einer Katalogstruktur ist: CHECK_<Name des Entitätstyps>, z. B. CHECK_ACCOUNT.

Die Namenskonvention für den ableitungsbezogenen Trigger-Funktionsknoten einer Katalogstruktur ist: DERIVE_<Name des Entitätstyps>, z. B. DERIVE_ACCOUNT.

Hinweis
Diese Namenskonventionen gelten nur für die Benennung der Trigger-Funktionsknoten einer Katalogstruktur. Sie gelten nicht für die Benennung der damit verknüpften Trigger-Funktionen. Für jeden Entitätstyp sollte es höchstens eine Trigger-Funktion pro Ereignis geben. Die Knoten des entsprechenden Funktionszweigs der Trigger-Funktionen stellen die entsprechenden Anwendungsmöglichkeiten dar.

Ende des Hinweises
Datenobjekte
Die Datenobjekte werden automatisch aus der Datenmodelldefinition generiert. Die Strukturtyp-Datenobjekte haben dann die gleichen Namen wie die entsprechenden Entitätstypen.

Hinweis
Die für das SAP-Erweiterungspaket 4 geltende Namenskonvention wird weiterhin unterstützt. Wir empfehlen jedoch, diese nicht mehr zu verwenden.

Ende des Hinweises

Standardmäßig gibt es folgende vordefinierte Datenobjekte, die durch Regeln und Funktionen nach Bedarf verwendet werden können:
- SAPFMDM_CREQUEST_TYPE: Änderung der Antragstyp-ID
- SAPFMDM_CREQUEST: Änderung der Antrags-ID
- SAPFMDM_EDITION_TYPE: Editionstyp-ID
- SAPFMDM_EDITION: Editions-ID
- SAPFMDM_PROCESS: Betriebswirtschaftliche Aktivität
- SAPFMDM_CREQUEST_STEP: Änderungsantragsschritt
- SAPFMDM_CREQUEST_INDEX: Änderungsantragsindex
- SAPFMDM_WORKITEM_ID: Workitem
- SAPFMDM_HRY_DELTA: Tiefe Struktur bestehend aus einer Hierarchiebeziehung (bzw. dem betreffenden Objektpaar) zur Validierung
  Diese muss in den hierarchiebezogenen Validierungsereignissen CHECK_ENTITY_HRY, CHECK_CREQUEST_HRY und CHECK_EDITION_HRY verwendet werden.
  
  Hinweis
  Wenn eine Trigger-Funktion nur die vordefinierten Datenobjekte enthält, führt das System sie einmal bei der Validierung aus.
  
  Ende des Hinweises
- BRFplus-Anwendung und -Katalog
  Das System erstellt die BRFplus-Anwendung und Katalogstruktur für jedes Datenmodell automatisch, wenn Sie Validierungen oder Ableitungen definieren.
  
  Hinweis
  Verwenden Sie den Namensraum der systemgenerierten BRFplus-Anwendung und Katalogstruktur zur Erstellung Ihrer eigenen Anwendungen und Kataloge. Das System verwendet FMDM_MODEL_<Name des Datenmodells>, z. B. FMDM_MODEL_0G für das Datenmodell 0G.
  
  Ende des Hinweises

Erweiterung für Validierung und Ableitung

Als Erweiterungsimplementierung dieser Web-Dynpro-Anwendung steht das Business Add-In (BAdI) Validierungen/Ableitungen definieren zur Verfügung. Damit können Sie Validierungen und Ableitungen mit alternativer Kodierung definieren.

Um das BAdI aufzurufen, wählen Sie im Customizing der Stammdaten-Governance unter Allgemeine Einstellungen Datenqualität und Suche die Customizing-Aktivität BAdI: Validierungen/Ableitungen definieren.

Wenn Entitätstyp 1 und Entitätstyp 4 die Kardinalität 1:N haben, können Sie bei der Ableitungsfunktion des Entitätstyps 4 auf die Werte des Entitätstyps 1 zur Bestimmung des Entitätstyps 4 lesend zugreifen.

Bei der Ableitungsfunktion des Entitätstyps 1 können Sie nicht lesend auf die Werte des Entitätstyps 4 zugreifen.

Aktivitäten

Um diese Web-Dynpro-Anwendung aufzurufen, wählen Sie im Customizing der Stammdaten-Governance unter Allgemeine Einstellungen Datenqualität und Suche die Customizing-Aktivität Validierungs- und Ableitungsregeln definieren.

Beispiel

Erstellen von BRFplus-Funktionen für Ableitungen von Entitäten mit der Ablage– und Verwendungsart 4

Die folgende Tabelle bildet ein Beispiel für unterschiedliche Kardinalitäten ab, wie sie im Abschnitt BRFplus-Strukturgenerierung beschrieben sind.

Entitäten	Entitätstyp	Attribute
CARR	1
		CURRCODE
CARR_DELTA	4 mit 1:1–Kardinalität
		URL
COUNTER	4 mit 1:N–Kardinalität
		COUNTNUM
		AIRPORT
		C_URL

Dieses Beispiel enthält die Entität CARR mit der Ablage– und Verwendungsart 1 und die abhängigen Entitäten CARR_DELTA und COUNTER mit der Ablage– und Verwendungsart 4. CARR_DELTA hat die Kardinalität 1:1 und COUNTER die Kardinalität 1:N. Die dritte Spalte gibt die Attribute der Entitäten an.

Generierte BRFplus-Strukturen

Entitäten	Attribute der generierten BRFplus-Strukturen
CARR
	CARR
	CURRCODE
	URL
CARR_DELTA
	URL
COUNTER
	CARR
	COUNT_NUM
	AIRPORT
	C_URL

Im Datenmodell haben die Entitäten mit der Ablage– und Verwendungsart 4 ihre eigenen Attribute. Im Gegensatz dazu fügt das System bei den generierten BRFplus-Strukturen für die Entitäten mit der Ablage– und Verwendungsart 4 mit der Kardinalität 1:1 deren Attribute zu den Attributen des Entitätstyps 1 hinzu. Aus diesem Grund hat die Struktur CARR das zusätzliche Attribut URL.

Wenn Sie eine Ableitung für CARR_DELTA in BRFplus erstellen möchten, so können Sie dies nicht mit der Funktion DERIVE_CARR_DELTA sondern nur mit der Entität DERIVE_CARR ausführen. Bei Entitäten mit der Kardinalität 1:1 greifen Sie auf Ableitungen in BRFplus mit dem Entitätstyp 1 zu.
Die Attribute des Entitätstyps 4 mit 1:1–Kardinalität sind in der generierten BRFplus-Struktur des Entitätstyps 1 vorhanden. Wenn Sie die Signatur für die BRFplus-Funktion angeben, müssen Sie die Struktur des Entitätstyps 1 CARR verwenden.
Im Gegensatz dazu rufen Sie einen Entitätstyps4 mit der Kardinalität 1:N wie z.B. COUNTER mit der Funktion DERIVE_COUNTER auf.
Signatur der BRFplus-Funktion DERIVE_COUNTER ist die Struktur COUNTER.