Allegato B/1 del bando di gara Allegato B/1 del

Transcript

Allegato B/1 del bando di gara
SPECIFICHE DI
INTEROPERABILITÀ
CON IL
PROTOCOLLO INFORMATICO
1
SOMMARIO
MODALITÀ OPERATIVE .................................................................................................................3
FILE ‘SEGNATURA.XML’ - DESCRIZIONE DEI TAG ..................................................................4
FILE ‘CONFERMA.XML’ - DESCRIZIONE DEI TAG OBBLIGATORI .........................................7
FILE ‘ECCEZIONE.XML’ - DESCRIZIONE DEI TAG ...................................................................8
ALLEGATO 1 - DTD INTERNA DI RIFERIMENTO......................................................................9
NOTE COMMENTATE DELLA DTD STANDARD......................................................................13
ALLEGATO 2
SEGNATURA DEL PROTOCOLLO INFORMATICO ....................................20
ALLEGATO 3 CONFERMA PROTOCOLLAZIONE .................................................................23
ALLEGATO 4 - ECCEZIONE (Con riferimenti alla pratica) ........................................................24
ALLEGATO 5 - ECCEZIONE (Con riferimenti alla transazione)...................................................25
APPENDICE 1 .................................................................................................................................26
APPENDICE 2 - DOCUMENTAZIONE TECNICA (WSProtocollo V. 1.0) ...................................27
Protocollo di comunicazione .............................................................................................................28
Descrizione dei componenti del sistema ...........................................................................................29
Descrizione del flusso di comunicazione ..........................................................................................30
Specifiche comandi XMLRPC ..........................................................................................................31
Indirizzo del webservice....................................................................................................................34
2
INTEROPERABILITÀ TRA APPLICAZIONI
Oltre alle standard dinamiche previste dalla normativa per quanto riguarda la interoperabilità dei
protocolli delle P.A., si specifica nel seguito la modalità di interoperabilità tra applicazioni
gestionali dell'ente e il sistema di Protocollo.
Si vuole poter protocollare automaticamente pratiche che vengono anche contemporaneamente
gestite da un sistema informativo generico.
MODALITÀ OPERATIVE
L’applicazione gestionale si presenta come un ente interoperabile. Redige dopo l’inserimento della
pratica nel gestionale stesso una segnatura in formato XML con i dati nel seguito dettagliati.
Detta segnatura in formato XML viene inoltrata, al sistema di protocollo secondo le modalità della
tecnologia di comunicazione basata sugli standard denominati Web Services (nello specifico
XMLRPC, vedi capitolo 11).
Al fine di semplificare la gestione della comunicazione si intende adottare lo schema già definito
dal CNIPA relativo alla interoperabilità tra sistemi di protocollo eterogenei. In particolare si fa
riferimento ad una DTD che è descritta nell’allegato 1) del presente documento.
Il flusso è cosi’ rappresentato:
− l’ente esterno che richiede la protocollazione (ovvero la procedura applicativa informatica)
invia una segnatura XML (vedi capitolo 3)
− il programma di protocollo riceve la segnatura. Il programma di protocollo implementa di
per se’ il lato web services di competenza; provvede al parser; alla gestione delle code, etc
− il programma di protocollo provvede alla protocollazione e invia al mittente un messaggio
XML di conferma oppure un messaggio XML di eccezione. Il messaggio XML di conferma è
descritto nel capitolo 4). Il messaggio di eccezione è descritto nel capitolo 5)
− A fronte del messaggio di conferma il programma applicativo richiedente provvede ad
effettuare i propri aggiornamenti con i riferimenti di protocollo assegnati e ad esso trasmessi.
− A fronte di una eccezione si dovranno concordare le codifiche degli eventuali motivi di
eccezione che si prevede di gestire. Ciò sarà fatto in sede di completamento dell’analisi. In ogni
caso l’eccezione prevede il rinvio della segnatura con le opportune correzioni.
Il sistema di web services dovrà prevedere da parte sua ulteriori modalità di gestione della
disponibilità e della integrità e della sicurezza della comunicazione.
3
FILE ‘SEGNATURA.XML’ - DESCRIZIONE DEI TAG
Questa segnatura XML è quella inviata dal programma applicativo che intende richiedere al
programma di protocollo l’assegnazione della protocollazione. (vedi esempio in allegato 2)
TAG
CONTENUTO
Intestazione/Identificatore/CodiceAmministrazione
Codice procedura (1) vedi
appendice
Intestazione/Identificatore/CodiceAOO
AOO000
Intestazione/Identificatore/NumeroRegistrazione
Numero Identificativo della pratica
generata nell’applicativo gestionale
(CHIAVE UNIVOCA)
Intestazione/Identificatore/DataRegistrazione
Data dell’evento (data di
acquisizione della pratica) nel
formato ISO aaaa-mm-gg
Intestazione/Origine/Mittente/Amministrazione/Denominazione(P → “Mittente” Se persona fisica
ersona)
(Cognome+Nome) (*)vedi nota
Intestazione/Origine/Mittente/Amministrazione/Denominazione
+
Intestazione/Origine/Mittente/AOO/Denominazione
→“Mittente” Se persona giuridica
(*) vedi nota - ( punto 2
obbligatorio, punto 3 facoltativo)
Intestazione/Origine/Mittente/Amministrazione/UnitaOrganizzativ Eventuale indirizzo del “Mittente”,
a/IndirizzoPostale
se non disponibile i campi vanno
inizializzati con stringa vuota
Intestazione/Oggetto
Oggetto della pratica puo essere
obbligatoriamente una delle
seguenti due:
Cambio di residenza
oppure
Richiesta di iscrizione anagrafica
Intestazione/Destinazione
Attributo ‘confermaricezione
=“si”’
Intestazione/Risposta/IndirizzoTelematico
Attributo ‘ tipo=”smtp”’ nel caso di
segnatura inviata via e-mail si
specifica un indirizzo e-mail
diverso da quello che ha spedito la
segnatura.xml.
Nel nostro caso deve indicare
“tipo=uri” .
Intestazione/Risposta/IndirizzoTelematico
Deve essere inizializzato con i
riferimenti tecnici del sistema di
comunicazione a cui inviare la
risposta. Deve coincidere con
l'indirizzo indicato dal gestionale al
momento dell'invocazione del
comando (di tipo 'Web Services')
per la richiesta di un nuovo numero
4
di protocollo (vedi Appendice 2).
Intestazione/Note
Annotazioni - facoltativo
Intestazione/Riservato
S/N – S per riservato, N per non
riservato
Riferimenti/ContestoProcedurale/CodiceAmministrazione
Login operatore che deve
coincidere con un account presente
nell’organigramma del protocollo.
vedi appendice 1)
Riferimenti/ContestoProcedurale/CodiceAOO
AOO000
Riferimenti/ContestoProcedurale/Identificativo
Deve essere valorizzato con
l'indirizzo IP della postazione da
cui l'utente esegue l'operazione. E'
utilizzato per l'invio alla stampante
termica dell'etichetta di protocollo.
Eventualmente viene valorizzato
con una stringa nulla affinchè non
venga stampata alcuna etichetta.
Riferimenti/ContestoProcedurale/TipoContestoProcedurale
Se la stringa è valorizzata con
questa parola
“IndicazioneClassificazione”, si
procede con la verifica
dell’esistenza della classifica
indicata nei tre tag consecutivi
Riferimenti/ContestoProcedurale/Classifica/Livello
“Titolo” vedi appendice
“Classe” vedi appendice
“SottoClasse” vedi appendice
Descrizione/Documento
Documento rappresentate la pratica
stessa.
Se è di tipo elettronico (file) gli
attributi vanno impostati a:
tipoRiferimento= “informatico”
id=<nome completo del file
fisico>.
Nel caso il documento non sia un
file scaricabile, ma si voglia
semplicemente dichiararne la
presenza cartacea vanno impostati
gli attributi a:
tipoRiferimento= “cartaceo”
id=<stringa univoca identificante il
documeto>.
Se si vuole stampare la
corrispondente etichetta di
protocollo l'attributo
“label_copy” deve essere impostato.
5
Esso indica il numero di copie
desiderato e deve rappresentare un
intero.
Se assente si assume il valore 0 di
default e non viene stampata alcuna
etichetta.
Nel caso in cui non vi sia alcun
documento da dichiarare il tag
“Documento” va sostituito con il
tag “TestoDelMessaggio”
eventualmente inizializzato con
una stringa nulla.
Anche “TestoDelMessaggio”
possiede l'attributo facoltativo
“label_copy” per il quale valgono le
stesse indicazioni precedentemente
illustrate.
Descrizione/Documento/URI
Indirizzo dal quale è possibile
eseguire il download del
file/documento. L'attributo
“tipoRiferimento” di “Documento”
deve essere impostato a
“informatico”
Descrizione/Documento/TitoloDocumento
Descrizione logica del documento
Descrizione/Allegati
Il tag “Allegati” viene utilizzato
per specificare altri eventuali
documenti presenti oltre al
documento precedentemente
illustrato.
All'interno del tag “Allegati”
vanno posizionati tanti tag
“Documento” quanti sono gli
allegati da dichiarare.
Se non vi sono allegati presenti il
tag va omesso
Descrizione/Allegati/Documento
Vedi Descrizione/Documento
Descrizione/Allegati/Documento/URI
Vedi Descrizione/Documento/URI
Descrizione/Allegati/Documento/TitoloDocumento
Vedi
Descrizione/Documento/TitoloDoc
umento
(*) Nota:
La lettura del mittente è piu’ complessa e viene ricercata in piu’ tag, rispettivamente nell’ordine:
1 – PERSONA FISICA
Mittente/Amministrazione/Denominazione (Persona | Cognome+Nome)
(se significativo) → “Mittente”
2 - PERSONA
GIURIDICA o ENTE
Mittente/Amministrazione/Denominazione → “Mittente”
3 – PERSONA
GIURIDICA o ENTE
Mittente/AOO/Denominazione (in combinazione tra le due) → “Mittente”
6
FILE ‘CONFERMA.XML’ - DESCRIZIONE DEI TAG OBBLIGATORI
Se tutte l’operazione di registrazione ha avuto esito positivo viene generato il file Conferma.xml
contenente i dati identificativi della registrazione di protocollo assegnata e i dati identificativi del
documento ricevuto.
La ‘conferma.xml’ viene spedita all'indirizzo indicato dal gestionale al momento dell'invocazione
del comando (di tipo 'Web Services') per la richiesta di un nuovo numero di protocollo (Vedi la
sezione 11.4. relativa al Capitolo 11).
Tale indirizzo va indicato anche nella Segnaura.xml, nel tag
Segnatura/Intestazione/Risposta/IndirizzoTelematico nel quale deve essere presente l’attributo
tipo="uri" con l’indirizzo del partner. ( Ovviamente sul file segnatura.xml deve essere valorizzato
l’attributo ‘confermaricezione =“si”’ ). (vedi esempio in allegato 3)
Identificatore/CodiceAmministrazione
Codice procedura vedi appendice 1
Identificatore/CodiceAOO
Viene inizializzato ad AOO000
Identificatore/NumeroRegistrazione
Numero di protocollo assegnato
Identificatore/DataRegistrazione
Data assegnata al numero di
protocollo (formato ISO yyyy-mmdd)
MessaggioRicevuto/Identificatore
Riporta le stesse informazioni
indicate nei tag
Intestazione/Identificatore presenti
nella Segnatura.xml ricevuta.
Serve per individuare a quale
pratica ci si riferisce.
7
FILE ‘ECCEZIONE.XML’ - DESCRIZIONE DEI TAG
In alternativa alla “conferma.xml”, in tutti i casi in cui la transazione non possa concludersi
efficacemente, viene generato il file “eccezione.xml” contenente i dati identificativi del documento
ricevuto e la descrizione dell’eccezione.
Il file “eccezione.xml” conterra’ informazioni di varia natura:
• segnatura illeggibile
• segnatura non completa
• segnatura non coerente con le logiche dell’applicativo
• segnatura non conforme alla DTD
• altro
Nel caso di segnatura trasmessa correttamente, ma non conforme alla DTD o non leggibile, la
richiesta di nuovo protocollo viene rifiutata fin dal principio.
Al momento dell'invocazione del comando Web Service per la richiesta di protocollazione viene
restituito il corrispettivo codice di errore (Vedi Capitolo 11 sezione 11.4.1.3).
E' comunque possibile la generazione e l'invio del file “eccezione.xml” per dati non conformi alla
Dtd. Questo avviene nel caso in cui gli altri controlli eseguiti durante la procedura di
protocollazione non vadano a buon fine.
Possono essere generate due distinte tipologie di “eccezioni”.
I due diversi file d'eccezione si distinguono per la modalità con la quale viene individuata la pratica
di riferimento.
Se la segnatura ricevuta è conforme, (è possibile eseguire il parser), nell'eccezione vengono inseriti
i dati riportati dal tag “Intestazione/Identificatore” della segnatura stessa (Vedi Capitolo 2).
Tali dati sono identificati nell'eccezione dal tag “MessaggioRicevuto/Identificatore”.
Nell'impossibilità di eseguire una lettura della segnatura viene utilizzato il tag
“MessaggioRicevuto/DescrizioneMessaggio”.
Tale tag contiene una stringa di testo similare alla seguente:
Request Id: 3212#Request Date: 2009-03-02#Receiver Uri: http://HOST_RICEVENTE_RISPOSTA#Request Sender
IP: 172.0.0.0
Tale stringa riporta informazioni relative alla transazione, di tipo Web Services, mediante la quale è
stata inoltrata dal gestionale la richiesta di protocollazione.
“Request Id” è l'identificativo di transazione comunicato dal gestionale al protocollo.
“Request Date” riporta in formato ISO la data in cui è avvenuta la transazione di richiesta.
“Receiver Uri” identifica a quale server è stata inviata la risposta.
“Request Sender IP” identifica l'indirizzo IP dal quale è giunta la richiesta di protocollazione.
Per maggiori dettagli vedi il Capitolo 11 relativo alla transazione XMLRPC.
Esempi di eccezioni sono riportati nell'allegato 4 e 5.
8
9
ALLEGATO 1 - DTD INTERNA DI RIFERIMENTO
WSPROTOCOLLO.DTD
raggiungibile all'URL interno: http://protocollo/Segnatura/wsprotocollo.dtd
<?xml version="1.0" encoding="ISO-8859-1"?>
<!ENTITY % dataPubblicazione "2001-05-07">
<!ELEMENT Segnatura (Intestazione, Riferimenti?, Descrizione)>
<!ATTLIST Segnatura
versione CDATA #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)>
<!ELEMENT DataRegistrazione (#PCDATA)>
<!ELEMENT PrimaRegistrazione (Identificatore)>
<!ELEMENT OraRegistrazione (#PCDATA)>
<!ATTLIST OraRegistrazione
tempo (locale | rupa | NMTOKEN) "locale"
>
<!ELEMENT Origine (IndirizzoTelematico, Mittente)>
<!ELEMENT Destinazione (IndirizzoTelematico, Destinatario*)>
<!ATTLIST Destinazione
confermaRicezione (si | no) "no"
>
<!ELEMENT PerConoscenza (IndirizzoTelematico, Destinatario*)>
<!ATTLIST PerConoscenza
>
<!ELEMENT Risposta (IndirizzoTelematico)>
<!ELEMENT IndirizzoTelematico (#PCDATA)>
<!ATTLIST IndirizzoTelematico
tipo (smtp | uri | NMTOKEN) "smtp"
note CDATA #IMPLIED
>
<!ELEMENT InterventoOperatore (#PCDATA)>
<!ELEMENT Riservato (#PCDATA)>
<!ELEMENT RiferimentoDocumentiCartacei EMPTY>
<!ELEMENT RiferimentiTelematici EMPTY>
<!ELEMENT Oggetto (#PCDATA)>
10
<!ELEMENT Classifica (CodiceAmministrazione?, CodiceAOO?, Denominazione?,
Livello+)>
<!ELEMENT Denominazione (#PCDATA)>
<!ELEMENT Livello (#PCDATA)>
<!ATTLIST Livello
nome CDATA #IMPLIED
>
<!ELEMENT Identificativo (#PCDATA)>
<!ELEMENT Note (#PCDATA)>
<!ELEMENT Mittente (Amministrazione, AOO)>
<!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,
<!ATTLIST UnitaOrganizzativa
tipo (permanente | temporanea) "permanente"
>
<!ELEMENT AOO (Denominazione, CodiceAOO?)>
<!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
<!ELEMENT Provincia (#PCDATA)>
<!ELEMENT Nazione (#PCDATA)>
<!ELEMENT Telefono (#PCDATA)>
<!ATTLIST Telefono
note CDATA #IMPLIED
>
<!ELEMENT Fax (#PCDATA)>
<!ATTLIST Fax
note CDATA #IMPLIED
>
11
>
<!ELEMENT Riferimenti (Messaggio | ContestoProcedurale | Procedimento)+>
<!ELEMENT Messaggio ((Identificatore | DescrizioneMessaggio),
PrimaRegistrazione?)>
<!ELEMENT DescrizioneMessaggio (#PCDATA)>
<!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)>
<!ELEMENT Descrizione ((Documento | TestoDelMessaggio), Allegati?, Note?)>
<!ELEMENT Documento ((URI, Impronta?)?, TitoloDocumento?,
PrimaRegistrazione?, TipoDocumento?, Oggetto?, Classifica*, NumeroPagine?,
Note?)>
<!ATTLIST Documento
id ID #IMPLIED
rife IDREF #IMPLIED
nome CDATA #IMPLIED
tipoMIME CDATA #IMPLIED
tipoRiferimento (MIME | informatico | cartaceo) "MIME"
label_copy CDATA #IMPLIED >
<!ELEMENT TitoloDocumento (#PCDATA)>
<!ELEMENT TipoDocumento (#PCDATA)>
<!ELEMENT NumeroPagine (#PCDATA)>
<!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
tipoRiferimento NMTOKEN #FIXED "MIME"
label_copy CDATA #IMPLIED >
<!ELEMENT Allegati (Documento | Fascicolo)+>
12
<!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
>
<!ELEMENT MessaggioRicevuto ((Identificatore, PrimaRegistrazione?) |
DescrizioneMessaggio)>
<!ELEMENT AggiornamentoConferma (Identificatore, MessaggioRicevuto,
Riferimenti?, Descrizione?)>
<!ATTLIST AggiornamentoConferma
>
<!ELEMENT NotificaEccezione (Identificatore?, MessaggioRicevuto, Motivo)>
<!ATTLIST NotificaEccezione
>
<!ELEMENT Motivo (#PCDATA)>
<!ELEMENT AnnullamentoProtocollazione (Identificatore, Motivo,
Provvedimento)>
<!ATTLIST AnnullamentoProtocollazione
>
<!ELEMENT Provvedimento (#PCDATA)>
13
NOTE COMMENTATE DELLA DTD STANDARD
<?xml version="1.0" encoding="UTF-8"?>
<!-*
*
* Autorita` per l'Informatica nella Pubblica Amministrazione
*
* Segnatura.dtd
*
* 2000-10-18
-->
<!-* Data di pubblicazione del DTD
-->
<!ENTITY % dataPubblicazione "2000-10-18">
<!-* Root ELEMENT
*
* Il DTD prevede tre possibili "root ELEMENT":
* - Segnatura
* - ConfermaRicezione
* - Ripudio
-->
<!-* Segnatura
*
* Si compone di tre sezioni, di cui la prima obbligatoria e le altre due opzionali:
* - la sezione Intestazione contiene i dati identificativi e le informazioni
* fondamentali del messaggio;
* - la sezione Riferimenti contiene le informazioni relative al contesto generale
* di cui il messaggio fa parte;
* - la sezione Descrizione contiene le informazioni descrittve riguardanti il
* contenuto del messaggio.
-->
<!ELEMENT Segnatura (Intestazione, Riferimenti?, Descrizione?)>
<!ATTLIST Segnatura
versione NMTOKEN #FIXED "%dataPubblicazione;"
>
<!-* Intestazione
*
* La sezione Intestazione contiene:
* - l'Identificatore di protocollo attribuito dalla AOO mittente, eventualmente
* accompagnato dall'Identificatore di PrimaRegistrazione, qualora i due
* Identificatori non coincidano;
* - gli indirizzi che caratterizzano la trasmissione telematica del messaggio;
* - alcuni flag di specifica delle caratteristiche del messaggio;
* - l'inquadramento formale del messaggio in termini di oggetto e classifica.
14
<!ELEMENT Intestazione (Identificatore, PrimaRegistrazione?, OraRegistrazione?, Origine, Destinazione+,
PerConoscenza*, Risposta?, Riservato?, InterventoOperatore?, RiferimentoDocumentiCartacei?, Oggetto, Classifica*,
Note?)>
<!-* Identificatore di una registrazione di protocollo
*
* Gli elementi che identificano una registrazione di protocollo sono:
* - codice identificativo della pubblica amministrazione, come riportato nell'indice
* delle pubbliche amministrazioni (DPR 428/98)
* - codice identificativo dell'Area Organizzativa Omogenea, come riportato
* nell'indice delle pubbliche amministrazioni (DPR 428/98);
* - numero della registrazione di protocollo (sette cifre decimali, ddddddd);
* - data della registrazione, in formato ISO 8601 esteso (aaaa-mm-gg).
-->
<!ELEMENT Identificatore (CodiceAmministrazione, CodiceAOO, NumeroRegistrazione, DataRegistrazione)>
<!ELEMENT CodiceAmministrazione (#PCDATA)>
<!ELEMENT CodiceAOO (#PCDATA)>
<!ELEMENT NumeroRegistrazione (#PCDATA)>
<!ELEMENT DataRegistrazione (#PCDATA)>
<!-* Identificatore della prima registrazione di protocollo, da specificare
* solo se non coincidente con l'Identificatore
-->
<!ELEMENT PrimaRegistrazione (Identificatore)>
<!-* L'ora di registrazione, in formato ISO 8601 esteso (hh:mm:ss[,ddd])
-->
<!ELEMENT OraRegistrazione (#PCDATA)>
<!ATTLIST OraRegistrazione
tempo (locale | rupa | CDATA) "locale"
>
<!-* Gli Indirizzi che caratterizzano la trasmissione del messaggio
* in formato telematico e amministrativo
-->
<!ELEMENT Origine (IndirizzoTelematico, Mittente)>
<!ELEMENT Destinazione (IndirizzoTelematico, Destinatario*)>
<!ATTLIST Destinazione
>
<!ELEMENT PerConoscenza (IndirizzoTelematico, Destinatario*)>
<!ATTLIST PerConoscenza
>
<!-* L'elemento Risposta indica un indirizzo da utilizzarsi per le risposte
* automatiche (i.e. conferma, ripudio).
* Da specificiare sole se diverso dall'indirizzo di origine
-->
<!ELEMENT Risposta (IndirizzoTelematico)>
<!-* Indirizzo telematico, tipicamente un indirizzo smtp
* Qualunque sia il protocollo utilizzato per il trasporto, l'IndirizzoTelematico
* deve contenere informazioni sufficienti per identificare il corrispondente
* indirizzo in modo univoco.
15
<!ELEMENT IndirizzoTelematico (#PCDATA)>
<!ATTLIST IndirizzoTelematico
tipo (smtp | url | CDATA) "smtp"
note CDATA #IMPLIED
>
<!-* Flag di richiesta intervento operatore (i.e. il messaggio non puo` essere
* protocollato e/o smistato in modo automatico).
* Puo` contenere una descrizione testuale del motivo della richiesta.
-->
<!ELEMENT InterventoOperatore (#PCDATA)>
<!-* Flag di richiesta trattamento riservato.
* Puo` contenere una descrizione testuale del motivo della richiesta.
-->
<!ELEMENT Riservato (#PCDATA)>
<!-* Flag di avvertimento della presenza di riferimenti a documenti cartacei
* (il messaggio non puo` quindi essere protocollato in modo automatico).
-->
<!ELEMENT RiferimentoDocumentiCartacei EMPTY>
<!-* Oggetto del messaggio
* Si raccomanda l'uso di descrizioni significative (>= 30 caratteri)
-->
<!ELEMENT Oggetto (#PCDATA)>
<!-* La specifica strutturata di una Classifica
-->
<!ELEMENT Classifica (CodiceAmministrazione?, CodiceAOO?, Denominazione?, Livello+)>
<!ELEMENT Denominazione (#PCDATA)>
<!ELEMENT Livello (#PCDATA)>
<!ATTLIST Livello
nome CDATA #IMPLIED
>
<!-* Note testuali esplicative
-->
<!ELEMENT Note (#PCDATA)>
<!-* Mittente e Destinatario
-->
<!ELEMENT Mittente (Amministrazione, AOO)>
<!ELEMENT Destinatario (((Amministrazione, AOO?) | (Denominazione, Persona*) | Persona+),
IndirizzoTelematico?, Telefono*, Fax*, IndirizzoPostale?)>
<!-* Indirizzo amministrativo in forma estesa e strutturata.
-->
<!ELEMENT Amministrazione (Denominazione, CodiceAmministrazione?, (UnitaOrganizzativa | (Persona*,
IndirizzoPostale, IndirizzoTelematico*, Telefono*, Fax*)))?>
<!ELEMENT UnitaOrganizzativa (Denominazione, (UnitaOrganizzativa | (Persona*, IndirizzoPostale,
16
<!ATTLIST UnitaOrganizzativa
tipo (permanente | temporanea) "permanente"
>
<!-* Nome esteso e codice di identificazione dell'area organizzativa
* omogenea
-->
<!ELEMENT AOO (Denominazione, CodiceAOO?)>
<!-* Persona fisica
-->
<!ELEMENT Persona (Denominazione | ((Nome?, Cognome, Titolo?, CodiceFiscale?, Ruolo?) | Ruolo))>
<!ATTLIST Persona
id ID #IMPLIED
rife IDREF #IMPLIED
>
<!ELEMENT Nome (#PCDATA)>
<!ELEMENT Cognome (#PCDATA)>
<!ELEMENT Titolo (#PCDATA)>
<!ELEMENT CodiceFiscale (#PCDATA)>
<!ELEMENT Ruolo (#PCDATA)>
<!-* Indirizzo postale
-->
<!ELEMENT IndirizzoPostale (Denominazione | (Toponimo, Civico, CAP, Comune, Provincia))>
<!ELEMENT Toponimo (#PCDATA)>
<!ATTLIST Toponimo
dug CDATA #IMPLIED
>
<!ELEMENT Civico (#PCDATA)>
<!ELEMENT CAP (#PCDATA)>
<!ELEMENT Comune (#PCDATA)>
<!ATTLIST Comune
codiceISTAT CDATA #IMPLIED
>
<!ELEMENT Provincia (#PCDATA)>

<!ELEMENT Riferimenti (Messaggio | ContestoProcedurale | Procedimento)+>

<!ELEMENT ContestoProcedurale (CodiceAmministrazione, CodiceAOO, Identificativo, TipoContestoProcedurale?,
Oggetto?, Classifica*, DataAvvio?, Note?)>
<!ATTLIST ContestoProcedurale
id ID #IMPLIED
rife IDREF #IMPLIED
>
<!ELEMENT Identificativo (#PCDATA)>
<!ELEMENT TipoContestoProcedurale (#PCDATA)>
<!ELEMENT DataAvvio (#PCDATA)>
<!-* Un Procedimento e` un ContestoProcedurale che ha dignita` di procedimento
* amministrativoai sensi della l. 241/90
-->
<!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
*
* Ogni messaggio contiene in generale:
* - un documento primario, rappresentato dal testo del messaggio o da altro
* documento;
* - un numero qualsiasi di documenti informatici allegati.
-->
<!ELEMENT Descrizione ((Documento | TestoDelMessaggio), Allegati?, Note?)>
<!-* Riferimento ad un documento
*
* Un riferimento puo` essere di tre tipi:
* - riferimento interno ad un documento informatico incluso nel messaggio
* (i.e. in una struttura MIME);
* - riferimento esterno ad un documento informatico reperibile in modo
* automatico (all'atto della protocollazione del messaggio) oppure a documento
* cartaceo trasmesso con modalita` tradizionali;
* - riferimento esterno ad un documento cartaceo trasmesso con modalita`
* tradizionali;
-->
<!ELEMENT Documento ((URI, Impronta?)?, TitoloDocumento?, PrimaRegistrazione?, TipoDocumento?, Oggetto?,
Classifica*, NumeroPagine?, Note?)>
<!ATTLIST Documento
id ID #IMPLIED
rife IDREF #IMPLIED
nome CDATA #IMPLIED
tipoRiferimento (MIME | informatico | cartaceo) "MIME"
>
<!ELEMENT TitoloDocumento (#PCDATA)>
<!ELEMENT TipoDocumento (#PCDATA)>
18
<!ELEMENT NumeroPagine (#PCDATA)>
<!-* Impronta di un documento informatico
* (usata solo per i riferimenti esterni)
-->
<!ELEMENT URI (#PCDATA)>
<!ELEMENT Impronta (#PCDATA)>
<!ATTLIST Impronta
algoritmo CDATA #FIXED "SHA-1"
codifica CDATA #FIXED "base64"
>
<!-* Riferimento al testo del messaggio, inteso come documento
* In generale, in una struttura MIME il testo del messaggio coincide
* con una body part priva di nome.
-->
<!ELEMENT TestoDelMessaggio EMPTY>
<!ATTLIST TestoDelMessaggio
id CDATA #IMPLIED
tipoRiferimento NMTOKEN #FIXED "MIME"
>
<!-* Lista di documenti allegati, eventualmente aggregati in fascicoli
-->
<!ELEMENT Allegati ((Documento | Fascicolo)+)>
<!-* Aggregazione di documenti in un fascicolo
-->
<!ELEMENT Fascicolo (CodiceAmministrazione?, CodiceAOO?, Oggetto?, Identificativo?, Classifica*, Note?,
(Documento | Fascicolo)+)>
<!ATTLIST Fascicolo
id ID #IMPLIED
rife IDREF #IMPLIED
>
<!-* ConfermaRicezione
*
* Contiene la descrizione del messaggio di cui si conferma la avvenuta ricezione.
* L'Identificatore corrisponde alla registrazione di protocollo in ingresso da
* parte del ricevente.
-->
<!ELEMENT ConfermaRicezione (Identificatore, MessaggioRicevuto, Note?)>
<!ATTLIST ConfermaRicezione
tipoAccettazione (provvisoria | definitiva) "definitiva"
>
<!-* La descrizione del messaggio ricevuto. L'identificatore corrisponde alla registrazione
* di protocollo in uscita da parte del mittente.
* Si rammenta che una conferma di ricezione deve poter essere prodotta anche per un
* messaggio non protocollato.
-->
<!ELEMENT MessaggioRicevuto ((Identificatore, PrimaRegistrazione?) | DescrizioneMessaggio)>
<!-* Ripudio
*
* Contiene la descrizione del messaggio ripudiato. Qualora possibile, e` opportuno
* includere l'Identificatore di registrazione del messaggio ripudiato. In questo caso
* l'identificatore corrisponde alla registrazione in uscita da parte del mittente.
19
* I DatiTrasmssione devono essere utilizzati solo in caso contrario (e.g. se il messaggio
* o la Segnatura sono indecifrabili).
-->
<!ELEMENT Ripudio ((Identificatore | DescrizioneMessaggio), Motivo)>
<!ATTLIST Ripudio
>
<!ELEMENT Motivo (#PCDATA)>
20
ALLEGATO 2
SEGNATURA.XML
21
SEGNATURA DEL PROTOCOLLO INFORMATICO
<?xml version="1.0" encoding="ISO-8859-1"?>
<!DOCTYPE Segnatura SYSTEM "http://protocollo/Segnatura/wsprotocollo.dtd">
<Segnatura xml:lang="it">
<Intestazione>
<Identificatore>
<CodiceAmministrazione> Codice Servizio come indicato in Appendice 1</CodiceAmministrazione>
<CodiceAOO>AOO000</CodiceAOO>
<NumeroRegistrazione>0000065</NumeroRegistrazione>
<DataRegistrazione>2009-09-27</DataRegistrazione>
</Identificatore>
<Origine>
<IndirizzoTelematico/>
<Mittente>
<Amministrazione>
<Denominazione>Cognome Nome Cittadino</Denominazione>
<UnitaOrganizzativa>
<Denominazione></Denominazione>
<IndirizzoPostale>
<Toponimo/>
<Civico/>
<CAP/>
<Comune/>
<Provincia/>
</IndirizzoPostale>
</UnitaOrganizzativa>
</Amministrazione>
<AOO>
<Denominazione> </Denominazione>
</AOO>
</Mittente>
</Origine>
<Destinazione confermaRicezione="si">
<IndirizzoTelematico tipo=”uri”/>
</Destinazione>
<Risposta>
<IndirizzoTelematico tipo="uri">http://HOST_RICEVENTE_RISPOSTA</IndirizzoTelematico>
</Risposta>
<Riservato>N</Riservato>
<Oggetto>Cambio di residenza || Richiesta iscrizione anagrafica</Oggetto>
22
<Note>Eventuali annotazioni</Note>
</Intestazione>
<Riferimenti>
<ContestoProcedurale>
<CodiceAmministrazione>login utente come indicato in appendice 1 </CodiceAmministrazione>
<Identificativo/>
<TipoContestoProcedurale>IndicazioneClassificazione</TipoContestoProcedurale>
<Classifica>
<Livello>Titolario: Titolo com indicato in appendice 1</Livello>
<Livello>Titolario: Classe come indicato in appendice 1</Livello>
<Livello>0</Livello>
</Classifica>
</ContestoProcedurale>
</Riferimenti>
<Descrizione>
<TestoDelMessaggio/>
<Allegati>
<Documento tipoRiferimento="informatico" id="protocollo_riservato.doc.p7m">
<URI>http://INDIRIZZO_SERVER/protocollo_riservato.doc.p7m</URI>
<TitoloDocumento>Allegato firmato</TitoloDocumento>
</Documento>
<Documento tipoRiferimento="informatico" nome="gecom.doc">
<URI>http://INDIRIZZO_SERVER/gecom.doc</URI>
<TitoloDocumento>Allegato non firmato</TitoloDocumento>
</Documento>
</Allegati>
</Descrizione>
</Segnatura>
23
ALLEGATO 3 CONFERMA PROTOCOLLAZIONE
CONFERMA.XML
<?xml version="1.0"?>
<!DOCTYPE ConfermaRicezione SYSTEM "http://protocollo/Segnatura/wsprotocollo.dtd">
<ConfermaRicezione>
<Identificatore>
<CodiceAmministrazione>Codice Servizio come indicato in Appendice
1</CodiceAmministrazione>
<NumeroRegistrazione>0000022</NumeroRegistrazione>
NUMERO DI
PROTOCOLLO ASSEGNATO
</Identificatore>
<MessaggioRicevuto>
<Identificatore>
<NumeroRegistrazione>0000065</NumeroRegistrazione> CHIAVE
TRASMESSA SU SEGNATURA.XML
</Identificatore>
</MessaggioRicevuto>
<Riferimenti>
<ContestoProcedurale>
<CodiceAmministrazione></CodiceAmministrazione>
<CodiceAOO></CodiceAOO>
<Identificativo></Identificativo>
<TipoContestoProcedurale>IndicazioneClassificazione</TipoContestoProcedurale>
<Classifica>
<Denominazione></Denominazione>
<Livello>'Titolario: Titolo com indicato in appendice 1'</Livello>
<Livello>'Titolario: Classe come indicato in appendice 1'</Livello>
<Livello>0</Livello>
</Classifica>
</ContestoProcedurale>
</Riferimenti>
</ConfermaRicezione>
24
ALLEGATO 4 - ECCEZIONE (Con riferimenti alla pratica)
Eccezione generata nel caso in cui sia possibile individuare dalla Segnatura.xml i riferimenti alla
pratica.
ECCEZIONE.XML
<!DOCTYPE NotificaEccezione SYSTEM "http://protocollo/Segnatura/wsprotocollo.dtd">
<NotificaEccezione>
<Identificatore>
<NumeroRegistrazione></NumeroRegistrazione>
<DataRegistrazione></DataRegistrazione>
</Identificatore>
<MessaggioRicevuto>
<Identificatore>
<NumeroRegistrazione>0000065</NumeroRegistrazione> CHIAVE
TRASMESSA SU SEGNATURA.XML
</Identificatore>
<Motivo>Classifica non presente :Categoria='Titolario: Titolo come indicato in
appendice 1' Classe='Titolario: Classe come indicato in appendice 1' SottoClasse=0</Motivo>
</NotificaEccezione>
25
ALLEGATO 5 - ECCEZIONE (Con riferimenti alla transazione)
Eccezione generata nel caso in cui non sia possibile individuare dalla Segnatura.xml i
riferimenti alla pratica.
Vengono specificati i riferimenti della transazione XMLRPC mediante la quale era stata
effettuata la richiesta di protocollazione.
ECCEZIONE.XML
<!DOCTYPE NotificaEccezione SYSTEM "http://protocollo/Segnatura/wsprotocollo.dtd">
<NotificaEccezione>
<MessaggioRicevuto>
<DescrizioneMessaggio>
Request Id: 3212#Request Date: 2009-03-02#Receiver Uri:
http://HOST_RICEVENTE_RISPOSTA#Request Sender IP: 172.0.0.0
</DescrizioneMessaggio>
<Motivo>Impossibile leggere la Segnatura.xml</Motivo>
</NotificaEccezione>
26
APPENDICE 1
27
Codice Servizio
450
Titolo
11
Classe
2
Utente
ssddres
APPENDICE 2 - DOCUMENTAZIONE TECNICA (WSProtocollo V. 1.0)
Viene riportata la documentazione relativa al protocollo utilizzato per l'implementazione del
WebServices.
28
Protocollo di comunicazione
L'interfacciamento fra il sistema di protocollo informatico (PI) ed un qualsiasi altro sistema
informativo avviene mediante il protocollo XMLRPC.
Mediante l'utilizzo del protocollo XMLRPC è possibile eseguire procedure fisicamente residenti su
sistemi informativi remoti.
Un qualsiasi sistema in rete può quindi invocare una procedura/funzione residente su un altro
server remoto (WebService) e ricevere da esso il risultato dell'elaborazione così attivata.
XMLRPC prevede l'utilizzo del protocollo HTTP per il layer di trasporto e l'XML per la codifica
dei dati trasmessi durante una sessione di comunicazione.
Fig. 1 – Schema sessione XMLRPC
I dati necessari all'invocazione della procedura remota vengono codificati in un “pacchetto” XML
secondo le specifiche XMLRPC dal sistema invocante.
Questo pacchetto viene inviato, mediante protocollo HTTP, al WebService il quale provvede a
decodificare l'XML ricevuto, eseguire la procedura invocata e ad inviare i risultati mediante un
secondo pacchetto XML.
29
Descrizione dei componenti del sistema
Viene di seguito riportata una descrizione dei componenti principali
necessari per il compimento del processo di protocollazione mediante XMLRPC.
Fig. 2 – Schema struttura sistema
Il sistema risulta costituito da due partner, il sistema di protocollo informatico (PI) e il
“Gestionale”, un qualsiasi applicativo che necessità di accedere al sistema di protocollo.
Il sistema di richiesta/ricezione di un nuovo numero di protocollo è di tipo asincrono.
Per questo motivo è prevista la realizzazione, in entrambi i partner, di un componente client
XMLRPC ed uno server (WebService) XMLRPC.
Il componente “1” rappresenta il client XMLRPC presente nel gestionale e responsabile di eseguire
la richiesta per un nuovo numero di protocollo.
Il componente “2” è il WebService implementato nel protocollo ed incaricato di ricevere le
richieste ed accodarle nel sistema di protocollazione.
Il componente “3” rappresenta il client XMLRPC del sistema di protocollo al quale è affidato il
compito di leggere la coda dei protocolli in uscita ed inviarli ai corrispettivi gestionali.
L'ultimo componente, il “4”, rappresenta il WebService, presente nel gestionale, ed implementato
al fine di ricevere le risposte di protocollazione (contenenti il numero di protocollo) provenienti dal
componente “3”.
30
31
Descrizione del flusso di comunicazione
La comunicazione fra i due partner è costituita da due fasi o sessioni XMLRPC;
una sessione di richiesta protocollo ed una sessione di invio del numero di protocollo (o
eventualmente messaggio di ripudio).
1.1.1
Sessione richiesta protocollo
Nella prima sessione, denominata “Sessione XMLRPC richiesta protocollo”, il gestionale,
mediante il componente “1”, richiede un nuovo numero di protocollo.
La richiesta avviene invocando il comando accoda presente nel WebService del protocollo (
componente “2” ).
La risposta generata da tale comando, ed inviata al componente “1” al termine dell'invocazione,
indica l'avvenuta accettazione o meno (status) alla richiesta effettuata.
In questo caso non viene restituito alcun numero di protocollo, ma semplicemente un
codice/messaggio identificante l'esito della richiesta.
Nel caso di accettazione avvenuta il comando “accoda” inserisce la richiesta nella coda presente
nel sistema di protocollazione e restituisce al componente “1” il codice di accettazione avvenuta.
A questo punto il gestionale rimane in attesa che avvenga la protocollazione e venga quindi
attivata la seconda sessione XMLRPC.
1.1.2
Sessione invio numero di protocollo
Nella seconda e ultima sessione, denominata “Sessione XMLRPC invio numero di protocollo”, il
sistema informatico di protocollo, mediante il componente “3”, invia al gestionale (e precisamente
al componente “4”) la risposta di protocollazione.
Questa risposta può contenere il nuovo numero di protocollo o eventualmente il messaggio di
ripudio.
Questa sessione viene attivata dal client del protocollo (“3”) invocando il comando ricevitore
implementato nel gestionale (componente “4”).
Attraverso tale invocazione il protocollo invia al gestionale la risposta alla richiesta di
protocollazione e riceve in cambio un codice di avvenuta ricezione (status invio risposta).
La risposta alla richiesta di protocollo può contenere un nuovo numero di protocollo oppure un
messaggio di ripudio nel caso in cui il sistema di protocollo abbia riscontrato qualche irregolarità
nei dati inviategli.
A questo punto l'intera procedura risulta essersi conclusa.
32
Specifiche comandi XMLRPC
Vengono di seguito riportate le specifiche relative ai singoli comandi da implementare nei due
WebServices.
I comandi da implementare sono due:
accoda
– presente nel sistema di protocollo e la cui implementazione è a cura del
soggetto manutentore
ricevitore – presente nel gestionale e implementata dalla rispettiva
software house del gestionale.
I comandi vengono invocati dai client XMLRPC eseguendo una chiamata HTTP di tipo POST.
I dati inviati mediante il POST rappresentano il pacchetto XML costituito secondo le specifiche
XMLRPC e contente il nome del comando da invocare e i parametri richiesti per la sua esecuzione.
1.1.3
Comando accoda
Il comando accoda è implementato dal soggetto manutentore del sistema di protocollo informatico.
A questo è demandato il compito di ricevere le richieste di protocollazione e accodarle nel sistema,
affidandole così alla procedura di protocollazione.
1.1.3.1
Indirizzo del webservice
L'URL del WebService presso il quale invocare il comando (eseguire il POST HTTP) è il seguente:
http://HOSTNAME_PROTOCOLLO/WSProtocollo/Incoming
1.1.3.2
Parametri necessari all'invocazione
Vengono ora riportati i parametri necessari all'invocazione del comando.
Questi vengono inviati mediante il pacchetto XMLRPC al webservice e devono comparire in esso
nell'ordine con cui vengono riportati di seguito.
− data_richiesta, identifica il momento in cui viene effettuata la richiesta dal gestionale e
deve essere nel formato ISO 8601 (YYYY-MM-DD H:M:S)
− chiave_univoca, rappresenta una chiave univoca utilizzata
univocamente una determinata sessione XMLRPC di richiesta
per
determinare
− uri_ricevitore, indica l'indirizzo a cui il protocollo dovrà inviare la risposta di
protocollazione (numero di protocollo o messaggio di ripudio)
− segnaturaenc64, è la segnatura, (vedi specifiche per l'interoperabilità, Capitolo 2)
codificata mediante l'algoritmo base64.
33
1.1.3.3
Codici status operazione
Al termine della procedura il comando risponde con una stringa riportante lo status nel formato
CODICE: MESSAGGIO_TESTUALE. Di seguito vengono riportati i possibili valori assunti.
- Richiesta accettata con successo
0: Accepted
- Data richiesta mancante o non valida
1: The date of the request is void or invalid (Format must be YYYY-MM-DD HH:MM:SS)
- Chiave univoca richiesta mancante o non valida
2: The unique request key is void or invalid
- Indirizzo ricevitore mancante o non valido
3: The receiver URI is void or invalid
- Segnatura mancante
4: The Segnatura XML data is void or invalid
- Segnatura non codificata correttamente in base64
4: The Segnatura is not properly encoded in base64
- La segnatura ricevuta non corrisponde alla DTD (errore validazione)
5: The XML received is not consistent with its DTD
- Errore interno mancata connessione verso DataBase del Protocollo
6: There is no connection to DB
- Errore interno esecuzione query
7: Query programming error
- Richiesta duplicata/già ricevuta
8: Duplicate request, request already made previously
- Errore interno generico
9: Internal System Error
34
1.1.3.4
Esempio pacchetto XMLRPC per l'invocazione del comando
Di seguito è riportato un esempio di pacchetto HTTP relativo alla chiamata XMLRPC.
L'XML riportato rappresenta il pacchetto XML inviato mediante POST e realizzato secondo le
specifiche XMLRPC.
POST /RPC2 HTTP/1.0
User-Agent: clientagent
Host: hostnameclient
Content-Type: text/xml
Content-length: 3373
<?xml version='1.0'?>
<methodCall>
<methodName>accoda</methodName>
<params>
<param>
<value><string>2008-09-30 00:00:00</string></value>
</param>
<param>
<value><int>892975</int></value>
</param>
<param>
<value><string>http://gestionale/componente_4</string></value>
</param>
<param>
<value><string>SEGNATURA IN BASE64</string></value>
</param>
</params>
</methodCall>
35
1.1.4
Comando ricevitore
Il comando ricevitore è implementato nel gestionale dalla relativa software house.
A questo è affidato il compito di ricevere le risposte di protocollazione (nuovo numero o messaggio
di ripudio), provenienti dal componente “3” e affidarle al gestionale.
Indirizzo del webservice
L'URL del WebService del gestionale presso cui invocare il comando dipende
dall'implementazione del gestionale e vengono comunicate al sistema di protocollo mediante il
parametro uri_ricevitore del comando “accoda”.
1.1.4.1
Parametri necessari all'invocazione
Vengono ora riportati i parametri necessari all'invocazione del comando.
Questi vengono inviati mediante il pacchetto XMLRPC al webservice e devono comparire in esso
nell'ordine con cui vengono riportati di seguito.
request_unique_key, coincide con il valore assunto dalla variabile chiave_univoca durante
l'invocazione del comando “accoda”, è indispensabile per identificare a quale richiesta la risposta
fa riferimento.
xml_response, è il messaggio xml di risposta al processo di protocollazione, (vedi specifiche per
l'interoperabilità), codificato in base64
1.1.4.2
Codici status operazione
Al termine della procedura il comando risponde con uno status nel formato CODICE:
MESSAGGIO_TESTUALE. Di seguito vengono riportati i possibili valori assunti.
- Richiesta accettata con successo
0: Accepted
- Richiesta non accettata
1: Rejected
36
1.1.4.3
Esempio pacchetto XMLRPC per l'invocazione del comando
Di seguito è riportato un esempio di pacchetto HTTP relativo alla chiamata XMLRPC.
L'XML riportato rappresenta il pacchetto XML inviato mediante POST e realizzato secondo le
specifiche XMLRPC.
POST /RPC2 HTTP/1.0
User-Agent: clientagent
Host: hostnameclient
Content-Type: text/xml
Content-length: 3373
<?xml version='1.0'?>
<methodCall>
<methodName>ricevitore</methodName>
<params>
<param>
<value><string>892975</string></value>
</param>
<param>
<value><string>RISPOSTA XML CODIFICATA BASE64
</string>
</value>
</param>
</params>
</methodCall>
37
38

Allegato B/1 del bando di gara Allegato B/1 del

Transcript

Documenti analoghi

Testo Specifiche Tecniche - Provincia Autonoma di Trento

Tavolo Element ESAGONO

Tavolo Element OTTAGONO

Tavolo Element CERCHIO

Esercizi XML File

Audio Technologies S.r.l.

Anche il supermarket si adegua - U

Accesso ad Internet per le Aziende

Programma_Tech4ability