PCT - Specifiche di interfaccia PDA-GC v2.pdf - Majorana

Ministero della Giustizia 

Dipartimento dell’organizzazione giudiziaria, del personale e dei servizi 

Direzione generale per i sistemi informativi automatizzati 

Sistemi informativi automatizzati per la giustizia civile e processo telematico 

PROCESSO CIVILE TELEMATICO 

Specifiche di Interfaccia tra 

Punto di Accesso e Gestore Centrale 

Versione 2.0

MINISTERO DELLA GIUSTIZIA – D.G.S.I.A. 


Versione 2.0 

SPECIFICHE DI INTERFACCIA TRA PUNTO DI ACCESSO E GESTORE CENTRALE 

Sommario 

1 GENERALITÀ.................................................................................................................................. 9 

1.1 SCOPO DEL DOCUMENTO ........................................................................................................................... 9 

1.2 APPLICABILITÀ.......................................................................................................................................... 9 

1.3 NOTAZIONI GRAFICHE............................................................................................................................... 9 

2 SCENARIO DEL PROCESSO CIVILE TELEMATICO...................................................................... 11 

3 FLUSSO DI ABILITAZIONE E GESTIONE UTENZE......................................................................... 13 

3.1 REGISTRAZIONE NUOVE UTENZE AVVOCATI E CTU................................................................................. 13 

3.1.1 Descrizione del flusso abilitativo....................................................................................................... 14 

3.1.2 Messaggi scambiati............................................................................................................................ 16 

3.2 VARIAZIONE UTENZE............................................................................................................................... 19 

3.2.1 Variazione generata dall’utente (avvocato) ....................................................................................... 20 

3.2.2 Variazione generata dal Consiglio dell’Ordine (solo per avvocati)................................................... 21 

3.3 CANCELLAZIONE UTENZE ........................................................................................................................ 23 

3.3.1 Cancellazione generata dall’utente (avvocato) .................................................................................. 24 

4 FLUSSI DOCUMENTALI................................................................................................................ 26 

4.1 IL DEPOSITO DI UN ATTO ......................................................................................................................... 26 

4.1.1 Fase di trasmissione dell’atto............................................................................................................. 29 

4.1.1.1 Struttura del messaggio di “inoltro atto”.......................................................................................30 

4.1.1.2 Struttura del messaggio di “attestazione temporale”..................................................................... 33 

4.1.1.3 Struttura del messaggio di “notifica eccezione”............................................................................ 34 

4.1.2 Fase di trasmissione dell’esito dell’atto ............................................................................................. 36 

4.1.2.1 Struttura del messaggio di “comunicazione esito”........................................................................ 36 

4.2 L’INVIO DI UN BIGLIETTO DI CANCELLERIA .............................................................................................. 39 

4.2.1 Il messaggio di “biglietto cancelleria” ............................................................................................... 39 

4.3 FLUSSO DI NOTIFICHE TRA DIFENSORI (TRAMITE CPECPT) ..................................................................... 44 

4.3.1 Invio delle notifiche avvocato-avvocato............................................................................................ 46 

4.3.2 Attestazioni temporali ricevute a seguito dell’invio di notifiche (Avvocato mittente) ...................... 48 

4.3.3 Ricezione notifiche e relative attestazioni temporali (Avvocato destinatario)................................... 49 

4.4 FUNZIONE DI RICHIESTA E RICEZIONE DELLA COPIA CONFORME .............................................................. 51 

5 CONSULTAZIONI.......................................................................................................................... 52 

5.1 CARATTERISTICHE DI POLISWEB............................................................................................................. 54 

5.2 ARCHITETTURA E FLUSSI DI COLLOQUIO TRA PUNTO ACCESSO E POLISWEB.......................................... 55 

5.3 INTERFACCE PER IL PUNTO DI ACCESSO.................................................................................................. 60 

5.3.1 Richiesta “Attivazione Sessione Utente PolisWeb” .......................................................................... 60 

PAGINA 2 DI 133



Versione 2.0 


5.3.2 Risposta PolisWeb alla richiesta di “Attivazione Sessione Utente PolisWeb”................................. 61 

5.3.3 Richiesta “Pagine Area Privata Consultazione PolisWeb”................................................................ 62 

5.3.4 Risposta di PolisWeb alla richiesta “Pagine Area Privata Consultazione PolisWeb”. ...................... 63 

5.3.5 Richiesta “Chiusura Sessione Utente PolisWeb”............................................................................... 63 

5.3.6 Risposta PolisWeb per richiesta “Chiusura Sessione Utente PolisWeb”........................................... 64 

5.3.7 Eccezioni............................................................................................................................................ 64 

5.4 INTERFACCE PER IL BACK-END DI POLIS WEB......................................................................................... 65 

5.4.1 Esempio Messaggio Richiesta Soap .................................................................................................. 66 

5.4.2 Esempio Messaggio Risposta Soap.................................................................................................... 67 

6 ACCESSO AI REGISTRI SUL GESTORE CENTRALE ..................................................................... 69 

6.1 ACCESSO AL REGINDE PER IL REPERIMENTO DI INDIRIZZI E CERTIFICATI DEGLI AVVOCATI.................... 69 

6.2 ACCESSO AL REGISTRO DEGLI UFFICI GIUDIZIARI................................................................................... 70 

7 POSTA CERTIFICATA................................................................................................................... 71 

8 ALLEGATI .................................................................................................................................... 72 

8.1 FORMATO DEI DATI.................................................................................................................................. 72 

8.2 DTD DEI FILE XML.................................................................................................................................... 73 

8.2.1 Attestazione.dtd ................................................................................................................................. 73 

8.2.2 Certificazione.dtd............................................................................................................................... 73 

8.2.3 Comunicazione.dtd ............................................................................................................................ 73 

8.2.4 Eccezione.dtd..................................................................................................................................... 74 

8.2.5 EsitoAtto.dtd...................................................................................................................................... 74 

8.2.6 InfoInoltro.dtd.................................................................................................................................... 74 

8.2.7 InfoIndirizzamento.dtd....................................................................................................................... 75 

8.2.8 ComunicazioneIndirizzi.dtd............................................................................................................... 77 

8.2.9 InfoNotifica.dtd.................................................................................................................................. 79 

8.3 DESCRIZIONE MESSAGGI DI ESITOATTO.................................................................................................. 80 

8.4 ANAGRAFICA DEGLI ERRORI RIPORTATI DAL GESTORE CENTRALE.......................................................... 84 

8.5 FORMATI WSDL ..................................................................................................................................... 86 

8.5.1 WSDL jpw-backend.wsdl.................................................................................................................. 86 

8.5.2 Schema wsdlschema.xsd.................................................................................................................... 89 

PAGINA 3 DI 133



Versione 2.0 


Indice delle figure 

Figura 1 - Scenario del Processo Civile Telematico ................................................................ 11 

Figura 2 - Flusso di creazione utenza Avvocato ...................................................................... 15 

Figura 3 - Busta RichiestaAggiornamentoUtenze................................................................... 17 

Figura 4 - Busta AttestazioneCertificata.................................................................................. 17 

Figura 5 - Busta EccezioneCertificata...................................................................................... 17 

Figura 6 - Busta ComunicazioneIndirizzi ................................................................................ 18 

Figura 7 - Busta AnomaliaIndirizzi.......................................................................................... 18 

Figura 8 - Struttura del file ComunicazioneIndirizzi.xml........................................................ 19 

Figura 9 - Flusso di variazione utenza - generata dall'utente Avvocato .................................. 20 

Figura 10 - Flusso di variazione utenza - generata dal CdO.................................................... 21 

Figura 11 - Busta AggiornamentoUtenze................................................................................. 22 

Figura 12 - Flusso di cancellazione utenza - generata dall'Avvocato...................................... 24 

Figura 13 - Sequence diagram del deposito atto ...................................................................... 27 

Figura 14 - Sequence diagram del deposito atto in caso di attestazione temporale................. 29 

Figura 15 - Sequence diagram del deposito atto in caso di notifica di eccezione................... 30 

Figura 16 - S/MIME di Inoltro Atto........................................................................................ 30 

Figura 17 - Struttura del file InfoInoltro.xml ........................................................................... 31 

Figura 18 - Struttura del file Certificazione.xml...................................................................... 32 

Figura 19 - MIME di Attestazione temporale .......................................................................... 33 

Figura 20 - Struttura del file Attestazione.xml......................................................................... 34 

Figura 21 - MIME di Notifica eccezione ................................................................................. 35 

Figura 22 - Struttura del file Eccezione.xml ............................................................................ 35 

Figura 23 - Sequence diagram del deposito atto – Fase di trasmissione dell’esito dell’atto ... 36 

Figura 24 - MIME di Comunicazione esito ............................................................................. 37 

Figura 25 - Struttura del file EsitoAtto.xml ............................................................................. 37 

Figura 26 - Sequence diagram dell’invio di un biglietto di cancelleria ................................... 39 

Figura 27 - S/MIME del Biglietto di Cancelleria..................................................................... 40 

Figura 28 – Struttura del file Comunicazione.xml................................................................... 41 

Figura 29 - Struttura del file InfoIndirizzamento.xml.............................................................. 42 

Figura 30 - Notifiche avvocato-avvocato................................................................................. 45 

Figura 31 - Dettaglio delle notifiche avvocato-avvocato......................................................... 46 

PAGINA 4 DI 133



Versione 2.0 


Figura 32 - S/MIME di InoltroNotificaAvvocato .................................................................... 46 

Figura 33 - Struttura del file InfoNotifica.xml......................................................................... 47 

Figura 34 - MIME di Attestazione temporale .......................................................................... 48 

Figura 35 - Struttura del file Attestazione.xml......................................................................... 48 

Figura 36 - S/MIME di AttestazioneConsegnaNotifica........................................................... 49 

Figura 37 - Busta di ConsegnaNotifica.................................................................................... 50 

Figura 38 - Busta di AttestazioneNotifica................................................................................ 50 

Figura 39 - Busta di ConsegnaCopiaConforme ....................................................................... 51 

Figura 40 - Sequence diagram Consultazione Web ................................................................. 53 

Figura 41 - Architettura per PolisWeb nel Punto di Accesso .................................................. 55 

Figura 42 - Sequenza Messaggi PA / FE-PW-PA- Attivazione Sessione................................ 56 

Figura 43 - Sequenza Messaggi PA / FE-PW-PA- Consultazione .......................................... 57 

Figura 44 - Sequenza Messaggi PA / FE-PW-PA- Chiusura Sessione.................................... 58 

Figura 45 - Sequenza Messaggi PA / FE-PW-PA- Eccezione Parametri Errati ...................... 59 

Figura 46 - Sequenza Messaggi PA / FE-PW-PA- Eccezione Utente Connesso..................... 59 

Figura 47 - Rappresentazione grafica dell’interfaccia WSDL per il back end di PolisWeb.... 65 

PAGINA 5 DI 133



Versione 2.0 


STORIA DELLE MODIFICHE APPORTATE 

Versione Data Descrizione Modifica 

1.0 22/11/2004 Prima emissione 

2.0 18/05/2007 Riferimenti: inserito D.M. 15 Dicembre 2005 

Inserito capitolo 3 Flusso di abilitazione e gestione utenze 

Capitolo 4: inseriti 

- 4.3 flusso di Notifica tra difensori 

- 4.4 Funzione di richiesta e ricezione della copia conforme 

Paragrafo 4.1 il Deposito di un atto: inserito elenco dei messaggi scambiati per il 

flusso di deposito atto 

Paragrafo 4.1.1.2 Struttura del messaggio di “attestazione temporale”: inserita 

specifica del subject della busta 

Paragrafo 4.1.1.3 Struttura del messaggio di “notifica eccezione”: 

- inserita specifica del subject della busta 

- inserito riferimento a paragrafo 8.4 Anagrafica degli errori riportati dal 

Gestore Centrale 

Paragrafo 4.1.2 Fase di trasmissione dell’esito dell’atto: inserita specifica di 

trasmissione da GC a PdA di Esito controlli automatici 

Paragrafo 4.1.2.1 Struttura del messaggio di “comunicazione Esito”: 

- inseriti possibili valori di CodiceEsito 

- inserita specifica del subject delle buste di comunicazione esito 

- inserito riferimento a paragrafo 8.3 descrizione dei messaggi di 

EsitoAtto 

Paragrafo 4.2 L’invio di un biglietto di cancelleria: modificato indirizzo 

CPECPT GL 

Paragrafo 4.2.1 Il messaggio di “Biglietto cancelleria”: 

- modificata Figura 20 S/MIME del Biglietto di Cancelleria 

- inserite specifiche della busta 

- modificata Figura 21 struttura del file Comunicazione.xml 

- inserita Figura 22 Struttura del file InfoIndirizzamento.xml e specifiche 

Inserito Capitolo 6 Accesso ai Registri su Gestore Centrale 

Paragrafo 8.2 DTD dei file xml: 

- aggiornato 8.2.6 InfoInoltro.dtd 

- inserito 8.2.7 InfoIndirizzamento.dtd 

- inserito 8.2.8 ComunicazioneIndirizzi.dtd 

- inserito 8.2.9 InfoNotifica.dtd 

Inserito paragrafo 8.3 descrizione dei messaggi di Esito Atto 

Inserito paragrafo 8.4 Anagrafica degli errori riportati dal Gestore Centrale 

PAGINA 6 DI 133



Versione 2.0 


DEFINIZIONI E ACRONIMI 

Nel presente capitolo è riportata la descrizione dei termini, degli acronimi e delle 

abbreviazioni usate nel documento. 

Acronimo Descrizione 

CdO Consiglio dell’Ordine 

CPC Codice di Procedura Civile 

CPECPT Casella di Posta Certificata Processo Telematico (anche CPEPT) 

DSN Delivery Status Notification 

DTD Document Type Definition 

GC Gestore Centrale 

HTTP HyperText Transfer Protocol 

HTTPS HyperText Transfer Protocol Secure 

MIME Multipurpose Internet Mail Extensions 

PCT Processo civile telematico 

PdA Punto di Accesso 

PIN Personal Identification Number 

RD Repository Documentale 

ReGIndE Registro Generale degli Indirizzi Elettronici 

ReLIndE Registro Locale degli Indirizzi Elettronici 

RPC Remote Procedure Call 

RUG Rete Unitaria della Giustizia 

RUPA Rete Unitaria della Pubblica Amministrazione 

S/MIME Secure Multipurpose Internet Mail Extensions 

SIC Sistema Informativo Civile 

SICI Sistema Informatico del Contenzioso Civile 

SIL Sistema Informativo del Lavoro 

SMTP Simple Mail Transfer Protocol 

SOAP Simple Object Access Protocol 

SPC Servizio Pubblico di Connessione 

SSLv3 Secure Sockets Layer version 3 

UG Ufficio Giudiziario 

UI User Interface 

UNEP Ufficio Notifiche e Protesti 

W3C World Wide Web Consortium 

XML eXtensible Markup Language 

PAGINA 7 DI 133



Versione 2.0 


RIFERIMENTI 

Progressivo Descrizione 

1 Regole Tecnico-Operative per l’Uso di Strumenti Informatici e Telematici nel 

Processo Civile e relativi allegati. 

2 Posta Elettronica Certificata “Allegato tecnico alle linee guida del servizio di 

trasmissione di documenti informatici mediante posta elettronica certificata” 

(http://www.ctrupa.it/RETE-RUPA/Posta-Elet). 

3 RFC 822 - Standard for the format of ARPA Internet text messages. 

(http://www.faqs.org/rfcs/rfc822.html) 

4 D.M. 15 Dicembre 2005 - Strutturazione dei modelli DTD (Document Type 

Definition) relativa all'uso di strumenti informatici e telematici nel processo 

civile. (GU n. 301 del 28-12-2005 - Suppl. Ordinario n.210) 

PAGINA 8 DI 133



Versione 2.0 


1 GENERALITÀ 

1.1 SCOPO DEL DOCUMENTO 

Obiettivo del presente documento è quello di descrivere struttura, formati e contenuti 

informativi delle interfacce tra Punto di Accesso e Gestore Centrale, nell’ambito delle 

interazioni attualmente previste dal Processo Civile Telematico. 

Non costituiscono oggetto del presente documento le interazioni esterne al contesto sopra 

individuato, e cioè tra Soggetti Abilitati Esterni e Punto di Accesso né quelle interne al 

Dominio Giustizia (interazioni tra Gestore Centrale e Gestori Locali e tra Gestore Locale e 

SICI). Analogamente è fuori dal contesto di analisi del presente documento la parte relativa 

alla redazione, firma e cifratura degli atti informatici da inviare agli Uffici Giudiziari. 

1.2 APPLICABILITÀ 

L’ambito di applicazione del presente documento è quello relativo al Processo Civile 

Telematico, (d’ora in avanti Processo Telematico), così come regolamentato dalla attuale 

versione delle norme tecnico-operative. 

1.3 NOTAZIONI GRAFICHE 

Nel presente documento, i DTD sono stati rappresentati graficamente secondo la notazione 

“W3C Schema”, come riportato, a titolo di esempio, nella figura seguente: 

Ogni “elemento” è rappresentato all’interno di un rettangolo. Rettangoli delimitati da linee 

continue indicano elementi obbligatori, mentre rettangoli delimitati da linee tratteggiate, 

indicano elementi opzionali (vedi figura seguente): 

PAGINA 9 DI 133



Versione 2.0 


Un elemento può essere costituito da un elemento a scelta tra quelli indicati a destra del 

simbolo 

come rappresentato dalla seguente figura: 

Un elemento è composto da tutti (se obbligatori) gli elementi presenti a destra del simbolo 

come rappresentato dalla seguente figura: 

Il simbolo “1..∞” indica una cardinalità del corrispondente elemento compresa fra 1 ed n 

(vale a dire che l’elemento è presente una o più volte). 

Il simbolo “0..∞” indica una cardinalità del corrispondente elemento compresa fra 0 ed n 

(vale a dire che l’elemento non è obbligatorio, ma che, se presente, può esserlo anche più di 

una volta). 

Gli elementi possono essere dotati di diversi attributi, che, in tale rappresentazione grafica, 

non vengono però evidenziati. Per una loro dettagliata descrizione si rimanda alla lettura dei 

DTD relativi (presenti in appendice). 

Anche altre strutture dati, non direttamente riconducibili a file XML, quali, ad esempio, buste 

MIME, S/MIME, file firmati, ecc., sono state riportate secondo la notazione “W3C Schema”. 

Tale rappresentazione non deve, quindi, essere considerata come rigorosa, ma è stata 

semplicemente adottata per uniformare lo stile grafico di schematizzazione. 

PAGINA 10 DI 133



Versione 2.0 


2 SCENARIO DEL PROCESSO CIVILE TELEMATICO 

Lo scenario operativo del Processo Civile Telematico (PCT) è rappresentato nella figura che 

segue: 

Soggetto 

abilitato 

esterno 

Soggetto 

abilitato 

esterno 

Soggetto 

abilitato 

esterno 

Soggetto 

abilitato 

esterno 

Internet 

Internet 

PdA 

PdA 

RUPA 

GL 

GL 

Ufficio 

Giudiziario 

GC 

RUG 

Ufficio 

Giudiziario 

Soggetto 

abilitato 

interno 

Soggetto 

abilitato 

interno 

Soggetto 

abilitato 

interno 

Soggetto 

abilitato 

interno 

Figura 1 - Scenario del Processo Civile Telematico 

Tale scenario prevede una serie di soggetti abilitati all’utilizzo dei servizi del PCT ripartiti 

logicamente tra soggetti esterni al Sistema Informatico Civile (SICI) e soggetti interni. I 

soggetti abilitati esterni (al momento limitati ai soli difensori di parte) fruiscono dei servizi 

offerti dal PCT per il tramite dei servizi realizzati da una serie di entità tecnico-organizzative: 

• i Punti di Accesso Esterni (PdA); 

• il Gestore Centrale dell’accesso (GC); 

• i Gestori Locali dell’accesso (GL). 

I PdA eseguono l’autenticazione dei soggetti abilitati esterni e forniscono loro i servizi di 

connessione al SICI. Forniscono inoltre servizi di: 

PAGINA 11 DI 133



Versione 2.0 


• trasmissione telematica dei documenti informatici processuali 

• accesso e gestione della casella di posta elettronica certificata del Processo Telematico 

(CPECPT), 

• invio notifiche tra difensori e gestione di quelle ricevute 

• richiesta e ricezione di Copia Conforme 

• accesso alle funzionalità di consultazione (PolisWeb) 

Il GC è il punto unico di interazione tra il SICI ed i PdA. Il GC fornisce i servizi di accesso al 

SICI ed i servizi di trasmissione telematica dei documenti informatici processuali verso i GL 

e verso i PdA. 

Il GL è parte del sistema informatico dell'Ufficio Giudiziario (UG). Il GL fornisce i servizi di 

accesso al singolo UG ed i servizi di trasmissione telematica dei documenti informatici 

processuali tra UG e GC. 

PAGINA 12 DI 133



Versione 2.0 


3 FLUSSO DI ABILITAZIONE E GESTIONE UTENZE 

La gestione delle utenze relative ai soggetti abilitati ad operare nel Processo Civile 

Telematico è regolamentata dalle Regole tecnico-operative (D.M. 14 ottobre 2004 [1]), 

articoli 14, 15 e 16. 

Affinché il Gestore Centrale possa effettuare la certificazione dei difensori (come prevista 

dall’art. 7, comma 1 del D.M. 14 ottobre 2004), ed anche al fine del popolamento del Registro 

Generale degli Indirizzi Elettronici, i consigli dell'ordine degli avvocati e il Consiglio 

nazionale forense debbono inviare al Gestore Centrale copia dell'albo, in formato elettronico, 

sottoscritta con firma digitale (art. 17, commi 2 e 3). 

A tal fine, il rappresentante del Consiglio dell’Ordine degli avvocati (CdO) nonché il 

rappresentante del Consiglio Nazionale Forense debbono disporre di un’apposita casella di 

posta elettronica certificata del processo telematico (CPECPT); al riguardo si configurano due 

casi: 

a) la CPECPT è creata sul proprio punto di accesso, qualora il CdO sia titolare del punto di 

accesso stesso; in questo caso l’indirizzo della CPECPT va comunicato alla DGSIA 

(Ufficio processo telematico) a cura del CdO; 

b) la CPECPT è creata sul punto di accesso del Ministero della Giustizia (PdA-MG), qualora 

il CdO non sia titolare di alcun PdA o non abbia delegato il CNF; in questo caso il CdO 

invia una richiesta alla DGSIA (Ufficio processo telematico), che dovrà riportare il codice 

fiscale, il nominativo, il numero di serie del certificato di firma digitale 1 del 

rappresentante. La DGSIA provvederà a creare l’account sul PdA-MG e a comunicarlo al 

CdO richiedente. 

Nel seguito vengono descritti i flussi abilitativi di Avvocati e CTU, i flussi di variazione dei 

dati e di cancellazione della registrazione invocati dagli utenti stessi. 

Tutte le modifiche dei dati nei Registri degli Indirizzi sono visibili agli utenti a partire dal 

giorno lavorativo successivo a quello in cui vengono effettuate. 

3.1 REGISTRAZIONE NUOVE UTENZE AVVOCATI E CTU 

Per la creazione di un utente il Punto di Accesso deve seguire le procedure descritte dalle 

Regole tecnico operative, allo scopo di generare la CPECPT del soggetto abilitato e ad 

inserire tutti i dati richiesti dalle Regole stesse. 

1 Il “Gestore Centrale” verifica che la comunicazione di variazione di status professionale degli Avvocati, non sia “semplicemente” firmata 

digitalmente, ma che lo sia esattamente col certificato digitale del Rappresentante/delegato del CdO di competenza 

PAGINA 13 DI 133



Versione 2.0 


I dati da registrare sono i seguenti: 

a) dati identificativi dell’utente, così come definiti per il Registro Generale degli Indirizzi 

Elettronici (ReGIndE): nome e cognome, codice fiscale, data e luogo di nascita, residenza, 

certificato digitale relativo alla chiave pubblica da utilizzare per la cifratura, ecc. 

b) altri dati utente necessari (ruolo, dati relativi ai difensori, ecc.). 

Le Regole Tecniche stabiliscono, agli articoli 14, 16 e 17, un flusso abilitativo che viene di 

seguito schematizzato: 

1. i soggetti esterni che desiderano registrarsi presso un Punto di Accesso, devono 

produrre una richiesta scritta, comunicando i seguenti dati (art. 14): 

• nome e cognome; 

• luogo e data di nascita; 

• codice fiscale; 

• residenza; 

• domicilio; 

• certificato digitale, relativo alla chiave pubblica, per la cifratura; 

• consiglio dell’ordine di appartenenza; 

inoltre è richiesto un certificato: 

• per i difensori, un certificato, rilasciato in data non anteriore a venti giorni, in 

cui il consiglio dell'ordine di appartenenza attesta l'iscrizione all'albo, all'albo 

speciale, al registro dei praticanti abilitati oppure la qualifica che legittima 

all’esercizio della difesa e l'assenza di cause ostative allo svolgimento 

dell'attività difensiva; 

• per gli esperti e gli ausiliari del giudice, il certificato di iscrizione all'albo dei 

consulenti tecnici o copia della nomina da parte del giudice dalla quale risulta 

che l'incarico non è esaurito. 

2. (art. 14 comma 7) il Punto di Accesso acquisisce tutti i dati necessari all’inserimento 

nei registri degli indirizzi elettronici, genera l’indirizzo elettronico e invia i dati 

acquisiti al Gestore Centrale dell’accesso e, per i soli avvocati, al consiglio dell’ordine 

di appartenenza; 

3. (art. 16, comma 4 e 5) avvocati e CTU comunicano, rispettivamente al consiglio 

dell’ordine ed alla cancelleria, i propri dati identificativi insieme all’indirizzo 

elettronico rilasciato dal PdA ed ai dati identificativi del Punto di Accesso. 

3.1.1 Descrizione del flusso abilitativo 

Per la realizzazione del flusso abilitativo sopra descritto, tutti i soggetti coinvolti (Punti di 

Accesso, Gestore Centrale, Consigli dell’Ordine) devono implementare delle procedure 

organizzative e dotarsi di adeguate infrastrutture informatiche che consentano la registrazione 

degli utenti. 

Viene definita una modalità di scambio dati che si differenzia per avvocati e CTU. 

PAGINA 14 DI 133



Versione 2.0 


La figura di seguito riportata schematizza il flusso previsto per la richiesta di abilitazione di 

un avvocato. 

Avvocato Punto di Accesso Gestore Centrale 

Rappresentante 

Consiglio dell’Ordine 

0 - Richiesta registrazione 

1 - Richiesta di abilitazione 

2 - Attestazione Temporale / Notifica eccezione 

3 -Abilitazione Utente 

4 - Comunicazione Indirizzi - Anomalie 

5 - Abilitazione Utente 

6 - Inoltro richiesta di abilitazione 

Figura 2 - Flusso di creazione utenza Avvocato 

Lo scambio di messaggi tra PdA, GC e CdO avviene per via telematica, e le comunicazioni 

sono strutturate in linguaggio XML, secondo il formato definito nel relativo decreto 

ministeriale (c.d. decreto DTD [4]). 

Di seguito la descrizione del flusso relativo alla creazione di un’utenza, nel caso particolare 

degli avvocati: 

a. L’avvocato si reca presso il proprio Consiglio dell’Ordine e richiede il certificato di 

appartenenza all’albo; 

b. L’avvocato consegna al Punto di Accesso prescelto una richiesta scritta di 

registrazione, accompagnata dal certificato di appartenenza all’albo e dalla chiave 

pubblica del proprio certificato di cifratura; 

c. Il Punto di Accesso genera l’indirizzo elettronico dell’avvocato; 

d. Il Punto di Accesso verifica che l’avvocato non abbia già un indirizzo elettronico nel 

Registro Generale degli Indirizzi, e invia al Gestore Centrale una richiesta di 

abilitazione dell’avvocato, in un formato XML che comprende codice fiscale, indirizzo 

elettronico, consiglio dell’ordine, codice del PdA, chiave pubblica del certificato di 

cifratura e dati anagrafici dell’avvocato; 

PAGINA 15 DI 133



Versione 2.0 


e. Il Gestore Centrale effettua i controlli formali sul messaggio ed in caso di esito positivo 

invia un’attestazione temporale. In caso di errore nel formato del messaggio viene 

inviata una notifica di eccezione ed il flusso viene interrotto; 

f. Il Gestore Centrale verifica il merito della richiesta. In caso di esito positivo si 

predispone all’aggiornamento del ReGIndE (che sarà operativo il giorno lavorativo 

seguente) con i dati del nuovo avvocato e invia al Punto di Accesso un file XML 

contenente gli indirizzi abilitati. In caso di esito negativo (ad esempio se l’avvocato è 

già presente nel ReGIndE) invia al Punto di Accesso un messaggio contenente 

l’anomalia; 

g. il Punto di Accesso riceve il file XML e a sua volta aggiorna il Registro Locale degli 

Indirizzi e abilita l’avvocato; 

h. il Gestore Centrale inoltra i dati degli avvocati di competenza di ciascun Consiglio 

dell’Ordine alle relative caselle di posta certificata. 

Lo scambio dei dati tra PdA, GC, CdO avviene tramite Posta Elettronica Certificata. 

Ogni Consiglio dell’Ordine nonché il Consiglio Nazionale Forense debbono disporre di una 

casella di posta elettronica certificata del processo telematico (CPECPT) per scambiare 

messaggi con il GC. L’accesso a tale CPECPT è riservato al Presidente del CdO o ad un suo 

delegato. Tale CPECPT non deve coincidere con quella eventualmente in possesso del 

Presidente del CdO (se avvocato) per la ricezione dei Biglietti di Cancelleria e delle altre 

comunicazioni per i difensori. 

Il CdO deve essere dotato dei mezzi informatici necessari alla produzione ed alla firma di file 

XML. La spedizione di tali file verso la CPECPT del Gestore Centrale viene effettuata con le 

funzionalità di gestione della CPECPT fornite dal Punto di Accesso. 

3.1.2 Messaggi scambiati 

Per la realizzazione del flusso abilitativo sopra descritto vengono scambiati fra Punto di 

Accesso, Gestore Centrale e Consiglio dell’Ordine i seguenti messaggi (gli indici sono in 

riferimento a Figura 2): 

Dal “Punto di Accesso” al “Gestore Centrale” 

1. BUSTA: “RichiestaAggiornamentoUtenze” 

ALLEGATO: “ComunicazioneIndirizzi.xml” 

SUBJECT: “POSTA CERTIFICATA: Comunicazione Indirizzi PdA: aaaa-nnnn” 

UTILIZZO: invio comunicazioni di iscrizione 

PAGINA 16 DI 133



Versione 2.0 


Figura 3 - Busta RichiestaAggiornamentoUtenze 

Dal “Gestore Centrale” al “Punto di Accesso” 

2.a BUSTA: “AttestazioneCertificata” 

ALLEGATO: “Attestazione.xml.p7m” 

SUBJECT: 

“POSTA CERTIFICATA: Attestazione: -aaaa-nnnn: GCMsgIdnn” 

UTILIZZO: Attestazione Temporale 

Figura 4 - Busta AttestazioneCertificata 

2.b BUSTA: “EccezioneCertificata” 

ALLEGATO: “Eccezione.xml” 

SUBJECT: 

“POSTA CERTIFICATA: Eccezione: -aaaa-nnnn: GCMsgIdnn” 

UTILIZZO: Notifica di Eccezione (alternativa all’attestazione temporale) 

Figura 5 - Busta EccezioneCertificata 

4.a BUSTA: “ComunicazioneIndirizzi” 


SUBJECT: “POSTA CERTIFICATA: Comunicazione Indirizzi PdA: GCMsgId-nn” 

UTILIZZO: Contiene nell’allegato i dati delle comunicazioni di iscrizione che sono 

state accettate dal Gestore Centrale 

PAGINA 17 DI 133



Versione 2.0 


Figura 6 - Busta ComunicazioneIndirizzi 

4.b BUSTA: “AnomaliaIndirizzi” 


SUBJECT: “POSTA CERTIFICATA: Anomalia PdA: -aaaa-nnnn: 

GCMsgId-nn” 

UTILIZZO: contiene nell’allegato gli elementi (comunicazioni di iscrizione) che sono 

stati rifiutati dal Gestore Centrale. 

Non è alternativa alla busta “ComunicazioneIndirizzi” 

Figura 7 - Busta AnomaliaIndirizzi 

Dal “Gestore Centrale” ai “Consigli dell’Ordine” 

6. BUSTA: “RichiestaAggiornamentoUtenze” 


SUBJECT: “POSTA CERTIFICATA: Comunicazione Indirizzi CdO: GCMsgId-nn” 

UTILIZZO: Contiene nell’allegato i dati delle comunicazioni di iscrizione che sono 

state accettate dal Gestore Centrale 

Il formato della busta è riportato in Figura 3 

Questo flusso comporta variazioni sul “Registro”, e tratta esclusivamente invio di dati 

“anagrafici”, non informazioni relative allo status del difensore. 

Possono essere trattati sia “Avvocati” sia “CTU” (per quest’ultima tipologia di utenza sono 

previste solo le buste dei punti 1, 2 e 4). 

I formati delle buste ed i DTD per la composizione degli XML in esse contenuti, sono 

pubblicati nel relativo decreto ministeriale (c.d. decreto DTD [4]). 

PAGINA 18 DI 133



Versione 2.0 


In particolare l’elemento “TipoOperazione” dell’allegato XML ComunicazioneIndirizzi 

assume il valore “I”. 

Di seguito la struttura dell’allegato ComunicazioneIndirizzi: 

Figura 8 - Struttura del file ComunicazioneIndirizzi.xml 

3.2 VARIAZIONE UTENZE 

Per effettuare la variazione dei dati di registrazione di un utente, le procedure da seguire 

ricalcano il flusso di inserimento. 

Per quanto riguarda gli avvocati, oltre alla modalità di variazione dei dati anagrafici 

richiesta dall’utente stesso (avvocato o CTU) è prevista la variazione dello stato 

PAGINA 19 DI 133



Versione 2.0 


dell’avvocato, comunicata dal Consiglio dell’Ordine (ad esempio per una sospensione o 

per la radiazione) con l’invio di un file XML di variazione dati dell’Albo firmato 

digitalmente. 

3.2.1 Variazione generata dall’utente (avvocato) 

Nel primo caso (modifica dei dati elencati all’art. 14 comma 6 delle Regole Tecniche alle 

lettere d), e), f) e g) ) il flusso previsto (nel caso di corretto invio dei messaggi) è il 

seguente: 




0 - Richiesta variazione dati 

1 - Richiesta di variazione 

2 - Attestazione Temporale 

3 – Aggiornamento ReGIndE 


5 – Aggiornamento ReLIndE 

6 - Inoltro file XML con dati di variazione 

Figura 9 - Flusso di variazione utenza - generata dall'utente Avvocato 

Lo scambio di messaggi tra PdA, GC e CdO avviene sempre per via telematica, e le 

comunicazioni sono strutturate in linguaggio XML, secondo il formato definito nel relativo 

decreto ministeriale (c.d. decreto DTD). 

Di seguito una descrizione del flusso: 

a. L’avvocato effettua la richiesta di variazione presso il proprio Punto di Accesso; 

b. Il Punto di Accesso invia al Gestore Centrale la richiesta di variazione, in un formato 

XML che comprende codice fiscale, indirizzo elettronico, consiglio dell’ordine, codice 

del PdA, chiave pubblica del certificato di cifratura e dati anagrafici dell’avvocato; 

c. Il Gestore Centrale, dopo avere effettuato i controlli formali invia al Punto di Accesso 

un’attestazione temporale in caso di esito positivo, una notifica di eccezione altrimenti. 

Quindi controlla il merito della richiesta e in caso positivo si predispone 

all’aggiornamento del ReGIndE (che sarà operativo il giorno lavorativo seguente) con i 

PAGINA 20 DI 133



Versione 2.0 


dati dell’avvocato ed invia un file XML con i dati modificati. In caso di esito negativo 

dei controlli il GC invia un messaggio contenente l’anomalia alla CPECPT del Punto 

di Accesso; 

d. il Punto di Accesso riceve il file XML e a sua volta aggiorna il Registro Locale degli 

Indirizzi; 

e. il Gestore Centrale inoltra i dati degli avvocati di competenza di ciascun Consiglio 

dell’Ordine alle relative caselle di posta certificata. 

Nota: Il caso previsto alla lettera g) dell’art. 14 comma 6 delle Regole Tecniche [1] (modifica 

del Consiglio dell’Ordine) viene trattato come una richiesta di cancellazione, che deve essere 

seguita da una nuova richiesta di registrazione. Allo stesso modo viene gestito anche il 

cambio di Punto di Accesso. 

Per i messaggi scambiati fra Punto di Accesso, Gestore Centrale e Consiglio dell’Ordine per 

la realizzazione del flusso di variazione sopra descritto si faccia riferimento al formato dei 

messaggi scambiati per il flusso di abilitazione utenze (3.1.2 Messaggi scambiati). 

Nota: L’elemento “TipoOperazione” dell’allegato XML ComunicazioneIndirizzi assume il 

valore “M”. 

3.2.2 Variazione generata dal Consiglio dell’Ordine (solo per avvocati) 

Nel caso di variazione dello stato del difensore generata dal Consiglio dell’Ordine il flusso 

previsto (nel caso di corretto invio dei messaggi) è il seguente: 

Consiglio 

dell’Ordine 


Punto di Accesso 

0 – Variazione stato difensore 

1 – Creazione XML 

2 – invio XML firmato 


4 – Variazione ReGIndE 


6 – invio XML 

7 – Aggiornamento ReLIndE 

Figura 10 - Flusso di variazione utenza - generata dal CdO 

PAGINA 21 DI 133



Versione 2.0 



comunicazioni sono strutturate in linguaggio XML, secondo i formati definiti nel relativo 

decreto ministeriale (c.d. decreto DTD) [4]. 


a. Il Consiglio dell’Ordine varia lo stato del difensore e crea il file XML contenente i dati 

dell’avvocato e il nuovo stato (attivo, sospeso, radiato, ecc.); 

b. il file XML viene firmato dal Presidente del CdO ed inviato alla casella di posta 

certificata del Gestore Centrale; 

c. Il Gestore Centrale, dopo avere effettuato i controlli formali invia alla CPECPT del 

Consiglio dell’Ordine un’attestazione temporale in caso di esito positivo, una notifica 

di eccezione altrimenti. Quindi controlla il merito della richiesta e in caso positivo si 

predispone all’aggiornamento del ReGIndE (che sarà operativo il giorno lavorativo 

seguente) con i dati dell’avvocato ed invia all’Ordine un file XML con i dati 

modificati. In caso di esito negativo dei controlli il GC invia un messaggio contenente 

l’anomalia alla CPECPT dell’Ordine; 

d. Il Gestore Centrale inoltra al Punto di Accesso il file XML ricevuto dal Consiglio 

dell’Ordine; 

e. Il Punto di Accesso aggiorna il Registro Locale degli Indirizzi. 

Per la realizzazione del flusso abilitativo sopra descritto vengono scambiati fra Punto di 

Accesso, Gestore Centrale e Consiglio dell’Ordine i seguenti messaggi: 

Dal “Consiglio dell’Ordine” al “Gestore Centrale” 

2 BUSTA: “AggiornamentoUtenze” 

ALLEGATO: “ComunicazioneIndirizzi.xml.p7m” 

SUBJECT: “POSTA CERTIFICATA: Comunicazione Indirizzi CdO: aaaa-nnnn” 

UTILIZZO: comunicazioni di variazione dati 

Figura 11 - Busta AggiornamentoUtenze 

Dal “Gestore Centrale” ai “Consigli dell’Ordine” 

3.a BUSTA: “AttestazioneCertificata” 


SUBJECT: “POSTA CERTIFICATA: Attestazione: -aaaa-nnnn: 

GCMsgIdnn” 

PAGINA 22 DI 133



Versione 2.0 



3.b BUSTA: “EccezioneCertificata” 


SUBJECT: “POSTA CERTIFICATA: Eccezione: -aaaa-nnnn: GCMsgId 

nn” 


5.a BUSTA: “ComunicazioneIndirizzi” 


SUBJECT: “POSTA CERTIFICATA: Comunicazione Indirizzi CdO: GCMsgId-nn” 

UTILIZZO: Contiene nell’allegato i dati delle comunicazioni di variazione dati che 

sono state accettate dal Gestore Centrale 

5.b BUSTA: “AnomaliaIndirizzi” 


SUBJECT: “POSTA CERTIFICATA: Anomalia CdO: -aaaa-nnnn: 

GCMsgId-nn” 

UTILIZZO: contiene nell’allegato gli elementi (comunicazioni di variazione dati) che 

sono stati rifiutati dal Gestore Centrale. 

Non è alternativa alla busta “ComunicazioneIndirizzi” 

Dal “Gestore Centrale” ai “Punti di Accesso” 

6 BUSTA: “AggiornamentoUtenze” 


SUBJECT: “POSTA CERTIFICATA: Comunicazione Indirizzi PdA: aaaa-nnnn” 


Note: Questo flusso comporta aggiornamento dei “Registri”. NON coinvolge utenze CTU. 

L’elemento “TipoOperazione” dell’allegato XML ComunicazioneIndirizzi assume il valore 

“V”. 

3.3 CANCELLAZIONE UTENZE 

La richiesta di cancellazione di un utente viene gestita come un caso particolare di variazione. 

PAGINA 23 DI 133



Versione 2.0 


Anche in questo caso la richiesta può essere generata direttamente dall’utente. 

3.3.1 Cancellazione generata dall’utente (avvocato) 

Il flusso previsto nel caso di corretto invio dei messaggi è il seguente: 




0 - Richiesta cancellazione 

1 - Richiesta di cancellazione 



3 - Aggiornamento ReGIndE 

5 - Aggiornamento ReLIndE 

6 - Inoltro file XML con richiesta di 

cancellazione 

Figura 12 - Flusso di cancellazione utenza - generata dall'Avvocato 


comunicazioni sono strutturate in linguaggio XML, secondo i formati definiti nel relativo 

decreto ministeriale (c.d.decreto DTD) [4]. 


0. L’avvocato effettua la richiesta di cancellazione presso il proprio Punto di Accesso; 

1. Il Punto di Accesso invia al Gestore Centrale la richiesta di cancellazione, nel formato 

XML delle richieste di aggiornamento dei dati dei soggetti abilitati; 

2. Il Gestore Centrale, dopo avere effettuato i controlli formali, in caso di esito positivo 

invia al Punto di Accesso un’attestazione temporale (viene altrimenti generata una 

Notifica di Eccezione). 

3. Quindi controlla il merito della richiesta e in caso positivo si predispone 

all’aggiornamento del Registro Generale degli Indirizzi Elettronici (che sarà operativo 

il giorno lavorativo seguente) cancellando (non fisicamente) l’avvocato 

4. e invia al Punto di Accesso un file XML con i dati della cancellazione. In caso di esito 

negativo dei controlli il GC invia un messaggio contenente l’anomalia alla CPECPT 

del Punto di Accesso; 

PAGINA 24 DI 133



Versione 2.0 


5. il Punto di Accesso riceve il file XML e a sua volta aggiorna il Registro Locale degli 

Indirizzi; 

6. il Gestore Centrale inoltra la richiesta di cancellazione a ciascun Consiglio dell’Ordine 

coinvolto, alle relative caselle di posta certificata. 

Per i messaggi scambiati fra Punto di Accesso, Gestore Centrale e Consiglio dell’Ordine per 

la realizzazione del flusso di cancellazione sopra descritto si faccia riferimento al formato dei 

messaggi scambiati per il flusso di abilitazione utenze (3.1.2 Messaggi scambiati). 

Nota: L’elemento “TipoOperazione” dell’allegato XML ComunicazioneIndirizzi assume il 

valore “C”. 

PAGINA 25 DI 133



Versione 2.0 


4 FLUSSI DOCUMENTALI 

I flussi documentali gestiti nell’ambito del Processo Civile Telematico che transitano 

attraverso il Punto di Accesso riguardano: 

deposito di atti informatici; 

ricezione biglietti di cancelleria; 

notifiche tra difensori; 

consegna copia. 

Nel primo caso il flusso documentale è attivato da un Avvocato che intende depositare un atto 

informatico presso un Ufficio Giudiziario. Nel contesto del presente documento ci si limiterà 

alla trattazione del processo di imbustamento e di inoltro dell’atto informatico al GC da parte 

del PdA. Verranno anche esaminati i messaggi di risposta, di direzione opposta, provenienti 

dal GC. Tali messaggi consentono di completare il ciclo logico funzionale del deposito atto, 

fornendo, nel contempo, le necessarie garanzie tecnico-legali che l’invio documentale è 

andato a buon fine e che l’atto è stato acquisito dall’Ufficio Giudiziario. 

Nel caso della ricezione dei biglietti di cancelleria il flusso trae origine dall’azione di un 

Cancelliere presso un Ufficio Giudiziario, e consente di notificare ad un Avvocato, per il 

tramite della sua CPECPT, il verificarsi di eventi rilevanti relativi ad una causa in cui egli è 

difensore di parte. Anche in questo caso è previsto un flusso di direzione opposta, innescato 

automaticamente dalla ricevuta di avvenuta consegna prodotta dal sistema di posta certificata 

del PdA presso cui la CPECPT è attestata. 

La notificazione telematica di documenti informatici tra difensori consiste nell’inoltro del 

documento dal Punto di Accesso del mittente alla CPECPT del destinatario. 

La funzione di consegna di copia conforme viene attivata tramite una funzionalità di richiesta 

di copia messa a disposizione da Polis Web. 

Nella funzione di deposito atto l’utilizzo del protocollo SMTP negli scambi tra PdA e GC è 

strumentale allo scambio di dati, mentre nei restanti flussi viene fatto uso dei meccanismi 

previsti dalla Posta Certificata nella specifica estensione definita dalle “Norme tecnicooperative 

del Processo Telematico”. Nel seguito della trattazione si farà ampio riferimento 

alla nomenclatura utilizzata da tale standard al quale si rimanda per maggiori approfondimenti 

(vedi Riferimenti, documento “Posta Certificata – Allegato Tecnico”). 

4.1 IL DEPOSITO DI UN ATTO 

Il deposito di un atto consiste nel suo complesso in un flusso attivato da un Avvocato e avente 

come destinatario un Ufficio Giudiziario e in un flusso di risposta che segnala l’esito del 

PAGINA 26 DI 133



Versione 2.0 


deposito. Come passo intermedio è previsto l’invio da parte del GC di un ulteriore messaggio 

di risposta che fornisce l’indicazione dell’ora in cui il deposito si intende effettuato 2 . 

Tali flussi, realizzati per il tramite delle varie entità tecnico-organizzative del PCT, sono 

rappresentati nella figura che segue: 

Avvocato Punto di Accesso Gestore Centrale Ufficio Giudiziario 

Inoltro atto 

Controllo formale e 

imbustamento atto 

Inoltro atto 

Controllo formale atto 

Attestazione Temporale 

Comunicazione esito 

controlli 

Invio esito 

Inoltro atto 

Comunicazione esito 

controlli 

Invio esito 

Verifiche e 

controlli 

automatici 

OK 

cancelliere 

Figura 13 - Sequence diagram del deposito atto 

Le interazioni tra PdA e GC avvengono attraverso lo scambio di messaggi basati su 

protocollo SMTP. Il GC riceve tali messaggi all’indirizzo 

gestorecentrale@processotelematico.giustizia.it 

I messaggi hanno una testata SMTP standard in cui devono essere impostati correttamente 

(vedi “Riferimenti”, documento “RFC822”) almeno i parametri “MSG-ID” e “FROM” (da 

utilizzare per individuare la provenienza del messaggio quando non è possibile procedere 

all’apertura della busta ricevuta). 

2 Solamente nel caso in cui vengano superati i controlli formali eseguiti sulla busta ricevuta. 

PAGINA 27 DI 133



Versione 2.0 


Al PdA viene anche richiesto di implementare il servizio SMTP standard di Delivery Status 

Notification (DSN), che assume il valore di ricevuta debole dei messaggi di risposta trasmessi 

dal SICI. La ricezione del DSN da parte del GC consente di controllare il corretto 

completamento del flusso logico della funzione. 

Per la realizzazione del flusso di deposito atto vengono scambiati fra Punto di Accesso e 

Gestore Centrale i seguenti messaggi: 

Dal “Punto di Accesso” al “Gestore Centrale” 

1. BUSTA: “InoltroAtto” 

ALLEGATO: “InfoInoltro.xml” 

ALLEGATO: “Atto.enc” 

ALLEGATO: “Certificazione.xml.p7m” (solo per PdA dei Consigli dell’Ordine) 

SUBJECT: “Comunicazione Indirizzi PdA: -aaaa-nnnn” 



2.a BUSTA: “AttestazioneTemporale” 


SUBJECT: “Attestazione - biz” 


2.b BUSTA: “NotificaEccezione” 


SUBJECT: “Notifica Eccezione - biz” 


3 BUSTA: “ComunicazioneEsitoControlli” 

ALLEGATO: “EsitoAtto.xml.p7m” 

SUBJECT: “EsitoAttoAuto - biz” 

UTILIZZO: Esito controlli automatici 

4 BUSTA: “ComunicazioneEsito” 

ALLEGATO: “EsitoAtto.xml.p7m” 

SUBJECT: “EsitoAtto - biz” 

UTILIZZO: Esito cancelleria 

PAGINA 28 DI 133



Versione 2.0 


4.1.1 Fase di trasmissione dell’atto 

Come anticipato precedentemente, la sequenza dei messaggi scambiati tra PdA e GC nella 

fase di trasmissione dell’atto può dare luogo a diverse alternative in funzione dell’esito dei 

controlli operati dal GC sulla busta ricevuta. Se tale busta è formalmente corretta il messaggio 

trasmesso è di attestazione temporale; altrimenti viene prodotto e spedito un messaggio di 

notifica eccezione 3 che segnala l’impossibilità di inoltrare l’atto a destinazione. 

Nel caso in cui il messaggio di inoltro atto ricevuto dal PdA sia corretto la sequenza e il tipo 

di messaggi scambiati è indicata nello schema seguente: 

Punto di Accesso Gestore Centrale Gestore Locale 

1: Inoltro Atto 

2: Deposito Atto 

3: Attestazione 

Temporale 

4: DSN 

Figura 14 - Sequence diagram del deposito atto in caso di attestazione temporale 

Nel caso in cui il GC riscontri un errore nel messaggio di inoltro dell’atto, oltre a non 

procedere al deposito presso il GL, invia al PdA un messaggio di notifica eccezione; sarà cura 

dell’utente mittente provvedere ad una nuova trasmissione. 

3 L’invio di un messaggio di notifica eccezione richiede comunque il soddisfacimento dei requisiti minimi di identificazione del PdA mittente 

cui spedire il messaggio di risposta. 

PAGINA 29 DI 133



Versione 2.0 




1: Inoltro Atto 

2: Notifica 

Eccezione 

3: DSN 

Figura 15 - Sequence diagram del deposito atto in caso di notifica di eccezione 

Il GC svolge quindi una funzione di garante del processo di inoltro assicurando che gli atti 

informatici depositati presso i GL non contengano errori attribuibili alle attività svolte dai 

PdA, ma solo eventualmente ascrivibili ad operazioni svolte in locale dall’Avvocato in fase di 

formazione dell’atto informatico. 

Nel seguito del documento viene descritta la struttura applicativa di ciascun messaggio 

generato nella fase di trasmissione dell’atto e in allegato vengono forniti i DTD di ciascuna 

struttura XML utilizzata. 

4.1.1.1 Struttura del messaggio di “inoltro atto” 

La struttura del messaggio SMTP di inoltro atto proveniente da un PdA è illustrata nella 

figura che segue: 

Figura 16 - S/MIME di Inoltro Atto 

Essa è costituita da un S/MIME, cioè da una struttura MIME sottoscritta da parte del PdA con 

proprio certificato server, a titolo di verifica della integrità del messaggio. 

Pertanto al suo interno è riconoscibile: 

• una struttura MIME contenente l’atto informatico e le informazioni di inoltro; 

PAGINA 30 DI 133



Versione 2.0 


• l’hash del MIME, cioè la registrazione in formato binario che contiene l’impronta del 

documento, firmata secondo le modalità tecniche previste dal D.P.R. 513/97 e dalle 

relative regole tecniche (D.P.C.M. 8/02/99). 

• il Certificato del PdA, ossia una struttura dati tipo X.509. I dati forniscono informazioni 

sul possessore del certificato, il firmatario del certificato, la versione, il numero seriale, 

l’algoritmo di firma, il periodo di validità, la corrispondente chiave pubblica e altri dati. 

Le parti costituenti la struttura MIME sono appresso descritte. 

File InfoInoltro.xml 

Il file InfoInoltro.xml contiene le informazioni di servizio per il GC. Tali informazioni 

consentono il routing del messaggio e la verifica dei dati di certificazione. 

Il file ha la seguente struttura: 

Figura 17 - Struttura del file InfoInoltro.xml 

• IdMsgPdA. 

Riporta l’identificativo univoco del messaggio generato dal PdA. Tali dati sono: 

CodicePdA = E’ il codice identificativo del PdA. 

Anno = E’ l’anno di generazione del messaggio. 

IdMsg = E’ un progressivo numerico univoco nell’ambito dell’anno. 

• Mittente. 

CodiceFiscale = È il codice fiscale dell’Avvocato che ha originato il messaggio. 

L’attributo ruolo indica il ruolo assunto dal mittente (al momento “Avvocato”). 

• Destinatario. 

CodiceUG = È il codice identificativo dell’UG destinatario. 

L’attributo tipo indica il tipo di destinatario (al momento “Ufficio”). Al momento è previsto 

un solo destinatario. 

• IdMsgMitt. 

IdMsgMitt = È l’identificato assegnato dall’Avvocato all’atto informatico. 

PAGINA 31 DI 133



Versione 2.0 


File Atto.enc 

Il file Atto.enc è l’atto informatico prodotto dall’Avvocato, criptato utilizzando la chiave 

pubblica di cifratura dell’UG destinatario. 

Il Punto di Accesso non entra nel merito del formato e del contenuto di questo file, che viene 

inoltrato verso il Gestore Centrale (e da questi verso il Gestore Locale) senza nessuna 

elaborazione. 

Il Gestore Locale dell’Ufficio Giudiziario destinatario potrà poi decrittarlo con la propria 

chiave privata, per verificarne la validità formale e del contenuto. 

File Certificazione.xml.p7m 

Il file Certificazione.xml.p7m può mancare nella busta di inoltro atto se il PdA non dispone 

delle informazioni atte a certificare l’Avvocato. 

Per certificazione del difensore si intende l’attestazione di iscrizione all'albo, all’albo 

speciale, al registro dei praticanti abilitati ovvero di possesso della qualifica che legittima 

l’esercizio della difesa e l'assenza di cause ostative allo svolgimento dell'attività difensiva. 

La certificazione del difensore è svolta dal Punto di Accesso, qualora questo sia gestito da un 

consiglio dell'ordine degli avvocati o dal Consiglio nazionale forense. Il Consiglio nazionale 

forense compie il servizio di certificazione dei difensori per i propri iscritti o per gli iscritti 

dei consigli dell'ordine, su delega di questi ultimi. 

Qualora il Punto di Accesso non effettui la certificazione del difensore, vi provvede il Gestore 

Centrale, sulla base di copia dell'albo fornita al Ministero della Giustizia e aggiornata dai 

consigli dell'ordine degli avvocati e dal Consiglio nazionale forense. 

Se presente, tale file è firmato dal PdA (firma server) ed ha la seguente struttura: 

Figura 18 - Struttura del file Certificazione.xml 

• CodiceFiscale. 

CodiceFiscale 

= È il codice fiscale dell’Avvocato che si certifica (deve coincidere 

con InfoInoltro/Mittente/CodiceFiscale). 

PAGINA 32 DI 133



Versione 2.0 


• DatiCertificazione. 

Riporta i dati risultanti nell’albo elettronico all’atto della certificazione 

CodiceOrdine = E’ l’organizzazione (CdO) che ha fornito i dati per la 

certificazione dello status dell’Avvocato. 

CodiceStatus 

Data 

Ora 

= 

= 

= 

E’ il codice dello status professionale dell’Avvocato risultante 

all’atto della certificazione (attivo, sospeso, radiato, ecc.). 

E’ la data in cui viene eseguita la certificazione. 

E’ l’ora in cui viene eseguita la certificazione. 

• EntitaCertificante. 

EntitaCertificante = In questo caso è il codice del PdA che ha eseguito la 

certificazione. 

4.1.1.2 Struttura del messaggio di “attestazione temporale” 

Se la busta ricevuta è formalmente corretta, il GC genera e trasmette al PdA da cui ha 

ricevuto la richiesta di inoltro dell’atto un messaggio di Attestazione temporale, la cui 

struttura è la seguente: 

Figura 19 - MIME di Attestazione temporale 

Il subject della busta di Attestazione Temporale sarà nel formato: 

Attestazione - biz::=?biz? 

dove “?biz?” è un identificativo univoco prodotto dal Gestore Centrale. 

Il messaggio contiene allegato all’interno della struttura MIME il file Attestazione.xml.p7m 

che ha la seguente struttura: 

PAGINA 33 DI 133



Versione 2.0 


Figura 20 - Struttura del file Attestazione.xml 

• IdMsgSMTP. 

IdMsgSMTP 

= In questo caso non è valorizzato (tale elemento è alternativo 

rispetto a i due successivi). 


IdMsgMitt = È l’identificato assegnato dall’Avvocato all’atto informatico 

(ricavato da InfoInoltro/IdMsgMitt) 

• IdMsgPdA. 

È l’identificato del messaggio di inoltro atto generato dal PdA (ricavato da 

InfoInoltro/IdMsgPdA) 



IdMsg = E’ un progressivo numerico univoco nell’ambito dell’anno. 

• DatiAttestazione. 

Contiene l’impronta della busta ricevuta (nel formato S/MIME) e la data e ora dell’evento 

di attestazione temporale 

Impronta = Impronta del file S/MIME ricevuto dal PdA 

Data = Data di produzione dell’attestazione temporale 

Ora = Ora di produzione dell’attestazione temporale 

4.1.1.3 Struttura del messaggio di “notifica eccezione” 

Qualora il GC riscontri un errore nella formazione della busta di inoltro atto, oltre a non 

eseguire il deposito dell’atto, genera e trasmette al PdA da cui ha ricevuto la richiesta di 

inoltro dell’atto un messaggio di Notifica eccezione. 

PAGINA 34 DI 133



Versione 2.0 


Il messaggio ha la seguente struttura: 

Figura 21 - MIME di Notifica eccezione 

Il subject della busta di Notifica Eccezione sarà nel formato: 

Notifica Eccezione - biz::=?biz? 

dove “?biz?” è un identificativo univoco prodotto dal Gestore Centrale. 

All’interno della struttura MIME è presente in allegato il file Eccezione.xml che ha la 

seguente struttura: 

Figura 22 - Struttura del file Eccezione.xml 

• IdMsgSMTP. 

IdMsgSMTP = È l’identificativo SMTP del messaggio ricevuto (parametro 

Message-ID). Tale identificativo potrebbe costituire l’unico 

modo di identificare il messaggio, qualora non fosse possibile 

eseguirne lo sbustamento. 

• IdMsgPdA. 

È l’identificato del messaggio di inoltro atto generato dal PdA (ricavato da 




IdMsg = E’ un progressivo numerico univo nell’ambito dell’anno. 

• DatiEccezione. 

CodiceEccezione = È il codice identificativo dell’errore riscontrato. 

DescrizioneEccezione = 

È la descrizione dell’errore riscontrato. 

PAGINA 35 DI 133



Versione 2.0 


In 8.4Anagrafica degli errori riportati dal Gestore Centrale vengono riportati i possibili 

codici di Eccezione e le relative descrizioni. 

4.1.2 Fase di trasmissione dell’esito dell’atto 

La sequenza e il tipo di messaggi scambiati in fase di trasmissione dell’esito dell’atto è 

indicata nello schema seguente: 

Punto di Accesso Gestore Centrale Ufficio Giudiziario 

2: Comunicazione esito 

controlli 

3: DSN 

1: esito controlli 

automatici 

4: esito 

5: Comunicazione esito 

6: DSN 

Figura 23 - Sequence diagram del deposito atto – Fase di trasmissione dell’esito dell’atto 

È quindi previsto l’invio al PdA di due tipologie di Comunicazione esito generate dal 

Gestore Locale e veicolate dal GC: 

• l’invio dell’esito di controlli automatici effettuati sulle buste depositate presso un 

Ufficio Giudiziario 

• il messaggio di Comunicazione esito generato a seguito di intervento del Cancelliere 

Non è previsto un preciso ordine sequenziale di arrivo degli esiti presso la casella di posta 

ordinaria del Punto di Accesso. 

4.1.2.1 Struttura del messaggio di “comunicazione esito” 

Quando il GC riceve un messaggio di esito atto dal GL (esito controlli automatici o esito di 

cancelleria), attraverso l’identificativo del messaggio (IdMsgGC) ricava tutte le informazioni 

necessarie per generare e recapitare al PdA un messaggio di Comunicazione esito. 

Il messaggio ha la seguente struttura: 

PAGINA 36 DI 133



Versione 2.0 


Figura 24 - MIME di Comunicazione esito 

Il messaggio contiene allegato all’interno della struttura MIME il file EsitoAtto.xml.p7m, 

firmato dall’UG. Tale file ha la seguente struttura: 

Figura 25 - Struttura del file EsitoAtto.xml 


IdMsgMitt 

= È l’identificativo assegnato dall’Avvocato all’atto informatico 

(ricavato da InfoInoltro/IdMsgMitt) 

• IdMsgPdA. 

È l’identificativo del messaggio di inoltro atto generato dal PdA (ricavato da 




IdMsg = E’ un progressivo numerico univo nell’ambito dell’anno. 

• DatiEsito. 

Impronta = Contiene l’impronta del file Atto.enc. 

NumeroRuolo = Contiene il numero di ruolo assegnato al fascicolo. (Presente 

solamente se l’atto depositato era una iscrizione a ruolo). 

PAGINA 37 DI 133



Versione 2.0 


CodiceEsito = Contiene il codice dell’esito dell’atto depositato. 

I possibili codici di esito sono: 

1 Esito positivo generato in automatico dal sistema 

2 Esito positivo generato manualmente dal Cancelliere 

-1 Esito negativo (si per esito automatico, sia per esito generato dal Cance 

DescrizioneEsito = Contiene la descrizione dell’esito dell’atto depositato. 

Data = E’ la data in cui è stato generato l’esito. 

Ora = E’ l’ora in cui è stato generato l’esito. 

Le due tipologie di esito verranno differenziate in base al subject della busta: 

• esito dei controlli automatici avrà come subject: 

EsitoAttoAuto – 

biz::= \private$\prt_attendi_dsn_generico{} 

• esito atto generato da cancelleria avrà come subject: 

EsitoAtto – 

biz::= \private$\prt_attendi_dsn_generico{} 

In 8.3 Descrizione Messaggi di EsitoAtto vengono riportati i messaggi di errore che possono 

essere notificati all’Avvocato in Esito Atto generato dai controlli automatici e in esito Atto 

generato dal cancelliere. 

PAGINA 38 DI 133



Versione 2.0 


4.2 L’INVIO DI UN BIGLIETTO DI CANCELLERIA 

La funzione in oggetto prevede l’invio di un messaggio di posta elettronica certificata (il 

biglietto di cancelleria) alla CPECPT di un Avvocato, e un flusso di risposta, di direzione 

opposta, innescato dalla produzione automatica della ricevuta di avvenuta consegna da parte 

del sistema di Posta Elettronica Certificata del Processo Telematico (PECPT) del PdA che 

gestisce la CPECPT. 

Giova ricordare che nell’ambito dei meccanismi di scambio previsti dalla Posta Certificata del 

Processo Telematico il sistema PECPT del PdA deve generare anche una ricevuta di presa in 

carico. Tale ricevuta viene prodotta dal server di dominio del sistema PECPT del PdA ed è 

destinata al corrispondente server mittente del GC. 

Il flusso del biglietto di cancelleria è originato dall’azione di un cancelliere presso un UG e 

sfrutta il corrispondente GL per la trasmissione della richiesta al GC (ComunicazioneUG). 

Il contenuto del messaggio ricevuto dal GC viene immesso nel circuito di Posta Certificata 

del Processo Telematico e trasmesso al destinatario utilizzando come mittente la CPECPT del 

GL che ha inoltrato la richiesta (@giustiziacertpt.it). 

Quando la CPECPT mittente riceve la ricevuta di avvenuta consegna il GC attiva un flusso di 

elaborazione che genera un messaggio di risposta verso il GL (Ricevuta Comunicazione). 

Lo schema seguente illustra la sequenza dei messaggi scambiati: 

Gestore locale Gestore Centrale Punto di Accesso 

1: ComunicazioneUG 

2: Biglietto di 

Cancelleria 

4: Ricevuta 

Comunicazione 

3: Ricevuta Avvenuta 

Consegna 

Figura 26 - Sequence diagram dell’invio di un biglietto di cancelleria 

4.2.1 Il messaggio di “biglietto cancelleria” 

Ricevuto il messaggio ComunicazioneUG da parte del GL, il servizio SMTP del GC genera 

un messaggio di Posta Certificata del Processo Telematico che ha la seguente struttura: 

PAGINA 39 DI 133



Versione 2.0 


Figura 27 - S/MIME del Biglietto di Cancelleria 

Il messaggio riporta come destinatario, la CPECPT dell’Avvocato cui la comunicazione è 

destinata, e come mittente la CPECPT del GL dal quale è stata ricevuta la comunicazione. 

Per la realizzazione del flusso di consegna del Biglietto di Cancelleria vengono scambiati fra 

Punto di Accesso e Gestore Centrale i seguenti messaggi: 


BUSTA: “BigliettodiCancelleria” 

ALLEGATO: “InfoIndirizzamento.xml” 

ALLEGATO: “AttoUG.enc” 

SUBJECT: “POSTA CERTIFICATA: Biglietto di Cancelleria: ?GCMsgID?” 

Dove “?GCMsgID?” è l’identificativo univo assegnato dal Gestore Centrale 

UTILIZZO: Biglietto di Cancelleria 

Gli allegati contenuti all’interno di Postacert.eml sono di seguito descritti. 

AttoUG.enc 

Il file AttoUG.enc corrisponde alla comunicazione, firmata dall’UG che l’ha generata (firma 

server) e contiene il file Comunicazione.xml (firmato) ed eventuali documenti allegati. 

Il file Comunicazione.xml ha la seguente struttura: 

PAGINA 40 DI 133



Versione 2.0 


dove: 

NumeroRuolo 

Figura 28 – Struttura del file Comunicazione.xml 

= Numero di iscrizione a ruolo del fascicolo cui si 

riferisce il biglietto di cancelleria 

Oggetto = Oggetto del biglietto 

Contenuto = Testo della comunicazione 

CodiceUG = Codice dell’Ufficio Giudiziario mittente 

CodiceFiscaleDestinatario = Codice Fiscale dell’Avvocato destinatario 

Data = Anno di 4 cifre; mese di 2 cifre; giorno di 2 cifre; 

carattere di separazione "-" (ISO 8601 esteso). Es.: 

2003-09-16 

Ora = Ora di 2 cifre (formato H24); minuti di 2 cifre; 

secondi di 2 cifre; carattere di separazione ":". Es.: 

13:08:09 

InfoIndirizzamento.xml 

Il file InfoIndirizzamento.xml contiene tutte le informazioni necessarie al routing del 

messaggio, il numero di ruolo e l’oggetto del biglietto di cancelleria. 

Ha la seguente struttura: 

PAGINA 41 DI 133



Versione 2.0 


Figura 29 - Struttura del file InfoIndirizzamento.xml 

dove: 

TipoFlusso = Il tipo flusso può assumere i seguenti valori: 

DAT, per il "Deposito Atto" (quindi per l'esito) 

BDC, per il "Biglietto di Cancelleria" 

CCC, per la "Consegna Copia" 

Versione 

= Versione del chiamante nella forma M.m.r (ad 

esempio: 2.5.1) 

IdSorgente = Terna identificativa assegnata dal sistema mittente 

Codice = Codice identificativo. Nel caso di persone fisiche e' 

il Codice Fiscale. 

Anno 

= L'anno deve essere di quattro cifre "aaaa" , ad 

esempio 2005 

Progressivo = Il progressivo deve essere numerico , ad esempio 

12345 

Mittente = Mittente del messaggio 

Destinatario = Destinatario del messaggio 

PAGINA 42 DI 133



Versione 2.0 


NumeroRuolo = Numero di iscrizione a ruolo 

Oggetto = Oggetto del messaggio 

Tempo = Data di invio del messaggio 

Data = Anno di 4 cifre; mese di 2 cifre; giorno di 2 cifre; 

carattere di separazione "-" (ISO 8601 esteso). Es.: 

2003-09-16 

Ora 

= Ora di 2 cifre (formato H24); minuti di 2 cifre; 

secondi di 2 cifre; carattere di separazione ":". Es.: 

13:08:09 

PAGINA 43 DI 133



Versione 2.0 


4.3 FLUSSO DI NOTIFICHE TRA DIFENSORI (TRAMITE CPECPT) 

La notificazione telematica di documenti informatici tra difensori consiste nell’inoltro del 

documento dal Punto di Accesso del mittente alla CPECPT del destinatario. A tale scopo il 

Punto di Accesso deve trasmettere il messaggio con il documento da notificare al Gestore 

Centrale dell'accesso che, a sua volta, inoltra il messaggio ricevuto al Punto di Accesso di 

destinazione. 

Di seguito viene descritto il flusso organizzativo, illustrato nel sequence diagram riportato in 

Figura 30, previsto per quanto di competenza del Punto di Accesso: 

1 l’avvocato prepara in locale la busta contenente la comunicazione. Questa viene firmata 

digitalmente e, se necessario, anche cifrata con la chiave pubblica dell’avvocato 

destinatario. La busta comprende anche le indicazioni di routing del messaggio in chiaro, 

in modo analogo a come avviene per l’inoltro atto, all’interno del file InfoNotifica.xml; 

2 l’avvocato si autentica sul proprio PdA e seleziona la funzionalità di invio comunicazione 

ad avvocato; 

3 il PdA esegue l’upload dei dati, effettua i controlli necessari, completa il file XML 

contenente le informazioni di instradamento del messaggio ed invia la busta via SMTP al 

GC; 

4 se corretta il GC appone l’Attestazione Temporale alla comunicazione, e la indirizza alla 

CPECPT dell’avvocato mittente e, insieme al messaggio, alla CPECPT dell’avvocato 

destinatario; 

5 la CPECT del destinatario, ricevuto il messaggio, invia al Gestore Centrale dell’accesso 

la ricevuta di avvenuta consegna; 

6 all’atto della ricezione della ricevuta di avvenuta consegna (RAC) da parte del PdA 

dell’avvocato destinatario, il GC esegue una nuova attestazione temporale: questa viene 

inviata alla CPECPT dell’avvocato destinatario e, insieme alla RAC, inserita in un 

messaggio indirizzato alla CPECPT dell’avvocato mittente; 

Nota: non è previsto l’invio di una notifica a più di un destinatario o a liste di destinatari. 

Per inviare comunicazioni e notifiche ad altri avvocati, ciascun avvocato deve conoscerne il 

codice fiscale e, qualora la comunicazione debba essere cifrata, deve avere a disposizione sul 

proprio posto di lavoro la chiave pubblica di cifratura del destinatario. Tali informazioni sono 

reperibili tramite un servizio di accesso LDAP per l’interrogazione del Registro degli 

Indirizzi Elettronici sul Gestore Centrale, come descritto in 6.1 Accesso al REGIndE per il 

reperimento di indirizzi e certificati degli avvocati. 

Il flusso previsto nel caso di corretto invio dei messaggi è il seguente: 

PAGINA 44 DI 133



Versione 2.0 


PdA Avvocato 

mittente 

CPECPT Avvocato 

mittente 


CPECPT Avvocato 

destinatario 

Invio messaggio da notificare (M) 


(AT1) 


(AT1) 

inoltro messaggio 


su RAC(M) 

inoltro ricevuta 


Figura 30 - Notifiche avvocato-avvocato 

Nella figura di seguito riportata, viene descritto in dettaglio il flusso delle notifiche tra 

difensori, mettendo in evidenza i messaggi scambiati tra le caselle di posta certificata degli 

attori coinvolti, includendo le ricevute di avvenuta consegna (RAC), ma considerando nel 

contesto non significative e quindi tralasciando le ricevute di presa in carico e di accettazione. 

PAGINA 45 DI 133



Versione 2.0 


Figura 31 - Dettaglio delle notifiche avvocato-avvocato 

4.3.1 Invio delle notifiche avvocato-avvocato 

La funzione consente ad un avvocato di inviare ad un altro avvocato una notifica o una 

comunicazione, sotto forma di documento informatico. 

La busta predisposta dall’avvocato localmente contiene le informazioni di instradamento 

dell’atto (file InfoNotifica.xml) e l’atto informatico cifrato (file Notifica.enc). 

Il PdA verificata la correttezza della struttura della busta caricata dall’avvocato crea un 

identificativo univoco (a livello PdA) dell’atto informatico da inoltrare (IdMsgPdA) 

aggiornando il file InfoNotifica.xml; infine crea e firma la busta da inviare al GC. 

La struttura del messaggio SMTP di ConsegnaNotifica che il PdA invia alla CPECPT del 

Gestore Centrale è illustrata nella figura che segue: 

Figura 32 - S/MIME di InoltroNotificaAvvocato 

Il subject del messaggio SMTP sarà nel formato: 

PAGINA 46 DI 133



Versione 2.0 


POSTA CERTIFICATA: Notifica: -aaaa-nnnnnnnnn 

File InfoNotifica.xml 

Il file InfoNotifica.xml contiene le informazioni di servizio per il GC. Il file ha la seguente 

struttura: 

Figura 33 - Struttura del file InfoNotifica.xml 

• IdMsgPdA 

Riporta l’identificativo univoco del messaggio generato dal PdA. Tali dati sono: 

CodicePdA = è il codice identificativo del PdA. 

Anno 

= è l’anno di generazione del messaggio. 

IdMsg 

= è un progressivo numerico univoco nell’ambito dell’anno. 

• Mittente 

CodiceFiscaleMitt = è il codice fiscale dell’Avvocato che ha originato il messaggio. 

• Destinatario 

CodiceFiscaleDest = è il codice fiscale dell’Avvocato destinatario. 


IdMsgMitt = è l’identificato assegnato dall’Avvocato al documento 

informatico 

File Notifica.enc 

Il file Notifica.enc è la notifica prodotta dall’Avvocato, cifrato utilizzando la chiave pubblica 

di cifratura dell’avvocato destinatario. 

Il Punto di Accesso non entra nel merito del formato e del contenuto di questo file, che viene 

inviato alla CPECPT del Gestore Centrale e da questi inoltrato alla CPECPT dell’Avvocato 

destinatario. 

PAGINA 47 DI 133



Versione 2.0 


4.3.2 Attestazioni temporali ricevute a seguito dell’invio di notifiche (Avvocato mittente) 

A seguito dell’invio di notifiche tra difensori, il Gestore Centrale emette delle attestazioni 

temporali a seguito di due eventi: 

• quando riceve una notifica (formalmente corretta) da inoltrare (AT1 in Figura 30); 

• quando riceve la ricevuta di avvenuta consegna (RAC) dal Punto di Accesso 

dell’avvocato destinatario. (RAC(M)+AT2 in Figura 30) 

Entrambe le attestazioni sono inviate alle caselle di posta certificata dell’avvocato mittente e 

del destinatario. 

Nel caso della ricezione da parte dell’avvocato mittente della seconda attestazione temporale, 

questa è accompagnata all’interno della busta dalla Ricevuta di Avvenuta Consegna emessa 

dal sistema di Posta Certificata del PdA destinatario della notifica. 

Nel caso in cui si sia verificato un errore nell’esecuzione dell’invio della notifica il Gestore 

Centrale emette notifiche di eccezione inviate al posto di un messaggio di attestazione 

temporale. 

La struttura del MIME di Attestazione temporale (AT1) è schematizzata nella figura che 

segue: 

Figura 34 - MIME di Attestazione temporale 

dove la struttura del file Attestazione.xml è la seguente: 

Figura 35 - Struttura del file Attestazione.xml 

PAGINA 48 DI 133



Versione 2.0 



IdMsgMitt 

= è l’identificativo assegnato dall’Avvocato mittente alla Notifica 

(ricavato da InoltroNotifica /IdMsgMitt) 

• IdMsgPdA. 

È l’identificato del messaggio di inoltro notifica generato dal PdA (ricavato da 

InoltroNotifica /IdMsgPdA): 

CodicePdA = è il codice identificativo del PdA. 

Anno 

= è l’anno di generazione del messaggio. 

IdMsg 


• DatiAttestazione. 

Contiene l’impronta della busta ricevuta (nel formato S/MIME) e la data e ora dell’evento 

di attestazione temporale: 

Impronta = Impronta del file S/MIME ricevuto dal PdA (InoltroNotifica) 

Tempo 

= Data e ora di produzione da parte del GC dell’attestazione 

temporale del messaggio di InoltroNotifica 

IdMsg 


La struttura del MIME di Attestazione temporale ((RAC(M)+AT2) contenente Attestazione 

temporale e Ricevuta di Avvenuta Consegna è schematizzata nella figura che segue: 

Figura 36 - S/MIME di AttestazioneConsegnaNotifica 

L’allegato Attestazione.xml.p7m ha la stessa struttura di Figura 34. 

4.3.3 Ricezione notifiche e relative attestazioni temporali (Avvocato destinatario) 

A seguito dell’invio di notifiche tra difensori, il Gestore Centrale emette delle attestazioni 

temporali a seguito di due eventi: 

• quando riceve una notifica (formalmente corretta) da inoltrare; 

• quando riceve la ricevuta di avvenuta consegna (RAC) dal Punto di Accesso 

dell’avvocato destinatario. 

PAGINA 49 DI 133



Versione 2.0 


Entrambe le attestazioni sono inviate alle caselle di posta certificata dell’avvocato mittente e 

del destinatario. 

La prima attestazione viene inviata all’avvocato destinatario in una busta che contiene anche 

il messaggio di notifica stesso (busta di ConsegnaNotifica), il cui Subject sarà nella forma: 

POSTA CERTIFICATA: Consegna Notifica: -aaaa-nnnnnnnnn: GCMsgId-nn 

Figura 37 - Busta di ConsegnaNotifica 

La seconda attestazione viene inviata all’avvocato destinatario all’interno della busta di 

AttestazioneNotifica: 

Figura 38 - Busta di AttestazioneNotifica 

La struttura del MIME di Attestazione temporale è la stessa della prima attestazione 

temporale ricevuta dal mittente, schematizzata in Figura 34; la struttura del file 

Attestazione.xml è schematizzata in Figura 35. 

PAGINA 50 DI 133



Versione 2.0 


4.4 FUNZIONE DI RICHIESTA E RICEZIONE DELLA COPIA CONFORME 

La funzione consente di accedere alla funzionalità di richiesta della copia conforme, messa a 

disposizione da Polis Web, e di accedere alla copia dei documenti rilasciati dall’Ufficio 

Giudiziario. 

Per il momento si può ipotizzare che la funzionalità si componga di due fasi distinte: 

1. la prima fase consiste nell’esecuzione di una richiesta sincrona, gestita da PolisWeb, 

che la invia all’Ufficio Giudiziario. Viene restituito un esito, che indica se la 

richiesta è stata accolta o meno. Per le specifiche della richiesta sincrona si faccia 

riferimento al relativo WSDL descritto in decreto DTD [4] 

2. la seconda fase avviene in modo asincrono, e consiste nell’invio da parte 

dell’Ufficio Giudiziario del documento richiesto (o dei documenti richiesti). L’invio 

avviene con un messaggio di posta elettronica certificata attraverso l’invio della 

busta ConsegnaCopiaConforme il cui schema è riportato in Figura 39. Il PdA deve 

garantire che il documento possa essere scaricato sul client del richiedente, dove il 

documento può essere decifrato. 

Figura 39 - Busta di ConsegnaCopiaConforme 

Nota: il flusso descritto potrà subire delle variazioni nella notazione “Consegna Copia 

Conforme” che potrà essere sostituita da “Consegna Copia”. 

PAGINA 51 DI 133



Versione 2.0 


5 CONSULTAZIONI 

Nell’ambito del Processo Civile Telematico l’attuale sistema PolisWeb fornisce una serie di 

servizi informativi riguardanti sia la giurisprudenza che la gestione operativa dei fascicoli e 

delle udienze del Contenzioso Civile relative ad ogni singolo Ufficio Giudiziario. 

Ogni funzionalità di consultazione realizzata nel sottosistema PolisWeb è di tipo sincrono e 

prevede un flusso che si scompone in: 

• flusso di richiesta verso l’Ufficio Giudiziario; 

• flusso di risposta dall’Ufficio Giudiziario. 

Il flusso di consultazione è sempre attivato dall’utente (al momento un Avvocato) che invia la 

propria richiesta all’Ufficio Giudiziario transitando per il Gestore Centrale. All’interno 

dell’UG il sottosistema Gestore Locale predispone le informazioni ottenute a seguito 

dell’interrogazione del SICI e del sottosistema di gestione del fascicolo informatico 

(repository documentale) e le inoltra al PolisWeb, per il tramite del GC. 

Il Gestore Locale implementa i propri servizi di consultazione attraverso dei Web Service e 

PolisWeb interagisce con essi utilizzando il protocollo di trasporto HTTPS e la 

serializzazione dei messaggi nel formato XML/SOAP. Le funzionalità fornite da un Web 

Service e le relative regole di invocazione vengono descritte in interfacce chiamate WSDL. 

Nella figura successiva è rappresentato il diagramma di sequenza relativo alla consultazione 

dei procedimenti personali e degli atti tramite l’applicazione Polis Web fornita sul Punto di 

accesso. 

PAGINA 52 DI 133



Versione 2.0 


Avvocato 

PolisWeb: 

Punto di Accesso Gestore Centrale Ufficio Giudiziario 

Richiesta consultazione 

Verifica Autenticazione 

Conferma Autenticazione 

Consultazione 

informazioni 

Richiesta info a UG 

Inoltro Risposta info da UG 

Inoltro Richiesta info a UG 

Risposta info da UG 

Figura 40 - Sequence diagram Consultazione Web 

L’interfaccia applicativa permette l’attivazione di PolisWeb, installato presso un Punto di 

Accesso, a seguito dell’autenticazione effettuata e delegata al Punto di Accesso stesso. 

A seguito dell’autenticazione di un utente da parte del Punto di Accesso, PolisWeb può essere 

attivato tramite l’interfaccia applicativa che espone e attraverso la quale riceve i parametri 

identificativi dell’utente e della sessione utente. 

PAGINA 53 DI 133



Versione 2.0 


5.1 CARATTERISTICHE DI POLISWEB 

PolisWeb per il Processo Telematico è costituita da un’applicazione Web basata sul modello 

J2EE. 

La soluzione architetturale e tecnologica di PolisWeb prevede l’utilizzo di un Web Server 

che implementi una strong authentication client tramite certificati digitali e di Jboss come 

container per la tecnologia java utilizzata (Jsp, Servlet, Bean). 

Per il progetto del Processo Telematico si è adottato Linux come sistema operativo dei sistemi 

server, e quindi anche per PolisWeb presso il Punto di Accesso è consigliata l’adozione di 

Linux. 

PolisWeb integrato e configurato presso il Punto di Accesso, non necessita di un Database. Le 

informazioni di configurazione sono definite all’interno di file nel filesystem. Le informazioni 

relative agli utenti non sono gestite da PolisWeb ma ricevute, e ritenute valide, 

dall’interfaccia per il Punto di Accesso. 

Si precisa comunque, date le caratteristiche open-source dei prodotti tecnologici utilizzati per 

PolisWeb, che il sistema operativo Microsoft Windows può essere valutato come ambiente 

server per il PolisWeb presso il Punto di Accesso. 

Tra le caratteristiche di PolisWeb, si ricorda inoltre la sua configurabilità. La configurabilità 

di PolisWeb nella Fase 1 del Processo Telematico, permette al Punto di Accesso una minima 

personalizzazione dell’Interfaccia Grafica per l’utente. Con la personalizzazione dei loghi, 

delle intestazioni, dei colori è possibile, ad esempio, allineare l’interfaccia utente di PolisWeb 

con alcune preferenze adottate dal Punto di Accesso. 

Nei paragrafi che seguono sono fornite le informazioni relative all’Interfaccia Applicativa tra 

Punto di Accesso e PolisWeb, con l’indicazione dei protocolli di comunicazione adottati. 

Nella tabella seguente sono riepilogate le caratteristiche tecnologiche di PolisWeb. 

CARATTERISTICA DESCRIZIONE 

Tipo Applicazione Applicazione Web Java 

Sistema Operativo Linux (Windows 2000 Server) SERVER 

Java Virtual Machine 1.4.2 SERVER 

Web Server Apache. SERVER 

Web Container Tomcat. SERVER 

Database Non necessario. SERVER 

Configurabilità Alcune caratteristiche del Front-End. SERVER 

Interfaccia Applicativa Parametri Intestazione Richieste http 

Parametri Intestazione Risposte http 

Protocollo PA-PW http 

Protocollo PW-GC https con mutua autenticazione 

PAGINA 54 DI 133



Versione 2.0 


Browser supportati 

Configurazione 

browser 

Microsoft Internet Explorer, Netscape, 

Mozilla. 

CLIENT 

Utilizzati Cookie e java script lato client. CLIENT 

Tabella 1 - Caratteristiche di PolisWeb per il Punto di Accesso 

5.2 ARCHITETTURA E FLUSSI DI COLLOQUIO TRA PUNTO ACCESSO E POLISWEB 

PolisWeb presso il Punto di Accesso permette agli utenti del Processo Telematico di accedere 

alle informazioni di Back-End presso gli Uffici Giudiziari, per il tramite del Gestore Centrale 

(Modalità Internet). 

Certificato Digitale 

Certificato Digitale 

https https https 

http http https 

https 

https 

Avvocato 

Studio 

Avvocato 

Internet 

Sistema 


Intranet 


Sistema 

PolisWeb 

- Le richieste utente sono gestite dal web server del Punto di Accesso e inoltrate al Web Server 

di PolisWeb. 

- Le risposte html di PolisWeb sono inviate all'utente dal Web Server del Punto di Accesso. 

Interdominio 

Sistema 


Figura 41 - Architettura per PolisWeb nel Punto di Accesso 

Si precisa che il precedente schema è stato volutamente rappresentato con un’immagine e non 

attraverso un diagramma UML, per dare la percezione schematica della relazione tra il 

sistema del Punto di Accesso e PolisWeb. Si precisa che essendo Polis Web multipiattaforma, 

l’applicazione potrà essere opzionalmente installata sulla stessa macchina del Punto di 

Accesso. Nei paragrafi successivi è riportata la descrizione dei flussi tra PA e PW attraverso 

un diagramma di sequenza. 

Il Punto di Accesso si interpone tra le richieste dell’utente e PolisWeb. Le richieste effettuate 

dall’utente, tramite browser web, sono autenticate dal Punto di Accesso (smart-card). A 

seguito dell’autenticazione dell’utente, il Punto di Accesso può attivare PolisWeb tramite 

l’interfaccia applicativa esposta. 

PolisWeb è installato presso la “Server Farm” del punto di accesso e isolato verso l’esterno 

(Internet, Interdominio, altro). 

Nel colloquio tra il Punto di Accesso e PolisWeb si evidenziano le seguenti esigenze: 

• Attivazione di una sessione utente di PolisWeb. 

• Richiesta di Consultazione Informazioni di PolisWeb. 

• Chiusura di una sessione utente di PolisWeb. 

• Gestione delle eccezioni. 

I diagrammi di sequenza, di seguito illustrati, permettono di definire il flusso di colloquio tra 

il Punto di Accesso e PolisWeb. 

PAGINA 55 DI 133



Versione 2.0 


Attivazione Sessione Utente di PolisWeb 

Figura 42 - Sequenza Messaggi PA / FE-PW-PA- Attivazione Sessione 

Spiegazione: 

• A seguito della richiesta di accesso all’area Privata di PolisWeb da parte di un utente 

autenticato dal Punto di Accesso, il PdA si interfaccia a PolisWeb chiedendo l’attivazione 

di una sessione utente. L’interfaccia applicativa di PolisWeb per l’attivazione della 

sessione utente prevede una serie di parametri descritti in dettaglio nel seguito di questa 

sezione del documento. 

• PolisWeb, a seguito della richiesta di attivazione di una sessione utente effettua il 

controllo dei parametri dell’interfaccia di attivazione, forniti dal Punto di Accesso. 

L’interfaccia di attivazione e i parametri di interscambio con PolisWeb sono descritti nel 

paragrafo 5.3.1 (JPW_COD_FISCALE, JPW_COGNOME, JPW_NOME, 

JPW_DT_ULTIMO_ACCESSO, JPW_INFO_PA). 

• Superati i controlli dei parametri (in caso contrario è attivata un’eccezione applicativa da 

parte di PolisWeb trattata in particolare nell’ultimo diagramma), PolisWeb attiva la 

sessione utente in base all’utente identificato dal Codice Fiscale ricevuto come parametro. 

L’attivazione della sessione prevede il controllo da parte di PolisWeb che, per il Codice 

Fiscale corrente, non risulti già attiva una sessione (eccezione). 

• A seguito dell’attivazione della sessione utente, PolisWeb individua la pagina di default 

da presentare all’utente a seguito dell’attivazione nell’area privata. 

• PolisWeb infine risponde al Punto di Accesso con la pagina html, indicando il Codice 

Ritorno 200 per la corretta attivazione della sessione utente e il cookie per le informazioni 

identificative della sessione di PolisWeb. 

PAGINA 56 DI 133



Versione 2.0 


Consultazione Informazioni di PolisWeb 

Figura 43 - Sequenza Messaggi PA / FE-PW-PA- Consultazione 

Spiegazione: 

• Il dialogo tra Punto di Accesso e PolisWeb è basato sullo scambio delle informazioni 

previste dall’interfaccia applicativa di PolisWeb per ogni richiesta effettuata dal Punto di 

Accesso. Il Punto di Accesso richiede una singola pagina di Consultazione di PolisWeb, 

fornendo i parametri dell’interfaccia e il Cookie di sessione ricevuto da PolisWeb dopo 

l’attivazione della sessione utente attiva. 

• PolisWeb controlla i parametri di interfaccia, che prevedono anche il cookie di sessione 

utente. Il cookie deve determinare in PolisWeb una corrispondenza tra una sessione valida 

e associata in precedenza al Codice Fiscale, ricevuto nella richiesta corrente (altrimenti 

Eccezione). 

• PolisWeb determina il contenuto html da fornire al Punto di Accesso, in base alla 

funzione richiesta. 

• PolisWeb infine risponde al Punto di Accesso con la pagina html, indicando il Codice 

Ritorno 200 per la corretta attivazione della sessione utente e il cookie per le informazioni 

identificative della sessione di PolisWeb. 

PAGINA 57 DI 133



Versione 2.0 


Chiusura Sessione Utente di PolisWeb 

Figura 44 - Sequenza Messaggi PA / FE-PW-PA- Chiusura Sessione 

Spiegazione: 

• La chiusura della sessione utente in PolisWeb può avvenire attraverso la richiesta diretta 

della funzione di logout da parte dell’utente, attraverso l’interfaccia utente di PolisWeb 

fornita all’utente dal Punto di Accesso. PolisWeb espone al Punto di Accesso, 

un’interfaccia applicativa per richiedere direttamente a PolisWeb la chiusura della 

sessione utente. Questa funzionalità può risultare utile nel caso in cui il Punto di Accesso 

determini una propria chiusura di sessione con l’utente (timeout). 

• PolisWeb a seguito della richiesta di chiusura di una sessione utente, da Parte del Punto di 

Accesso, controlla la corrispondenza tra cookie di sessione attivata e il codice fiscale 

corrispondente (Eccezione se non corrisponde). 

• PolisWeb, a seguito della chiusura di una propria sessione utente (anche nel caso di 

richiesta da parte dell’utente), risponde al Punto di Accesso con un contenuto html, 

riportando il Codice Ritorno 799 ad indicare l’avvenuta chiusura della sessione utente. 

PAGINA 58 DI 133



Versione 2.0 


Eccezione PolisWeb in caso di ricezione di parametri errati dal Punto di Accesso 

Figura 45 - Sequenza Messaggi PA / FE-PW-PA- Eccezione Parametri Errati 

Come descritto nei diagramma di sequenza precedenti, in caso di controlli non validi 

PolisWeb determina una Eccezione segnalata al Punto di Accesso attraverso il Codice di 

Ritorno. L’elenco dei codici previsti è riportato successivamente, e nel caso dei parametri 

errati è impostato a 700. 

Eccezione PolisWeb in caso di richiesta di attivazione di una sessione per utente 

connesso 

Figura 46 - Sequenza Messaggi PA / FE-PW-PA- Eccezione Utente Connesso 

PAGINA 59 DI 133



Versione 2.0 


Nel caso di richiesta dell’attivazione per un utente che risulta già connesso il codice di ritorno 

impostato da PolisWeb per il Punto di Accesso è uguale a 701. 

5.3 INTERFACCE PER IL PUNTO DI ACCESSO 

Di seguito sono descritte le informazioni di interscambio tra il Punto di Accesso e PolisWeb, 

relative a: 

• Richiesta attivazione di una sessione utente di PolisWeb da parte del Punto di Accesso. 

• Risposta di PolisWeb al Punto di Accesso , alla richiesta di attivazione di una sessione 

utente. 

• Richiesta a PolisWeb delle pagine del front-end di consultazione dell’area privata, da 

parte del Punto di Accesso. 

• Risposta di PolisWeb alla richiesta da parte del Punto di Accesso delle pagine del frontend 

di consultazione dell’area privata. 

• Richiesta di chiusura di una sessione utente di PolisWeb da parte del Punto di Accesso. 

• Risposta di PolisWeb al Punto di Accesso, alla richiesta di chiusura di una sessione 

utente. 

• Risposte di PolisWeb al Punto di Accesso, in caso di Eccezione. 

5.3.1 Richiesta “Attivazione Sessione Utente PolisWeb” 

Per l’attivazione di una sessione utente di PolisWeb, da parte del Punto di Accesso è fornita 

un’interfaccia applicativa che prevede l’utilizzo del protocollo http tra PA e PW. 

Il PA (Client) invia la richiesta di login verso il server PolisWeb aggiungendo nella testata 

della richiesta client le informazioni dell'utente, individuate a seguito di un’autenticazione 

valida con smart-card. 

Sono di seguito fornite le modalità di attivazione dell’interfaccia applicativa di PolisWeb e un 

esempio del relativo messaggio di richiesta http inviata dal PA a PW. 

Richiesta http inviata dal Punto di Accesso a PolisWeb per l’attivazione della sessione 

utente: http://hostpwpa/pwprivate?action=Login 

Esempio di Messaggio di Richiesta http inviata dal Punto di Accesso a PolisWeb – Attivazione Sessione 

POST /pwprivate?action=Login HTTP/1.0 

Accept: image/gif, image/x‐xbitmap, image/jpeg, image/pjpeg, application/vnd.ms‐powerpoint, application/vnd.ms‐excel, 

application/msword, */* 

Accept‐Language: it 

User‐Agent: Mozilla/4.0 (compatible; MSIE 5.5; Windows NT 5.0) 

Host: jpolisweb:8081 

JPW_COD_FISCALE: CPRGRGXXXXXXXXX 

JPW_COGNOME: YYYYYYYY 

JPW_NOME: ZZZZZZZZZ 

JPW_DT_ULTIMO_ACCESSO: GG/MM/YYYY HH24:MI:SS 

JPW_INFO_PA: XXXXXXXXXXXXXXXXXXXX 

 

PAGINA 60 DI 133



Versione 2.0 


Spiegazione: 

Il Punto di Accesso fornisce nell’intestazione del messaggio di richiesta http (Header 

Http_Request) inviato a PolisWeb i seguenti parametri: 

• JPW_COD_FISCALE: rappresenta il Codice Fiscale dell’utente autentificato dal Punto di 

Accesso. Questo parametro è obbligatorio. Il Codice Fiscale dell’utente è utilizzato da 

PolisWeb per l’attivazione della sessione utente. Per ogni singolo utente è consentita 

l’attivazione di una sola sessione contemporanea, e per ogni richiesta di informazione è 

verificata la presenza di una sessione attiva valida in PolisWeb. 

• JPW_COGNOME: rappresenta il Cognome dell’utente. Permette di visualizzare 

sull’Interfaccia Utente di PolisWeb il nominativo dell’utente attivo nella sessione 

visualizzata nel browser . 

• JPW_NOME: rappresenta il Nome dell’utente. Vedi JPW_COGNOME. 

• JPW_DT_ULTIMO_ACCESSO: rappresenta la data di ultimo accesso da parte 

dell’utente al sistema di consultazione PolisWeb per il Processo Telematica dal Punto di 

Accesso. Permette di visualizzare sull’Interfaccia Utente di PolisWeb la data di ultimo 

accesso dell’utente e di poter utilizzare correttamente la consultazione dell’Agenda 

relativa agli ultimi eventi. 

• JPW_INFO_PA: rappresenta un parametro, utile al Punto di Accesso, per l’interscambio 

di informazioni con PolisWeb. Questo parametro non è necessario a PolisWeb, ma è reso 

disponibile al Punto di Accesso. Questa informazione è restituita, al Punto di Accesso, nel 

messaggio di risposta. Un utilizzo pratico può essere ad esempio ricevere e restituire una 

chiave della sessione utente del Punto di Accesso. 

5.3.2 Risposta PolisWeb alla richiesta di “Attivazione Sessione Utente PolisWeb” 

PolisWeb alla richiesta di attivazione di una nuova sessione utente risponde al client del 

Punto di Accesso con un messaggio riportante nella header http i parametri di interfaccia 

applicativa e il cookie relativo alla sessione utente attivata in PolisWeb. 

Esempio di Risposta http resituita da PolisWeb al Punto di Accesso 

HTTP/1.1 200 OK 

Content‐Type: text/html; charset=iso‐8859‐1 

Connection: close 

Date: Tue, 21 Oct 2003 16:03:01 GMT 

Server: Apache Tomcat/4.0.3 (HTTP/1.1 Connector) 

Set‐Cookie: JSESSIONID= A889EA5555C7A387F36A7A2892045FFD;Path=/ 

JPW_CODICE_RITORNO: 200 

JPW_DESCR_SEGNALAZIONE: OK 


 

Spiegazione: 

• Set-Cookie: JSESSIONID= A889EA5555C7A387F36A7A2892045FFD;Path=/: 

rappresenta l’informazione identificativa della sessione utente di PolisWeb. Questa 

informazione deve essere ritornata a PolisWeb nelle successive richieste, per associare 

correttamente utente e sessione utente. 

PAGINA 61 DI 133



Versione 2.0 


• JPW_CODICE_RITORNO: rappresenta il codice di ritorno previsto da PolisWeb, in base 

alla codifica riportata nella tabella …vedi oltre. Nel caso di corretta attivazione della 

nuova sessione utente assume il valore “200”. Per quanto riguarda le situazioni in cui 

PolisWeb non riesce ad attivare, o determinare, la sessione utente (ad. Es. già collegato) 

consultare il trattamento delle risposte “Eccezioni”, analizzate in ultimo. 

• JPW_DESCR_SEGNALAZIONE: rappresenta una stringa di descrizione del codice di 

ritorno. Nel caso di corretta attivazione della sessione utente assume il valore di “OK”. 

• JPW_INFO_PA: è il parametro ricevuto nella richiesta del Punto di Accesso. Questo 

parametro è restituito, senza nessun trattamento, in risposta. 

Si precisa che la risposta http di PolisWeb contiene oltre ai parametri di interscambio previsti 

con il PA, anche l’html della prima pagina consultabile dall’utente a seguito dell’attivazione 

della sessione (pagina di default). 

Di seguito vengono elencati i Codici di Ritorno individuati ad oggi: 

JPW_COD_RITORNO JPW_DESCR_SEGNALAZIONE COMMENTI PDA 

200 OK Si 

700 Parametro invalido o non presente. Un parametro fondamentale per l'elaborazione non e' Si 

presente o è invalido. Esempio mancanza del codice 

fiscale o dello username nella richiesta. 

701 Utente già connesso. E’ stata trovata un'altra sessione attiva per lo stesso Si 

Codice Fiscale. 

709 Sessione errata. Le informazioni di sessione non corrispondono ad Si 

una sessione valida. 

710 Informazioni sessione errata. Le informazioni di sessione non corrispondono con il Si 

Codice Fiscale associato. 

799 Chiusura sessione. L’utente ha richiesto una chiusura della sessione. Si 

Tabella 2 - Codici Ritorno FE-PW-PA 

5.3.3 Richiesta “Pagine Area Privata Consultazione PolisWeb” 

Il Punto di Accesso successivamente all’attivazione della sessione di PolisWeb, deve inoltrare 

tutte le richieste dell’utente a PolisWeb dopo aver aggiunto all’intestazione della richiesta 

http (header http request) i parametri definiti dall’interfaccia di attivazione di PolisWeb. 

Esempio Messaggio di Richiesta http inviata dal Punto di Accesso a PolisWeb – Consultazione Informazioni 

POST /forms/RicercaFascicoliPersonali;jsessionid=A889EA5555C7A387F36A7A2892045FFD?action=ElencoFascicoliPersonali 

HTTP/1.0 



Referer: http://localhost:8081/pwprivate?action=Login 


Content‐Type: application/x‐www‐form‐urlencoded 


Host: localhost:8081 

Content‐Length: 33 

Pragma: no‐cache 

Cookie: JSESSIONID=A889EA5555C7A387F36A7A2892045FFD 




PAGINA 62 DI 133



Versione 2.0 



 

Spiegazione: 

• Cookie: JSESSIONID=A889EA5555C7A387F36A7A2892045FFD: rappresenta 

l’informazione identificativa della sessione utente in PolisWeb, ricevuta in risposta dal PA 

dopo la richiesta di attivazione della sessione utente. 

• JPW_COD_FISCALE: rappresenta il Codice Fiscale dell’utente. E’ obbligatorio. 

PolisWeb controlla l’associazione del Codice Fiscale con la sessione utente identificata 

con le informazioni del cookie. 

• JPW_COGNOME, JPW_NOME, JPW_DT_ULTIMO_ACCESSO: vedi descrizione 

fornita nella richiesta di attivazione della sessione. 

5.3.4 Risposta di PolisWeb alla richiesta “Pagine Area Privata Consultazione PolisWeb”. 

La risposta fornita da PolisWeb è nello stesso formato della risposta descritta per la richiesta 

di attivazione della sessione utente. La risposta differisce nel contenuto l’html della pagina di 

consultazione richiesta. 

5.3.5 Richiesta “Chiusura Sessione Utente PolisWeb” 

Sono di seguito forniti le modalità di attivazione dell’interfaccia applicativa di PolisWeb per 

la chiusura di una sessione utente, e un esempio del relativo messaggio di richiesta http 

inviata dal PA a PW. 

Richiesta http inviata dal Punto di Accesso a PolisWeb per la chiusura della sessione utente: 

http://hostpwpa/pwprivate?action=Logout 

Esempio di Messaggio di Richiesta http inviata dal Punto di Accesso a PolisWeb – Chiusura Sessione 

POST /pwprivate;jsessionid=A889EA5555C7A387F36A7A2892045FFD?action=Logout HTTP/1.0 



Referer: http://localhost:8081/pwprivate?action=Login 


Content‐Type: application/x‐www‐form‐urlencoded 


Host: localhost:8081 

Content‐Length: 33 

Pragma: no‐cache 

Cookie: JSESSIONID=A889EA5555C7A387F36A7A2892045FFD 





 

Analogamente ai messaggi di richiesta precedenti, per richiedere la chiusura forzata di una 

specifica sessione utente, occorre attivare l’azione di Logout indicando le informazioni 

relative all’utente (Cookie e Codice Fiscale). 

PAGINA 63 DI 133



Versione 2.0 


5.3.6 Risposta PolisWeb per richiesta “Chiusura Sessione Utente PolisWeb” 

PolisWeb alla richiesta di chiusura di una sessione utente, dopo aver chiuso la sessione utente, 

risponde al client del Punto di Accesso con un messaggio riportante nella header http i 

parametri di interfaccia applicativa previsti. 

Esempio di Risposta http restituita da PolisWeb al Punto di Accesso per Richiesta Chiusura Sessione 

HTTP/1.1 200 OK 







JPW_DESCR_SEGNALAZIONE: OK 


 

Spiegazione: 

• JPW_COD_RITORNO: con il valore di Codice di Ritorno “799” il punto di accesso ha la 

conferma della chiusura della sessione e può redirigere l’utente in una funzionalità del 

Punto di Accesso. 

5.3.7 Eccezioni 

Con il concetto di eccezione, relativamente all’interfaccia tra PA e PW, si intendono 

situazioni in cui ad una precisa richiesta del Punto di Accesso PolisWeb non può rispondere 

come dovuto. Queste eccezioni possono essere dovute sia ad errate impostazione dei 

parametri di attivazione del Punto di Accesso che per condizioni di stato di PolisWeb. Le 

eccezioni ad oggi individuate sono le seguenti: 

• 700 – Parametro invalido o non presente. Un parametro dell’interfaccia di attivazione di 

PolisWeb, fondamentale per l’elaborazione della richiesta, non è fornito o è invalido. 

• 701 – Utente già connesso. Nell’elaborazione della richiesta di attivazione di una nuova 

sessione utente, è trovata un’altra sessione attiva per lo stesso Codice Fiscale. 

• 709 – Sessione errata. Le informazioni di sessione fornite a PolisWeb attraverso 

l’interfaccia di attivazione, non corrispondono ad una sessione valida. 

• 710 – Informazione sessione errata. Le informazioni di sessione fornite a PolisWeb 

attraverso l’interfaccia di attivazione, non corrispondono con il Codice Fiscale associato. 

Esempio di Risposta http restituita da PolisWeb al Punto di Accesso in caso di Eccezione 

HTTP/1.1 200 OK 







JPW_DESCR_SEGNALAZIONE: Parametro invalido o non presente. 


 

PAGINA 64 DI 133



Versione 2.0 


Spiegazione: 

• JPW_COD_RITORNO: con il valore di Codice di Ritorno “700” il punto di accesso ha 

l’evidenza di una situazione di “Eccezione”. In caso di un’eccezione il Punto di Accesso 

può intercettare e condizionare il flusso http. La risposta di PolisWeb contiene comunque 

l’html di visualizzazione dell’eccezione riscontrata. 

5.4 INTERFACCE PER IL BACK-END DI POLIS WEB 

Di seguito vengono descritte le interfacce utilizzate da PolisWeb per il colloquio con il backend. 

La documentazione completa del WSDL (con i servizi ed i tipi di dati) è riportata negli 

Allegati al paragrafo 8.5 (jpw-backend-wsdl e jpw-backend-wsdl-type). 

Figura 47 - Rappresentazione grafica dell’interfaccia WSDL per il back end di PolisWeb 

Operazione: {urn:JPW-BackEnd}execute 

Descrizione: esegue l’interrogazione specificata 

Parametri: 

• name: nome dell’interrogazione, descritta come stringa, presente nel binding SOAP come 

elemento del body di richiesta 

• valueSet: insieme dei parametri necessari all’interrogazione, descritto da un opportuno 

tipo XML, presente nel binding SOAP come elemento del body di richiesta 

• orderBy: ordinamenti dell’insieme dei risultati, descritto da un opportuno tipo XML, 

presente nel binding SOAP come elemento del body di richiesta 

Risultato: Lista di record risultato, codificato da opportuno tipo XML, presente nel binding 

SOAP come elemento del body di risposta. 

Operazione: {urn:JPW-BackEnd}getRowClassDescriptor 

Descrizione: ritorna il descrittore del tipo di record specificato. 

Parametri: 

• className: tipo di record da descrivere, descritto come stringa, presente nel binding 

SOAP come elemento del body di richiesta. 

Risultato: descrittore del record specificato, codificato da opportuno tipo XML, presente nel 

binding SOAP come elemento del body di risposta. 

PAGINA 65 DI 133



Versione 2.0 


Operazione: {urn:JPW-BackEnd}getServiceDescriptor 

Descrizione: ottiene il descrittore per l’interrogazione specificata. 

Parametri: 

• serviceName: nome del servizio da descrivere, descritto come stringa, presente nel 

binding SOAP come elemento del body di richiesta. 

Risultato: descrittore del servizio specificato, codificato da opportuno tipo XML, presente 

nel binding SOAP come elemento del body di risposta. 

Operazione: {urn:JPW-BackEnd}getServiceNames 

Descrizione: ritorna la lista dei nomi dei servizi disponibili 

Parametri: nessuno 

Risultato: array di stringhe con i nomi delle interrogazioni, codificato da tipo XML, presente 

nel binding SOAP come elemento del body di risposta. 

5.4.1 Esempio Messaggio Richiesta Soap 

Il messaggio di seguito riportato rappresenta un esempio di Messaggio SOAP di richiesta di 

un servizio di back-end, preparato da PolisWeb e inviato al Gestore Locale. 

 

 

 

 

 

RicercaInformazioniFascicoliPerTipo 

 

vntlsnxxxxxxxxxx 

xxxxxxxx 

xx 

 

RGN 

1999 

5 

1 

 

 

 

 

 

 

 

 

Nella struttura del messaggio di esempio si evidenziano gli elementi previsti per 

l’impostazione: 

PAGINA 66 DI 133



Versione 2.0 


• Del servizio richiesto. 

• Dei parametri di ricerca. 

• Dei parametri di ordinamento. 

5.4.2 Esempio Messaggio Risposta Soap 

Il messaggio di seguito riportato rappresenta un esempio di Messaggio SOAP di risposta di un 

servizio di back-end, ricevuto da PolisWeb e generato dal Gestore Locale. 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

PAGINA 67 DI 133



Versione 2.0 


 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Nella struttura del messaggio di esempio sono in evidenza le informazioni di dettaglio 

determinate per ogni risultato elementare individuto dalla ricerca (Riga e Attributi). 

PAGINA 68 DI 133



Versione 2.0 


6 ACCESSO AI REGISTRI SUL GESTORE CENTRALE 

Il Gestore Centrale mantiene aggiornato il Registro Generale degli Indirizzi Elettronici 

(ReGIndE), dove è registrato l'elenco di tutti gli indirizzi elettronici attivati dai Punti di 

Accesso. Sul Gestore Centrale viene inoltre mantenuto un registro degli Uffici Giudiziari, in 

cui sono registrati i dati di tutti i Tribunali che partecipano al Processo Telematico. 

Il Gestore Centrale mette a disposizione un servizio che consente di interrogare i registri 

accedendo in modalità LDAP. 

6.1 ACCESSO AL REGINDE PER IL REPERIMENTO DI INDIRIZZI E CERTIFICATI 

DEGLI AVVOCATI 

Per inviare comunicazioni e notifiche ad altri avvocati, ciascun avvocato deve conoscerne il 

codice fiscale ed eventualmente la chiave pubblica di cifratura del destinatario. 

Il registro generale degli indirizzi elettronici sul Gestore Centrale contiene gli indirizzi e i dati 

di tutti gli avvocati e dei CTU; la struttura LDAP di accesso al REGIndE è descritta nel 

paragrafo 5.1 del Decreto DTD [4]. 

Ad ogni indirizzo elettronico di persona fisica sono associate le seguenti informazioni: 

a) nome e cognome; 

b) luogo e data di nascita; 

c) codice fiscale; 

d) data, ora e minuti dell'ultima variazione dell'indirizzo elettronico; 

e) residenza; 

f) domicilio; 

g) stato dell’indirizzo: attivo, non attivo; 

h) certificato digitale relativo alla chiave pubblica, da utilizzare per la cifratura; 

i) data, ora e minuti dell’ultimo aggiornamento del certificato digitale; 

j) consiglio dell’ordine o ente di appartenenza; 

k) stato del soggetto abilitato: attivo, non attivo; 

l) codice del Punto di Accesso di appartenenza; 

m) ruolo del soggetto abilitato: avvocato, CTU. 

L’indirizzo elettronico di enti collettivi, siano essi non riconosciuti ovvero persone giuridiche, 

associa le seguenti informazioni: 

a) denominazione sociale; 

b) codice fiscale; 

c) data ed ora dell'ultima variazione dell'indirizzo elettronico; 

d) sede legale; 

e) certificato digitale relativo alla chiave pubblica da utilizzare per la cifratura; 

f) data ed ora dell’ultimo aggiornamento del certificato digitale; 

g) stato dell’indirizzo: attivo, non attivo. 

PAGINA 69 DI 133



Versione 2.0 


6.2 ACCESSO AL REGISTRO DEGLI UFFICI GIUDIZIARI 

In fase di redazione e preparazione degli atti o dei documenti da inviare verso un Ufficio 

Giudiziario, gli avvocati devono avere a propria disposizione sul posto di lavoro il codice 

identificativo dell’Ufficio destinatario e, per inviare un atto cifrato, anche la chiave pubblica 

di cifratura. 

Il Gestore Centrale mantiene un registro degli Uffici Giudiziari, in cui sono registrati i dati di 

tutti i Tribunali che partecipano al Processo Telematico e mette a disposizione un servizio di 

interrogazione del registro, in modalità LDAP descritta nel paragrafo 5.2 del Decreto DTD 

[4]. 

PAGINA 70 DI 133



Versione 2.0 


7 POSTA CERTIFICATA 

Il Punto di Accesso mette a disposizione di ciascun soggetto abilitato iscritto una Casella di 

Posta Certificata del Processo Telematico (CPECPT). 

La posta certificata viene utilizzata per la trasmissione di documenti informatici dall'ufficio 

giudiziario ad un soggetto abilitato esterno. È compito del Gestore Centrale dell’accesso 

immettere le comunicazioni inviate dall’UG nel sistema di posta certificata e gestire le 

ricevute di avvenuta consegna rilasciate dal PdA. 

Per quanto riguarda le funzioni attualmente implementate, la posta certificata viene utilizzata 

per l’invio agli Avvocati dei Biglietti di Cancelleria da parte dell’UG, per i flussi di 

abilitazione e gestione utenze, per l’invio di notifiche tra difensori e consegna copia. Si 

rimanda ai paragrafi 3 e 4 per una descrizione dei flussi. 

Le caratteristiche di un sistema di posta elettronica certificata sono riportate nel documento 

“Allegato tecnico alle linee guida del servizio di trasmissione di documenti informatici 

mediante posta elettronica certificata” (http://www.ctrupa.it/RETE-RUPA/Posta-Elet). 

Le caratteristiche specifiche della posta elettronica certificata del Processo Telematico sono 

invece descritte nell’allegato “B” alle Regole Tecniche. 

PAGINA 71 DI 133



Versione 2.0 


8 ALLEGATI 

8.1 FORMATO DEI DATI 

Nome campo Tipo dato Lunghezza Formato / Valori ammessi 

Anno Char 4 

CodiceEccezione Char 5 “E0032” 

CodiceEsito Char 5 “S0007” 

CodiceFiscale Char 16 “MRORSS70E06H501P” 

CodiceFiscaleDestinatario Char 16 “MRORSS70E06H501P” 

CodiceGC char 15 “GESTORECENTRALE” 

CodicePdA char 15 “PUNTOACCESSO001” 

CodiceOrdine char 15 “ORDINE000000001” 

CodiceGL char 15 “” 

CodiceStatus Char 1 A= attivo, “R”= Radiato, “S”= Sospeso 

CodiceUG Varchar 15 

Contenuto Varchar illimitata Testo del biglietto di cancelleria 

Data Char 10 “2003-09-16” 

DescrizioneEccezione Varchar 255 “” 

DescrizioneEsito Varchar 255 “” 

IdMsg Number 9 

IdMsgMitt Varchar 255 

IdMsgSMTP Varchar 255 

Impronta Bit 160 “” 

NumeroRuolo Varchar 13 “12345678/2004” 

Oggetto Varchar 255 “” 

Ora Char 8 “13:08:09” 

PAGINA 72 DI 133



Versione 2.0 


8.2 DTD DEI FILE XML 

8.2.1 Attestazione.dtd 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

8.2.2 Certificazione.dtd 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

8.2.3 Comunicazione.dtd 

 

 

 

 

 

PAGINA 73 DI 133



Versione 2.0 


 

 

 

8.2.4 Eccezione.dtd 

 

 

 

 

 

 

 

 

 

 

 

 

8.2.5 EsitoAtto.dtd 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

8.2.6 InfoInoltro.dtd 

 

 

 

 

 

 

 

 

 

 

 

PAGINA 74 DI 133



Versione 2.0 


 

 

Nota: 

• Nei possibili valori dell’attributo “ruolo”dell’elemento “Mittente” è elencato “AdS” 

che indica l’utenza Avvocatura dello Stato attualmente prevista solamente sul punto di 

Accesso Ministeriale 

8.2.7 InfoIndirizzamento.dtd 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 



Versione 2.0 


*********************************** Mittente ******************************** 

* Mittente del messaggio. 

****************************************************************************** 

--> 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Note: 

• Nei possibili valori dell’elemento TipoFlusso è elencato “CRL” indicante il flusso di 

“Integrazione CDP” attualmente previsto solamente per il Punto di Accesso 

Ministeriale 

• Nei valori possibili dell’attributo “tipo” dell’elemento “Mittente” è elencato “AdS” 



PAGINA 76 DI 133



Versione 2.0 


8.2.8 ComunicazioneIndirizzi.dtd 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

PAGINA 77 DI 133



Versione 2.0 


 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Nota: 

• Nei possibili valori dell’elemento “Ruolo” sono elencati “AvvocatoAdS” e 

“FunzionarioAdS” che indicano utenze dell’Avvocatura dello Stato attualmente 

previste solo sul punto di Accesso Ministeriale 

PAGINA 78 DI 133



Versione 2.0 


8.2.9 InfoNotifica.dtd 

 

 

 

 

 

 

 

 

 

 

 

 

 

Nota: 

• Nei possibili valori dell’attributo “ruolo” dell’elemento “Mittente” è elencato “AdS” 



PAGINA 79 DI 133



Versione 2.0 


8.3 DESCRIZIONE MESSAGGI DI ESITOATTO 

Nella tabella seguente è riportato l’elenco completo dei messaggi che verranno notificati 

all’avvocato in base ad errori riscontrati dai controlli automatici: 

Errore riscontrato in Tipologia Messaggio Primo esito per l’avvocato da 

concatenare a Messaggio 

Analisi Busta 

Il Depositante ha lo status della 

certificazione 

impostato a 'R' (radiato) o 'S' (sospeso) 

ERROR 

Depositante Radiato Sospeso 

o cancellato 

Busta non elaborabile FATAL Errore server busta non 

elaborata 

Contenuti (Attestazione.xml o 

Certificazione.xml) 

non elaborabili 

Errore generico e imprevisto alla fine 

dei controlli 

FATAL Impossibile elaborare 

impronta 

Hash dell'atto principale 

sono necessarie verifiche da parte della 

cancelleria 

sono necessarie verifiche tecniche da 

parte dell'ufficio ricevente 



FATAL Errore imprevisto sono necessarie verifiche tecniche da 


Impossibile decifrare la busta FATAL Impossibile decifrare la busta sono necessarie verifiche tecniche da 


Analisi IndiceBusta 

IndiceBusta.xml non presente FATAL Indice busta non trovato necessario effettuare nuovamente il 

deposito 

IndiceBusta in formato non corretto FATAL Indice busta non corretto necessario effettuare nuovamente il 

deposito 

Assenza di allegati indicati nell'indice 

della busta 

ERROR 

Assente allegato definito in 

Indice Busta 


cancelleria 

Analisi Atto 

Non è presente l'atto giudiziario definito 

in IndiceBusta. 

FATAL Atto principale mancante necessario effettuare nuovamente il 

deposito 

Certificato di firma non valido ERROR Certificato firma non valido sono necessarie verifiche tecniche da 


Certificato firma scaduto ERROR Certificato firma scaduto necessario effettuare nuovamente il 

deposito 

Atto non integro rispetto alla firma 

elettronica 

apposta sullo stesso 

ERROR 

Atto non integro rispetto alla 

firma elettronica 

Errore inatteso durante la verifica firma FATAL Errore durante la verifica della 

firma 

del documento 

necessario effettuare nuovamente il 

deposito 



Non tutti i firmatari sono integri ERROR Firma non integra sono necessarie verifiche tecniche da 


Il mittente non è tra i firmatari dell'atto ERROR Il mittente non è tra i firmatari 

dell'atto 

Documento non valido rispetto al DTD ERROR Documento XML non 

conforme rispetto 

al DTD 


cancelleria 



PAGINA 80 DI 133



Versione 2.0 


Impossibilità di elaborare la struttura 

dell'atto 

(errore nel formato XML) 

Il firmatario dell'atto non è costituito 

parte in causa 

(atti in corso di causa) 

ERROR Impossibile elaborare la 

struttura 

XML dell'atto 



ERROR Firmatario non parte in causa sono necessarie verifiche da parte della 

cancelleria 

Numero di ruolo non indicato ERROR Numero di ruolo non indicato sono necessarie verifiche da parte della 

cancelleria 

Numero di ruolo non esistente nel 

SICC 

Il firmatario non è costituito nell'atto 

introduttivo 

ERROR Numero di ruolo non valido sono necessarie verifiche da parte della 

cancelleria 

ERROR Il firmatario non parte in causa necessario effettuare nuovamente il 

deposito 

Atto depositato fuori termine WARN Termini deposito scaduti in attesa di conferma da parte della 

cancelleria: l'atto verrà 

comunque accettato 

Tag Parte (ParteCostituenda) e relativi 

tag annidati sono incompleti 

Verifica formato dati (valuta, data, ora, 

numeri) 

ERROR 

ERROR 

Dati della parte assenti o non 

indicati 

Atteso 

[numero,data,ora,valuta] 

rilevato [valore] 

Molteplicità dei tag non valida ERROR Documento XML non valido, 

assente dato "nome tag" 

Data in citazione iscrizione a ruolo non 

possibile 

(festivo, fuori termini...) 

WARN 

Data udienza di comparizione 

errata 


cancelleria 


cancelleria 



in attesa di conferma da parte della 

cancelleria: l'atto 

verrà comunque accettato 

Analisi Allegati 

Assente allegato Procura alle liti WARN Allegato Procura alle liti 

assente 

Assente allegato Iscrizione al ruolo ERROR Allegato Iscrizione a Ruolo 

assente 

Allegato non conforme al formato del 

file 

richiesto dalle regole tecniche 


file 


in attesa di conferma da parte della 

cancelleria: l'atto 

verrà comunque accettato 


cancelleria 

ERROR Formato di file non ammesso sono necessarie verifiche tecniche da 


ERROR Allegato non riconosciuto sono necessarie verifiche tecniche da 


Certificato di firma non valido ERROR Certificato firma non valido sono necessarie verifiche tecniche da 



deposito 

Allegato non integro rispetto alla 

firma elettronica apposta sullo stesso 

ERROR Allegato non integro rispetto 

alla firma elettronica 


firma del documento 


deposito 



Non tutti i firmatari sono integri ERROR Firma non integra sono necessarie verifiche tecniche da 


Presenza di allegati non indicati 

nell'indice della busta 

ERROR 

Presenza di allegati non 

definiti in Indice Busta 


cancelleria 

PAGINA 81 DI 133



Versione 2.0 


Nella tabella seguente è riportato l’elenco completo dei messaggi che verranno notificati 

all’avvocato dal Cancelliere: 

Errore riscontrato in Tipologia Messaggio Secondo esito in caso di rifiuto da 

concatenare a Messaggio 

Analisi Busta 

Il Depositante ha lo status della 

certificazione 

impostato a 'R' (radiato) o 'S' (sospeso) 

ERROR 

Depositante Radiato Sospeso 

o cancellato 

Busta non elaborabile FATAL Errore server busta non 

elaborata 

Contenuti (Attestazione.xml o 

Certificazione.xml) 

non elaborabili 

Errore generico e imprevisto alla fine 

dei controlli 

FATAL Impossibile elaborare 

impronta 

Hash dell'atto principale 


deposito 


deposito 


deposito 

FATAL Errore imprevisto necessario effettuare nuovamente il 

deposito 

Impossibile decifrare la busta FATAL Impossibile decifrare la busta necessario effettuare nuovamente il 

deposito con certificato di cifratura 

corretto 

Analisi IndiceBusta 

IndiceBusta.xml non presente FATAL Indice busta non trovato necessario effettuare nuovamente il 

deposito (se non si è già provveduto) 

IndiceBusta in formato non corretto FATAL Indice busta non corretto necessario effettuare nuovamente il 


Assenza di allegati indicati nell'indice 

della busta 

ERROR 

Assente allegato definito in 

Indice Busta 


deposito 

Analisi Atto 

Non è presente l'atto giudiziario definito 

in IndiceBusta. 

FATAL Atto principale mancante necessario effettuare nuovamente il 


Certificato di firma non valido ERROR Certificato firma non valido necessario effettuare nuovamente il 

deposito 



Atto non integro rispetto alla firma 

elettronica 

apposta sullo stesso 

ERROR 

Atto non integro rispetto alla 

firma elettronica 


firma 

del documento 




deposito 

Non tutti i firmatari sono integri ERROR Firma non integra necessario effettuare nuovamente il 

deposito 

Il mittente non è tra i firmatari dell'atto ERROR Il mittente non è tra i firmatari 

dell'atto 


deposito 

PAGINA 82 DI 133



Versione 2.0 


Documento non valido rispetto al DTD ERROR Documento XML non 

conforme rispetto 

al DTD 

Impossibilità di elaborare la struttura 

dell'atto 

(errore nel formato XML) 

Il firmatario dell'atto non è costituito 

parte in causa 

(atti in corso di causa) 

ERROR Impossibile elaborare la 

struttura 

XML dell'atto 


deposito 


deposito 

ERROR Firmatario non parte in causa necessario effettuare nuovamente il 

deposito 

Numero di ruolo non indicato ERROR Numero di ruolo non indicato necessario effettuare nuovamente il 

deposito 

Numero di ruolo non esistente nel 

SICC 

Il firmatario non è costituito nell'atto 

introduttivo 

Atto depositato fuori termine WARN Termini deposito scaduti 

Tag Parte (ParteCostituenda) e relativi ERROR Dati della parte assenti o non 

tag annidati sono incompleti 

indicati 

Verifica formato dati (valuta, data, ora, 

numeri) 

ERROR Numero di ruolo non valido necessario effettuare nuovamente il 

deposito 

ERROR Il firmatario non parte in causa necessario effettuare nuovamente il 


ERROR 

Atteso 

[numero,data,ora,valuta] 

rilevato [valore] 

Molteplicità dei tag non valida ERROR Documento XML non valido, 

assente dato "nome tag" 

Data in citazione iscrizione a ruolo non 

possibile 

(festivo, fuori termini...) 

WARN 

Data udienza di comparizione 

errata 


deposito 


deposito 


deposito 

Analisi Allegati 

Assente allegato Procura alle liti WARN Allegato Procura alle liti 

assente 

Assente allegato Iscrizione al ruolo ERROR Allegato Iscrizione a Ruolo 

assente 


file 



file 



deposito 

ERROR Formato di file non ammesso necessario effettuare nuovamente il 

deposito 

ERROR Allegato non riconosciuto necessario effettuare nuovamente il 

deposito 

Certificato di firma non valido ERROR Certificato firma non valido necessario effettuare nuovamente il 

deposito 



Allegato non integro rispetto alla 

firma elettronica apposta sullo stesso 

ERROR Allegato non integro rispetto 

alla firma elettronica 


firma del documento 




deposito 

Non tutti i firmatari sono integri ERROR Firma non integra necessario effettuare nuovamente il 

deposito 

Presenza di allegati non indicati 

nell'indice della busta 

ERROR 

Presenza di allegati non 

definiti in Indice Busta 


deposito 

PAGINA 83 DI 133



Versione 2.0 


8.4 ANAGRAFICA DEGLI ERRORI RIPORTATI DAL GESTORE CENTRALE 

La seguente tabella riporta l’anagrafica degli errori che possono essere inseriti dal Gestore 

Centrale nei messaggi di notifica eccezione. 

Codice 

E0101 

E0102 

E0103 

E0104 

E0200 

E0201 

E0202 

E0203 

E0204 

E0205 

E0300 

E0301 

E0303 

E0304 

E0400 

E0401 

E0402 

E0403 

E0405 

E0406 

E0500 

E0501 

E0502 

Descrizione 

L'element ?? non e' valorizzato 

L'element ?? non ha un formato valido. 

L'element ?? non ha un valore ammesso. 

L'attributo ?? non ha un valore ammesso. 

Il certificato ?? non e' valido o e' scaduto. 

Il Punto di Accesso presente in InfoInoltro non corrisponde con il titolare del 

Certificato di firma. 

L'element ?? non e' integro. 

Il file ?? non dovrebbe essere presente. 

L'Utente risulta abilitato su altro PDA. 

Il Punto di Accesso (??) presente in InfoInoltro non corrisponde a quello del 

Mittente. 

Il messaggio primario ricevuto non e' integro. 

La struttura di ?? non e' valida. 

Il messaggio primario ricevuto non e' integro. La parte ?? e' mancante. 

Il content-type del messaggio non e' riconosciuto. 

L'identificativo del messaggio ricevuto non e' univoco (IdMsgPdA). 

Il Mittente del messaggio (CF = ??) non e' autorizzato al Processo Telematico. 

Il destinatario del messaggio (InoltroAtto/Destinatario = ??) e' sconosciuto o non e' 

consentito. 

L'Avvocato certificato (CF = ??) non e' il Mittente del messaggio 

(InoltroAtto/Mittente). 

Il ?? e' sconosciuto. 

Il Destinatario del messaggio (CF = ??) non e' autorizzato al Processo Telematico. 

La certificazione allegata non contiene la firma. 

La certificazione allegata non corrisponde al relativo DTD. 

Il codice fiscale contenuto nella Certificazione non corrisponde con il codice 

fiscale di InfoInoltro. 

PAGINA 84 DI 133



Versione 2.0 


E0503 

E0504 

E0505 

E0506 

E0600 

E0601 

E0602 

E0603 

E0604 

E0605 

E0606 

E0607 

E0608 

E0609 

E0700 

E0701 

E0702 

E0703 

La data riportata dalla certificazione non corrisponde con la data odierna. 

Il Punto di Accesso riportato nella certificazione non coincide con quello che ha 

inviato il messaggio. 

L'ordine riportato nella certificazione non esiste. 

Lo status dell'Avvocato riportato nella certificazione non e' corretto. 

Informazioni mancanti nella ComunicazioneUG. 

Codice del Gestore Locale sconosciuto. 

Codice Fiscale del destinatario sconosciuto. 

Impossibile recuperare la ComunicazioneUG. 

Identificativo duplicato. 

Struttura ComunicazioneUG errata. 

Messaggio non riconosciuto. 

Il nodo 'esitoAtto' non punta ad alcun allegato. 

Status Difensore non presente. 

Formato Codice Fiscale non valido. 

Errore nella verifica della firma della ComunicazioneIndirizzi.xml.p7m. 

Firmatario della ComunicazioneIndirizzi.xml.p7m non identificato. 

Rilevati errori nella validazione dei dati del Soggetto Esterno. 

La ComunicazioneIndirizzi allegata non corrisponde al relativo DTD. 

Il codice “??” è, divolta in volta, sostituito dal valore specifico. 

PAGINA 85 DI 133



Versione 2.0 


8.5 FORMATI WSDL 

8.5.1 WSDL jpw-backend.wsdl 

services bindings porttypes messages 

wsConsultazione ServiceConsultazioneBinding ServiziConsultazione executeRequest 

service wsConsultazione 

ports 

executeResponse 

ServiziConsultazionePort 

binding tns:ServiceConsultazioneBinding 

extensibi 

lity 

getRowClassDescriptorRequest 

getRowClassDescriptorResponse 

getServiceDescriptorRequest 

getServiceDescriptorResponse 

getServiceNamesRequest 

getServiceNamesResponse 

source 

 

 

 

 

binding ServiceConsultazioneBinding 

type tns:ServiziConsultazione 

extensibility 

operations 

Execute 

extensibi 

lity 

input 

output 

getRowClassDescriptor 

extensibi 

lity 

input 

output 

getServiceDescriptor 

extensibi 

lity 

input 

output 

GetServiceNames 

extensibi 

PAGINA 86 DI 133



Versione 2.0 


used by 

lity 

input 

output 

Service wsConsultazione in Port ServiziConsultazionePort 

source 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

porttype ServiziConsultazione 

operations 

execute 

input tns:executeRequest 

output tns:executeResponse 

getRowClassDescriptor 

input tns:getRowClassDescriptorRequest 

output tns:getRowClassDescriptorResponse 

getServiceDescriptor 

input tns:getServiceDescriptorRequest 

output tns:getServiceDescriptorResponse 

getServiceNames 

input tns:getServiceNamesRequest 

output tns:getServiceNamesResponse 

PAGINA 87 DI 133



Versione 2.0 


used by 

binding ServiceConsultazioneBinding 

source 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

message executeRequest 

parts name 

type xsd:string 

valueSet 

type tns:valueSetType 

used by 

orderBy 

type tns:orderByType 

PortType ServiziConsultazione in Operation execute 

source 

 

 

 

 

message executeResponse 

parts 

used by 

rowList 

type tns:rowListType 

PortType ServiziConsultazione in Operation execute 

source 

 

 

message getRowClassDescriptorRequest 

parts name 


used by PortType ServiziConsultazione in Operation getRowClassDescriptor 

PAGINA 88 DI 133



Versione 2.0 


source 

 

 

message getRowClassDescriptorResponse 

parts 

used by 

return 

type tns:rowClassDescriptorType 

PortType ServiziConsultazione in Operation getRowClassDescriptor 

source 

 

 

message getServiceDescriptorRequest 

parts 

used by 

name 


PortType ServiziConsultazione in Operation getServiceDescriptor 

source 

 

 

message getServiceDescriptorResponse 

parts 

used by 

return 

type tns:serviceDescriptorType 

PortType ServiziConsultazione in Operation getServiceDescriptor 

source 

 

 

message getServiceNamesRequest 

parts 

used by 

PortType ServiziConsultazione in Operation getServiceNames 

source 

message getServiceNamesResponse 

parts 

used by 

return 

type tns:stringArrayType 

PortType ServiziConsultazione in Operation getServiceNames 

source 

 

 

8.5.2 Schema wsdlschema.xsd 

targetNamespace: 

urn:JPW-BackEnd 

PAGINA 89 DI 133



Versione 2.0 


Complex types 

orderByEntryType 

orderByType 

Simple types 

typeEnum 

propertyType 

rowClassDescriptorType 

rowListType 

rowType 

serviceDescriptorType 

srowType 

stringArrayType 

subRowsType 

valueSetType 

Elements Groups Complex types Simple types Attr. groups 

anyType Array anyURI arrayCoordinate arrayAttributes 

anyURI Struct Array base64 arrayMemberAttributes 

Array base64Binary commonAttributes 

base64Binary 

boolean 

byte 

date 

dateTime 

decimal 

double 

duration 

ENTITIES 

ENTITY 

float 

gDay 

gMonth 

gMonthDay 

gYear 

gYearMonth 

hexBinary 

ID 

boolean 

byte 

date 

dateTime 

decimal 

double 

duration 

ENTITIES 

ENTITY 

float 

gDay 

gMonth 

gMonthDay 

gYear 

gYearMonth 

hexBinary 

ID 

IDREF 

PAGINA 90 DI 133



Versione 2.0 


IDREF 

IDREFS 

int 

integer 

language 

long 

Name 

NCName 

negativeInteger 

NMTOKEN 

NMTOKENS 

nonNegativeInteger 

nonPositiveInteger 

normalizedString 

NOTATION 

positiveInteger 

QName 

short 

string 

Struct 

time 

token 

unsignedByte 

unsignedInt 

unsignedLong 

IDREFS 

int 

integer 

language 

long 

Name 

NCName 

negativeInteger 

NMTOKEN 

NMTOKENS 

nonNegativeInteger 

nonPositiveInteger 

normalizedString 

NOTATION 

positiveInteger 

QName 

short 

string 

Struct 

time 

token 

unsignedByte 

unsignedInt 

unsignedLong 

unsignedShort 

unsignedShort 

complexType orderByEntryType 

diagram 

namespace urn:JPW-BackEnd 

used by 

element orderByType/entry 

attributes Name Type Use Default Fixed Annotation 

property xsd:string required 

mode xsd:string required 

source 

 

PAGINA 91 DI 133



Versione 2.0 


 

 

complexType orderByType 



children entry 

source 

 

 

 

 

element orderByType/entry 


type tns:orderByEntryType 


property xsd:string required 

mode xsd:string required 

source 

complexType propertyType 



type extension of string 

used by 

elements srowType/property valueSetType/value 


name xsd:string required 

type tns:typeEnum string 

source 

 

 

 

 

 

 

 

PAGINA 92 DI 133



Versione 2.0 


complexType rowClassDescriptorType 



children property classRef 

source 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

element rowClassDescriptorType/property 





source 

 

 

 

 

 

element rowClassDescriptorType/classRef 




PAGINA 93 DI 133



Versione 2.0 


source 

 

 

 

 

complexType rowListType 



children row 


available xsd:string required 

time xsd:string required 

source 

 

 

 

 

 

 

element rowListType/row 


type tns:rowType 

children property subRows 


class xsd:string required 

source 

PAGINA 94 DI 133



Versione 2.0 


complexType rowType 



type extension of tns:srowType 

children property subRows 

used by 

element rowListType/row 



source 

 

 

 

 

 

 

 

 

 

element rowType/subRows 


type tns:subRowsType 

children row 



source 

PAGINA 95 DI 133



Versione 2.0 


complexType serviceDescriptorType 



children params rowClass 

source 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

element serviceDescriptorType/params 





source 

 

 

 

 

 

element serviceDescriptorType/rowClass 



PAGINA 96 DI 133



Versione 2.0 



source 

 

 

 

 

complexType srowType 



children property 

used by element subRowsType/row 

complexType rowType 

source 

 

 

 

 

element srowType/property 


type tns:propertyType 




source 

complexType stringArrayType 



type restriction of soap-enc:Array 


soapenc:arrayType 

tns:offset 

id 

href 

xs:string 

tns:arrayCoordin 

ate 

xs:ID 

xs:anyURI 

PAGINA 97 DI 133



Versione 2.0 


source 

 

 

 

 

 

 

complexType subRowsType 



children row 

used by 

element rowType/subRows 



source 

 

 

 

 

 

element subRowsType/row 


type tns:srowType 

children property 

source 

complexType valueSetType 



children value 

source 

 

PAGINA 98 DI 133



Versione 2.0 


 

 

 

element valueSetType/value 


type tns:propertyType 




source 

simpleType typeEnum 


type restriction of NMTOKEN 

used by attributes propertyType/@type rowClassDescriptorType/property/@type 

serviceDescriptorType/params/@type 

facets enumeration string 

enumeration integer 

enumeration date 

enumeration binary 

enumeration float 

enumeration boolean 

source 

 

 

 

 

 

 

 

 

 

element soap-enc:anyType 


namespace http://schemas.xmlsoap.org/soap/encoding/ 

source 

PAGINA 99 DI 133



Versione 2.0 


element soap-enc:anyURI 



type soap-enc:anyURI 


id 

xs:ID 

href 

xs:anyURI 

source 

element soap-enc:Array 



type soap-enc:Array 


tns:arrayType 

tns:offset 

xs:string 


ate 

id 

xs:ID 

href 

xs:anyURI 

source 

element soap-enc:base64Binary 



type soap-enc:base64Binary 


id 

xs:ID 

href 

xs:anyURI 

source 

element soap-enc:boolean 



PAGINA 100 DI 133



Versione 2.0 


type soap-enc:boolean 


id 

xs:ID 

href 

xs:anyURI 

source 

element soap-enc:byte 



type soap-enc:byte 


id 

xs:ID 

href 

xs:anyURI 

source 

element soap-enc:date 



type soap-enc:date 


id 

xs:ID 

href 

xs:anyURI 

source 

element soap-enc:dateTime 



type soap-enc:dateTime 


id 

xs:ID 

href 

xs:anyURI 

source 

element soap-enc:decimal 



PAGINA 101 DI 133



Versione 2.0 


type soap-enc:decimal 


id 

xs:ID 

href 

xs:anyURI 

source 

element soap-enc:double 



type soap-enc:double 


id 

xs:ID 

href 

xs:anyURI 

source 

element soap-enc:duration 



type soap-enc:duration 


id 

xs:ID 

href 

xs:anyURI 

source 

element soap-enc:ENTITIES 



type soap-enc:ENTITIES 


id 

xs:ID 

href 

xs:anyURI 

source 

element soap-enc:ENTITY 



PAGINA 102 DI 133



Versione 2.0 


type soap-enc:ENTITY 


id 

xs:ID 

href 

xs:anyURI 

source 

element soap-enc:float 



type soap-enc:float 


id 

xs:ID 

href 

xs:anyURI 

source 

element soap-enc:gDay 



type soap-enc:gDay 


id 

xs:ID 

href 

xs:anyURI 

source 

element soap-enc:gMonth 



type soap-enc:gMonth 


id 

xs:ID 

href 

xs:anyURI 

source 

element soap-enc:gMonthDay 



PAGINA 103 DI 133



Versione 2.0 


type soap-enc:gMonthDay 


id 

xs:ID 

href 

xs:anyURI 

source 

element soap-enc:gYear 



type soap-enc:gYear 


id 

xs:ID 

href 

xs:anyURI 

source 

element soap-enc:gYearMonth 



type soap-enc:gYearMonth 


id 

xs:ID 

href 

xs:anyURI 

source 

element soap-enc:hexBinary 



type soap-enc:hexBinary 


id 

xs:ID 

href 

xs:anyURI 

source 

element soap-enc:ID 



PAGINA 104 DI 133



Versione 2.0 


type soap-enc:ID 


id 

xs:ID 

href 

xs:anyURI 

source 

element soap-enc:IDREF 



type soap-enc:IDREF 


id 

xs:ID 

href 

xs:anyURI 

source 

element soap-enc:IDREFS 



type soap-enc:IDREFS 


id 

xs:ID 

href 

xs:anyURI 

source 

element soap-enc:int 



type soap-enc:int 


id 

xs:ID 

href 

xs:anyURI 

source 

element soap-enc:integer 



PAGINA 105 DI 133



Versione 2.0 


type soap-enc:integer 


id 

xs:ID 

href 

xs:anyURI 

source 

element soap-enc:language 



type soap-enc:language 


id 

xs:ID 

href 

xs:anyURI 

source 

element soap-enc:long 



type soap-enc:long 


id 

xs:ID 

href 

xs:anyURI 

source 

element soap-enc:Name 



type soap-enc:Name 


id 

xs:ID 

href 

xs:anyURI 

source 

element soap-enc:NCName 



PAGINA 106 DI 133



Versione 2.0 


type soap-enc:NCName 


id 

xs:ID 

href 

xs:anyURI 

source 

element soap-enc:negativeInteger 



type soap-enc:negativeInteger 


id 

xs:ID 

href 

xs:anyURI 

source 

element soap-enc:NMTOKEN 



type soap-enc:NMTOKEN 


id 

xs:ID 

href 

xs:anyURI 

source 

element soap-enc:NMTOKENS 



type soap-enc:NMTOKENS 


id 

xs:ID 

href 

xs:anyURI 

source 

element soap-enc:nonNegativeInteger 



PAGINA 107 DI 133



Versione 2.0 


type soap-enc:nonNegativeInteger 


id 

xs:ID 

href 

xs:anyURI 

source 

element soap-enc:nonPositiveInteger 



type soap-enc:nonPositiveInteger 


id 

xs:ID 

href 

xs:anyURI 

source 

element soap-enc:normalizedString 



type soap-enc:normalizedString 


id 

xs:ID 

href 

xs:anyURI 

source 

element soap-enc:NOTATION 



type soap-enc:NOTATION 


id 

xs:ID 

href 

xs:anyURI 

source 

element soap-enc:positiveInteger 



PAGINA 108 DI 133



Versione 2.0 


type soap-enc:positiveInteger 


id 

xs:ID 

href 

xs:anyURI 

source 

element soap-enc:QName 



type soap-enc:QName 


id 

xs:ID 

href 

xs:anyURI 

source 

element soap-enc:short 



type soap-enc:short 


id 

xs:ID 

href 

xs:anyURI 

source 

element soap-enc:string 



type soap-enc:string 


id 

xs:ID 

href 

xs:anyURI 

source 

PAGINA 109 DI 133



Versione 2.0 


element soap-enc:Struct 



type soap-enc:Struct 


id 

xs:ID 

href 

xs:anyURI 

source 

element soap-enc:time 



type soap-enc:time 


id 

xs:ID 

href 

xs:anyURI 

source 

element soap-enc:token 



type soap-enc:token 


id 

xs:ID 

href 

xs:anyURI 

source 

element soap-enc:unsignedByte 



type soap-enc:unsignedByte 


id 

xs:ID 

PAGINA 110 DI 133



Versione 2.0 


href 

xs:anyURI 

source 

element soap-enc:unsignedInt 



type soap-enc:unsignedInt 


id 

xs:ID 

href 

xs:anyURI 

source 

element soap-enc:unsignedLong 



type soap-enc:unsignedLong 


id 

xs:ID 

href 

xs:anyURI 

source 

element soap-enc:unsignedShort 



type soap-enc:unsignedShort 


id 

xs:ID 

href 

xs:anyURI 

source 

group soap-enc:Array 



used by complexType soap-enc:Array 

source 

 

PAGINA 111 DI 133



Versione 2.0 


 

 

 

group soap-enc:Struct 



used by complexType soap-enc:Struct 

source 

 

 

 

 

complexType soap-enc:anyURI 



type extension of anyURI 

used by 

element soap-enc:anyURI 


id 

xs:ID 

href 

xs:anyURI 

source 

 

 

 

 

 

 

complexType soap-enc:Array 



PAGINA 112 DI 133



Versione 2.0 


used by 

element soap-enc:Array 

complexType stringArrayType 


annotation 

tns:arrayType 

tns:offset 

id 

href 

documentation 

xs:string 


ate 

xs:ID 

xs:anyURI 

'Array' is a complex type for accessors identified by position 

source 

 

 

'Array' is a complex type for accessors identified by position 

 

 

 

 

 

 

complexType soap-enc:base64Binary 



type extension of base64Binary 

used by 

element soap-enc:base64Binary 


id 

xs:ID 

href 

xs:anyURI 

source 

 

 

 

 

 

 

complexType soap-enc:boolean 


PAGINA 113 DI 133



Versione 2.0 



type extension of boolean 

used by 

element soap-enc:boolean 


id 

xs:ID 

href 

xs:anyURI 

source 

 

 

 

 

 

 

complexType soap-enc:byte 



type extension of byte 

used by 

element soap-enc:byte 


id 

xs:ID 

href 

xs:anyURI 

source 

 

 

 

 

 

 

complexType soap-enc:date 



type extension of date 

used by 

element soap-enc:date 


id 

xs:ID 

href 

xs:anyURI 

source 

 

PAGINA 114 DI 133



Versione 2.0 


 

 

 

 

 

complexType soap-enc:dateTime 



type extension of dateTime 

used by 

element soap-enc:dateTime 


id 

xs:ID 

href 

xs:anyURI 

source 

 

 

 

 

 

 

complexType soap-enc:decimal 



type extension of decimal 

used by 

element soap-enc:decimal 


id 

xs:ID 

href 

xs:anyURI 

source 

 

 

 

 

 

 

PAGINA 115 DI 133



Versione 2.0 


complexType soap-enc:double 



type extension of double 

used by 

element soap-enc:double 


id 

xs:ID 

href 

xs:anyURI 

source 

 

 

 

 

 

 

complexType soap-enc:duration 



type extension of duration 

used by 

element soap-enc:duration 


id 

xs:ID 

href 

xs:anyURI 

source 

 

 

 

 

 

 

complexType soap-enc:ENTITIES 



type extension of ENTITIES 

used by 

element soap-enc:ENTITIES 

PAGINA 116 DI 133



Versione 2.0 



id 

xs:ID 

href 

xs:anyURI 

source 

 

 

 

 

 

 

complexType soap-enc:ENTITY 



type extension of ENTITY 

used by 

element soap-enc:ENTITY 


id 

xs:ID 

href 

xs:anyURI 

source 

 

 

 

 

 

 

complexType soap-enc:float 



type extension of float 

used by 

element soap-enc:float 


id 

xs:ID 

href 

xs:anyURI 

source 

 

 

 

 

PAGINA 117 DI 133



Versione 2.0 


 

 

complexType soap-enc:gDay 



type extension of gDay 

used by 

element soap-enc:gDay 


id 

xs:ID 

href 

xs:anyURI 

source 

 

 

 

 

 

 

complexType soap-enc:gMonth 



type extension of gMonth 

used by 

element soap-enc:gMonth 


id 

xs:ID 

href 

xs:anyURI 

source 

 

 

 

 

 

 

complexType soap-enc:gMonthDay 



PAGINA 118 DI 133



Versione 2.0 


type extension of gMonthDay 

used by 

element soap-enc:gMonthDay 


id 

xs:ID 

href 

xs:anyURI 

source 

 

 

 

 

 

 

complexType soap-enc:gYear 



type extension of gYear 

used by 

element soap-enc:gYear 


id 

xs:ID 

href 

xs:anyURI 

source 

 

 

 

 

 

 

complexType soap-enc:gYearMonth 



type extension of gYearMonth 

used by 

element soap-enc:gYearMonth 


id 

xs:ID 

href 

xs:anyURI 

source 

 

 

PAGINA 119 DI 133



Versione 2.0 


 

 

 

 

complexType soap-enc:hexBinary 



type extension of hexBinary 

used by 

element soap-enc:hexBinary 


id 

xs:ID 

href 

xs:anyURI 

source 

 

 

 

 

 

 

complexType soap-enc:ID 



type extension of ID 

used by 

element soap-enc:ID 


id 

xs:ID 

href 

xs:anyURI 

source 

 

 

 

 

 

 

PAGINA 120 DI 133



Versione 2.0 


complexType soap-enc:IDREF 



type extension of IDREF 

used by 

element soap-enc:IDREF 


id 

xs:ID 

href 

xs:anyURI 

source 

 

 

 

 

 

 

complexType soap-enc:IDREFS 



type extension of IDREFS 

used by 

element soap-enc:IDREFS 


id 

xs:ID 

href 

xs:anyURI 

source 

 

 

 

 

 

 

complexType soap-enc:int 



type extension of int 

used by 

element soap-enc:int 

PAGINA 121 DI 133



Versione 2.0 



id 

xs:ID 

href 

xs:anyURI 

source 

 

 

 

 

 

 

complexType soap-enc:integer 



type extension of integer 

used by 

element soap-enc:integer 


id 

xs:ID 

href 

xs:anyURI 

source 

 

 

 

 

 

 

complexType soap-enc:language 



type extension of language 

used by 

element soap-enc:language 


id 

xs:ID 

href 

xs:anyURI 

source 

 

 

 

 

PAGINA 122 DI 133



Versione 2.0 


 

 

complexType soap-enc:long 



type extension of long 

used by 

element soap-enc:long 


id 

xs:ID 

href 

xs:anyURI 

source 

 

 

 

 

 

 

complexType soap-enc:Name 



type extension of Name 

used by 

element soap-enc:Name 


id 

xs:ID 

href 

xs:anyURI 

source 

 

 

 

 

 

 

complexType soap-enc:NCName 



PAGINA 123 DI 133



Versione 2.0 


type extension of NCName 

used by 

element soap-enc:NCName 


id 

xs:ID 

href 

xs:anyURI 

source 

 

 

 

 

 

 

complexType soap-enc:negativeInteger 



type extension of negativeInteger 

used by 

element soap-enc:negativeInteger 


id 

xs:ID 

href 

xs:anyURI 

source 

 

 

 

 

 

 

complexType soap-enc:NMTOKEN 



type extension of NMTOKEN 

used by 

element soap-enc:NMTOKEN 


id 

xs:ID 

href 

xs:anyURI 

source 

 

 

PAGINA 124 DI 133



Versione 2.0 


 

 

 

 

complexType soap-enc:NMTOKENS 



type extension of NMTOKENS 

used by 

element soap-enc:NMTOKENS 


id 

xs:ID 

href 

xs:anyURI 

source 

 

 

 

 

 

 

complexType soap-enc:nonNegativeInteger 



type extension of nonNegativeInteger 

used by 

element soap-enc:nonNegativeInteger 


id 

xs:ID 

href 

xs:anyURI 

source 

 

 

 

 

 

 

PAGINA 125 DI 133



Versione 2.0 


complexType soap-enc:nonPositiveInteger 



type extension of nonPositiveInteger 

used by 

element soap-enc:nonPositiveInteger 


id 

xs:ID 

href 

xs:anyURI 

source 

 

 

 

 

 

 

complexType soap-enc:normalizedString 



type extension of normalizedString 

used by 

element soap-enc:normalizedString 


id 

xs:ID 

href 

xs:anyURI 

source 

 

 

 

 

 

 

complexType soap-enc:NOTATION 



type extension of QName 

used by 

element soap-enc:NOTATION 

PAGINA 126 DI 133



Versione 2.0 



id 

xs:ID 

href 

xs:anyURI 

source 

 

 

 

 

 

 

complexType soap-enc:positiveInteger 



type extension of positiveInteger 

used by 

element soap-enc:positiveInteger 


id 

xs:ID 

href 

xs:anyURI 

source 

 

 

 

 

 

 

complexType soap-enc:QName 



type extension of QName 

used by 

element soap-enc:QName 


id 

xs:ID 

href 

xs:anyURI 

source 

 

 

 

 

PAGINA 127 DI 133



Versione 2.0 


 

 

complexType soap-enc:short 



type extension of short 

used by 

element soap-enc:short 


id 

xs:ID 

href 

xs:anyURI 

source 

 

 

 

 

 

 

complexType soap-enc:string 



type extension of string 

used by 

element soap-enc:string 


id 

xs:ID 

href 

xs:anyURI 

source 

 

 

 

 

 

 

complexType soap-enc:Struct 


PAGINA 128 DI 133



Versione 2.0 



used by 

element soap-enc:Struct 


id 

xs:ID 

href 

xs:anyURI 

source 

 

 

 

complexType soap-enc:time 



type extension of time 

used by 

element soap-enc:time 


id 

xs:ID 

href 

xs:anyURI 

source 

 

 

 

 

 

 

complexType soap-enc:token 



type extension of token 

used by 

element soap-enc:token 


id 

xs:ID 

href 

xs:anyURI 

source 

 

 

 

 

 

PAGINA 129 DI 133



Versione 2.0 


 

complexType soap-enc:unsignedByte 



type extension of unsignedByte 

used by 

element soap-enc:unsignedByte 


id 

xs:ID 

href 

xs:anyURI 

source 

 

 

 

 

 

 

complexType soap-enc:unsignedInt 



type extension of unsignedInt 

used by 

element soap-enc:unsignedInt 


id 

xs:ID 

href 

xs:anyURI 

source 

 

 

 

 

 

 

complexType soap-enc:unsignedLong 



type extension of unsignedLong 

PAGINA 130 DI 133



Versione 2.0 


used by 

element soap-enc:unsignedLong 


id 

xs:ID 

href 

xs:anyURI 

source 

 

 

 

 

 

 

complexType soap-enc:unsignedShort 



type extension of unsignedShort 

used by 

element soap-enc:unsignedShort 


id 

xs:ID 

href 

xs:anyURI 

source 

 

 

 

 

 

 

simpleType soap-enc:arrayCoordinate 


type string 

source 

 

 

simpleType soap-enc:base64 


type base64Binary 

source 

 

PAGINA 131 DI 133



Versione 2.0 


 

attributeGroup soap-enc:arrayAttributes 


used by 

complexType soap-enc:Array 


tns:arrayType 

tns:offset 

xs:string 


ate 

source 

 

 

 

attributeGroup soap-enc:arrayMemberAttributes 



tns:position 


ate 

source 

 

 

attributeGroup soap-enc:commonAttributes 


used by 

complexTypes soap-enc:anyURI soap-enc:Array soap-enc:base64Binary soap-enc:boolean soap-enc:byte 

soap-enc:date soap-enc:dateTime soap-enc:decimal soap-enc:double soap-enc:duration 

soap-enc:ENTITIES soap-enc:ENTITY soap-enc:float soap-enc:gDay soap-enc:gMonth soapenc:gMonthDay 

soap-enc:gYear soap-enc:gYearMonth soap-enc:hexBinary soap-enc:ID soapenc:IDREF 

soap-enc:IDREFS soap-enc:int soap-enc:integer soap-enc:language soap-enc:long 

soap-enc:Name soap-enc:NCName soap-enc:negativeInteger soap-enc:NMTOKEN soapenc:NMTOKENS 

soap-enc:nonNegativeInteger soap-enc:nonPositiveInteger soapenc:normalizedString 

soap-enc:NOTATION soap-enc:positiveInteger soap-enc:QName soapenc:short 

soap-enc:string soap-enc:Struct soap-enc:time soap-enc:token soapenc:unsignedByte 

soap-enc:unsignedInt soap-enc:unsignedLong soap-enc:unsignedShort 


annotation 

id 

href 

documentation 

xs:ID 

xs:anyURI 

Attributes common to all elements that function as accessors or 

represent independent (multi-ref) values. The href attribute is 

intended to be used in a manner like CONREF. That is, the element 

content should be empty iff the href attribute appears 

source 

 

PAGINA 132 DI 133



Versione 2.0 


 

Attributes common to all elements that function as accessors or 

represent independent (multi-ref) values. The href attribute is 

intended to be used in a manner like CONREF. That is, the element 

content should be empty iff the href attribute appears 

 

 

 

 

 

 

Documento predisposto grazie alla collaborazione del Raggruppamento Temporaneo d’Impresa composto da: 

Gruppo Poste Italiane 

e da: 

PAGINA 133 DI 133

PCT - Specifiche di interfaccia PDA-GC v2.pdf - Majorana

You also want an ePaper? Increase the reach of your titles

Delete template?

Save as template?