Ansicht
Dokumentation

ABENBDL_VALIDATIONS - BDL VALIDATIONS

General Material Data   RFUMSV00 - Advance Return for Tax on Sales/Purchases  
Diese Dokumentation steht unter dem Copyright der SAP AG.

- validation

validation ValName on save { CUD1; CUD2; ... }
                         $| { field Field1, Field2, ... ; }

Wirkung

Hiermit wird die Konsistenz von RAP-Business-Objekten auf der Basis von Auslösebedingungen überprüft. Bei Erfüllung der Auslösebedingung der Validierung wird sie automatisch vom RAP-Framework gerufen. Auslösebedingungen können modifizierende Operationen (create, update, delete) CUD1; CUD2; ... oder modifizierte Felder Field1; Field2; ... sein. Validierungen werden immer während der Sicherungssequenz am Ende einer Transaktion gerufen, wie vom obligatorischen Zusatz on save vermerkt. Eine gerufene Validierung kann inkonsistente Instanzdaten vor dem Sichern ablehnen und Meldungen an den Consumer zurückgeben. Validierungen müssen in der RAP-Behandlermethode FOR VALIDATE im lokalen ABAP-Behavior-Pool (ABP) implementiert werden.

Auslösebedingungen

Es kann eine oder mehrere Auslösebedingungen geben. Die Auslösebedingungen können Änderungen an Feldwerten oder die Ausführung von einer der Standardoperationen create, update oder delete sein. Bei Ausführung einer dieser Operationen für eine Entwurfsinstanz oder für eine aktive Instanz werden Validierungen mit den jeweiligen Auslösebedingungen ausgelöst. Es können mehrere Auslösebedingungen miteinander kombiniert werden.

• create: die Validierung wird beim Anlegen einer Instanz ausgeführt.

• update: die Validierung wird beim Aktualisieren einer Instanz ausgeführt.

das Aktualisieren funktioniert nur in Kombination mit der Auslösebedingung create.

• delete: die Validierung wird beim Löschen einer Instanz ausgeführt.

• field: die Validierung wird dann ausgeführt, wenn der Wert von einem der angegebenen Felder Field1, Field2, ... durch eine anlegende oder aktualisierende Operation geändert wird. Die für die Auslösebedingungen verwendeten Felder müssen der gleichen Entität gehören, der die Validierung zugeordnet ist.

Fehlschlagen einer Validierung und Reaktionen

Beim Fehlschlagen einer Validierung für eine spezifische Entitätsinstanz kommt es zu folgenden Reaktionen:

• Es kann eine Fehlermeldung in die reported-Struktur der MODIFY ENTITIES-Anweisung geschrieben werden.

• Es wird ein Eintrag in die failed- und reported-Strukturen der COMMIT ENTITIES-Anweisung geschrieben.

• Die Operation schlägt fehl, und der gesamte Inhalt des transaktionalen Puffers der aktuellen RAP LUW wird abgelehnt. Eine RAP-LUW wird nur dann auf der Datenbank festgeschrieben wenn alle Datenänderungen konsistent sind. Eine einzige Inkonsistenz führt zu der Ablehnung des ganzen Inhalts des transaktionalen Puffers.

• Es sind keine weiteren Datenänderungen möglich, solange die ungültigen Instanzen nicht korrigiert werden. Eine ungültige Entitätsinstanz muss entweder über eine Aktualisierungsoperation korrigiert, oder der transaktionale Puffer muss über die EML-Anweisung ROLLBACK ENTITIES geleert werden. Dies liegt daran, dass die COMMIT ENTITIES-Anweisung bei ungültigen Instanzen die Sicherungssequenz abbricht und der transaktionale Puffer wird nicht geleert.

Verfügbarkeit

• Verwaltete RAP-BOs

• Nicht verwaltete und entwurfsfähige RAP-BOs

Nicht verfügbar für nicht verwaltete Nicht-Entwurfs-RAP-BOs

Entwicklungsleitfaden für das ABAP-RESTful-Anwendungsprogrammiermodell, Abschnitt Validations

Hinweise

• Die Reihenfolge der Validierungen ist nicht fest. Falls mehr als eine Validierung durch die gleiche Bedingung ausgelöst wird, ist die Reihenfolge der Ausführungen beliebig.

• Die Verwendung von EML-MODIFY-Anweisungen in der Implementierung von Validierungen ist nicht erlaubt.
  
  

Beispiel

Im folgenden Beispiel wird eine verwaltete BDEF gezeigt, die die Validierung ValidateBuyerId definiert.

Die Validierung wird im ABAP-Behavior-Pool implementiert werden. Hiermit wird die Gültigkeit einer in einer Bestellung angegebenen Käufer-ID verifiziert, in dem die Existenz dieser Käufer-ID in der Datenbank aller Geschäftspartner geprüft wird. Ausgelöst wird sie nach einer Änderung des Feldes BuyerId. Bei einer nicht gültigen Käufer-ID werden die Datenänderungen abgelehnt und eine Fehlernachricht zurückgegeben.

EML-Zugriff 1: gültige Instanzen werden auf der Datenbank festgeschrieben und es kommt bei ungültigen Instanzen zu einer Fehlermeldung.

Das Programm DEMO_CDS_VALIDATION greift über EML auf das Business-Objekt zu. Es werden drei BO-Instanzen angelegt, eine gültige und zwei ungültige. Die gültige Entitätsinstanz wird auf der Datenbank festgeschrieben, während es bei den ungültigen Instanzen zu Fehlermeldungen kommt. Die gültige Entitätsinstanz wird in einer RAP-LUW als die ungültigen Instanzen angelegt. Wenn alle drei Entitätsinstanzen in einer RAP-LUW angelegt worden wären, und in diesem Fall mit der gleichen COMMIT ENTITIES-Anweisung, würden alle drei abgelehnt werden.

Ergebnis: gültige Instanzen werden auf der Datenbank festgeschrieben und es kommt bei ungültigen Instanzen zu einer Fehlermeldung.

IMAGE @@ABDOC_VALIDATION.png@@443@@240@@

EML-Zugriff 2: auch wenn eine RAP-LUW nur eine einzige inkonsistente Instanz enthält, wird der ganze Inhalt des transaktionalen Puffers abgelehnt.

Mit dem Programm DEMO_CDS_VALIDATION_1 wird demonstriert, dass Validierungen Datenänderungen über eine RAP-LUW annehmen oder ablehnen. Es werden die gleichen BO-Instanzen wie im Report DEMO_CDS_VALIDATION angelegt, eine gültig und die anderen beiden ungültig.

Quelltextausschnitt:

Da diese RAP-LUW zwei inkonsistente Instanzen enthält, werden alle Datenänderungen, auch die gültige Instanz, abgelehnt.

Ergebnis: Die gültige Instanz wird nicht auf der Datenbank festgeschrieben.

IMAGE @@ABDOC_VALIDATION_FAILED.png@@427@@110@@

EML-Zugriff 3: falls eine ungültige Instanz nicht korrigiert oder aktiv gelöscht wird, sind keine weiteren Datenänderungen möglich.

Mit dem Programm DEMO_CDS_VALIDATION_2 wird die Blockierung weiterer Änderungen durch eine ungültige Instanz demonstriert:

• Es wird eine gültige Instanz angelegt und auf der Datenbank festgeschrieben.

• Es wird versucht, eine ungültige Instanz anzulegen. Dies wird von der Validierung abgelehnt.

• Es wird versucht, eine weitere gültige Instanz anzulegen. Dies wird abgelehnt. Es muss zuerst die ungültige Instanz korrigiert oder gelöscht werden.

Quelltextausschnitt:

Ergebnis: nur die erste gültige Instanz wird auf der Datenbank festgeschrieben. Die zweite gültige Instanz wird blockiert.

IMAGE @@ABDOC_VALIDATION_FAILED_1.png@@330@@104@@

Weitere Informationen über das Beispiel oben finden Sie im ausführbaren Beispiel CDS BDL - validation.

RFUMSV00 - Advance Return for Tax on Sales/Purchases   BAL_S_LOG - Application Log: Log header data  
Diese Dokumentation steht unter dem Copyright der SAP AG.

Length: 11607 Date: 20240523 Time: 161751     sap01-206 ( 149 ms )