Vai al contenuto
Abbiamo creato un workflow che si occupa di tutta la parte di data preparation, blending e pulizia. Lo abbiamo schedulato su Alteryx Server o tramite lo Scheduler affinché vada in esecuzione ogni tot tempo… ma questo “tot tempo” non è un valore facilmente identificabile.
Perché, ad esempio, il workflow ha senso che parta solo dopo che Oracle ha finito di popolare la tabella usata come input in Alteryx.
E, per complicare un po’ le cose, la popolazione delle tabelle prevede una parte di dato storico e una parte di dato fresco, quindi a dicembre il processo ci metterà molto più tempo rispetto che a gennaio!
Corriamo il rischio che il workflow parta ancor prima che Oracle abbia finito di popolare la tabella, restituendoci degli output inutili.
Se riusciamo a trovare una logica implementabile in Alteryx, possiamo creare un piccolo workflow che controllerà se il processo Oracle di popolamento della tabella ha finito e, SOLO in caso affermativo, questo workflow di controllo manderà in esecuzione tramite DOS il workflow principale di data preparation, blending e pulizia dei dati.
Essendo piccolo e veloce, questo workflow di controllo potrà essere schedulato su server con una frequenza molto alta, anche ogni 5 minuti, senza correre il rischio di intasare le task di Alteryx Server con processi lunghissimi che accodano tutti gli altri.
Dati del problema:
- Un workflow principale di data preparation, “Workflow_1.yxmd”, da schedulare
- Un processo Oracle che popola la tabella usata come input nel “Workflow_1.yxmd” e che quando ha finito crea un file chiamato “Log_popolamento.txt” in una cartella specifica
Se clicchiamo su un punto vuoto del canvas in Alteryx e andiamo nella tab “Events” della configurazione del workflow, vediamo che è possibile settare degli eventi che partono alla fine dell’esecuzione del workflow:
Questi eventi possono essere inizializzati a determinate condizioni. Ad esempio se il workflow riesce ad andare in esecuzione e finire il processo senza errori.
Possiamo quindi creare un evento che utilizzi DOS per mandare in esecuzione il Workflow_1.yxmd ma solo solo se il workflow finisce senza errori e strutturare il workflow affinché vada a controllare se trova il file “Log_popolamento.txt” nella cartella in cui dovrà essere creato e utilizzare un tool per creare un errore nel caso in cui il log ancora non ci fosse.
In questo modo l’evento non partirà.
1) Creazione del workflow di test
Dobbiamo controllare se esiste il file “Log_popolamento” in una determinata cartella. Possiamo usare un Directory Tool che ci restituirà l’elenco di tutti i file che si trovano in una determinata cartella e/o sottocartelle:
Dato che stiamo cercando un file di testo, possiamo anche limitare l’input all’estensione .txt.
Notare che tra le colonne del Directory Tool abbiamo anche la data di creazione del file, l’ultimo accesso e la data dell’ultima scrittura. Quindi questo procedimento sarebbe valido anche se il log scritto da Oracle avesse sempre lo stesso nome e venisse sovrascritto. Ci basterà controllare che la data di ultima scrittura sia successiva a un certo valore. Se ad esempio la popolazione delle tabelle avviene giornalmente, la data di ultima scrittura dovrà essere = alla data di oggi.
Ora è il momento di impostare il test. Possiamo utilizzare un Filter Tool e la condizione FileName=”Log_popolamento.txt”:
E ora possiamo creare un errore che blocchi l’evento DOS.
Se il file è arrivato, avrò 1 record nel connettore T (True) del Filter Tool. Se il file non è arrivato, avrò 0 record nel connettore T (True) del Filter Tool.
Possiamo usare un Count Records Tool per farci contare quante righe passano dal connettore T:
Il tool si trova nella tab “Transform” e non necessita di alcuna configurazione.
Adesso possiamo spostarci nella tab “Developer” e trascinare nell’area di lavoro il “Message Tool”.
Il tool ci permette di creare diversi tipi di messaggi che verranno mostrati nel log del workflow. In questo caso dobbiamo impostare il tool nel seguente modo:
- When to send the Message: Before Rows Where Expression is True, e impostiamo la condizione [Count]=0. Il tool creerà il messaggio non appena identificherà un record in cui la colonna [Count], creata con il Count Records, è uguale a zero.
- Message Type: Error – And Stop Passing Records, in questo modo verrà creato un errore che non permetterà al workflow di raggiungere il 100% di avanzamento e non farà partire l’evento finale
- Message Expression: dobbiamo scrivere il messaggio che poi leggeremo nel log.
2) Creazione dell’evento DOS
Ora che il workflow di test è finito, possiamo creare l’evento DOS che mandi in esecuzione il vero workflow.
Clicchiamo su un punto vuoto dell’area di lavoro e andiamo nella tab “Events” delle configurazioni del workflow, e scegliamo di creare un nuovo evento “Run Command”.
Le cose essenziali da impostare sono 2: la cartella in cui si trova l’eseguibile dell’AlteryxEngineCmd e l’istruzione dos da lanciare.
- Run Event When: After Run Without Errors, l’evento parte dopo che il workflow termina l’esecuzione senza errori
- Command: bisogna andare ad aprire il file “AlteryxEngineCmd.exe”
- Command Arguments [Optional]: dobbiamo scrivere l’istruzione dos.
Se stessimo usando i comandi dos al di fuori di Alteryx, dovremmo:
- aprire il prompt di dos
- spostarci nella directory in cui è contenuto l’AlteryxEngineCmd.exe con il comando “cd C:\Program Files\Alteryx\bin\”
- impartire il comando tramite l’istruzione “AlteryxEngineCmd.exe C:\directory\Nome_del_Workflow.yxmd”
Gli step 1, 2 e metà del 3 sono impostati nel box “Command”. L’ultima parte dello step 3, nel box “Command Arguments”.
Ora possiamo provare se tutto il processo funziona.
Il mio “Workflow_1” è un workflow semplicissimo che legge il file “Log_popolamento” e crea un output sul desktop in formato .yxdb che si intitola “Ha funzionato”:
Se ora vado nella cartella e rinomino il file .txt che stiamo cercando (per fingere che non sia ancora arrivato), il risultato sarà questo.
Se invece torno nella cartella e rinomino nel modo giusto il file .txt che stiamo cercando, (per fingere che sia arrivato), il risultato sarà questo:
L’evento è partito e ha mandato in esecuzione il secondo workflow in 0,3 secondi.
Possiamo quindi schedulare questo workflow con evento annesso, anche con una frequenza piuttosto alta, e lasciare che sia lui a mandare in esecuzione il workflow principale “Workflow_1.yxmd” quando il file di input effettivamente viene creato.
