Questa caratteristica continua con un nuovo paradigma: gestire i dati in modo guidato dagli eventi. Il 4D 21 fornisce una serie completa di eventi relativi alle operazioni di database(salvataggio o drop).
Gli eventi ORDA possono sostituire i trigger e offrono molti più vantaggi: maggiore controllo, consentendo di codificare la logica aziendale (compresi i lavori che richiedono molto tempo, come la stampa di fatture o la memorizzazione di dati esterni) direttamente in una funzione della classe di dati ORDA. Rispondono agli eventi a livello di dati, come ad esempio nuovi, modifiche, salvataggi e rilasci (CRUD).
Gli eventi ORDA offrono una granularità precisa e una sofisticata gestione degli errori, che portano a una forte integrità dei dati e a una migliore organizzazione del codice.
Scoprite come implementare la logica di business appropriata in ogni fase di un’azione di salvataggio o rilascio.
HDI_ORDA_Eventi_Salvare_Cancellare
Eventi ORDA – Un valzer a più riprese
In questo precedente blogpost abbiamo presentato il primo evento di una lunga serie: l’evento touch.
I nuovi eventi relativi alle operazioni di database sono progettati per essere utilizzati nel livello ORDA attraverso entità gestite con la parola chiave This cosa che non è possibile con i trigger.
Rispetto ai trigger, questi eventi offrono una granularità più fine per il rilevamento di specifiche operazioni di database e una sofisticata gestione degli errori che può interrompere l’azione se necessario.
A differenza dei trigger, gli eventi non solo consentono di implementare azioni prima delle azioni di salvataggio/rilascio. Possono anche eseguire azioni durante e dopo le operazioni di salvataggio/rilascio.
La gestione degli errori è potente: è possibile restituire errori personalizzati con diverse gravità e informazioni aggiuntive dettagliate per l’utente finale.
In precedenza, era possibile implementare alcune funzioni a questo scopo, ma bisognava richiamarle manualmente ogni volta che era necessario.
Ora, questa funzione offre una logica completa guidata dagli eventi, che si attiva automaticamente al momento opportuno. È possibile implementarla una sola volta e lasciare che il motore 4D la gestisca in fase di esecuzione:
- I dati incoerenti possono essere scartati in anticipo senza coinvolgere il livello di persistenza.
- Le interazioni con i sistemi esterni possono avvenire proprio quando i dati 4D sono persistiti.
- Le azioni possono essere attivate quando il salvataggio/rilascio non va a buon fine
E c’è una buona notizia: al contrario dei trigger, ORDA non blocca l’intera tabella sottostante di una classe di dati durante il salvataggio/rilascio di un’entità. Diversi eventi possono essere eseguiti in parallelo, purché coinvolgano entità distinte (cioè record).
Se si fa affidamento su un blocco completo dell’intera tabella per gestire numeri di sequenza univoci o simili, è necessario gestirlo per conto proprio, ad esempio con i singleton, il che consente di bloccare solo quando necessario e di avere il pieno controllo su questo processo.
Le fasi distinte di un’operazione di database
Quando si esegue un’azione di salvataggio o di rilascio, questi eventi consentono di implementare la logica di business in tre fasi distinte dell’azione:
- Convalida dell’azione di salvataggio o di rilascio: Utile per verificare la coerenza dei dati relativi a questa azione, ad esempio:
- Lo stato dell’entità che sta per essere eliminata è impostato su “DA ELIMINARE”?
- La data di partenza è < alla data di arrivo in un’entità di prenotazione?
Grazie a questo evento, è possibile interrompere l’azione di salvataggio/cancellazione e restituire un errore all’utente finale. In questo modo si garantisce che i dati siano coerenti e pronti prima di avviare l’azione di salvataggio/cancellazione.
- Durante il salvataggio/rilascio: Da utilizzare se è necessario sincronizzare le operazioni del database con un sistema esterno, ad esempio:
- Quando si salva un’entità, si scrivono dati su un disco, si crea un documento su Google Drive, ecc.
In questo evento, è possibile restituire errori in caso di mancato arresto dell’azione. Questi errori possono essere gestiti nell’evento successivo descritto di seguito.
- Dopo l ‘azione di salvataggio o rilascio: Qui è possibile adottare misure relative a potenziali errori generati durante le azioni di salvataggio/rilascio, ad es:
- Contrassegnare un prodotto come “Da controllare” perché si è verificato un errore durante l’azione di drop.
Grazie a questi eventi, ogni fase dell’azione di salvataggio o di rilascio può avere una propria logica aziendale dedicata.
Questi eventi vengono attivati non appena viene attivata l’operazione di database tramite ORDA o il server REST.
vediamo in azione con degli esempi
dove implementare gli eventi
Gli eventi ORDA devono essere implementati nella classe Entity, utilizzando la parola chiave event parola chiave.
gli eventi validate
Questi eventi vengono attivati prima dell’ azione di salvataggio o rilascio e possono interrompere l’azione restituendo un errore. In questo caso, gli altri eventi descritti di seguito (tranne l’evento after) non vengono attivati.
Possono essere implementati:
- A livello di attributo: per verificare la consistenza di un attributo specifico.
- A livello di entità: per controllare il contenuto dell’entità a livello globale o per confrontare gli attributi.
Esempio:
In questo esempio, nella classe ProductsEntity, è stato implementato un eventovalidateSave per l’attributomargin . L’utente non può salvare un prodotto con un margine inferiore al 50%. In questo caso, viene restituito un errore per interrompere l’azione di salvataggio e fornire un feedback all’utente finale.
// 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
La stessa logica si applica a un eventovalidateDrop. Ad esempio, si può impedire a un utente di abbandonare un prodotto il cui stato non è “Da eliminare”.
gli eventi di salvataggio e abbandono
Questi eventi vengono attivati proprio durante l ‘azione di salvataggio o di abbandono e possono restituire errori se qualcosa va storto. Possono essere implementati:
- A livello di attributo: per monitorare le modifiche ai valori di attributi specifici.
- A livello di entità: per controllare il contenuto dell’entità a livello globale o per confrontare gli attributi.
Esempio:
In questo esempio, nella classe ProductsEntity, è stato implementato un evento disalvataggio per l’attributouserManualPath . Quando un prodotto viene salvato, il documento del manuale utente viene creato sul disco e il suo percorso viene memorizzato nell’attributo userManualPath e il suo percorso viene memorizzato nell’attributo . Queste due azioni devono essere coerenti.
Se si verifica un errore durante la creazione del documento del manuale utente sul disco, viene restituito un errore per fornire un feedback e per procedere nell’evento successivo (afterSave), descritto di seguito.
Si noti che il contenuto del file viene generato in precedenza, al di fuori dell’evento disalvataggio, perché può richiedere molto tempo.
// 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 $resultLa stessa logica si applica all’eventodrop. Ad esempio, è possibile abbandonare il documento del manuale utente mentre si abbandona il prodotto.
gli eventi successivi
Questi eventi vengono attivati dopo l ‘azione di salvataggio o di rilascio. Poiché l’azione è terminata, non possono restituire errori. Il loro scopo principale è quello di attivare la logica di business se si è verificato un errore durante gli eventi precedenti.
Se non si è verificato alcun errore, possono anche gestire la logica post-successo, ad esempio l’invio di un’e-mail di conferma.
Questi eventi sono implementati solo a livello di entità.
Esempio:
In questo esempio, nella classe ProductsEntity è stato implementato un eventoafterSave. Se l’attributo userManualPath non è stato salvato correttamente in precedenza, il suo valore viene ripristinato per essere coerente con il documento del manuale utente mancante sul disco.
// 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 La stessa logica si applica a un eventoafterDrop:ad esempio, quando la caduta di un prodotto fallisce, è possibile registrare l’incidente.
Si noti che le operazioni lunghe devono essere evitate il più possibile negli eventi. Se possibile, tali operazioni devono essere implementate altrove.
Non aspettare di implementare gli eventi per contare su una forte integrità dei dati.
👉 S caricate l’HDI per approfondire i dettagli dell’implementazione degli eventi ORDA e guardate il video qui sotto per avere maggiori dettagli sull’esecuzione dell’HDI.
Aggiungere il link al video IT