Definizione delle interfacce di colloquio SOAP...

Progetto B2

Definizione delle interfacce di colloquio SOAP 1.1

1


DOCUMENTO: Definizione delle interfacce di colloquio SOAP 1.1. 1.0

EMISSIONE – VERIFICA – APPROVAZIONE Nome firma Emesso da: Alessio Sardaro

Verificato da:

Approvato da:

LISTA DI DISTRIBUZIONE

AGGIORNAMENTI

Versione Data Paragrafi Modificati Motivo Modifica

1.0 18/10/2005 Prima stesura.

Progetto B2


2

1.0 24/10/2005 Aggiornamento nome metodo 2,3,4.3

Indice

1. Introduzione. ..................................................................................................................................... 3 2. Definizioni busta per l’invio e la ricezione dei messaggi di protocollo............................................ 3

2.1. Invio messaggi di protocollo..................................................................................................... 4 2.2. Ricezione dei messaggi di protocollo ....................................................................................... 5

3. Definizioni busta per l’invio e la ricezione dei messaggi di comunicazione.................................... 6 3.1. Ricezione dei messaggi di comunicazione non conformi......................................................... 7 3.2. Invio messaggio di avvenuta protocollazione........................................................................... 8

4. Comunicazione esito ricezione messaggio ....................................................................................... 9 5. Appendice ....................................................................................................................................... 11

5.1. Esempio di busta di richiesta SOAP per l’invio dei messaggi di protocollo. ........................ 11 5.2. Esempio di busta di richiesta per la ricezione dei messaggi di protocollo ............................ 11 5.3. Esempio di busta di ricezione Messaggio di protocollo ......................................................... 12 5.4. DTD Segnatura informatica .................................................................................................... 13 5.5. DTD messaggi di notifica protocollo...................................................................................... 34 5.6. DTD messaggi dell’indice regionale delle AOO .................................................................... 36 5.7. DTD ACKNOWLEDGEMENT............................................................................................. 45 5.8. DTD messaggio comunicazione non conforme ...................................................................... 46 5.9. Composizione dei parametri dei messaggi di protocollo e funzionamento per l’invio Loopback............................................................................................................................................. 48

5.9.1. Segnatura.xml: ................................................................................................................ 48 5.9.2. Conferma.xml: ................................................................................................................ 49 5.9.3. Aggiornamento.xml: ....................................................................................................... 50 5.9.4. Annulamento.xml: .......................................................................................................... 51 5.9.5. Eccezione.xml:................................................................................................................ 51

6. Riferimenti ...................................................................................................................................... 52

Progetto B2


3

1. Introduzione. Il presente documento contiene la definizione delle specifiche alternative per l'utilizzo del sottosistema dedicato all’interoperabilità per lo scambio dei messaggi di protocollo fornito dal Sistema di Cooperazione Applicativa della Rete Telematica Regionale Toscana (RTRT). Le specifiche sono riferite alla modalità SOAP 1.1 per l’invio e la ricezione dei messaggi di protocollo e comunicazione. I metodi illustrati nel documento sono quindi un’alternativa a quelli gia descritti nel documento “Documento Interfacce v1.5.doc” ( vedi [11]), questi nuovi metodi permettono l’invio dei messaggi a quei linguaggi che non riescono a supportare “SOAP 1.1 with attach”.

2. Definizioni busta per l’invio e la ricezione dei messaggi di protocollo

Il seguente xml rappresenta il WSDL1 solo per le funzioni di invio e ricezione dei messaggi di protocollo relativamente allo standard SOAP 1.1. <wsdl:definitions targetNamespace="http://localhost/protocollo/services/RichiediProtocollo"> <wsdl:types> <schema targetNamespace="http://localhost/protocollo/services/RichiediProtocollo"> <import namespace="http://schemas.xmlsoap.org/soap/encoding/"/> <complexType name="ArrayOf_xsd_string"> <complexContent> <restriction base="soapenc:Array"> <attribute ref="soapenc:arrayType" wsdl:arrayType="xsd:string[]"/> </restriction> </complexContent> </complexType> </schema> </wsdl:types> <wsdl:message name="putMessaggioNewResponse"> <wsdl:part name="putMessaggioNewReturn" type="xsd:string"/> </wsdl:message> <wsdl:message name="putMessaggioNewRequest"> <wsdl:part name="nomeSIL" type="xsd:string"/> <wsdl:part name="nomeEvento" type="xsd:string"/> <wsdl:part name="idMessaggio" type="xsd:string"/> <wsdl:part name="base64" type="impl:ArrayOf_xsd_string"/> <wsdl:part name="contentType" type="impl:ArrayOf_xsd_string"/> <wsdl:part name="name" type="impl:ArrayOf_xsd_string"/> </wsdl:message> <wsdl:message name="getMessaggioNewRequest"> <wsdl:part name="nomeSIL" type="xsd:string"/> <wsdl:part name="nomeEvento" type="xsd:string"/> <wsdl:part name="type" type="xsd:string"/> </wsdl:message>

1 Il WSDL presente sul proxy avrà anche gli altri metodi getMessaggio e putMessaggio relativi al SOAP with attach , quindi si può distinguere dagli altri in base ai parametri passati descritti in seguito.

Progetto B2


4

<wsdl:message name="getMessaggioNewResponse"> <wsdl:part name="getMessaggioNewReturn" type="impl:ArrayOf_xsd_string"/> </wsdl:message> <wsdl:portType name="WSRichiediMSGProtocollo"> <wsdl:operation name="getMessaggioNew" parameterOrder="nomeSIL nomeEvento type"> <wsdl:input message="impl:getMessaggioNewRequest" name="getMessaggioNewRequest"/> <wsdl:output message="impl:getMessaggioNewResponse" name="getMessaggioNewResponse"/> </wsdl:operation> <wsdl:operation name="putMessaggioNew" parameterOrder="nomeSIL nomeEvento idMessaggio base64 contentType name"> <wsdl:input message="impl:putMessaggioNewRequest" name="putMessaggioNewRequest"/> <wsdl:output message="impl:putMessaggioNewResponse" name="putMessaggioNewResponse"/> </wsdl:operation> </wsdl:portType> <wsdl:binding name="RichiediProtocolloSoapBinding" type="impl:WSRichiediMSGProtocollo"> <wsdlsoap:binding style="rpc" transport="http://schemas.xmlsoap.org/soap/http"/> <wsdl:operation name="getMessaggioNew"> <wsdlsoap:operation soapAction=""/> <wsdl:input name="getMessaggioNewRequest"> <wsdlsoap:body encodingStyle="http://schemas.xmlsoap.org/soap/encoding/" namespace="http://ricezione.webservices.interfacce.sil.protocollo.italdata.it" use="encoded"/> </wsdl:input> <wsdl:output name="getMessaggioNewResponse"> <wsdlsoap:body encodingStyle="http://schemas.xmlsoap.org/soap/encoding/" namespace="http://localhost/protocollo/services/RichiediProtocollo" use="encoded"/> </wsdl:output> </wsdl:operation> <wsdl:operation name="putMessaggioNew"> <wsdlsoap:operation soapAction=""/> <wsdl:input name="putMessaggioNewRequest"> <wsdlsoap:body encodingStyle="http://schemas.xmlsoap.org/soap/encoding/" namespace="http://ricezione.webservices.interfacce.sil.protocollo.italdata.it" use="encoded"/> </wsdl:input> <wsdl:output name="putMessaggioNewResponse"> <wsdlsoap:body encodingStyle="http://schemas.xmlsoap.org/soap/encoding/" namespace="http://localhost/protocollo/services/RichiediProtocollo" use="encoded"/> </wsdl:output> </wsdl:operation> </wsdl:binding> <wsdl:service name="WSRichiediMSGProtocolloService"> <wsdl:port binding="impl:RichiediProtocolloSoapBinding" name="RichiediProtocollo"> <wsdlsoap:address location="http://localhost/protocollo/services/RichiediProtocollo"/> </wsdl:port> </wsdl:service> </wsdl:definitions>

2.1. Invio messaggi di protocollo

Il SIL potrà inviare un messaggio di protocollo interrogando un apposito webservice attestato sul Proxy Applicativo. Ogni SIL evoluto dovrà quindi implementare un client SOAP in grado di comporre ed inviare un messaggio di protocollo nel formato di busta SOAP vedi esempio appendice 4.1. Per la composizione della busta il client si potrà anche avvalere della elaborazione della descrizione WSDL presente sul Proxy Applicativo all’indirizzo:

http://<NAL>/protocollo/services/RichiediProtocollo?wsdl

Progetto B2


5

invocando semplicemente il seguente metodo relativo all’invio dei messaggi: String putMessaggioNew(String nomeSIL,String nomeEvento,String idMessaggio,String base64[],String contentType[],String name[]) Il client, quindi, invia la busta SOAP, comprensiva dei parametri necessari per l’interrogazione del webservice sul Proxy Applicativo. I parametri sono descritti di seguito:

1. nomeSIL -> Il nome SIL assegnato dalla regione .(es.:10) 2. nomeEvento -> Il nome dell’ evento=Protocollo, 3. idMessaggio -> l’id del messaggio vedi appendice 4.9 4. base64[] -> Un array di stringhe base64 che sono la codifica relativa agli attach inviati, ogni

stringa a posizione i 5. contentType[] -> Un array di stringhe contentType che deve contenere tipo di contenuto

dell’attach nella posizione i dell’array base64 6. name[] -> Un array dei nomi che contengono nella posizione il nome dell’array codificato in

base64 nella posizione medesima. Es.: La posizione nell’array base64 indica che le altre caratteristiche dell’attach si possono trovare negli altri array nella stessa posizione, quindi un array è caratterizzato dalla seguente terna di valori. Base64[1]=” LjAiIGVuY28=…………………………………..” contenType[1]=”application/pdf” name[1]=”doc.pdf” La risposta del webservice, attestato sul Proxy Applicativo, è una ulteriore busta che come risposta ha una stringa contenente un xml relativo al DTD in appendice 4.7. I file xml da inviare al primo posto nelle stringhe di attach sono specificati nel DTD in appendice (vedi 4.4)

2.2. Ricezione dei messaggi di protocollo

Il SIL potrà ricevere un messaggio di protocollo interrogando un apposito webservice attestato sul Proxy Applicativo. Ogni SIL evoluto dovrà quindi implementare un client SOAP in grado di comporre ed inviare un messaggio nel formato di busta SOAP, nella cui body part saranno contenuti i parametri necessari (nome SIL , nome evento, type per il momento solo base64) a ricevere i messaggi di protocollo relativi al singolo SIL . Il messaggio di protocollo si compone un array di stringhe che a tre a tre contengono i seguenti contenuti:

1) Posizione i codifica base 64 dell’attach 2) Posizione i+1 content/type dell’attach 3) Posizione i+2 nome dell’attach

Progetto B2


6

I primi tre conterranno sempre il file xml.

http://<NAL>/protocollo/services/RichiediProtocollo?wsdl invocando semplicemente il metodo relativo alla ricezione dei messaggi

String[] getMessaggioNew(String nomeSIL,String nomeEvento,String type) Il client, quindi, invia la busta SOAP, ed a seguito della richiesta, il Proxy Applicativo restituirà il messaggio, vedi esempio Al termine della comunicazione, il client del SIL comunicherà al Proxy Applicativo l’esito, sia nel caso positivo che negativo interrogando il webservice dedicato all’ack riportato qui sotto (vedi capitolo 4):

http://<NAL>/protocollo/services/InvioACK?wsdl

3. Definizioni busta per l’invio e la ricezione dei messaggi di comunicazione

Il seguente xml rappresenta il WSDL per l’invio e la ricezione dei messaggi di protocollo relativamente allo standard SOAP 1.1, , che sono da usare in alternativa esclusiva rispetto alle omonime che funzionano con “SOAP with Attach”. . <wsdl:definitions targetNamespace="http://localhost/protocollo/services/RichiediComunicazione"> <wsdl:types> <schema targetNamespace="http://localhost/protocollo/services/RichiediComunicazione"> <import namespace="http://schemas.xmlsoap.org/soap/encoding/"/> <complexType name="ArrayOf_xsd_string"> <complexContent> <restriction base="soapenc:Array"> <attribute ref="soapenc:arrayType" wsdl:arrayType="xsd:string[]"/> </restriction> </complexContent> </complexType> </schema> </wsdl:types> <wsdl:message name="getMessaggioNewResponse"> <wsdl:part name="getMessaggioNewReturn" type="impl:ArrayOf_xsd_string"/> </wsdl:message> <wsdl:message name="getMessaggioNewRequest"> <wsdl:part name="nomeSIL" type="xsd:string"/> <wsdl:part name="nomeEvento" type="xsd:string"/> <wsdl:part name="type" type="xsd:string"/> </wsdl:message> <wsdl:message name="putMessaggioNewResponse"> <wsdl:part name="putMessaggioNewReturn" type="xsd:string"/> </wsdl:message> <wsdl:message name="putMessaggioNewRequest"> <wsdl:part name="nomeSIL" type="xsd:string"/> <wsdl:part name="nomeEvento" type="xsd:string"/> <wsdl:part name="idMessaggio" type="xsd:string"/>

Progetto B2


7

<wsdl:part name="base64" type="impl:ArrayOf_xsd_string"/> <wsdl:part name="contentType" type="impl:ArrayOf_xsd_string"/> <wsdl:part name="name" type="impl:ArrayOf_xsd_string"/> </wsdl:message> <wsdl:portType name="WSRichiediMSGComunicazione"> <wsdl:operation name="putMessaggioNew" parameterOrder="nomeSIL nomeEvento idMessaggio base64 contentType name"> <wsdl:input message="impl:putMessaggioNewRequest" name="putMessaggioNewRequest"/> <wsdl:output message="impl:putMessaggioNewResponse" name="putMessaggioNewResponse"/> </wsdl:operation> <wsdl:operation name="getMessaggioNew" parameterOrder="nomeSIL nomeEvento type"> <wsdl:input message="impl:getMessaggioNewRequest" name="getMessaggioNewRequest"/> <wsdl:output message="impl:getMessaggioNewResponse" name="getMessaggioNewResponse"/> </wsdl:operation> </wsdl:portType> <wsdl:binding name="RichiediComunicazioneSoapBinding" type="impl:WSRichiediMSGComunicazione"> <wsdlsoap:binding style="rpc" transport="http://schemas.xmlsoap.org/soap/http"/> <wsdl:operation name="putMessaggioNew"> <wsdlsoap:operation soapAction=""/> <wsdl:input name="putMessaggioNewRequest"> <wsdlsoap:body encodingStyle="http://schemas.xmlsoap.org/soap/encoding/" namespace="http://ricezione.webservices.interfacce.sil.protocollo.italdata.it" use="encoded"/> </wsdl:input> <wsdl:output name="putMessaggioNewResponse"> <wsdlsoap:body encodingStyle="http://schemas.xmlsoap.org/soap/encoding/" namespace="http://localhost/protocollo/services/RichiediComunicazione" use="encoded"/> </wsdl:output> </wsdl:operation> <wsdl:operation name="getMessaggioNew"> <wsdlsoap:operation soapAction=""/> <wsdl:input name="getMessaggioNewRequest"> <wsdlsoap:body encodingStyle="http://schemas.xmlsoap.org/soap/encoding/" namespace="http://ricezione.webservices.interfacce.sil.protocollo.italdata.it" use="encoded"/> </wsdl:input> <wsdl:output name="getMessaggioNewResponse"> <wsdlsoap:body encodingStyle="http://schemas.xmlsoap.org/soap/encoding/" namespace="http://localhost/protocollo/services/RichiediComunicazione" use="encoded"/> </wsdl:output> </wsdl:operation> </wsdl:binding> <wsdl:service name="WSRichiediMSGComunicazioneService"> <wsdl:port binding="impl:RichiediComunicazioneSoapBinding" name="RichiediComunicazione"> <wsdlsoap:address location="http://localhost/protocollo/services/RichiediComunicazione"/> </wsdl:port> </wsdl:service> </wsdl:definitions>

3.1. Ricezione dei messaggi di comunicazione non conformi

Il SIL potrà ricevere un messaggio di comunicazione non conforme interrogando un apposito webservice attestato sul Proxy Applicativo. Ogni SIL evoluto dovrà quindi implementare un client SOAP in grado di comporre ed inviare un messaggio nel formato di busta SOAP, nella cui body part saranno contenuti i parametri necessari (nome SIL , nome evento, type per il momento solo base64) a ricevere i messaggi di protocollo relativi al singolo SIL . Il messaggio di protocollo si compone un array di stringhe che a tre a tre contengono i seguenti contenuti:

Progetto B2


8

1) Posizione i ->codifica base 64 dell’attach 2) Posizione i+1 ->content/type dell’attach 3) Posizione i+2 -> nome dell’attach

I primi tre conterranno sempre il file xml, i secondi tre un attach in formato eml.

Per la composizione della busta, il client si potrà anche avvalere della elaborazione della descrizione WSDL presente sul Proxy Applicativo all’indirizzo:

http://<NAL>/protocollo/services/RichiediComunicazione?wsdl

invocando semplicemente il metodo relativo alla ricezione dei messaggi . String[] getMessaggioNew(String nomeSIL,String nomeEvento,String type)

Il client, quindi, invia la busta SOAP, ed a seguito della richiesta, il Proxy Applicativo restituirà il messaggio contenente un array di stringhe descritto in precedenza.

Al termine della ricezione del messaggio, il client del SIL comunicherà al Proxy Applicativo l’esito, sia nel caso positivo che negativo (ad esempio per interruzione sul canale di comunicazione), per mezzo di un acknowledgement. Il SIL evoluto dovrà quindi implementare un ulteriore client SOAP in grado comporre ed inviare il messaggio di acknowledgement nel formato di busta SOAP, nella cui body part sono contenuti i parametri (nome SIL, nomeevento, ack=si/no, descrizione eventuale errore) necessari a comunicare al proxy applicativo l’esito della comunicazione. Per la composizione della busta il client si potrà anche avvalere della elaborazione della descrizione WSDL presente sul Proxy Applicativo all’indirizzo:


invocando semplicemente il metodo relativo alla comunicazione dell’esito della comunicazione (vedi capitolo 4).

In mancanza della ricezione dell’acknowledgement il Proxy Applicativo renderà disponibile al SIL il messaggio che non ha ricevuto correttamente per un numero N di volte, configurabile a livello di singolo SIL.

3.2. Invio messaggio di avvenuta protocollazione

Se previsto, al termine della ricezione di un messaggio di comunicazione non conforme ed a protocollazione avvenuta, il client del SIL comunicherà al Proxy Applicativo la avvenuta protocollazione. Il SIL evoluto dovrà quindi implementare un client SOAP in grado comporre ed inviare il messaggio di avvenuta protocollazione con i parametri descritti nel paragrafo 2.1 (Invio messaggi di protocollo) con l’accortezza di sostituire il nome evento con quello di Comunicazione . e

Progetto B2


9

nell’array di stringhe base64 dovrà codificare un file xml di conferma di ricezione avente nome Conferma.xml., tale file contiene il documento strutturato nel modo indicato di seguito: <?xml version="1.0" encoding="UTF-8"?> <ConfermaRicezione> <Identificatore> <CodiceAmministrazione>…………</CodiceAmministrazione> <CodiceAOO>……….…</CodiceAOO> <NumeroRegistrazione>……………</NumeroRegistrazione> <DataRegistrazione>………………</DataRegistrazione> </Identificatore> <MessaggioRicevuto> <Identificatore> <CodiceAmministrazione>COMUNICAZIONE</CodiceAmministrazione> <CodiceAOO>COMUNICAZIONE</CodiceAOO> <NumeroRegistrazione>……</NumeroRegistrazione> <DataRegistrazione>……</DataRegistrazione> </Identificatore> </MessaggioRicevuto> </ConfermaRicezione>

In particolare, nella sezione <MessaggioRicevuto> verranno riportate le informazioni relative al mittente del messaggio che è stato protocollato che, essendo un soggetto non pubblico accreditato, non sarà legato ad alcuna AOO o amministrazione. Il SIL dovrà, quindi, valorizzare i tag relativi a CodiceAmministrazione e CodiceAOO con il testo “COMUNICAZIONE”, ed inserire le informazioni relative a NumeroRegistrazione (che valorizzerà con il MessageID) e DataRegistrazione di cui dispone (perchè presenti nel messaggio originario ricevuto). Per la composizione della busta SOAP il client del SIL si potrà anche avvalere della elaborazione della descrizione WSDL presente sul Proxy Applicativo all’indirizzo:

http://<NAL>/protocollo/services/RichiediComunicazione?wsdl invocando semplicemente il metodo relativo all’invio dei messaggi. String putMessaggioNew(String nomeSIL,String nomeEvento,String idMessaggio,String base64[],String contentType[],String[] name)

4. Comunicazione esito ricezione messaggio Al termine della ricezione dei messaggi, il client del SIL comunicherà al Proxy Applicativo l’esito, sia nel caso positivo che negativo (ad esempio per interruzione sul canale di comunicazione), per mezzo di un acknowledgement. Il SIL evoluto dovrà quindi implementare un ulteriore client SOAP in grado di comporre ed inviare il messaggio di acknowledgement nel formato di busta SOAP, nella cui body part sono contenuti i parametri (nome SIL, nomeevento, ack=si/no, descrizione eventuale errore) necessari

Progetto B2


10

a comunicare al proxy applicativo l’esito della comunicazione. Per la composizione della busta il client si potrà anche avvalere della elaborazione della descrizione WSDL presente sul Proxy Applicativo all’indirizzo:


invocando semplicemente il metodo relativo alla comunicazione dell’esito della comunicazione. In mancanza della ricezione dell’acknowledgement il Proxy Applicativo renderà disponibile al SIL il messaggio che non ha ricevuto correttamente per un numero N di volte, configurabile a livello di singolo SIL. Il risultato sarà sempre un array di stringhe formattate secondo il seguente elenco

1) Posizione i ->codifica base 64 dell’attach 2) Posizione i+1 ->content/type dell’attach 3) Posizione i+2 -> nome dell’attach

Contenente l’ack.xml che descrive l’esito.

Progetto B2


11

Appendice Non tutti gli schemi dei DTD riportati a seguire sono esplosi fino all’ultimo livello. Per il dettaglio completo fare comunque riferimento alla definizione del DTD. Tutti i campi data definiti nei seguenti DTD, sono da intendersi in formato ISO 8601 esteso (i.e. aaaa-mm-gg), mentre i campi ora devono essere in formato ISO 8601 esteso (i.e. hh:mm:ss[,ddd] - ad esempio 16:09:19,710; si noti che l'indicazione dei millisecondi è opzionale).

4.1. Esempio di busta di richiesta SOAP per l’invio dei messaggi di protocollo. <SOAP-ENV:Envelope xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/" xmlns:SOAP-ENC="http://schemas.xmlsoap.org/soap/encoding/" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:m0="http://schemas.xmlsoap.org/soap/encoding/"> <SOAP-ENV:Body> <m:putMessaggioNew xmlns:m="http://ricezione.webservices.interfacce.sil.protocollo.italdata.it" SOAP-ENV:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"> <nomeSIL xsi:type="xsd:string">10</nomeSIL> <nomeEvento xsi:type="xsd:string">Protocollo</nomeEvento> <idMessaggio xsi:type="xsd:string"> AMM01**AOO.10**125**2004-08-10</idMessaggio> <base64 xsi:type="SOAP-ENC:Array" SOAP-ENC:arrayType="xsd:string[3]"> <m0:item0 xsi:type="xsd:string"></m0:item0> <m0:item1 xsi:type="xsd:string"></m0:item1> <m0:item2 xsi:type="xsd:string"></m0:item2> </base64> <contentType xsi:type="SOAP-ENC:Array" SOAP-ENC:arrayType="xsd:string[3]"> <m0:item0 xsi:type="xsd:string">text/xml</m0:item0> <m0:item1 xsi:type="xsd:string">application/pdf</m0:item1> <m0:item2 xsi:type="xsd:string">application/zip</m0:item2> </contentType> <name xsi:type="SOAP-ENC:Array" SOAP-ENC:arrayType="xsd:string[3]"> <m0:item0 xsi:type="xsd:string">Segnatura.xml</m0:item0> <m0:item1 xsi:type="xsd:string">Documento.pdf</m0:item1> <m0:item2 xsi:type="xsd:string">Attach.zip</m0:item2> </name> </m:putMessaggioNew> </SOAP-ENV:Body> </SOAP-ENV:Envelope>

4.2. Esempio di busta di richiesta per la ricezione dei messaggi di protocollo <SOAP-ENV:Envelope xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/" xmlns:SOAP-ENC="http://schemas.xmlsoap.org/soap/encoding/" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema"> <SOAP-ENV:Body> <m:getMessaggioNew xmlns:m="http://ricezione.webservices.interfacce.sil.protocollo.italdata.it" SOAP-ENV:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"> <nomeSIL xsi:type="xsd:string">10</nomeSIL> <nomeEvento xsi:type="xsd:string">Protocollo</nomeEvento> <type xsi:type="xsd:string">base64</type> </m:getMessaggioNew> </SOAP-ENV:Body> </SOAP-ENV:Envelope>

Progetto B2


12

4.3. Esempio di busta di ricezione Messaggio di protocollo

L’esempio riporta una busta SOAP di risposta contenente una “Segnatura.xml”codificata base64 e un attach “prova.zip” come si può evincere dall’ xml relativo. <?xml version="1.0" encoding="UTF-8"?> <soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"> <soapenv:Body> <ns1:getMessaggioNewResponse soapenv:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/" xmlns:ns1="http://ricezione.webservices.interfacce.sil.protocollo.italdata.it"> <ns1:getMessaggioNewReturn xsi:type="soapenc:Array" soapenc:arrayType="xsd:string[6]" xmlns:soapenc="http://schemas.xmlsoap.org/soap/encoding/"> <item> PD94bWwgdmU= cnNpb249IjE= LjAiIGVuY28= ZGluZz0iSVM= Ty04ODU5LTE= Ij8+DQo8U2U= Z25hdHVyYSA= eG1sbnM6eHM= aT0iaHR0cDo= Ly93d3cudzM= Lm9yZy8yMDA= MS9YTUxTY2g= ZW1hLWluc3Q= YW5jZSIgeHM= aTpub05hbWU= c3BhY2VTY2g= ZW1hTG9jYXQ= aW9uPSIvcHI= b3ZhL1NlZ24= YXR1cmEueHM= Z..................... </item> <item> text/xml </item> <item> Segnatura.xml</item> <item> UEsDBAoAAAA= AACuWloxlok= nKYmAAAAJgA= AAAJAAAAdGU= c3RvLnhtbEM= aWFvIHNvbm8= IGwndXRlbnQ= ZSEhIQ0KDQo= YWxsYSBwcm8= c3NpbWFQSwE= AhQACgAAAAA= AK5aWjGWiZw= piYAAAAmAAA= AAkAAAAAAAA= AAEAIAC2gQA= AAAAdGVzdG8= LnhtbFBLBQY= AAAAAAEAAQA= NwAAAE0AAAA= AAAAAE0AAAA= </item> <item> application/pdf </item> <item>doc.pdf </item> </ns1:getMessaggioNewReturn> </ns1:getMessaggioNewResponse>

Progetto B2


13

</soapenv:Body> </soapenv:Envelope>

4.4. DTD Segnatura informatica

Figura 1 – Schema del DTD Segnatura – AggiornamentoConferma

Progetto B2


14

Figura 2 – Schema del DTD Segnatura - AnullamentoProtocollazione

Figura 3 – Schema del DTD Segnatura - NotificaEccezione

Progetto B2


15

Figura 4 – Schema del DTD Segnatura - ConfermaRicezione

Progetto B2


16

Figura 5 – Schema del DTD Segnatura – Segnatura

Progetto B2


17

<?xml version="1.0" encoding="ISO-8859-1"?>   <!ENTITY % dataPubblicazione "2001-05-07">   <!ELEMENT Segnatura (Intestazione, Riferimenti?, Descrizione)> <!ATTLIST Segnatura

Progetto B2


18

versione NMTOKEN #FIXED "%dataPubblicazione;" xml:lang NMTOKEN #FIXED "it" >  <!ELEMENT Intestazione (Identificatore, PrimaRegistrazione?, OraRegistrazione?, Origine, Destinazione+, PerConoscenza*, Risposta?, Riservato?, InterventoOperatore?, RiferimentoDocumentiCartacei?, RiferimentiTelematici?, Oggetto, Classifica*, Note?)>  <!ELEMENT Identificatore (CodiceAmministrazione, CodiceAOO, NumeroRegistrazione, DataRegistrazione)> <!ELEMENT CodiceAmministrazione (#PCDATA)> <!ELEMENT CodiceAOO (#PCDATA)> <!ELEMENT NumeroRegistrazione (#PCDATA)>

Progetto B2


19

<!ELEMENT DataRegistrazione (#PCDATA)>  <!ELEMENT PrimaRegistrazione (Identificatore)>  <!ELEMENT OraRegistrazione (#PCDATA)> <!ATTLIST OraRegistrazione tempo (locale | rupa | NMTOKEN) "locale" >  <!ELEMENT Origine (IndirizzoTelematico, Mittente)> <!-- *************************** Destinazione ******************************** * * * Ciascun elemento Destinazione contiene i dati telematici ed * * amministrativi di un singolo destinatario del Messaggio Protocollato. * * * * L'attributo confermaRicezione indica la richiesta di invio di una * * Conferma di Ricezione da parte del destinatario. * * * * Regole di corrispondenza * * - se la Destinazione del Messaggio Protocollato e` una pubblica *

Progetto B2


20

* amministrazione l'IndirizzoTelematico indicato deve corrispondere * * a quello della casella istituzionale della AOO destinataria, ai * * sensi dell'art. 15 comma 3 del d.P.C.M. 31/10/00. * * * ************************************************************************* --> <!ELEMENT Destinazione (IndirizzoTelematico, Destinatario*)> <!ATTLIST Destinazione confermaRicezione (si | no) "no" >  <!ELEMENT PerConoscenza (IndirizzoTelematico, Destinatario*)> <!ATTLIST PerConoscenza confermaRicezione (si | no) "no" >  <!ELEMENT Risposta (IndirizzoTelematico)> <!-- *************************** IndirizzoTelematico ************************* * * * Un IndirizzoTelematico contiene un indirizzo, ad esempio di posta * * elettronica, utilizzato per la trasmissione telematica. * * * * L'attributo tipo di indirizzo telematico specificato. * * Il token "smtp" indica un indirizzo SMTP, il token "uri" indica la * * specifica di un indirizzo telematico tramite la sintassi delle URI. * * Il formato libero (NMTOKEN) e` da utilizzarsi per l'indicazione di * * tipo di sistemi di messaging diversi da quelli utilizzati su internet *

Progetto B2


21

* (e.g. sistemi proprietari). * * * * Regole aggiuntive * * - il contenuto dell'elemento IndirizzoTelematico di tipo "smtp" * * deve essere sintatticamente conforme a quanto previsto dalla * * specifica pubblica RFC 822; * * - il contenuto dell'elemento IndirizzoTelematico di tipo "uri" * * deve essere sintatticamente conforme a quanto previsto dalla * * specifica pubblica RFC 1738. * * * * Regole di corrispondenza * * - non e` ammesso l'uso del tipo "uri" per l'indicazione di un * * indirizzo SMTP (i.e. tramite una URI "mailto:"); * * - qualunque sia il tipo di protocollo di trasporto telematico * * adottato, la specifica di un IndirizzoTelematico deve essere * * completa e non ambigua. * * * ************************************************************************* --> <!ELEMENT IndirizzoTelematico (#PCDATA)> <!ATTLIST IndirizzoTelematico tipo (smtp | uri | NMTOKEN) "smtp" note CDATA #IMPLIED >  <!ELEMENT InterventoOperatore (#PCDATA)>  <!ELEMENT Riservato (#PCDATA)>  <!ELEMENT RiferimentoDocumentiCartacei EMPTY> <!-- *************************** RiferimentiTelematici *********************** * * * L'elemento RiferimentiTelematici e` indice della presenza nel *

Progetto B2


22

* Messaggio Protocollato di riferimenti esterni a Documenti Informatici * * dislocati in una posizione remota (e.g. repositorio condiviso). * * * * La collocazione effettiva dei Documenti Informatici e` indicata * * all'interno dell'elemento Documento. * * * ************************************************************************* --> <!ELEMENT RiferimentiTelematici EMPTY>  <!ELEMENT Oggetto (#PCDATA)>  <!ELEMENT Classifica (CodiceAmministrazione?, CodiceAOO?, Denominazione?, Livello+)> <!ELEMENT Denominazione (#PCDATA)> <!ELEMENT Livello (#PCDATA)> <!ATTLIST Livello nome CDATA #IMPLIED >  <!ELEMENT Identificativo (#PCDATA)>

Progetto B2


23

 <!ELEMENT Note (#PCDATA)>  <!ELEMENT Mittente (Amministrazione, AOO)> <!-- *************************** Destinatario ******************************** * * * L'elemento Destinatario descrive un destinatario del Messaggio * * Protocollato. * * * * Regole aggiuntive * * - la descrizione del Destinatario deve includere come minimo la * * Denominazione della Amministrazione oppure una Denominazione * * generica oppure il riferimento ad una Persona fisica. * * * * Regole di corrispondenza * * - qualora specificata, la Denominazione della AOO destinataria deve * * corrispondere all'IndirizzoTelematico della casella istituzionale * * indicata nel Mittente. * * * * Si noti che la specifica del Destinatario e` opzionale e pertanto * * l'inserimento di un simile elemento privo di informazioni * * significative e` inutile. * * *

Progetto B2


24

************************************************************************* --> <!ELEMENT Destinatario (((Amministrazione, AOO?) | (Denominazione, Persona*) | Persona+), IndirizzoTelematico?, Telefono*, Fax*, IndirizzoPostale?)>  <!ELEMENT Amministrazione (Denominazione, CodiceAmministrazione?, (UnitaOrganizzativa | ((Ruolo | Persona)*, IndirizzoPostale, IndirizzoTelematico*, Telefono*, Fax*)))>  <!ELEMENT UnitaOrganizzativa (Denominazione, Identificativo?, (UnitaOrganizzativa | ((Ruolo | Persona)*, IndirizzoPostale, IndirizzoTelematico*, Telefono*, Fax*)))> <!ATTLIST UnitaOrganizzativa tipo (permanente | temporanea) "permanente" >  <!ELEMENT AOO (Denominazione, CodiceAOO?)> <!-- *************************** Ruolo *************************************** * * * Un elemento Ruolo contiene la specifica del ruolo ricoperto da una * * persona fisica. * * * *************************************************************************

Progetto B2


25

--> <!ELEMENT Ruolo (Denominazione, Identificativo?, Persona?)>  <!ELEMENT Persona ((Denominazione | (Nome?, Cognome, Titolo?, CodiceFiscale?)), Identificativo?)> <!ATTLIST Persona id ID #IMPLIED rife IDREF #IMPLIED > <!ELEMENT Nome (#PCDATA)> <!ELEMENT Cognome (#PCDATA)> <!ELEMENT Titolo (#PCDATA)> <!ELEMENT CodiceFiscale (#PCDATA)>  <!ELEMENT IndirizzoPostale (Denominazione | (Toponimo, Civico, CAP, Comune, Provincia, Nazione?))> <!ELEMENT Toponimo (#PCDATA)> <!ATTLIST Toponimo dug CDATA #IMPLIED > <!ELEMENT Civico (#PCDATA)> <!ELEMENT CAP (#PCDATA)> <!ELEMENT Comune (#PCDATA)> <!ATTLIST Comune codiceISTAT CDATA #IMPLIED >

Progetto B2


26

<!ELEMENT Provincia (#PCDATA)> <!ELEMENT Nazione (#PCDATA)> <!ELEMENT Telefono (#PCDATA)> <!ATTLIST Telefono note CDATA #IMPLIED > <!ELEMENT Fax (#PCDATA)> <!ATTLIST Fax note CDATA #IMPLIED >  <!ELEMENT Riferimenti (Messaggio | ContestoProcedurale | Procedimento)+>  <!ELEMENT Messaggio ((Identificatore | DescrizioneMessaggio), PrimaRegistrazione?)>  <!ELEMENT DescrizioneMessaggio (#PCDATA)> <!-- *************************** ContestoProcedurale ************************* * * * Un elemento ContestoProcedurale indica un riferimento ad un * * Contesto Procedurale ovvero lo svolgimento di un generico complesso * * di attivita` amministrative in qualche modo collegate. * * * * Un Contesto procedurale e` pertanto un elemento aggregante di * * attivita` svolte all'interno di una o piu` Unita` Organizzative * * associate alla stessa AOO; le azioni svolte nell'ambito di un * * Contesto Procedurale sono finalizzate alla produzione di un *

Progetto B2


27

* risultato, finale o intermedio, che ha valore anche all'esterno * * delle Unita` Organizzative coinvolte. * * * * Regole aggiuntive * * - la DataAvvio deve essere in formato ISO 8601 esteso * * (i.e. aaaa-mm-gg - ad esempio 1963-07-15). * * * * Regole di corrispondenza * * - la forma dell'Identificativo puo` essere stabilita dalla AOO che lo * * attribuisce, tuttavia il contenuto di tale elemento deve essere * * sufficiente per l'identificazione univoca del corrispondente * * Contesto Procedurale; * * - anche il TipoContestoProcedurale puo` essere stabilito dalla AOO * * che attribuisce l'Identificativo; tuttavia non sono ammessi tipi * * che corrispondono a Procedimenti (ai sensi della l. 241/90), * * per cui si deve utilizzare un elemento Procedimento. * * * ************************************************************************* --> <!ELEMENT ContestoProcedurale (CodiceAmministrazione, CodiceAOO, Identificativo, TipoContestoProcedurale?, Oggetto?, Classifica*, DataAvvio?, Note?)> <!ATTLIST ContestoProcedurale id ID #IMPLIED rife IDREF #IMPLIED > <!ELEMENT TipoContestoProcedurale (#PCDATA)> <!ELEMENT DataAvvio (#PCDATA)>  <!ELEMENT Procedimento (CodiceAmministrazione, CodiceAOO, Identificativo, TipoProcedimento?, Oggetto?, Classifica*, Responsabile?, DataAvvio?, DataTermine?, Note?)> <!ATTLIST Procedimento id ID #IMPLIED rife IDREF #IMPLIED > <!ELEMENT TipoProcedimento (#PCDATA)> <!ELEMENT Responsabile (Persona)> <!ELEMENT DataTermine (#PCDATA)> <!-- *************************** Descrizione ********************************* * * * L'elemento opzionale Descrizione contiene la descrizione strutturata *

Progetto B2


28

* del contenuto del Messaggio Protocollato. * * * * L'elemento Documento si riferisce al Documento primario del Messaggio * * protocollato se questo viene inviato da una AOO di una amministrazione* * ad una AOO di una diversa amministrazione. In tal caso il Documento * * deve essere sottoscritto secondo le norme stabilite dal d.P.R. * * 445/2000. * * * * I Documenti primari riguardanti scambi tra AOO della stessa * * amministrazione possono essere indicati nell'elemento Documento o, * * in alternativa, nell'elemento TestoDelMessaggio. Se indicati nell' * * elemento Documento possono eventualmente essere sottoscritti secondo * * le modalità espresse nell'art. 5 della delibera AIPA 51/2000. * * * * Regole aggiuntive * * - l'elemento Descrizione deve essere presente in una Segnatura * * Informatica, in quanto permette di interpretare la struttura * * che rappresenta il Messaggio Protocollato. * * * ************************************************************************* --> <!ELEMENT Descrizione ((Documento | TestoDelMessaggio), Allegati?, Note?)> <!-- *************************** Documento************************************ * * * Un elemento Documento specifica un riferimento ad un Documento che * * costituisce parte integrante del Messaggio Protocollato. * * L'indicazione dei riferimento a Documenti rappresenta un aspetto * * cruciale per l'efficacia delle indicazioni tecniche specifiche qui * * contenute. * * * * Si possono avere tre tipi di riferimenti, definiti dal valore * * dell'attributo tipoRiferimento di Documento: * * 1) "MIME"/"DIME" * * riferimento a un Documento Informatico contenuto nella struttura * * che costituisce il messaggio; * * 2) "telematico" * * riferimento esterno a un Documento Informatico comunque * * reperibile per altra via (e.g. in un repositorio condiviso); * * 3) "cartaceo" * * riferimento esterno a un Documento Cartaceo trasmesso per via * * tradizionale (e.g. spedizione postale o tramite posta interna). * * * * Gli attributi id e nome di Documento caratterizzano dal punto vista * * tecnico il riferimento al Documento effettivo. Il significato degli * * attributi varia a seconda del tipo di riferimento. In particolare: * * * * - Per i riferimenti di tipo "MIME"/"DIME", il valore dell'attributo nome * corrisponde al valore del parametro filename dell'attributo * * Content-Disposition o, in subordine, al valore del parametro name * * dell'attributo Content-Type specificato per una body part della * * struttura. L'attributo id puo` essere utilizzato allo scopo di * * definire un identificatore univoco del riferimento nell'ambito della * * struttura XML. * * * * - Nel caso di un riferimento di tipo "telematico" l'attributo id puo` * * essere utilizzato allo scopo di definire un identificatore univoco * * del riferimento nell'ambito della struttura XML. * * * * - Nel caso di un riferimento di tipo "cartaceo" il valore * * dell'attributo id corrisponde al valore dell'identificativo del * * Documento Cartaceo e deve essere sempre specificato per i Documenti *

Progetto B2


29

* Cartacei non protocollati, che non hanno quindi un Identificatore di * * Registrazione riportato nell'elemento PrimaRegistrazione. Nel caso di * * un Documento Cartaceo privo di identificativo, l'attributo id puo` * * essere specificato al solo scopo di definire un identificatore * * univoco del riferimento nell'ambito della struttura XML. Viceversa, * * l'attributo nome non ha alcun significato e non deve quindi essere * * utilizzato. * * * * L'attributo tipoMIME va utilizzato solo per riferimenti a * Documenti Informatici. * * * * Regole aggiuntive * * - devono essere rispettate le regole sopra descritte per l'uso degli * * attributi di Documento. * * * * Regole di corrispondenza * * - devono essere rispettate le regole di corrispondenza sopra * * descritte per il significato dei valori degli attributi di * * Documento. * * * ************************************************************************* --> <!ELEMENT Documento ((CollocazioneTelematica, Impronta?)?, TitoloDocumento?, PrimaRegistrazione?, TipoDocumento?, Oggetto?, Classifica*, NumeroPagine?, Note?)> <!ATTLIST Documento id ID #IMPLIED rife IDREF #IMPLIED nome CDATA #IMPLIED tipoMIME CDATA #IMPLIED tipoRiferimento (MIME | DIME | telematico | cartaceo) "MIME" >  <!ELEMENT TitoloDocumento (#PCDATA)>  <!ELEMENT TipoDocumento (#PCDATA)>  <!ELEMENT NumeroPagine (#PCDATA)> <!-- *************************** CollocazioneTelematica, Impronta ************

Progetto B2


30

* * * Un riferimento esterno di tipo "telematico" comporta la * * specificazione di un riferimento esterno come URI, cioe` Uniform * * Resource Identifier (RFC 1738), all'interno di un elemento di tipo * * CollocazioneTelematica. Ad un riferimento esterno di questo tipo puo` * * anche essere associata un'impronta. * * * * Regole aggiuntive * * - un elemento CollocazioneTelematica ed, eventualmente, Impronta deve * * essere presente in un Documento se e solo se il valore * * dell'attributo tipoRiferimento e` "telematico". * * - il contenuto dell'elemento CollocazioneTelematica deve essere * * sintatticamente conforme a quanto previsto dalla specifica * * pubblica RFC 1738. * * * * Regole di corrispondenza * * - l'Impronta, se presente, deve corrispondere al Documento * * Informatico indicato nell'elemento CollocazioneTelematica. * * * * Si assume comunque che l'accettazione in ingresso di Messaggi * * Protocollati che contengono riferimenti esterni a Documenti * * Informatici costituisca una scelta di gestione da parte dell'AOO * * ricevente. Pertanto, tale accettazione potrebbe essere limitata ad * * alcuni mittenti istituzionali o negata del tutto. Di quest'aspetto * * deve essere contenuta indicazione nel manuale di gestione della AOO. * * * ************************************************************************* --> <!ELEMENT CollocazioneTelematica (#PCDATA)> <!ELEMENT Impronta (#PCDATA)> <!ATTLIST Impronta algoritmo CDATA #FIXED "SHA-1" codifica CDATA #FIXED "base64" >  <!ELEMENT TestoDelMessaggio EMPTY> <!ATTLIST TestoDelMessaggio id CDATA #IMPLIED tipoMIME CDATA #IMPLIED tipoRiferimento NMTOKEN #FIXED "MIME" > <!-- *************************** Allegati ************************************ * * * L'elemento opzionale Allegati contiene una lista di elementi * * Documento o Fascicolo. Lo scopo di tale lista e` quello di fornire * * una descrizione, possibilmente strutturata, dei Documenti allegati al *

Progetto B2


31

* Documento primario. * * Piu` precisamente, il contenuto dell'elemento Allegati ha due scopi: * * 1) descrivere l'elenco dei Documenti allegati; * * 2) descrivere la struttura dal punto di vista amministrativo del * * Messaggio Protocollato, in termini di organizzazione in Fascicoli * * dei Documenti inclusi. * * E` quindi anche possibile che, nella descrizione della struttura, * * si faccia riferimento piu` volte allo stesso Documento, incluso il * * Documento primario (e.g. Documenti logicamente appartenenti a piu` di * * un Fascicolo). * * * * Regole di corrispondenza * * - la citazione multipla di uno stesso Documento nella descrizione * * strutturale contenuta in Allegati deve essere resa utilizzando il * * meccanismo XML degli ID/IDREF. In altri termini, il riferimento * * effettivo al Documento deve essere specificato una sola volta e * * accompagnato dalla definizione dell'attributo id di Documento; gli * * altri riferimenti vengono specificati utilizzando l'attributo rife. * * * * Si veda in proposito anche la definizione dell'elemento Documento * * descritta precedentemente. * * * ************************************************************************* --> <!ELEMENT Allegati (Documento | Fascicolo)+>  <!ELEMENT Fascicolo (CodiceAmministrazione?, CodiceAOO?, Oggetto?, Identificativo?, Classifica*, Note?, (Documento | Fascicolo)+)> <!ATTLIST Fascicolo id ID #IMPLIED rife IDREF #IMPLIED >  <!ELEMENT ConfermaRicezione (Identificatore, MessaggioRicevuto, Riferimenti?, Descrizione?)> <!ATTLIST ConfermaRicezione versione NMTOKEN #FIXED "%dataPubblicazione;" xml:lang NMTOKEN #FIXED "it" > <!-- *************************** MessaggioRicevuto *************************** * * * L'elemento MessaggioRicevuto contiene la descrizione del messaggio *

Progetto B2


32

* ricevuto. L'identificatore corrisponde alla registrazione di * * protocollo in uscita da parte del mittente. * * * * Regole di corrispondenza * * - l'elemento DescrizioneMessaggio deve essere utilizzato solo per * * confermare la ricezione di Messaggi non protocollati. * * * ************************************************************************* --> <!ELEMENT MessaggioRicevuto ((Identificatore, PrimaRegistrazione?) | DescrizioneMessaggio)>  <!ELEMENT AggiornamentoConferma (Identificatore, MessaggioRicevuto, Riferimenti?, Descrizione?)> <!ATTLIST AggiornamentoConferma versione NMTOKEN #FIXED "%dataPubblicazione;" xml:lang NMTOKEN #FIXED "it" >  <!ELEMENT NotificaEccezione (Identificatore?, MessaggioRicevuto, Motivo)> <!ATTLIST NotificaEccezione versione NMTOKEN #FIXED "%dataPubblicazione;" xml:lang NMTOKEN #FIXED "it" > <!ELEMENT Motivo (#PCDATA)> <!-- **************************** AnnullamentoProtocollazione **************** * * * In generale, un Messaggio di Annullamento Protocollazione contiene *

Progetto B2


33

* un Documento XML avente un AnnullamentoProtocollazione come * * "ROOT ELEMENT". * * * * Un elemento AnnullamentoProtocollazione contiene l'identificatore * * della registrazione annullata e gli estremi del corrispondente * * provvedimento amministrativo. * * Per gli attributi di AnnullamentoProtocollazione valgono le stesse * * considerazioni svolte per gli attributi dell'elemento Segnatura. * * * ************************************************************************* --> <!ELEMENT AnnullamentoProtocollazione (Identificatore, Motivo, Provvedimento)> <!ATTLIST AnnullamentoProtocollazione versione NMTOKEN #FIXED "%dataPubblicazione;" xml:lang NMTOKEN #FIXED "it" > <!ELEMENT Provvedimento (#PCDATA)>

Progetto B2


34

4.5. DTD messaggi di notifica protocollo

Figura 6 – Schema del DTD Notifica Protocollo

<?xml version="1.0" encoding="UTF-8"?>         <!ELEMENT cartcert (intestazione, dati)> <!ATTLIST cartcert tipo (accettazione | non_accettazione | avvenuta_consegna | errore_di_consegna) #REQUIRED errore (nessuno | no_dest | no_conforme | AOO_errata | errore_generico) "nessuno" >  <!ELEMENT intestazione (mittente)>  <!ELEMENT mittente (#PCDATA)>  <!ELEMENT dati (idmessaggio, data, consegna*, errore-esteso?)>  <!ELEMENT idmessaggio (identificativoPA, identificativoAOO, numeroProtocollo, Anno)>  <!ELEMENT identificativoPA (#PCDATA)>

Progetto B2


35

<!ELEMENT identificativoAOO (#PCDATA)>  <!ELEMENT numeroProtocollo (#PCDATA)>  <!ELEMENT Anno (#PCDATA)>  <!ELEMENT data (giorno, ora)>  <!ELEMENT giorno (#PCDATA)>  <!ELEMENT ora (#PCDATA)>   <!ELEMENT consegna (#PCDATA)>   <!ELEMENT errore-esteso (destinatario*)>  <!ELEMENT destinatario (indirizzo, motivazione?)>  <!ELEMENT indirizzo (#PCDATA)>  <!ELEMENT motivazione (#PCDATA)>

Progetto B2


36

4.6. DTD messaggi dell’indice regionale delle AOO

Figura 7 – Schema del DTD Messaggi indice regionale delle AOO - Iscrizione AOO

Vengono riportati di seguito alcuni esempi di DTD per la validazione dei file XML utilizzati per la gestione dell’indice regionale delle AOO.

Progetto B2


37

<?xml version="1.0" encoding="UTF-8"?>   <!ELEMENT IscrizioneAOO (AOO, description, mail, nomeSIL?, webserviceVisura?, nomeResp?, cognomeResp?, mailResp?, telephonenumberResp?, dataistituzione, datasoppressione?, CAurl?, telephoneNumber?, facsimiletelephonenumber?, l?, street?, postalcode?, regione?, provincia?, codiceuff*, servizio*)>  <!ELEMENT AOO (#PCDATA)>  <!ELEMENT description (#PCDATA)>  <!ELEMENT mail (#PCDATA)>  <!ELEMENT nomeSIL (#PCDATA)>  <!ELEMENT webserviceVisura (#PCDATA)>  <!ELEMENT nomeResp (#PCDATA)>  <!ELEMENT cognomeResp (#PCDATA)>  <!ELEMENT mailResp (#PCDATA)>  <!ELEMENT telephonenumberResp (#PCDATA)>  <!ELEMENT dataistituzione (#PCDATA)>  <!ELEMENT datasoppressione (#PCDATA)>  <!ELEMENT CAurl (#PCDATA)>  <!ELEMENT telephoneNumber (#PCDATA)>  <!ELEMENT facsimiletelephonenumber (#PCDATA)>  <!ELEMENT l (#PCDATA)>  <!ELEMENT street (#PCDATA)>  <!ELEMENT postalcode (#PCDATA)>  <!ELEMENT regione (#PCDATA)>  <!ELEMENT provincia (#PCDATA)>  <!ELEMENT codiceuff (#PCDATA)>  <!ELEMENT servizio (nomes, descriziones, fruibs, servizioTelematico, mailS, telephonenumbers)>

Progetto B2


38

<!ELEMENT nomes (#PCDATA)>  <!ELEMENT descriziones (#PCDATA)>  <!ELEMENT fruibs (#PCDATA)>  <!ELEMENT servizioTelematico (#PCDATA)>  <!ELEMENT mailS (#PCDATA)>  <!ELEMENT telephonenumbers (#PCDATA)>

Progetto B2


39

Figura 8 – Schema del DTD Messaggi indice regionale delle AOO – Aggiornamento IAOO

Progetto B2


40

<?xml version="1.0" encoding="UTF-8"?>   <!ELEMENT AggiornamentoIAOO (AOO, description, mail, nomeSIL?, webserviceVisura?, nomeResp?, cognomeResp?, mailResp?, telephonenumberResp?, dataistituzione, datasoppressione?, CAurl?, telephoneNumber?, facsimiletelephonenumber?, l?, street?, postalcode?, regione?, provincia?, codiceuff*, servizio*)>  <!ELEMENT AOO (#PCDATA)>  <!ELEMENT description (#PCDATA)>  <!ELEMENT mail (#PCDATA)>  <!ELEMENT nomeSIL (#PCDATA)>  <!ELEMENT webserviceVisura (#PCDATA)>  <!ELEMENT nomeResp (#PCDATA)>  <!ELEMENT cognomeResp (#PCDATA)>  <!ELEMENT mailResp (#PCDATA)>  <!ELEMENT telephonenumberResp (#PCDATA)>  <!ELEMENT dataistituzione (#PCDATA)>  <!ELEMENT datasoppressione (#PCDATA)>  <!ELEMENT CAurl (#PCDATA)>  <!ELEMENT telephoneNumber (#PCDATA)>  <!ELEMENT facsimiletelephonenumber (#PCDATA)>  <!ELEMENT l (#PCDATA)>  <!ELEMENT street (#PCDATA)>  <!ELEMENT postalcode (#PCDATA)>  <!ELEMENT regione (#PCDATA)>  <!ELEMENT provincia (#PCDATA)>  <!ELEMENT codiceuff (#PCDATA)>

Progetto B2


41

<!ELEMENT servizio (nomes, descriziones, fruibs, servizioTelematico, mailS, telephonenumbers)>  <!ELEMENT nomes (#PCDATA)>  <!ELEMENT descriziones (#PCDATA)>  <!ELEMENT fruibs (#PCDATA)>  <!ELEMENT servizioTelematico (#PCDATA)>  <!ELEMENT mailS (#PCDATA)>  <!ELEMENT telephonenumbers (#PCDATA)>

Progetto B2


42

Figura 9 – Schema del DTD Messaggi indice regionale delle AOO - Aggiornamento IUO

Progetto B2


43

<?xml version="1.0" encoding="UTF-8"?>   <!ELEMENT AggiornamentoIUO (ou, description, dn?, aooref?, mail?, st?, CAurl?, telephoneNumber?, facsimiletelephonenumber?, l?, street?, postalcode?, regione?, provincia?, nomeResp?, cognomeResp?, mailResp?, telephonenumberResp?, servizio*)>  <!ELEMENT ou (#PCDATA)>  <!ELEMENT description (#PCDATA)>  <!ELEMENT dn (#PCDATA)>  <!ELEMENT aooref (#PCDATA)>  <!ELEMENT mail (#PCDATA)>  <!ELEMENT st (#PCDATA)>  <!ELEMENT CAurl (#PCDATA)>  <!ELEMENT telephoneNumber (#PCDATA)>  <!ELEMENT facsimiletelephonenumber (#PCDATA)>  <!ELEMENT l (#PCDATA)>  <!ELEMENT street (#PCDATA)>  <!ELEMENT postalcode (#PCDATA)>  <!ELEMENT regione (#PCDATA)>  <!ELEMENT provincia (#PCDATA)>  <!ELEMENT nomeResp (#PCDATA)>  <!ELEMENT cognomeResp (#PCDATA)>  <!ELEMENT mailResp (#PCDATA)>  <!ELEMENT telephonenumberResp (#PCDATA)>

Progetto B2


44

<!ELEMENT servizio (nomeS, descrizioneS, fruibS, servizioTelematico, mailS, telephonenumberS)>  <!ELEMENT nomeS (#PCDATA)>  <!ELEMENT descrizioneS (#PCDATA)>  <!ELEMENT fruibS (#PCDATA)>  <!ELEMENT servizioTelematico (#PCDATA)>  <!ELEMENT mailS (#PCDATA)>  <!ELEMENT telephonenumberS (#PCDATA)>

Progetto B2


45

4.7. DTD ACKNOWLEDGEMENT

Figura 10 – Schema del DTD Acknowledgement

<?xml version="1.0" encoding="UTF-8"?>  <!ELEMENT acknowledgement (codice, descrizione?)>  <!ELEMENT codice (#PCDATA)>  <!ATTLIST codice esito (SI | NO) "SI">  <!ELEMENT descrizione (#PCDATA)>

Progetto B2


46

4.8. DTD messaggio comunicazione non conforme

Figura 1 - Schema del DTD di comunicazione non conforme

<?xml version="1.0" encoding="UTF-8"?>   <!ELEMENT nonconforme (intestazione, dati)>  <!ATTLIST nonconforme tipologia (ANOMTRASP | NONPAINT | NONPAWEB) #REQUIRED>  <!ELEMENT intestazione (mittente)>  <!ELEMENT mittente (#PCDATA)>  <!ELEMENT dati (idmessaggio, data, consegna*, errore-esteso?)>

Progetto B2


47

 <!ELEMENT idmessaggio (#PCDATA)>  <!ATTLIST idmessaggio avvenutaProtocollazione (noninvio | invio) #REQUIRED>  <!ELEMENT data (giorno, ora)>  <!ELEMENT giorno (#PCDATA)>  <!ELEMENT ora (#PCDATA)>  <!ELEMENT consegna (#PCDATA)>  <!ELEMENT errore-esteso (#PCDATA)>

Progetto B2


48

4.9. Composizione dei parametri dei messaggi di protocollo e funzionamento per l’invio Loopback

Una volta composto il messaggio il sistema individuerà i destinatari in base ai dati contenuti nell’xml inviato. In questa sezione si spiega la modalità loopback dell’invio dei messaggi di protocollo che corrisponde ad una attivazione di una coda che permette di inviare a se stessi. Le modalità di loopback per la composizione dei messaggi rimane la stessa di quella operativa, l’unica differenza e di compilare gil xml con i dati relativi ai veri destinatari del messaggio di protocollo.

4.9.1. Segnatura.xml: Il giallo indica i parametri per l’ID del messaggio (AMM124**AOO.124**123**2004-06-01) che sono relativi alla AOO mittente, invece il rosso indica i dati relativi ai destinatari ,che in questo caso è la mail certificata del destinatario e il codice della AOO. Nel caso operativo i dati destinatari cambieranno in base alla AOO alla quale si vuole spedire il messaggio, mentre i dati relativi alla AOO mittente sono sempre gli stessi eccetto il numero e la data di registrazione. i parametri delle AOO mittente sono : nomeSIL=124 (codice di test) nomeEvento= Protocollo idMessaggio= AMM124**AOO.124**123**2004-06-01 (questo è l’unico parametro che cambia in base al messaggio inviato.) <?xml version="1.0" encoding="UTF-8"?> <Segnatura xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:noNamespaceSchemaLocation="/prova/Segnatura.xsd"> <Intestazione> <Identificatore> <CodiceAmministrazione>AMM124</CodiceAmministrazione> <CodiceAOO>AOO.124</CodiceAOO> <NumeroRegistrazione>123</NumeroRegistrazione> <DataRegistrazione>2004-06-01</DataRegistrazione> </Identificatore> <Origine> <IndirizzoTelematico> [email protected] </IndirizzoTelematico> <Mittente> <Amministrazione> <Denominazione>Amministrazione di prova 02</Denominazione> <Ruolo> <Denominazione>Ruolo</Denominazione> </Ruolo> <IndirizzoPostale> <Denominazione>Via delle Vigne 12 - Firenze</Denominazione> </IndirizzoPostale> </Amministrazione> <AOO> <Denominazione>Area Organizzativa Omogenea di prova 02</Denominazione> </AOO> </Mittente> </Origine> <Destinazione> <IndirizzoTelematico>[email protected]</IndirizzoTelematico> <Destinatario> <Amministrazione> <Denominazione>Amministrazione del SIL 01</Denominazione> <Ruolo> <Denominazione>Ruolo</Denominazione>

Progetto B2


49

</Ruolo> <IndirizzoPostale> <Denominazione>Via dei ghibellini, 123 - Firenze</Denominazione> </IndirizzoPostale> </Amministrazione> <AOO> <Denominazione>Area Organizzativa Omogenea 01</Denominazione> <CodiceAOO>AOO.124</CodiceAOO> </AOO> </Destinatario> </Destinazione> <Oggetto>Registrazione documento</Oggetto> </Intestazione> <Descrizione> <Documento nome="Documento2.xml"> <TitoloDocumento>Documento primario 2</TitoloDocumento> <TipoDocumento>Circolare</TipoDocumento> <Oggetto>Oggetto del documento di prova 2</Oggetto> <NumeroPagine>1</NumeroPagine> <Note>Note del documento</Note> </Documento> <Allegati> <Documento nome="Doc_Allegato1.pdf"> <TitoloDocumento>Allegato 1</TitoloDocumento> <TipoDocumento>Allegato</TipoDocumento> <Oggetto>Allegato al documento di prova 2</Oggetto> <NumeroPagine>1</NumeroPagine> <Note>Allegato al documento</Note> </Documento> <Documento nome="Doc_Allegato2.pdf"> <TitoloDocumento>Allegato 2</TitoloDocumento> <TipoDocumento>Allegato</TipoDocumento> <Oggetto>Allegato al documento di prova 2</Oggetto> <NumeroPagine>2</NumeroPagine> <Note>Allegato al documento</Note> </Documento> <Documento nome="Doc_Allegato3.pdf"> <TitoloDocumento>Allegato 3</TitoloDocumento> <TipoDocumento>Allegato</TipoDocumento> <Oggetto>Allegato al documento di prova 2</Oggetto> <NumeroPagine>3</NumeroPagine> <Note>Allegato al documento</Note> </Documento> </Allegati>

4.9.2. Conferma.xml: Il giallo indica i parametri per l’ID del messaggio (AMM124**AOO.124**125**2004-08-12 ) che sono relativi alla AOO mittente, invece il rosso indica i dati relativi al destinatario ,che in questo caso sono il codice delle AOO il codice della amministrazione, il numero di protocollo e la data del messaggio ricevuto precedentemente (es. dalla Segnatura.xml ) che hanno fatto richiesta della conferma. Nel caso operativo i dati dei destinatari cambieranno in base alla AOO alla quale si deve spedire il messaggio di conferma.

Progetto B2


50

I parametri delle AOO mittente sono : nomeSIL=124 (codice di test) nomeEvento= Protocollo idMessaggio= AMM124**AOO.124**125**2004-08-12 (questo è l’unico parametro che cambia in base al messaggio inviato.)

<?xml version="1.0" encoding="UTF-8"?> <ConfermaRicezione xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:noNamespaceSchemaLocation="/prova/Segnatura.xsd"> <Identificatore> <CodiceAmministrazione>AMM124</CodiceAmministrazione> <CodiceAOO>AOO.124</CodiceAOO> <NumeroRegistrazione>125</NumeroRegistrazione> <DataRegistrazione>2004-08-12</DataRegistrazione> </Identificatore> <MessaggioRicevuto> <Identificatore> <CodiceAmministrazione>AMM124</CodiceAmministrazione> <CodiceAOO>AOO.124</CodiceAOO> <NumeroRegistrazione>987654321</NumeroRegistrazione> <DataRegistrazione>2004-08-06</DataRegistrazione> </Identificatore> </MessaggioRicevuto> </ConfermaRicezione

4.9.3. Aggiornamento.xml: Il giallo indica i parametri per l’ID del messaggio (AMM124**AOO.124**123**2004-06-01) che sono relativi alla AOO mittente, invece il rosso indica i dati relativi al destinatario ,che in questo caso sono il codice delle AOO il codice della amministrazione , il numero di protocollo e la data del messaggio ricevuto precedentemente (es. dalla Segnatura.xml ) al quale si deve inviare l’aggiornamento. Nel caso operativo i dati dei destinatari cambieranno in base alla AOO alla quale si deve spedire il messaggio di aggiornamento. I parametri delle AOO mittente sono :

nomeSIL=124 (codice di test) nomeEvento= Protocollo idMessaggio= AMM124**AOO.124**123**2004-06-01 (questo è l’unico parametro che cambia in base al messaggio inviato.)

<?xml version="1.0" encoding="UTF-8"?> <AggiornamentoConferma xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:noNamespaceSchemaLocation="/prova/Segnatura.xsd"> <Identificatore> <CodiceAmministrazione>AMM124</CodiceAmministrazione> <CodiceAOO>AOO.124</CodiceAOO> <NumeroRegistrazione>123</NumeroRegistrazione> <DataRegistrazione>2004-06-01</DataRegistrazione> </Identificatore> <MessaggioRicevuto> <Identificatore> <CodiceAmministrazione>AMM124</CodiceAmministrazione>

Progetto B2


51

<CodiceAOO>AOO.124</CodiceAOO> <NumeroRegistrazione>122343</NumeroRegistrazione> <DataRegistrazione>2004-04-01</DataRegistrazione> </Identificatore> </MessaggioRicevuto> </AggiornamentoConferma>

4.9.4. Annulamento.xml: Il rosso indicano il destinatario ,che in questo caso sono il codice delle AOO il codice della amministrazione, il numero di protocollo e la data del messaggio ricevuto precedentemente (es. dalla Segnatura.xml ) che è stato annullato. Quindi L’id del messaggio per una particolarità del messaggio in questione coincide con i dati del destinatario: AMM124**AOO.124**125**2004-08-12 Nel caso operativo i dati dei destinatari cambieranno in base alla AOO alla quale si deve spedire il messaggio di annullamento. <?xml version="1.0" encoding="UTF-8"?> <AnnullamentoProtocollazione xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:noNamespaceSchemaLocation="/prova/Segnatura.xsd"> <Identificatore> <CodiceAmministrazione>AMM124</CodiceAmministrazione> <CodiceAOO>AOO.124</CodiceAOO> <NumeroRegistrazione>125</NumeroRegistrazione> <DataRegistrazione>2004-08-12</DataRegistrazione> </Identificatore> <Motivo>Motivo 1</Motivo> <Provvedimento>Provvedimento 1</Provvedimento> </AnnullamentoProtocollazione>

4.9.5. Eccezione.xml: Il giallo indica i parametri per l’ID del messaggio (AMM124**AOO.124**125**2004-08-10) che sono relativi alla AOO mittente, invece il rosso indica i dati relativi al destinatario ,che in questo caso sono il codice delle AOO il codice della amministrazione, il numero di protocollo e la data del messaggio ricevuto precedentemente (es. dalla Segnatura.xml) che ha subito una eccezione. Nel caso operativo i dati dei destinatari cambieranno in base alla AOO alla quale si deve spedire il messaggio di conferma. <?xml version="1.0" encoding="UTF-8"?> <NotificaEccezione xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:noNamespaceSchemaLocation="/prova/Segnatura.xsd"> <Identificatore> <CodiceAmministrazione>AMM124</CodiceAmministrazione> <CodiceAOO>AOO.124</CodiceAOO> <NumeroRegistrazione>125</NumeroRegistrazione> <DataRegistrazione>2004-08-10</DataRegistrazione>

Progetto B2


52

</Identificatore> <MessaggioRicevuto> <Identificatore> <CodiceAmministrazione>AMM124</CodiceAmministrazione> <CodiceAOO>AOO.124</CodiceAOO> <NumeroRegistrazione>7654321</NumeroRegistrazione> <DataRegistrazione>2004-02-10</DataRegistrazione> </Identificatore> </MessaggioRicevuto> <Motivo>String</Motivo> </NotificaEccezione>

5. Riferimenti ��

!��!��"��#$��%��$�� &&'��()�'�

�� (�*�+�� (,�,��'� ��$��,�,��*�+�� %��$��-$��(� '.��##$��.��

�� ,��,��%��/��!��$0��1��(�(�(,(�

,��,��%��/��(��$��$��2%$��!��3��/�4��!��$0��1�

�)�� !��$0��1��

�-��!��$0��1��5�5��#��!��"��#$��$#0��5��0%��6�,�,.��%!!��$/��5%��!��"��#$��(��

�+�� 7%��$8��$�,8��5�$��9:��

7%��$�5��5��/�4��$##��5��$4��!%00�� $��$��44$��/��#��(��

�;�� 5�$9��"��$�$999,��$��9�� ,��$��$��%��$��5��/�4��$5#�55��%#��"��#$��#��$��!�5�$��$��"��$�$��

�*�� 5/��%!!��#!��$��:<�,!!��$��/��

�"�$5��%��%�$�!��$��!��$4��$!!��$��/$��9�,�9��%��$�!��5/��%!!��:<�,!!��$��/��

�'�� !��5��/�4�(�(��5�$�$(�� "�$5��%��%�$�!��$��!��$4��$!!��$��/$��9�,�9��%��$�!��5/��%!!��:<�,!!��$��/��

Progetto B2


53

=!%00��$��5%��5��>�0?��

�&�� !��>>>(��"(��"��"��)+(�:�� Multipurpose Internet Mail Extensions

�

� �� (�(�(��'��#0��.��(�))+(!�"� �(�(�(��'��#0��.��(�))+��

� �� %#��"$��/ (+(�� %#��"$��

Definizione delle interfacce di colloquio SOAP...

Documents

Transcript of Definizione delle interfacce di colloquio SOAP...