Trigger

La funzionalità Trigger, introdotta nella release 2021.06++, ha lo scopo di consentire la definizione di script che vengono eseguiti automaticamente al momento della registrazione sulla tabella LOGDOC di una specifica operazione, come ad esempio il salvataggio, la cancellazione o la pubblicazione di un documento o di una registrazione.

Gli script sono di fatto molto simili a Task, la cui esecuzione non è però attivata in base ad una schedulazione temporale ma viene attivata nel momento in cui viene effettuata un’operazione sul database, sia essa di inserimento, aggiornamento o eliminazione.

A differenza dei trigger che vengono definiti a livello di database, sulle operazioni “fisiche” effettuate su specifiche tabelle, i Trigger di QualiWare vengono definite sulle operazioni “logiche” che vengono registrate, come detto, sulla tabella LOGDOC, e che sono visibili nella funzionalità “Cronologia” disponibile nella toolbar di ogni scheda.

La definizione dei Trigger viene effettuata da QualiWare Server Daemon.

La scheda di configurazione si presenta come nella figura seguente:

Nel riquadro subito sopra l’area dove può essere specificato lo script, è possibile specificare i 4 criteri in base ai quali il trigger deve essere attivato, che corrispondono ad altrettanti campi della tabella LOGDOC. 

I 4 campi sono

• IDDOC: tipo della registrazione, come definito nella scheda Utenti e Abilitazioni, linguetta “Abilitazioni”;
• CODDOC: codice del documento o registrazione, contenuto nel campo “_CODDOC” della tabella principale della registrazione stessa, o della tabella DOCUMENT;
• Operazione: operazione a seguito della quale deve essere eseguito il trigger;
• NOTE: note relative all’operazione. 

Sui campi IDDOC, CODDOC e NOTE è possibile utilizzare il carattere “%” come wildcard. Ad esempio, se si vuole applicare un trigger ai documenti presenti in una specifica categoria, è possibile assegnare IDDOC=’DW’ e CODDOC='<codice categoria>%’. Se poi si vuole eseguire il trigger solo in caso di pubblicazione del documento, è possibile inserire NOTE=’%#PUBLISHDOCUMENT%’. Questo perchè la gestione documentale inserisce, nelle note della registrazione su LOGDOC, degli hashtag specifici che consentono di distinguere i vari tipi di azione effettuata sul documento.

E’ di particolare importanza specificare correttamente questi criteri per evitare che il codice venga eseguito quando non è necessario, il che potrebbe avere un impatto anche molto negativo sulle prestazioni dell’applicazione.

Lo script può fare uso della variabile DB, che contiene un riferimento all’oggetto QWDatabase che implementa la connessione del database, nonchè delle variabili IDDOC, CODDOC, TOP e NOTE, che contengono i valori effettivi dei rispettivi campi del record di LOGDOC che è stato registrato a seguito dell’operazione, dove TOP=Tipo operazione. 
Lo script può ritornare “False” se si desidera che vengano annullate anche tutte le operazioni effettuate sul database (inserimenti, aggiornamenti o eliminazioni di record) nella stessa transazione, compresa la registrazione su LOGDOC che ha attivato il trigger. 
Nel caso il trigger ritorni “False”, all’utente verrà mostrato un messaggio d’errore, che può essere specificato assegnandolo alla variabile ErrorMessage all’interno del codice. Tale variabile non deve essere dichiarata in quanto ciò avviene implicitamente. Nel caso tale assegnazione non venga effettuata, verrà restituito un messaggio generico.

NOTE IMPORTANTI
1) le modifiche apportate ai trigger vengono  recepite all’avvio della sessione utente. Solamente in fase di modifica, queste vengono attivate immediatamente senza che l’utente che le sta sviluppando debba disconnettersi. per fare i test. Pertanto, dopo avere effettuato il test e abilitato il trigger, è necessario comunicare agli utenti di disconnettersi e riconnettersi a QualiWare o, in alternativa, riavviare il pool. Analogamente, se si sta effettuando lo sviluppo su un database diverso da quello principale, e si è attivata una sessione di QualiWare su quel database per effettuare i test, è necessario ricordarsi di uscire dalla sessione corrente e rientrare in QualiWare prima di effettuare le prove, altrimenti non verranno recepite le modifiche.
2) è bene effettuare lo sviluppo e la modifica di uno script disattivando il flag “Abilitato”, e riabilitarlo solo al termine delle modifiche e dopo avere effettuato il test con successo. Le modifiche saranno attive al successivo accesso dell’utente. In altre parole, come detto al punto precedente, se un utente ha una sessione attiva, questa continuerà ad utilizzare la versione in vigore al momento dell’accesso. Per questo motivo, se il trigger esiste già ed è attivo, si suggerisce di effettuare le modifiche su una copia, e, una volta validata, attivare la nuova versione, disattivare la vecchia e riavviare il pool di IIS per essere certi che le sessioni esistenti siano disconnesse;
3) è possibile disattivare l’esecuzione dei trigger che agiscono su una specifica tabella assegnando a “True” la proprietà DontExecuteTrigger dell’oggetto QWTable.