ORDA – Handhabung einer ereignisgesteuerten Logik bei Datenbankoperationen

Diese Funktion wird mit einem neuen Paradigma fortgesetzt: Daten werden ereignisgesteuert verarbeitet. 4D 21 bietet eine ganze Reihe von Ereignissen im Zusammenhang mit Datenbankoperationen(Speichern oder Löschen).

ORDA-Ereignisse können Trigger ersetzen und bieten viele weitere Vorteile: mehr Kontrolle, so dass Sie Ihre Geschäftslogik (einschließlich zeitaufwändiger Aufgaben wie das Drucken von Rechnungen oder das Speichern externer Daten) direkt in einer ORDA-Datenklassenfunktion codieren können. Sie reagieren auf Ereignisse auf Datenebene, wie z.B. new, modify, save, drop (CRUD)

ORDA-Ereignisse bieten eine präzise Granularität und eine ausgefeilte Fehlerbehandlung, was zu einer hohen Datenintegrität und einer besseren Code-Organisation führt.

Erfahren Sie, wie Sie die entsprechende Geschäftslogik in jedem Schritt einer Save- oder Drop-Aktion implementieren.

HDI_ORDA_Ereignisse_Speichern_Verwerfen

ORDA-Ereignisse – Ein Walzer in mehreren Zeiten

In diesem Blogpost haben wir das erste Ereignis aus einer langen Reihe vorgestellt: das berührte Ereignis.

Die neuen Datenbankoperations-Ereignisse sind so konzipiert , dass sie in der ORDA-Schicht durch Entitäten verwendet werden können, die mit dem This Schlüsselwort behandelt werden, was mit Triggern nicht möglich ist.

Im Vergleich zu Triggern bieten diese Ereignisse eine feinere Granularität zur Erkennung spezifischer Datenbankoperationsschritte und eine ausgefeilte Fehlerbehandlung, die die Aktion bei Bedarf stoppen kann.

Im Gegensatz zu Triggern können Sie mit Ereignissen nicht nur Aktionen vor den Speicher-/Ablageaktionen durchführen. Sie können auch Aktionen während und nach dem Speichern/Verwerfen ausführen.

Sie können benutzerdefinierte Fehler mit unterschiedlichen Schweregraden und detaillierten Zusatzinformationen für den Endbenutzer zurückgeben.

Zuvor konnten Sie zwar einige Funktionen dafür implementieren, mussten diese aber überall, wo es nötig war, manuell aufrufen.

Jetzt bietet diese Funktion eine vollständige ereignisgesteuerte Logik, die automatisch zum richtigen Zeitpunkt ausgelöst wird. Implementieren Sie sie einmal und lassen Sie die 4D Engine sie zur Laufzeit verarbeiten:

• Inkonsistente Daten können im Voraus abgelehnt werden, ohne dass die Persistenzschicht involviert ist.
• Interaktionen mit externen Systemen können genau dann erfolgen, wenn die 4D Daten persistiert werden
• Aktionen können ausgelöst werden, wenn das Speichern/Ablegen fehlschlägt

Und eine gute Nachricht: Im Gegensatz zu Triggern sperrt ORDA nicht die gesamte zugrundeliegende Tabelle einer Datenklasse während des Speicherns/Droppings einer Entität. Mehrere Ereignisse können parallel ablaufen, solange sie unterschiedliche Entitäten (d.h. Datensätze) betreffen.

Wenn Sie auf eine vollständige Sperre der gesamten Tabelle angewiesen sind, um eindeutige Sequenznummern oder ähnliches zu handhaben, müssen Sie dies selbst tun, z.B. mit Singletons – und dies ermöglicht Ihnen, nur bei Bedarf zu sperren – und die volle Kontrolle über diesen Prozess zu haben.

Die verschiedenen Phasen einer Datenbankoperation

Wenn eine Speicher- oder Ablageaktion ausgeführt wird, können Sie mit diesen Ereignissen die Geschäftslogik in drei verschiedenen Phasen der Aktion implementieren:

• Validierung der Speicher- oder Ablageaktion: Nützlich für die Überprüfung der Datenkonsistenz in Bezug auf diese Aktion, z.B.:
  • Steht der Status der Entität, die gelöscht werden soll, auf „TO DELETE“?
  • Ist das Abreisedatum < Ankunftsdatum in einer Buchungsentität ?

Dank dieses Ereignisses können Sie den Vorgang des Speicherns/Löschens stoppen und dem Endbenutzer einen Fehler zurückmelden. Dadurch wird sichergestellt, dass die Daten konsistent und bereit sind, bevor die eigentliche Speicher-/Lösch-Aktion durchgeführt wird.

• Während des Speicherns / Ablegens: Verwenden Sie dies, wenn Sie Ihre Datenbankoperationen mit einem externen System synchronisieren müssen, z .B.:
  • Beim Speichern einer Entität, beim Schreiben von Daten auf einen Datenträger, beim Erstellen eines Dokuments auf einem Google Drive, usw.

In diesem Ereignis können Sie Fehler zurückgeben, wenn die Aktion nicht beendet werden kann. Diese Fehler können dann in dem weiter unten beschriebenen Nach-Ereignis behandelt werden.

• Nach der Speicher- oder Ablageaktion: Hier können Sie Maßnahmen in Bezug auf potenzielle Fehler ergreifen, die während der Speicher- oder Ablageaktion auftreten, z. B:
  • Markieren Sie ein Produkt als „zu prüfen“, weil bei der Ablegeaktion ein Fehler aufgetreten ist.

Dank dieser Ereignisse kann jeder Schritt des Speicherns oder Ablegens mit einer eigenen Geschäftslogik versehen werden.

Diese Ereignisse werden ausgelöst, sobald die Datenbankoperation über ORDA oder den REST-Server ausgelöst wird.

Lassen Sie uns dies anhand von Beispielen in Aktion sehen

wo Ereignisse zu implementieren sind

ORDA-Ereignisse müssen in der Entity-Klasse mit dem event Schlüsselwort.

die Validierungsereignisse

Diese Ereignisse werden vor der Speicher- oder Ablageaktion ausgelöst und können die Aktion durch Rückgabe eines Fehlers stoppen. In diesem Fall werden die anderen unten beschriebenen Ereignisse (mit Ausnahme des After-Ereignisses) nicht ausgelöst.

Sie können implementiert werden:

• Auf der Ebene der Attribute: zur Überprüfung der Konsistenz eines bestimmten Attributs
• Auf der Ebene der Entität: um den Inhalt der Entität global zu prüfen oder Attribute zu vergleichen

Beispiel:

In diesem Beispiel wurde in der ProductsEntity-Klasse ein validateSave-Ereignis für das Attributmargin implementiert. Der Benutzer kann ein Produkt mit einer Marge von weniger als 50% nicht speichern. In diesem Fall wird ein Fehler zurückgegeben, um den Speichervorgang zu stoppen und dem Endbenutzer eine Rückmeldung zu geben.

// ProductsEntity class
//
// validateSave event at attribute level
Function event validateSave margin($event : Object) : Object
	
var $result : Object
	
//The user can't create a product whose margin is < 50%
If (This.margin<50)
	$result:={errCode: 1; message: "The validation of this product failed"; \
	extraDescription: {info: "The margin of this product ("+String(This.margin)+") is lower than 50%"}; seriousError: False}
End if 
return $result

Die gleiche Logik gilt für ein validateDrop-Ereignis. So können Sie beispielsweise verhindern, dass ein Benutzer ein Produkt ablegt, dessen Status nicht „Zu löschen“ ist.

die Ereignisse zum Speichern / Ablegen

Diese Ereignisse werden genau während der Speicher- oder Ablegeaktion ausgelöst und können Fehler zurückgeben, wenn etwas schief läuft. Sie können implementiert werden:

• Auf Attributsebene: zur Überwachung von Änderungen an bestimmten Attributswerten
• Auf der Ebene der Entität: um den Inhalt der Entität global zu überprüfen oder Attribute zu vergleichen

Beispiel:

In diesem Beispiel wurde in der Klasse ProductsEntity ein Speicherereignis für das AttributuserManualPath implementiert. Wenn ein Produkt gespeichert wird, wird das Benutzerhandbuch-Dokument auf der Festplatte erstellt und sein Pfad wird im userManualPath Attribut gespeichert. Diese beiden Aktionen müssen konsistent sein.

Wenn beim Erstellen des Benutzerhandbuchs auf der Festplatte ein Fehler auftritt, wird ein Fehler zurückgegeben, um eine Rückmeldung zu geben und im nächsten Ereignis (afterSave), das weiter unten beschrieben wird, fortzufahren.

Beachten Sie, dass der Inhalt der Datei zuvor außerhalb des Speicherereignisses erstellt wird, da dies zeitaufwändig sein kann.

// ProductsEntity class
// saving event at attribute level
Function event saving userManualPath($event : Object) : Object
	
var $result : Object
var $userManualFile : 4D.File
var $fileCreated : Boolean
	
If (This.userManualPath#"")
	$userManualFile:=File(This.userManualPath)
				
	// The user manual document file is created on the disk
	// This may fail if no more space is available
	Try
            // The content of the file has been generated and stored in a map in Storage.docMap previously
	    $docInfo:=Storage.docMap.query("name = :1"; This.name).first()
            $userManualFile.setContent($docInfo.content)
	Catch
		// E.g.: No more space on disk
		$result:={errCode: 1; message: "Error during the save action for this product"; extraDescription: {info: "There is no available space on disk to store the user manual"}}
	End try
End if 
	
return $result

Die gleiche Logik gilt für ein Drop-Ereignis. Sie können zum Beispiel das Benutzerhandbuch ablegen, während Sie das Produkt ablegen.

die Nach-Ereignisse

Diese Ereignisse werden nach der Aktion Speichern oder Ablegen ausgelöst. Da die Aktion abgeschlossen ist, können sie keine Fehler zurückgeben. Ihr Hauptzweck besteht darin, die Geschäftslogik auszulösen, wenn bei früheren Ereignissen ein Fehler aufgetreten ist.

Wenn kein Fehler aufgetreten ist, können sie auch die Logik nach dem Erfolg behandeln – zum Beispiel das Senden einer Bestätigungs-E-Mail.

Diese Ereignisse sind nur auf Entitätsebene implementiert.

Beispiel:

In diesem Beispiel wurde in der Klasse ProductsEntity ein afterSave-Ereignis implementiert. Wenn das userManualPath Attribut nicht ordnungsgemäß gespeichert wurde, wird sein Wert zurückgesetzt, damit er mit dem fehlenden Benutzerhandbuchdokument auf der Festplatte übereinstimmt.

// ProductsEntity class
Function event afterSave($event : Object)
	
	If (($event.status.success=False) && ($event.status.errors=Null))  // $event.status.errors is filled if the error comes from the validateSave event
		
		// The userManualPath attribute has not been properly saved
		// Its value is reset
		If ($event.savedAttributes.indexOf("userManualPath")=-1)
			This.userManualPath:=""
			This.status:="KO"
		End if 
		
	End if 

Die gleiche Logik gilt für ein afterDrop-Ereignis –wenn z. B. das Fallenlassen eines Produkts fehlschlägt, können Sie den Vorfall protokollieren.

Beachten Sie, dass lange Operationen in Ereignissen so weit wie möglich vermieden werden müssen. Wenn möglich, müssen solche Operationen an anderer Stelle implementiert werden.

Warten Sie nicht mit der Implementierung von Ereignissen, um sich auf eine starke Datenintegrität zu verlassen.

👉 Laden Sie die HDI herunter, um in die Implementierungsdetails von ORDA-Ereignissen einzutauchen, und sehen Sie sich das nachstehende Video an, um weitere Einzelheiten zur Ausführung der HDI zu erfahren.

Den EN-Videolink hinzufügen