agid / ssu-ws Goto Github PK

Quesito

Non mi è chiaro se sia stato deciso e in quale sede se sia necessario:

• Procedere alla generazione e trasmissione di un documento pdf quale rappresentazione “analogica” della domanda e cosa debba comprendere esattamente (solo rappresentazione del modulo o anche elenco dei documenti allegati)
• Firmare digitalmente il modulo xml o il documento pdf che lo rappresenta o se l’autenticazione con Spid sia ritenuta sufficiente (come sembrerebbe secondo il CAD)
• Se i documenti allegati debbano comunque essere sempre firmati o solo in alcuni casi (specificato nei metadati?) o se l’inoltro (firmato o autenticato Spid) sia sufficiente

Problema: trasmissione di istanze con allegati documentali numerosi e/o di grosse dimensioni

Il tipo di informazione non strutturato contenuto negli allegati è ciò che può causare problemi di timeout nelle comunicazioni, ci sono svariati casi in cui il numero e la dimensione degli allegati è tale da far sì che l’invio dell’istanza avvenga con difficoltà o non risulti possibile.

Proposta

Bisognerebbe pensare fin da ora ad un meccanismo che preveda l’invio di un “indice” dei contenuti in modalità sincrona ed un successivo invio/recupero asincrono degli allegati. Il meccanismo scelto dovrebbe consentire al chiamante e al ricevente di identificare la conclusione della trasmissione, anche ai fini del corretto calcolo dei tempi del procedimento. In WS* esiste il concetto di conversazione con gestione della sessione di comunicazione, ma, anche in considerazione che l’interfaccia tecnica potrebbe un giorno cambiare, gestirei la comunicazione da applicativo con un pattern di scambio concordato.

Problema: il riferimento territoriale usa la codifica ISTAT dei Comuni

E’ importante che tutti i componenti del SSU usino lo stesso set di metadati (stessa versione e stesso livello di specializzazione delle informazioni).
Per questo motivo il riferimento territoriale viene stabilito dal front-office in funzione del Procedimento e dello Sportello Unico che deve prenderlo in carico e poi viene passato invariato a back-office ed enti terzi.
Serve ad identificare nel Registro SSU il set di metadati pertinenti ad un procedimento erogato dallo Sportello Unico che deve erogare il servizio richiesto, in modo che possano essere recepite eventuali personalizzazioni definite localmente, nell’ambito territoriale applicabile allo specifico Sportello Unico.
Per come funziona il SSU tutti i componenti accedono ad un Registro SSU di riferimento (può essere locale, ma anche un Registro condiviso a livello Regionale, è solo una questione di HA e prestazioni, perché il contenuto viene mantenuto sincronizzato su tutti i Registri).
Un’Api del Registro consentirà di interrogare il proprio Registro e recuperare il riferimento territoriale in funzione del Procedimento e dello sportello unico selezionato dal Presentatore.
Il riferimento territoriale consentirà di selezionare la sezione del Registro SSU corretta.
La personalizzazione avviene a livello del singolo procedimento che ne ha necessità (magari su centinaia di procedimenti solo per uno o due è stata fatta una personalizzazione locale).
Come regola generale un procedimento può essere personalizzato solo fintanto che la personalizzazione impatta solo sugli enti terzi del territorio nel cui ambito opera lo sportello unico.
Se impatta su enti che operano anche per altri sportelli unici di altri ambiti territoriali può essere accettata solo se condivisa anche dagli altri ambiti territoriali.
Quindi ad es. i moduli dei VdF devono essere nazionali, quelli delle Aziende Sanitari devono essere Regionali, quelli degli endo-procedimenti dei comuni possono essere personalizzati a livello di ambito territoriale coperto dallo Sportello Unico.
Per uno stesso procedimento posso avere alcuni metadati modificati a livello regionale ed altri a livello di Sportello Unico, al provvedimento verrà assegnato un riferimento territoriale di Sportello Unico (quello più specifico).
Va anche tenuto conto che non tutti gli Sportelli Unici sono localizzati in un Comune: in Regione FVG esistono (almeno per ora) le Unioni Territoriali Intercomunali (UTI), i raggruppamenti di Comuni e le Comunità Montane che possono essere sede di SUAP, alcuni sportelli unici possono essere regionali (Regione o Agenzia Regionale).
Potrei peraltro avere più sportelli unici che condividono lo stesso set di personalizzazioni per un certo procedimento pur insistendo su territori diversi.

Possibili soluzioni

Il codice IPA potrebbe essere adatto ad identificare un qualsiasi ente e quindi uno sportello unico
<xs:simpleType name="CodiceIpaType">
xs:annotation
xs:documentation
pattern da definire se possibile
</xs:documentation>
</xs:annotation>
<xs:restriction base="xs:string"/>
</xs:simpleType>

In alternativa si potrebbe definire una codifica gestita appositamente per identificare l’ambito di personalizzazione di una porzione del Registro, magari condivisa da più sportelli unici.
Considerato che la territorialità è legata anche al territorio degli enti terzi coinvolti nel procedimento e non solo alla localizzazione dello sportello unico forse ha più senso la seconda soluzione.
La verifica che le personalizzazioni siano fatte in modo “territorialmente” valido non è così banale da fare in automatico.
Manterrei però il codice IPA per altri motivi.

Credo che sia già definito in AgID_basic_components.xsd

<xs:simpleType name="CodiceAmministrazione">
    <xs:restriction base="xs:string">
        <xs:pattern value="[A-Za-z0-9\-_]{1,16}"/>
    </xs:restriction>
</xs:simpleType>

riguardo...

<xs:element name="RiferimentoComune" type="msgtype:CodiceIstatComuneType"/>

...forse sarebbe meglio generalizzare. Cosa succede se la cosa compete ad Unione di Comuni o altra forma associata? Si potrebbe usare il nome "RiferimentoEnte" e il relativo codice IndicePA (che tutti gli enti pubblici hanno).

Problema: tipo di dato troppo specifico

Identifica univocamente un procedimento all’interno del dominio amministrativo di un Ente (o meglio di una AOO di un ente). Viene definito come intero non negativo.

Possibile soluzione

Come per l’di istanza e per motivazioni analoghe si propone di usare un tipo string come tipo base.
<xs:simpleType name="IDProcedimentoType">
xs:annotation
xs:documentationidentifica in modo univoco in un ente un tipo di procedimento
</xs:documentation>
</xs:annotation>
<xs:restriction base="xs:string" />
</xs:simpleType>

riguardo...

<xs:element name="IDProcedimento" type="msgtype:IDProcedimentoType"/>
(..)
<xs:simpleType name="IDProcedimentoType">
<xs:restriction base="xs:nonNegativeInteger"/>
</xs:simpleType>

...come si pensa di codificare i procedimenti (e dove saranno disponibili gli elenchi di procedimenti/codici dei singoli enti)? forse il tipo IDProcedimentoType potrebbe avere qualche informazione in più (ad esempio un denominazione procedimento, regime amministrativo, ecc).
...come si pensa di collegare procedimenti, endo-procedimenti e istanze/moduli?

Salve,
mi sembra che negli attuali wsdl non siano esplicitato alcun profilo di sicurezza,
raccomandato dalla linee guida dell' interoperabilità (https://docs.italia.it/italia/piano-triennale-ict/lg-modellointeroperabilita-docs/it/bozza/doc/doc_04/soluzioni-di-sicurezza.html ).
Come si garantisce ad esempio integrità del messaggio/autenticazione/opponibilità ai terzi della comunicazione ?

Problema: ridefinizione di concetti simili già definiti

In MODULI_common_components.xsd esiste già una definizione di AllegatoBinarioType che comprende il contenuto base64 e una sezione di metadati fra cui il MimeType che si potrebbe riusare. Riporto di seguito quanto già definito:

<xs:complexType name="AllegatoBinarioType">
    <xs:complexContent>
        <xs:extension base="moduli:RiferimentoGenericoAllegatoType">
            <xs:sequence>
                <xs:element name="contenuto" type="xs:base64Binary"/>
            </xs:sequence>
        </xs:extension>
    </xs:complexContent>
</xs:complexType>

<xs:complexType name="RiferimentoGenericoAllegatoType" >
    <xs:sequence>
        <xs:element name="nomeFile" type="xs:string" />
        <xs:element name="descrizione" type="xs:string" minOccurs="0"/>
        <xs:element name="nomeFileAlt" type="xs:string" minOccurs="0"/>  
        <xs:element name="mime" type="enumeration:MimeTypeEnum" />  
        <xs:element name="dimensione" type="xs:positiveInteger" minOccurs="0"/>
    </xs:sequence>
</xs:complexType>

Proposta:

Riusare i tipi già definiti e quindi:
• usare AllegatoBinarioType al posto di BinaryFileType
• derivare XmlBinaryFileType da AllegatoBinarioType fissando il MimeType a text/xml

Proposta
Si propone di usare il tag annotation per descrivere il significato e lo scopo di tipi ed elementi usati negli schemi, laddove può servire

Problema: in caso di domanda unica il procedimento non è staticamente determinato

Nel caso di SUAP non abbiamo un solo procedimento, la domanda unica viene composta in base alla selezione di n>=1 procedimenti fatta dinamicamente dall’utente, a meno di non enumerare tutte le combinazioni lecite di procedimenti (probabilmente ci sono delle combinazioni che hanno senso e altre non ammissibili).
Il caso di uno Sportello Unico semplice diventa un sotto caso semplificato del SUAP in cui l’elenco contiene esattamente un procedimento.

Possibile soluzione

Si passa la lista di tutti i procedimenti selezionati dall’utente: ad ogni procedimento della lista saranno collegati nel Catalogo (registro SSU) gli Enti terzi e i relativi endo-procedimenti e gli schemi xsd dei moduli pertinenti per ogni procedimento.
<xs:complexType name="ElencoProcedimentiType">
xs:annotation
xs:documentationelenco di 1 o più identificatori di tipi di procedimento
</xs:documentation>
</xs:annotation>
<xs:sequence maxOccurs="unbounded">
<xs:element name="IDProcedimento" type="msgtype:IDProcedimentoType"/>
</xs:sequence>
</xs:complexType>

Il front-office dovrà comporre un unico schema dati considerando una sola volta i sotto-schemi comuni a tutti i procedimenti selezionati (sicuramente lo schema dei dati anagrafici) in modo da far compilare al richiedente un unico modulo senza sezioni ripetute (once-only).
Lo schema dati risultante potrebbe essere passato durante la consegna dell’istanza al back-office insieme al modulo xml compilato (il back-office potrebbe anche ricostruirlo a partire dalla lista dei procedimenti).

Problema derivato: impatto della domanda unica sulle comunicazioni con gli enti terzi

Le considerazioni fatte sopra hanno un impatto anche su tutte le comunicazioni con gli enti terzi, perché il modulo dati e lo schema a cui deve essere conforme, nonché le regole schematron applicabili, nel caso SUAP, non sono staticamente definite, ma vanno composte a run-time in funzione delle scelte del richiedente.

Todo:
Vanno riviste i parametri delle comunicazioni con gli enti terzi

Problema: utilizzo del Filetype per la struttura del Payload

Una richiesta comporta la compilazione di un modulo e l’invio del modulo e di 0 o più allegati. Sia Modulo che Allegato condividono lo stesso tipo FileType composto da un contenuto Xml ed un contenuto binario, di cui solo il secondo è obbligatorio. Mi ero sempre immaginato un modulo come un contenuto Xml ed un allegato come un contenuto binario qualsiasi (con il suo MimeType). Un’istanza dovrebbe veicolare un contenuto Xml (obbligatorio) e un elenco (eventualmente vuoto) di allegati binari. Per capirci, il contenuto xml dei Vigili del fuoco dovrebbe far parte del documento xml della domanda unica, non essere allegato alla domanda unica. In linea di massima gli allegati dovrebbero trasportare contenuto informativo esterno (progetto dell’ingegnere, planimetria, foto, ...) non riconducibili ad un documento xml elaborabile da un ente terzo o comunque una vista di maggior dettaglio di quanto riportato nel modulo xml che può solo essere letta ed interpretata da un essere umano.

Proposta:

Si propone una ristrutturazione del Payload informativo dell’istanza

Problema: tipo di dato troppo specifico

Se ho capito bene è l’id che mantiene la correlazione fra tutti i messaggi riferite alla stessa domanda unica. Viene definita come intero non negativo:
<xs:simpleType name="IDIstanzaType">
<xs:restriction base="xs:nonNegativeInteger"/>
</xs:simpleType>
L’id istanza deve identificare univocamente un’istanza del procedimento che nasce dalla domanda unica di un soggetto, quindi dovrà essere univoco all’interno del dominio amministrativo di un Ente (o meglio di una AOO di un ente).
Per il sistema di trasporto risulta indifferente il tipo di dato ed eventuali vincoli di formato.
Possibile soluzione
Si propone di usare un tipo di dati stringa che consente di serializzare qualsiasi tipo di dato, per consentire implementazioni diverse, ad es basate su Guid o altri schemi che assicurino comunque il rispetto del requisito di univocità.
<xs:simpleType name="IDIstanzaType">
xs:annotation
xs:documentationidentifica in modo univoco in un ente un'istanza di procedimento
</xs:documentation>
</xs:annotation>
<xs:restriction base="xs:string" />
</xs:simpleType>