Segnatura XML, #3: interoperabilità interna e registrazione guidata da software

Eccoci al terzo, conclusivo, capitolo della saga sulla segnatura XML, che fa anche da sequel (o remake) al precedente articolo a tema segnatura interoperabile.

Lo scenario d’uso è quello di un software gestionale o di un servizio online (un software di gare telematiche, un servizio di iscrizione all’asilo nido) che forma o riceve un documento e deve registrarlo al protocollo. Si tratta del caso di “integrazione” principe che tanti grattacapi regala a chi si occupa di trasformazione digitale in un ente pubblico.

A scanso di equivoci ricordiamo che la finalità della protocollazione informatica del documento è sì, nell’immediato, conferire pieno valore giuridico alla comunicazione (validazione temporale, garanzia di integrità) ma anche (e forse soprattutto) costituire correttamente l’archivio digitale dell’ente ed evitare che sia parcellizzato nei repository di file associati ai software gestionali, spesso e volentieri non rispondenti ai requisiti minimi di gestione documentale. Un archivio digitale unitario e organico consente di ricercare il patrimonio documentario dell’ente e di accedervi in un unico luogo, prescindendo dai singoli software gestionali che compongono il sistema informativo e in un orizzonte temporale ampio che può prevedere anche l’avvicendamento di soluzioni fra i software gestionali.

Quando tutto va bene, il protocollo espone delle sue interfacce (API, web service, RESTful API ecc.) proprietarie e il software che vuole registrare sviluppa un adeguato connettore. A parte i costi (economici, mentali e tecnologici), ci sarà spesso qualcosa che non torna: per esempio, chi si occupa di fascicolare? Chi si occupa e come di stabilire le competenze/permessi sul documento protocollato? Se al protocollo è associata una scrivania che accompagna il flusso dei documenti, chi si occupa di gestire il flusso? Non essendoci logiche condivise, non è escluso che i due attori in scena (software gestionale e protocollo informatico) si attendano reciprocamente che di qualche operazione si faccia carico l’altro. E non se ne esce.

Vorrei qui rispondere a una domanda: cosa manca alla segnatura XML per essere utilizzata per la protocollazione a partire da un software gestionale o da un servizio online? Tale protocollazione dovrebbe possibilmente (dove la natura del flusso lo consenta) essere non presidiata, almeno lato “ufficio protocollo”.

Procedendo con ordine: una volta resa disponibile un’interfaccia (web service), il processo deve garantire:

• il transito da software gestionale a protocollo del contenuto (file/componenti digitali) del documento;
• il transito delle informazioni descrittive del documento;
• alcune indispensabili funzioni di gestione del documento protocollato;
• messaggi di riscontro sulle operazioni eseguite.

Per facilità di lettura in coda al post si trova la restituzione grafica, più immediatamente intellegibile dell’XML-schema della segnatura XML come definita dall’allegato 6 delle linee guida.

L’interfaccia

Abbiamo sicuramente l’interfaccia tecnologica: come il protocollo dell’ente espone il web service agli altri enti può esporlo all’interno del sistema informativo locale a beneficio dei software gestionali presenti. Quindi la tecnologia infrastrutturale, basata su protocollo di trasporto HTTPS, buste SOAP e scambio di XML c’è. Al limite vanno ampliati i dati scambiati, aggiungendo tag opportuni ai file XML scambiati.

Una parentesi è d’obbligo: non mi sono noti esempi di implementazione dei web service da parte di software house o pubbliche amministrazioni. La documentazione tecnica pubblicata su GitHub, da quello che ho potuto apprezzare, non tratta questioni di autenticazione (rimanda alle linee guida generali di interoperabilità tecnica, che a loro volta descrivono possibili scenari senza prescrizioni tecniche univoche) e i WSDL a disposizione (i documenti che descrivono le regole per interagire con i web service tramite l’interfaccia SOAP) sembrano indicare come uniche funzioni gestite la comunicazione di inoltro di messaggio e il relativo l’annullamento (qualunque cosa siano).

Nell’incertezza, diciamo che potrebbe mancare qualcosa relativamente all’autenticazione dell’utente-macchina. La macchina interna ha un’interazione più articolata e profonda rispetto a una AOO esterna che, semplicemente, “deposita” un documento. Come spiegato nel seguito, infatti, perché tutto funzioni ha necessità di compiere attività di gestione documentale (es.: lettura di informazioni di registrazioni precedenti o creazione di un fascicolo). Diciamo quindi che occorre implementare, sia lato autenticazione ai servizi SOAP e conseguente interazione, sia lato protocollo informatico, dei meccanismi che assegnino all’utente-macchina che usa i web service il corretto profilo di autorizzazione, nel caso dipendente dall’eventuale utente-persona che sta utilizzando il software gestionale.

Il documento in arrivo

Ipotizziamo che il software gestionale debba trasmettere al protocollo per la registrazione un documento che ha ricevuto tramite un suo front office esposto sul web o altro. Mettiamoci anche nel caso in cui si voglia una protocollazione del tutto non presidiata, possibile se il software gestionale è dotato dell’intelligenza necessaria a individuare con certezza alcune informazioni necessarie alla protocollazione. A partire dalla segnatura, vediamo cosa c’è e cosa manca. Suddividiamo in informazioni di descrizione del documento e informazioni gestionali (relative al flusso documentale).

La descrizione del documento

• l’oggetto del protocollo c’è: nel tag “Intestazione”;
• l‘indice di classificazione e il fascicolo ci sono: ancora ne tag “Intestazione”. Nelle intenzioni della segnatura XML i tag indicano classe e fascicolo in partenza, ma in caso di protocollazione interna all’ente potremmo tenerli buoni come classe e fascicolo di destinazione;
• il mittente c’è: come tag complesso “Mittente” di tipo “SoggettoType” nel tag complesso “Descrizione”, tag obbligatorio con una e una sola occorrenza (non ripetibile). Anche se la segnatura XML è pensata per comunicazioni fra AOO il mittente può essere una Amministrazione, un’AmministrazioneEstera, una PersonaFisica o una PersonaGiuridica;
• il destinatario c’è: ancora come tag complesso del tag complesso “Descrizione”, con stesse caratteristiche del mittente, con l’eccezione che può essere ripetuto;
• l’elenco dei file/componenti digitali del documento c’è: ancora dentro il tag complesso “Descrizione”, grazie ai tag “DocumentoPrimario” (obbligatorio) e “Allegato” (opzionale e ripetibile).

Il tag “Riferimenti” consente anche di citare una registrazione di protocollo precedente alla quale si risponde o ci si collega. Per la gioia del vincolo archivistico, cosa inserire in questo tag dipende dal software gestionale protocollante che deve sviluppare logiche proprie per mantenere relazioni fra i documenti che produce e/o vede transitare (per esempio per legare una richiesta di integrazioni documentali alla risposta).

Manca un tag specifico per indicare la modalità di trasmissione (per registrazioni manuali da interfaccia del protocollo si sceglie di solito fra e-mail. PEC, consegna a mano, posta raccomandata, posta ordinaria…): si ipotizza che sia il protocollo informatico a implementare logiche per compilare questo dato con una formula del tipo “Via WS da software X”.

La gestione

Una volta protocollato il documento deve essere smistato/assegnato e reso accessibile all’UO (Unità Organizzativa) che deve lavorarci, perché competente per quell’affare. La segnatura XML, nei tag “Destinatario” e “Mittente” che descrivono i corrispondenti della comunicazione, consentono, per i soggetti di tipo Amministrazione, di specificare proprio fino al dettaglio della UO destinataria, utilizzando uffici (UO) e relativi codici censiti sull’Indice PA (IPA). Nella pratica spesso un documento è assegnato/smistato a più UO, per competenza o per conoscenza: lo schema XML attuale consente di inserire più destinatari e di specificare tramite l’attributo “perConoscenza” il tipo di smistamento (almeno per il Destinatario).

Perché lo smistamento funzioni, occorre un’operazione preliminare: allineare i codici usati nell’organigramma interno al software di protocollo informatico a quelli dell’Indice PA (IPA).

Nel 99.9% dei casi, poi, il protocollo informatico è un sistema di gestione informatica dei documenti e ha una componente che si occupa di far fluire i documenti fra le unità organizzative (uffici) dell’ente: solitamente, quando un protocollo viene assegnato a una UO, sulla scrivania o cruscotto digitale di quest’ultima appare una notifica che consente di prendere visione del documento, prenderlo in carico, marcarlo come “eseguito”, trasmetterlo ad altro ufficio con annotazioni ecc. Se c’è un software gestionale che forma e gestisce documenti, ci si immagina che il documento fluisca tramite quest’ultimo e non tramite il sistema di gestione documentale. Può comunque darsi il caso in cui il software collegato al protocollo esaurisca il suo compito con la protocollazione e il flusso documentale (e amministrativo) prosegua tutto nel sistema di gestione informatica dei documenti.

E’ così necessario che l’interfaccia di protocollazione consenta di evitare che il sistema di gestione informatica dei documenti “notifichi” la presenza della comunicazione all’ufficio a cui è stata smistata. A ben vedere. la segnatura XML attuale non prevede un tag o un attributo adatto allo scopo. Infatti, ritenendo che sia versatile poter controllare la notifica indipendentemente per ogni UO bersaglio di smistamento, si osserva che l’unico altro attributo specificabile è “richiediConferma”, che non può essere usato perché sovrintende fra AOO distinte all’invio del messaggio di conferma di protocollazione, messaggio che con i dovuti aggiustamenti è utile anche per protocollazioni a partire da software del sistema informativo. Occorre quindi inserire nel tag “Destinatario” un nuovo attributo (“notificaDestinatario”?), che controlla la notifica agli uffici.

Il documento in partenza

Per un documento in partenza vale quanto detto sopra. Tuttavia, poiché l’ente protocollante è in questo caso mittente (descritto nel tag “Mittente”, correttamente non ripetibile), ci sono delle complicazioni nel caso in cui per il documento protocollato in partenza debbano essere assegnati permessi di accesso (smistamento per competenza o per conoscenza) a ulteriori UO rispetto a quella che cura la registrazione. Una soluzione è inserire gli uffici dell’ente fra i destinatari (tag “Destinatario”, ripetibile, con specificazione fino al livello UO) e adottare la convenzione – da implementare come logica del software di protocollo informatico – che quando l’ente stesso è destinatario di un documento di cui è mittente, il protocollo informatico non invia a se stesso ma aggiunge le UO indicate fra gli smistamenti (per conoscenza o per competenza, secondo quanto indicato).

Il trasferimento del contenuto

Oltre alla descrizione dei documenti occorre trasferirne anche il contenuto, vale a dire i file che compongono il documento e che il software gestionale ha ottenuto verosimilmente tramite un suo front office pubblicato sul web che, magari, ha implementato gli accorgimenti necessari perché il documento sia formato in conformità alle linee guida.

Anche questa è una funzione che è già prevista per la comunicazione fra AOO via web service. Infatti, la segnatura XML è solo la prima parte di quanto trasmesso tramite il web service. La seconda parte, racchiusa nel tag “File”, comprende proprio i file, codificati in Base64.

Le ulteriori funzioni

Perché l’integrazione fra software gestionale e protocollo informatico sia pienamente efficace, occorre che anche altre funzioni del protocollo informatico/sistema di gestione informatica siano attivabili tramite web service. Si tratta di funzioni giustamente non contemplate per la comunicazione fra AOO perché non pertinenti.

Di seguito un breve elenco di ulteriori servizi, indispensabili, da implementare nell’interfaccia:

• richiesta di consultazione della lista dei fascicoli esistenti e relativa risposta;
• richiesta di creazione di un fascicolo (con gestione dei sottofascicoli) e relativa risposta;
• richiesta di invio di un documento protocollato (via PEC/mail) tramite il protocollo informatico e relativa risposta;
• richiesta di consultazione dell’esito dell’invio di un documento protocollato e relativa risposta con comunicazione di eventuali ricevute PEC di accettazione e consegna;
• richiesta di visualizzazione dei dati descrittivi di una registrazione di protocollo (secondo il profilo di autorizzazione dell’utente) e relativa risposta;
• richiesta di prelievo di file contenuti in una registrazione di protocollo e relativa risposta.

Servizi aggiuntivi, non strettamente indispensabili, riguardano:

• richiesta di modifica di una registrazione di protocollo (secondo il profilo di autorizzazione dell’utente) e relativa risposta;
• richiesta di consultazione del titolario di classificazione codificato nel protocollo informatico e relativa risposta;
• richiesta di consultazione dell’organigramma codificato nel protocollo informatico e relativa risposta.

Nessuna delle funzioni sopra menzionate, giustamente, è contemplata per la comunicazione fra AOO perché chiaramente non pertinente.

Sarebbe quindi fondamentale ampliare le definizioni dei web service per lo scambio di messaggi fra AOO per coprire anche queste funzioni.

Fra le funzioni ulteriori non sfigurerebbe qualcosa che riguardi i tempi di conservazione dei documenti. Tuttavia, riguardo scarto e selezione negli archivi digitali, non esistono ancora prassi talmente consolidate da essere standardizzate in un’interazione automatizzata fra software.

Verso uno standard?

Buone parte di quanto necessario per la protocollazione a partire da un software gestionale interno al sistema informativo dell’ente protocollante è già previsto nelle regole di interoperabilità per la comunicazione fra AOO. Per quanto riguarda il trasferimento di documenti e relative descrizioni, gli adeguamenti riguardano:

• gestione dei profili di autorizzazione, anche sulla base dell’eventuale utente autenticato sul software gestionale che invoca i web service;
• aggiunta di un attributo al tag “Destinatario” per attivare o disattivare la notifica della registrazione alle UO destinatarie;
• consentire intestazioni prive dei dati di registrazione o, meglio, prevedere un tag o un attributo che specifichi se la segnatura riguarda una registrazione esistente o se invece è una richiesta di registrazione;
• rendere la sezione dedicata al sigillo qualificato non necessaria in caso di richieste di registrazione.

Le ulteriori funzioni di gestione documentale elencate poco sopra non sono invece previste, in nessuna misura, nelle regole per la comunicazione fra AOO, essendo funzioni proprie delle interazioni all’interno del sistema informativo dell’ente protocollante. Poiché tali funzioni sono piuttosto elementari e richiedono un’interazione con scambio di un numero esiguo di dati, la definizione di ulteriori schemi XML e servizi SOAP a livello nazionale (AgID) appare non eccessivamente onerosa e potrebbe far evolvere veramente la segnatura XML e i web service pensati per la comunicazione fra AOO distinte verso uno standard per la protocollazione di documenti a partire da software interni al sistema informativo dell’ente. Si tratterebbe verosimilmente della prima realizzazione di uno standard nazionale di interfaccia e di interoperabilità fra componenti del back-office di un ente.

In conclusione, va sottolineato che l’adozione di un’interfaccia standard di comunicazione con software esterni non va a toccare e non interferisce con le logiche di funzionamento di un software e quindi non ne pregiudica funzionalità e punti di forza. L’interfaccia standard di comunicazione ha invece l’enorme vantaggio di far cessare l’esigenza di sviluppare connettori ad hoc fra software, con abbattimento di tempi e costi e beneficio per la sostenibilità del sistema informativo.

Tornando al caso specifico dell’integrazione col protocollo, sarebbe possibile dotare qualunque software gestionale del connettore per integrarsi con qualunque software di protocollo informatico: basterebbe configurare l’indirizzo (endpoint) del web service, qualche dato di autenticazione e, se non si automatizza anche quello, inserire le informazioni su titolario e organigramma.

Foto di Gerd Altmann da Pixabay