Indice articolo

In Sme.UP ERP è possibile mettersi in ascolto di cartelle  di file system o di rete per rilevare la creazione, la modifica o la cancellazione di file (anche di diversa tipologia) e, a fronte del tipo dello specifico file o del suo contenuto, permettere al sistema gestionale di agire di conseguenza.

 

Di cosa si tratta e come funziona?

Il problema di fondo che ha permesso la nascita dello strumento che andremo ora ad analizzare è stata la crescente necessità di dover prendere una decisone ogni qualvolta venga creato, modificato o eliminato un file all’interno di cartelle specifiche. Nasce così l’ascoltatore di cartelle su file-system.

Si pensi alla volontà di storicizzare i file di documenti scannerizzati. In una situazione normale, i documenti verrebbero scannerizzati in una cartella condivisa specifica, per poi essere smistati “a mano” e posizionati nelle corrette cartelle su server.
Per facilitare questo compito per esempio si potrebbe pensare di utilizzare un Ascoltatore sulla cartella condivisa, il quale nel momento in cui viene generata la scansione scatena un evento. Tale evento verrà poi gestito dal Decisore che, per esempio sulla base del nome del file, lo deposita nella corretta cartella in archivio.

Altro caso potrebbe essere quello di un macchinario aziendale che legge le istruzioni da compiere in un file su un server interno all’azienda.  Il progettista potrebbe aver intenzione di aggiornare i dati di quello che il macchinario deve fare e grazie all’Ascoltatore, scatenare un evento in modo tale che il macchinario possa accorgersi di questa modifica e quindi ricevere il comando di fermarsi e ricominciare la prossima lavorazione con i nuovi settaggi.

Tutto questo avviene avvalendosi delle funzionalità messe a disposizione in Sme.UP ERP, dal costruttore A37, dove, a fronte di variazioni all’interno di cartelle specificate inizialmente, l’Ascoltatore comunicherà al Decisore l’evento rilevato. Interviene quindi una seconda figura all’interno di questa struttura che è quella del Decisore.

Nel codice del Decisore è presente l’algoritmo specifico che decide cosa farne dell’evento arrivato: spostare il file, leggerne il contenuto, far partire una macchina, mandare una mail etc. E’ quindi il Decisore che risponde alla domanda “perché il sistema sta monitorando la casella?”.

 

Separare i ruoli è fondamentale!

L’Ascoltatore

L’Ascoltatore è implementato utilizzando e configurando nel migliore dei modi lo script SCP_SET del LOA37_XX (e tutto ciò che ne deriva) che vedremo tra poco.
Esso semplicemente si avvale del plugin scritto nel parametro Class che una volta configurato e lanciato si mette già in ascolto sugli eventi generati.

Si rimanda agli approfondimenti sullo specifico argomento ma, per dare una panoramica, A37 è il costruttore che permette al gestionale di ricevere eventi dal mondo esterno, sia dal mondo fisico (IIOT etc.) sia dal mondo virtuale (file-system, posta, etc.).

Il Decisore

Il Decisore è quel programma che riceve in ingresso l’evento e prende le decisioni sul da farsi.
Esso è quindi scritto dal programmatore ed avrà il compito oltre che di gestire l’input dell’evento e/o delle variabili passategli, di generare un output che può andare dallo spostare file, al comandare macchine … alla più svariata operazione attuabile a fronte di un evento scatenante e gestibile.

 

La configurazione

L’implementazione dell’Ascoltatore che si collega alle cartelle e resta in ascolto, è contenuta come plugin in Sme.UP Provider e viene attivata configurando uno script di A37. I parametri necessari all’attivazione sono i dati relativi ai percorsi, il tipo di evento di cui bisogna controllare e i riferimenti al nome del Decisore.

Di seguito un esempio di configurazione implementabile tramite uno script LOA37.
Lo scopo finale di questo script di esempio è quello di copiare il file (txt,pdf,jpg o doc) nella cartella locale “C:\Users\Scimam\Desktop\FileScaricati” , dopo che l’Ascoltatore si è accorto della sua creazione sul server centrale nella cartella “\\srv.smeup.com\SMEDOC\USER\SCIMAM\TEMP” .

ESEMPIO
::A37.SUPPRV DtaQ="SCIMAM" Active="1" 
 
-- unità fisica 
::SEZ Cod="A01" Txt="Monitor cartella input " 
::A37.CLSSEZ Class="Smeup.smeui.iotspi.connectors.filesystem.FileSystemConnector" Pgm="£X" Log="Yes"

-- variabili configurazione unità fisica 
::A37.CNFSEZ Name="PATH" Value="\\srv.smeup.com\SMEDOC\USER\SCIMAM\TEMP" 
::A37.CNFSEZ Name="FILTER" Value="txt;pdf;jpg;doc" 
::A37.CNFSEZ Name="RECURSIVE" Value="true" 
::A37.CNFSEZ Name="EVENT" Value="C"
-- variabili configurazione del Pgm 
::A37.CNFPGM Name="PATHD" Value="C:\Users\Scimam\Desktop\FileScaricati" 

-- unità logica 
::SUB Cod="001" Txt="Cartella arrivo Scanner" 

-- varibili di configurazione dell'unità logica 
::A37.SUBVAR Name="STATUS" TpVar="V2SI/NO" DftVal="1" 

-- variabili di messaggio 
::A37.MSGVAR Name="EVENT" TpVar="**" DftVal="" 
::A37.MSGVAR Name="PATH" TpVar="**" DftVal="" 
::A37.MSGVAR Name="DIMENSION" TpVar="**" DftVal="" 
::A37.MSGVAR Name="DATETIME" TpVar="**" DftVal=""

 

Spieghiamo nel dettagio Nel dettaglio

::A37.SUPPRV DtaQ="CODICE_PROVIDER"

indica qual’è il provider su cui verrà attivato l’Ascoltatore

::A37.CLSSEZ Class="Smeup.smeui.iotspi.connectors.filesystem.FileSystemConnector" TOg="" Ogg="" Pgm="XX"

nella specifica CLSSEZ sono presenti il parametro Class che riporta la classe java attiva dell’ascoltatore (che è il plugin meup.smeui.iotspi.connectors.filesystem.FileSystemConnector) ed il parametro Pgm che indica chi sarà il Decisore. Il valore XX di esempio indica che il programma che si occuperà di trattare i dati originati dall’Ascoltatore sarà il LOA37_XX.

::A37.CNFSEZ Name="PATH" Value="PATH_CARTELLA_DA_ASCOLTARE" 
::A37.CNFSEZ Name="FILTER" Value="TIPI_FILE_DA_MONITORARE" 
::A37.CNFSEZ Name="RECURSIVE" Value="TRUE_O_FALSE" 
::A37.CNFSEZ Name="EVENT" Value="TIPO_DI_EVENTO" 
::A37.CNFPGM Name="PATHD" Value="VARIABILE_DA_FAR_ARRIVARE_AL_DECISORE"

Indicano, nell’ordine:

  • percorso della cartella da monitorare (NB: il path deve essere raggiungibile dal provider in cui risiede il plugin; il path deve essere tra i path del “PROVIDER_PATHS” nell’SCP_CLO come descritto qui);
  • i tipi di file da monitorare intervallati da “;” (ad esempio “txt;pdf;jpg”);
  • ricorsività di monitoraggio anche nelle sottocartelle della cartella di partenza definita nel “PATH” che assume valori “true” o “false”.
    Così facendo si portranno gestire in automatico eventi su file nelle cartelle che verranno create sotto quella di partenza;
  • tipo di eventi gestiti sul file (creazione, modifica o cancellazione) ed i dati inseribili sono “C”, “M”, “D” intervallati da “;” (ad esempio “C;D” per monitorare creazione e/o cancellazione di file)
  • variabile da far arrivare al Pgm ovvero al Decisore, opzionale e non necessario come parametro, ma utile in caso in cui si debba passare al Decisore delle informazoni aggiuntive.
    Nell’esempio soprastante per esempio è stata utilizzata per indicare il percorso di destinazione dove spostare il file una volta scatenato l’evento.

Il resto dello script va lasciato com’è nell’esempio perché indica le strutture dati di comunicazione fra il plugin ed il costruttore A37.

A titolo esemplificativo, mostro le variabili di messaggio che arrivano al Decisore nell’esempio precedente (che sono tutte le variabili di messaggio e le variabili CNFPGM):

 

Una volta sistemato lo script ed avviato il Provider definito per l’attivazione della funzione la funzionalità è attiva.

 

Come inserire un PROVIDER_PATHS?

Per rendere raggiungibile un percorso al nostro provider, è necessario inserirlo all’interno di una variabile chiamata PROVIDER_PATHS. Il modo per inserirla è abbastanza semplice e prevede di creare un membro LIBRERIA_IN_LINEA/SCP_CLO/NOME_UTENTE_PROVIDER nell’ambiente con cui il provider accede all’AS.

Nel mio caso avendo il provider che accede all’ambiente di sviluppo personale e con il mio nome utente, ho creato il membro W_SCIMAM/SCP_CLO/SCIMAM in cui è bastato inserire queste righe:

------------------------------------------------------------------------------------------------- 
Variabili provider 
------------------------------------------------------------------------------------------------- 
 
::C.SEZ Cod="Variable" 
::C.VAR Cod="PROVIDER_PATHS" Txt="Path accettati dal server remoto" Value="\\srv.smeup.com\SMEDOC\USER\SCIMAM\TEMP;C:\Users\Scimam\Desktop\FileScaricati"

 

Una volta avviato il provider, per verificare che abbia accettato correttamente i percorsi inseriti precedentemente, basterà accedere alla pagina di debug del provider stesso e controllare se cliccando su “test percorsi abilitati”  se sotto la voce “PROVIDER_PATHS” vengono visualizzati.

I Log sono nostri amici

Anche se la maggior parte degli utenti non controlla mai cosa viene scritto nei log, essi possono essere di grande aiuto per capire se tutto è stato configurato in modo corretto. Se il processo sta lavorando come ci si aspetta o se ci sono errori che impediscono il funzionamento o generano comportamenti non voluti.

I log si possono trovare come al solito nella cartella dei log del provider e precisamente se lo script è stato caricato correttamente troveremo all’interno della cartella LOG un file di questo tipo (dove le ultime 5 lettere stanno ad indicare il nome del file e la sezione, nel mio caso LOA37_FS e sezione A01):

I log che ci troveremo dinnanzi sono così composti e ci daranno una panoramica del funzionamento e dei vari eventi che vengono scatenati:

 

Conclusione

Con questo articolo si è voluto porre l’attenzione sul fatto che, con l’ascolto di eventi in cartelle, Sme.UP ERP può utilizzare questo strumento come canale di input, rendendo quindi semplice la creazione di sistemi di acquisizione dati o, addirittura, di sistemi di interazione sulla logica dei BOT.