Web service per comunicazione fra AOO: ipotesi di sviluppo per la comunicazione fra macchine
L’apparato normativo che l’Agenzia per l’Italia Digitale mette a disposizione dei sistemi di gestione informatica dei documenti prevede da tempo (almeno dal 2013, anno di pubblicazione della circolare n. 60) ausili tecnologici per la trasmissione di documenti fra pubbliche amministrazioni. SI tratta appunto delle regole per l’interoperabilità di protocollo, delle quali la cosiddetta segnatura (il file segnatura.xml che accompagna buona parte dei messaggi e-mail o PEC che provengono da un ente pubblico) è l’evidenza più comune. La segnatura in formato XML contiene, in un linguaggio ben codificato, tutti gli elementi che consentono al protocollo ricevente di registrare in modo automatico la comunicazione ricevuta. In realtà poi non è così perché la registrazione a protocollo richiede anche elementi non contenuti nella segnatura XML e che sono di fatto noti solo a chi riceve la comunicazione: per esempio, a quale ufficio è destinata, va assegnata per conoscenza a qualche altro ufficio?
Inizio subito con una parentesi. Il termine segnatura ha un significato preciso in archivistica e non riguarda certo solo documenti spediti da un posto a un altro, tradizionalmente è ciò che lega un documento nella sua manifestazione fisica alle informazioni descrittive che lo riguardano, siano esse contenute in un registro (anche di protocollo) o in un repertorio o anche solo limitate a una mera numerazione cronologica. Con queste premesse sembrerebbe ragionevole chiamare segnatura anche la raccolta di metadati – prevista prima dalle regole tecniche e adesso, più corposa, dall’allegato 5 delle linee guida – a corredo di un documento informatico. A ben vedere sfugge anche il motivo intimo della distinzione fra i metadati associati a un documento riposto nel sistema di gestione documentale e quelli associati a un documento che da quello stesso sistema fuoriesce. Sembrebbe ragionevole, infatti, che nella trasmissione da un sistema documentale a un altro il documento si portasse dietro il suo corredo originario di metadati al quale aggiungere quelli necessari per il suo viaggio: informazioni su mittente e destinatario, riferimenti più marcati al contesto procedurale, dati di validazione e, forse, poco altro. Fine della parentesi.
Nel disegno tracciato dalle nuove regole per la segnatura del protocollo interoperabile, ogni protocollo informatico espone un endpoint di un Web service con tecnologia e linguaggio ben definiti: una porta perennemente aperta, in ascolto. Il funzionamento di dettaglio di queste meccanismo di interopaerabilità non è di interesse al momento, potremo dedicargli in seguito un approfondimento ad hoc.
Il punto che ci interessa qui è che, per quanto i web service per il protocollo interoperabile siano pensati per la comunicazione fra AOO (cioè fra enti distinti, semplificando), ben potrebbero essere usati anche da applicativi interni all’amministrazione, per raggiungere la tanto agognata interoperabilità documentale fra i componenti del sistema informativo locale. Infatti, in una qualsiasi organizzazione pubblica o privata, una pluralità di componenti (software) del sistema informativo formano documenti che devono entrare correttamente nell’archivio. Che si scelga di trasferire tutti i documenti (le loro evidenze informatiche, meglio) in un unico posto fisico o che si desideri creare dei collegamenti stabili e duraturi fra la registrazione del documento, che necessariamente sta nel protocollo e lo descrive, e le evidenze informatiche del documento, che con le dovute cautele possono rimanere anche sotto la responsabilità del software che le ha formate o ricevute, si deve comunque stabilire una connessione efficiente fra i software che producono documenti e il protocollo informatico. Una connessione che magari sia standard, sia come interfaccia tecnologica sia come linguaggio comune (semantica).
I web service per l’interoperabilità di protocollo ben potrebbero prestarsi allo scopo, con alcune aggiunte. Infatti ai web service così come delineati dalle linee guida mancano alcuni elementi. In sintesi, manca la parte di gestione del documento: l’assgnazione a un ufficio (unità organizzativa), a un responsabile del procedimento, la definizione di permessi di accesso ecc. Tutti elementi propri delle regole di gestione documentale dell’organizzazione.
Un’obiezione che si potrebbe muovere è che se è l’applicativo (software, gestionale, verticale – chiamatalo come volete) deve guidare la registrazione a protocollo, allora l’applicativo stesso deve acquisire competenza documentale e sull’organizzazione dell’archivio dell’organizzazione, quando ci si attenderebbe che sia il software di protocollo ad avere in sé tutte le conoscenze al riguardo. Niente di sconvolgente però. La tenuta dell’archivio è fatto umano, demandato nell’organizzazione non solo al records manager ma, nell’operatività, a tutti i membri dell’organizzazione che, nella cornice di regole dettate dal records manager, vi applicano una propria intelligenza. Di fatto, il responsabile di una procedura conosce meglio di chiunque altro i documenti propri della procedura e le loro relazioni. Ciò ha anche un riflesso nella legislazione: il responsabile del procedimento è anche responsabile della tenuta del fascicolo. Quindi, se il software verticale in qualche modo assorbe le esigenze procedurali dettate dal responsabile del procedimento, assorbe pure le logiche di gestione documentale proprie del procedimento.
Fin qui l’introduzione dell’argomento. Nelle prossime puntate iniziamo ad analizzare cosa mancherebbe per usare il web service del protocollo interoperabile per integrare gli applicativi in modo standard. Prima, forse, conviene anche una breve sintesi dello schema di funzionamento del protocollo interoperabile secondo le nuove specifiche.
