Il contenuto del presente documento costituisce materiale riservato. Ogni violazione sarà punita ai sensi di legge.
Nuova Architettura CBI Porting degli attuali Servizi CBI nella Nuova Architettura
Riferimenti
Oggetto: Porting degli attuali Servizi CBI nella Nuova Architettura
Modello Documento: CBI.doc
Nome File: PORTING-MO-001 Porting attuali Servizi - v.00.07.09.doc
Versione: 00.07.09 – Pagine 59
Ultimo aggiornamento: 22/07/2010 11.35.36
Data creazione: 22/12/2004
Autore: Segreteria Tecnica CBI
Revisore: GdL Architettura – GdL standard
Titolo:
Nuova Architettura CBI
Codice
PORTING-MO-001 Versione
00.07.09
Tipologia Documento:
Porting degli attuali Servizi CBI nella Nuova Architettura
Data
09-07-2010
Pagina
2/59
Revisioni
Data Ver. Presentato
a
In vigore dal Aggiornamenti
01-06-2005 00.01 Primo rilascio
30-01-2006 00.02 Par. 2.3.2 - Inserimento di chiarimenti specifici e di esempi sui criteri di omogeneità nella creazione del file
Par. 2.3.3 - Chiarimento sulle modalità di composizione Header di Servizio
Par. 2.4 - Precisazioni sulla modalità di compilazione dei blocchi “Info File” e “Info Supporto” contenuti nel messaggio di stato avanzamento
Par. 2.4 - Inserimento di chiarimenti specifici su criteri e regole di composizione msg di avanzamento e aggiornamento codici d’errore previsti nei messaggi d’avanzamento
Par. 2.5 - Inserimento chiarimenti specifici sull’invio del supporto logico “CN”
Par. 2.6 - Chiarimento sulle modalità di invocazione del servizio “PORTING-A4”
Cap. 4 - Aggiornamento Regole di Governance, con l’inserimento di casi particolari di errore
Cap. 5 - Aggiornamento dei servizi esposti nel Directory con l’inserimento del servizio “PORTING-I4”
Cap. 5 - Inserimento modalità di indirizzamento dei flussi nel caso di Marketplace
Par. 8.3.2 - Aggiornamento stati di avanzamento dei supporti logici
Par. 8.3.2.3.1 – Aggiornamento campi del Body del msg XML di richiesta di servizio accompagnatorio del file
Par. 8.3.2.3.2 - Aggiornamento campi del Body del msg XML di stato avanzamento
Par. 8.4 – Inserimento esempi di XML in Allegato D con inserimento dei namespace in cui i vari blocchi di informazione sono definiti
02-05-2006 00.03 Par. 8.3.2.3.2 - Inserimento rimando al documento CBI-STD-001
Par. 2.6 – Inserimento appositi chiarimenti Cap. 8 – Allegato D – Aggiornamento esempi di
XML inserendo esempi specifici di 1° e 2° messaggio di avanzamento
Par. 2.4 – Inserimento chiarimenti specifici sulle modalità di correlazione tra messaggio di richiesta e messaggi di avanzamento
Par. 2.4.1 – Inserimenti chiarimenti sulle modalitàdi costruzione del messaggio 17 in caso di errore sul controllo di corrispondenza tra messaggio XML e file
Titolo:
Nuova Architettura CBI
Codice
PORTING-MO-001 Versione
00.07.09
Tipologia Documento:
Porting degli attuali Servizi CBI nella Nuova Architettura
Data
09-07-2010
Pagina
3/59
Cap. 5 – Differenziazione tra supporti logici di tipo “SL” inviati da Banca e supporti logici di tipo “SL” inviati dal Cliente
Par. 2.3.2 – Indicazione della riduzione del limite temporale sul controllo di univocità dei supporti logici da 13 mesi a 6 mesi
Par. 2.4.1 – Inserimento ulteriore codice d’errore sul messaggio 17 (PSL4): firma digitale come criterio di omogeneità
Par. 2.4.1 – Inserimento nota relativamente ad errori di parsing
Par. 2.2 – Eliminazione dell’attività di “Invio CN” da sequence e activity diagram per il servizio Porting
Par. 2.4.1 - Inserimento ulteriore controllo in ricezione relativo al Codice ABI e al CUC della Banca Passiva e ulteriore codice d’errore sul messaggio 17 (PSL6)
Cap. 5 – Inserimento chiarimento su controlli da effettuare su campi del Directory per indirizzamento flussi Porting
07-06-2006 00.04 Par 2.4.1 – Inserimento codice d’errore “PSL4” (Supporto logico non omogeneo per destinatario)
Allegato D – Modifica dell’esempio XML relativo al 1° messaggio di avanzamento (eliminando i blocchi “Info supporto” per ricezione OK)
Par. 2.4.1 e Par. 4.4.4 – Inserimento chiarimento specifico sulle modalità di segnalazione dell’errore in caso di incoerenza di informazioni nel solo messaggio XML
Par. 8.3.2.3.1 – Aggiornamento tipo dato del campo “Firma”, contenente la Busta PKCS#7
Cap. 6 – Inserimento durata “Giornata Applicativa” Par. 8.3.2.3.2 – Aggiornamento tipo dato associato
al campo “Numero disposizione” Par. 3.3 - chiarimenti su cosa si intende per
“controlli applicativi” Par. 4 – eliminazione refuso nota 4 a piè di pagina Par. 2.6 – eliminata la caratteristica di
“temporaneità” della soluzione prevista per la modalità di veicolazione dei flussi I4
09-06-2006 00.05 Par. 2.5 – Modifica modalità di invio supporti logici “A4”
17-07-2006 00.06 In vigore a partire dal
21-07-2006 per
l’effettuazione dei test
Par. 2.6 – Modifica modalità di trattamento dei flussi “I4”
Cap. 5 - Inserimento chiarimento sulle modalità di indirizzamento degli stati di avanzamento e degli esiti per richieste provenienti da Marketplace
Par. 2.4.1 – Inserimento chiarimento sui controlli da effettuare dalla Banca Destinataria per predisporre il 1° messaggio di avanzamento
20-12-2006 00.07 In vigore a partire
dall’attivazione della
totalità dei servizi
Porting
Par. 8.3.2.3.1 – Modifica descrizione campo “Riferimento temporale” all’interno del blocco “Firma”
Par. 2.6 – Inserimento apposito paragrafo per la gestione dei supporti logici “Q4” e “A4”
Par. 4.5 – Inserimento paragrafo per la gestione del recupero flussi in caso di errore
Par. 4.5.2 – Inserimento chiarimento specifico su modalità di rinvio dei flussi da parte del Mittente
Titolo:
Nuova Architettura CBI
Codice
PORTING-MO-001 Versione
00.07.09
Tipologia Documento:
Porting degli attuali Servizi CBI nella Nuova Architettura
Data
09-07-2010
Pagina
4/59
Par. 2.5 – Inserimento chiarimento specifico su invio supporti logici “A4” e “Q4”
Cap. 5 - Inserimento precisazione su dove reperire il codice marketplace necessario per l’indirizzamento degli esiti delle disposizioni di pagamento
Par. 8.3.2.3.1 – Eliminazione refuso “XML Signature” come possibile valore del campo “Tipo firma”
Par. 2.4 – Variazione nei controlli da effettuare in merito all’omogeneità dei flussi per destinatario logico
Par. 2.3.2 – Variazione della nota 1 in merito ai criteri di omogeneità
18-04-2007 00.07.04 In vigore a partire
dalla data di
attivazione del primo
set di Nuovi Servizi
CBI
Par 8.3.2.3.1 – Modificata la struttura del blocco firma che viene reso facoltativo
Par. 7 – Descrizione delle modalità di scarto in caso di errori correlati alla verifica della firma digitale
Par. 2.4.1 e Par 2.4.2 – Aggiunti i riferimenti al paragrafo 7 per la trattazione dei temi relativi alla gestione della firma digitale
05-07-2007 00.07.05 In vigore a partire
dalla data di
attivazione del primo
set di Nuovi Servizi
CBI
Nessuna modifica al presente documento. Sono stati rimossi dalla documentazione specifica dei Servizi Porting i file di schema relativi alla definizione degli header di tratta e di servizio e del blocco firma. Per tali file si deve fare riferimento a quelli contenuti nella documentazione PARTE GENERALE
31-10-2007 00.07.06 In vigore a partire dal
25 Febbraio 2008
Par. 8.3.2.3.1 – Inserita precisazione circa l’utilizzo del campo <CreDt>, il quale non deve contenere il dettaglio relativo al Time Zone
Par. 8.3.2.3.2 – Inserita precisazione circa l’utilizzo del campo <CreDt>, il quale non deve contenere il dettaglio relativo al Time Zone
18-02-2008 00.07.07 Novembre 2008 Par. 8.5: inserito elenco dei qualificatori tipo messaggio da utilizzare per la strutturazione degli identificativi di file e messaggi, in accordo a quanto specificato nel documento Parte Generale
10-10-2008 00.07.08 In vigore a partire dalla data di attivazione della firma digitale sui flussi dispositivi di Porting
Par. 2.4.1: meglio dettagliato la verifica di coerenza tra i supporti logici referenziati nel messaggio XML e quelli contenuti nel file
Par. 4.4.6: aggiunta precisazione in merito alle modalità di composizione dei messaggi 20 (ordine nel quale sono referenziati i supporti originari)
Par. 4.5.1: modifica della procedura di recupero dei flussi a seguito di un errore effettuato dal ricevente
Par 2.4.2: inserimento chiarimento circa le modalità di scarto in caso di codice SIA non censito
Par. 2.1: inserimento chiarimento circa la differenza tra supporti logici informativi e dispositivi
Par. 2.4.1: aggiunta tipologia di scarto dei flussi firmati provenienti da mittenti fisici non autorizzati
Par. 7: inserito apposito paragrafo che descrive le modalità di scarto di flussi firmati provenienti da mittenti fisici non autorizzati
Par. 8.3.2.3.2: modificata descrizione relativa al
Titolo:
Nuova Architettura CBI
Codice
PORTING-MO-001 Versione
00.07.09
Tipologia Documento:
Porting degli attuali Servizi CBI nella Nuova Architettura
Data
09-07-2010
Pagina
5/59
codice di errore PF5 Par. 5: inserito chiarimento circa modalità di
indirizzamento degli esiti di pagamento verso MarketPlace
09-07-2010 00.07.09 30 agosto 2010 Par. 2.2.1.1: eliminato riferimento ai flussi “CN” non previsti dalla attuale architettura di Rete
Par 2.3.2: aggiunta precisazione circa i criteri di aggregazione dei supporti logici nel file e circa la dimensione massima dei file. Aggiunta precisazione in merito alla data e il periodo di riferimento per effettuare il controllo di univocità dei supporti logici
Par. 2.4.1 aggiunta verifica omogeneità dei supporti logici relativamente all’utilizzo della firma digitale e alla tipologia di firma utilizzataall’interno di uno stesso flusso
Par. 7: aggiornati i riferimenti tecnici per la gestione della firma digitale a norma (cfr. deliberazione CNIPA n°45 del 21 maggio 2009 in vigore dal 30 agosto 2010)
Par. 7.3: inserite precisazioni circa i controlli relativi alla firma digitale. Ordine dei controlli e “leggibilità” della busta
Allegato C: modificata descrizione dei campi relativi al blocco di informazioni sulla firma
24-05-2010 00.07.09 1 Novembre 2010 Par. 6 Definizione e determinazione dei tempi di attraversamento sistema CBI
Titolo:
Nuova Architettura CBI
Codice
PORTING-MO-001 Versione
00.07.09
Tipologia Documento:
Porting degli attuali Servizi CBI nella Nuova Architettura
Data
09-07-2010
Pagina
6/59
Riservatezza e divulgazione
Il “Consorzio Customer to Business Interaction” – di seguito definito Consorzio CBI – in qualità di titolare dei marchi CBI fornisce queste informazioni prevedendo che siano mantenuti i livelli di correttezza e, se indicati, di riservatezza sui relativi contenuti. Il documento potrà pertanto essere fotocopiato o riprodotto in tutto o in parte ed i contenuti potranno essere divulgati a terzi, anche consulenti, purché siano rispettate le disposizioni di cui alla Intellectual Property Rights disponibile sul sito web consortile.
Titolo:
Nuova Architettura CBI
Codice
PORTING-MO-001 Versione
00.07.09
Tipologia Documento:
Porting degli attuali Servizi CBI nella Nuova Architettura
Data
09-07-2010
Pagina
7/59
Indice dei Contenuti 1 Obiettivi del documento................................................................................9
1.1 Struttura del documento....................................................................................9
2 Il Servizio “PORTING ATTUALI TRACCIATI” ...............................................10
2.1 Introduzione................................................................................................... 10
2.2 Porting degli attuali tracciati: caso d’uso ........................................................... 10 2.2.1 Ipotesi di base ed attori identificati ............................................................ 10
2.3 Invocazione di Servizio .................................................................................... 15 2.3.1 Regole per la creazione del supporto logico ................................................ 17 2.3.2 Regole per la creazione del file .................................................................. 17 2.3.3 Regole per la creazione del messaggio ....................................................... 19
2.4 Stati di avanzamento....................................................................................... 20 2.4.1 Controlli e regole di composizione del 1° messaggio di avanzamento ............ 21 2.4.2 Controlli e regole di composizione del 2° messaggio di avanzamento ............ 23
2.5 Considerazioni su invio supporti logici “F4”, “R4”................................................ 24
2.6 Considerazioni su invio supporti logici “Q4”, “A4” ............................................... 25
2.7 Considerazioni su invio supporti logici “I4”......................................................... 26
3 Diagnostica .................................................................................................27
3.1 Diagnostica sul messaggio ............................................................................... 27
3.2 Diagnostica sul file .......................................................................................... 27
3.3 Diagnostica sul supporto logico ........................................................................ 27
4 Regole di governance..................................................................................28
4.1 Mancato rispetto delle tempistiche di invio dei messaggi di avanzamento............. 28
4.2 Mancato rispetto della sequenza di invio dei messaggi di avanzamento................ 29
4.3 Casi specifici di errore...................................................................................... 29 4.3.1 File non trovato ........................................................................................ 29 4.3.2 Non omogeneità dei supporti logici ............................................................ 29 4.3.3 Supporti logici non referenziati .................................................................. 29 4.3.4 Errori di diagnostica applicativa su alcuni supporti logici............................... 30
4.4 Casi generali di errore ..................................................................................... 30 4.4.1 Non univocità della correlazione file-messaggio ........................................... 30 4.4.2 Messaggio ricevuto illeggibile..................................................................... 30 4.4.3 Supporti logici duplicati ............................................................................. 30 4.4.4 Incoerenza “Nome servizio” e “Tipologia flusso” nel messaggio XML ............. 31 4.4.5 Mancata corrispondenza nel 1° messaggio di avanzamento.......................... 31
Titolo:
Nuova Architettura CBI
Codice
PORTING-MO-001 Versione
00.07.09
Tipologia Documento:
Porting degli attuali Servizi CBI nella Nuova Architettura
Data
09-07-2010
Pagina
8/59
4.4.6 Mancata corrispondenza nel 2° messaggio di avanzamento.......................... 31
4.5 Recupero dei flussi in caso di errore ................................................................. 31 4.5.1 Errore imputabile al soggetto ricevente ...................................................... 31 4.5.2 Errore imputabile al soggetto mittente........................................................ 32 4.5.3 Gestione delle contestazioni ...................................................................... 32
5 Individuazione indirizzo di erogazione del Servizio Porting .......................33
6 Livelli di servizio..........................................................................................34
7 Firma digitale ..............................................................................................39
7.1 Controllo del mittente fisico dei flussi firmati...................................................... 39
7.2 Controllo di omogeneità per apposizione della firma digitale ............................... 39
7.3 Verifica della firma sui singoli supporti logici ...................................................... 41
8 Allegati ........................................................................................................43
8.1 Allegato A – Criteri di identificazione univoca di messaggio e file ......................... 43
8.2 Allegato B - Popolamento del Directory a fini di “porting” ................................... 43
8.3 Allegato C – Struttura dei Messaggi XML d’invio file/stato d’avanzamento ............ 43 8.3.1 Considerazioni generali ............................................................................. 43 8.3.2 Struttura.................................................................................................. 43
8.4 Allegato D – Esempi di XML ............................................................................. 55
8.5 Allegato E – strutturazione degli identificativi univoci e qualificatori di tipo messaggio ............................................................................................................ 59
Titolo:
Nuova Architettura CBI
Codice
PORTING-MO-001 Versione
00.07.09
Tipologia Documento:
Porting degli attuali Servizi CBI nella Nuova Architettura
Data
09-07-2010
Pagina
9/59
1 Obiettivi del documento Il presente documento ha l'obiettivo di definire i criteri e le modalità con i quali deve essere realizzato il “porting” degli attuali Servizi CBI sulla Nuova Architettura, nonché evidenziare le attività che, propedeuticamente, devono essere svolte per rendere possibile tale “porting”. Il documento richiama definizioni, concetti e criteri già espressi nella documentazione attinente sia all’attuale, sia alla Nuova Architettura CBI. In particolare è presa come riferimento la seguente documentazione: gli standard tecnici dell’attuale architettura, identificati dal Codice Classificazione “CBI-XXX-NNN”, ove:
- CBI: è il codice di progetto assegnato dalla Segreteria Tecnica dell’Associazione per il CBI per la documentazione relativa all’attuale architettura:
- XXX: è la tipologia di documento (ad esempio BON, AEA, F24, etc.); - NNN: è il codice progressivo del documento nell’ambito della tipologia XXX.
“STPG-MO-001 Nuovi Servizi – Parte Generale”; “FIRMA-MO-001 Introduzione alla Firma Digitale: aspetti tecnici e generalità”. Dato il livello di approfondimento dei temi trattati, il Documento si configura come Manuale Operativo e destinato a quanti sono chiamati ad effettuare le implementazioni necessarie al Porting.
1.1 STRUTTURA DEL DOCUMENTO Il documento è strutturato nelle seguenti sezioni:
- Definizione del Servizio “Porting Attuali Tracciati”; - Regole di governance; - Diagnostica; - Individuazione dell’indirizzo di erogazione del Servizio; - Livelli di servizio; - Firma digitale applicata al Porting; - Criteri di identificazione univoca di messaggio e file (Allegato A); - Popolamento del Directory ai fini del Porting (Allegato B); - Struttura dei messaggi XML (Allegato C); - Esempi di messaggi XML (Allegato D).
Titolo:
Nuova Architettura CBI
Codice
PORTING-MO-001 Versione
00.07.09
Tipologia Documento:
Porting degli attuali Servizi CBI nella Nuova Architettura
Data
09-07-2010
Pagina
10/59
2 Il Servizio “PORTING ATTUALI TRACCIATI”
2.1 INTRODUZIONE I supporti logici in uso nell’attuale architettura sono veicolati nella Nuova Architettura mediante l’invocazione, da parte della Banca Mittente, di un Servizio “PORTING ATTUALI TRACCIATI”, strutturato come segue: - invio verso la Banca Destinataria di un “file di supporti logici” (veicolato tramite file transfer); - invio verso la Banca Destinataria di un “messaggio XML” (veicolato tramite message switching)
contenente i riferimenti del file e le informazioni riepilogative sui supporti logici in esso contenuti. A tale invocazione di servizio, la Banca Destinataria risponde inviando verso la Banca Mittente uno o più messaggi XML di stato avanzamento/segnalazione errori rilevati. In deroga a quanto definito nel documento CBI-STD-001, nel presente documento per supporti logici informativi si intendono i supporti aventi come destinatario finale una azienda (es. RH, esiti RiBa) mentre vengono indicati come dispositivi i supporti logici aventi come destinatario finale una banca (es. PC, RiBa). Il Servizio “PORTING ATTUALI TRACCIATI” è un “unicum”, con un’unica invocazione, ancorché sia composto da due parti logicamente correlate – l’invio di un file e l’invio del relativo messaggio - che devono risultare altresì sincronizzate tra loro. In linea con tale principio, i capitoli che seguono sono stati redatti in accordo ai seguenti “criteri base”: - la funzionalità di sincronizzazione, in invio e ricezione, di “file+messaggio” è fornita da un apposito
modulo applicativo, realizzato e messo a disposizione delle Banche della Comunità CBI. Tale funzionalità, pertanto, non è a carico delle Applicazioni Bancarie;
- tutti i flussi (supporti logici, file di supporti logici e messaggi) devono essere sottoposti a diagnostica prima del loro invio sulla Rete Logica; tale diagnostica deve essere effettuata tramite un diagnostico certificato (in accordo ai requisiti definiti da ACBI);
- la responsabilità delle attività di diagnostica è in capo alla Banca, fermo restando la facoltà di quest’ultima di delegare tale attività ad un soggetto terzo (Gestore del Punto d’Accesso, STD etc.).
2.2 PORTING DEGLI ATTUALI TRACCIATI: CASO D’USO Al fine di descrivere le funzionalità e le caratteristiche tecnologiche offerte dalla Nuova Architettura rispetto alla veicolazione dei supporti logici, è stato identificato un “caso d’uso” descrittivo dell’invocazione della richiesta di servizio da parte della Banca Mittente e delle relative risposte inviate dalla Banca Destinataria. Il “caso d’uso” prende in considerazione l’invocazione del Servizio ed i relativi stati di avanzamento/segnalazioni d’errore – ed è stato sviluppato costruendo un modello UML rappresentato da: sequence diagram: descrive le interazioni tra i vari soggetti/attori in funzione dello scorrere del tempo,
rappresentato dall’asse verticale del diagramma; activity diagram: descrive il flusso delle attività svolte dai diversi attori evidenziandone i possibili
parallelismi.
2.2.1 Ipotesi di base ed attori identificati Al fine di garantire la generalità del modello, questo è stato costruito in accordo alle seguenti “ipotesi di base”:
Titolo:
Nuova Architettura CBI
Codice
PORTING-MO-001 Versione
00.07.09
Tipologia Documento:
Porting degli attuali Servizi CBI nella Nuova Architettura
Data
09-07-2010
Pagina
11/59
le attività potenzialmente delegabili ad una STD sono state assegnate alla Banca; il che comporta che nel modello i due attori sono coincidenti. A ciascuna Banca è lasciata la valutazione se tali attività debbano essere svolte in proprio o, sotto la propria responsabilità, tramite STD;
le modalità di accesso alla Nuova Architettura (NA) dipendono dal contesto tecnologico/architetturale di riferimento esistente presso ciascuna Banca (es. Punto di Accesso NA presso la STD della Banca). Per questo motivo il “Gestore del Punto di Accesso” non è identificato come attore autonomo, ma coincide con la Banca. A ciascuna Banca è lasciata la valutazione se tali attività debbano essere svolte in proprio o, sotto la propria responsabilità, tramite STD oppure un Gestore del Punto di Accesso;
l’invio del file/messaggio avviene direttamente tra Banca Mittente e Banca Destinataria; non è considerato in questo modello l’utilizzo di repository esterni residenti presso Terze Parti;
l’invio/ricezione del “file+messaggio” è a carico di una apposita funzione di sincronizzazione fornita da un modulo di sistema.
Il modello logico di interconnessione utilizzato per la modellazione del caso d’uso è riportato nella figura seguente
Punto diAccesso
NA
BancaDestinataria
Punto diAccesso
NA
Banca MittenteDirectory
Le modalità di interconnessione Banca - Punto di Accesso NA potranno esseredifferenti per ciascuna banca (es. Punto di Accesso NA presso la Banca/STD)
Aziendacliente
Aziendacliente
Figura 1 – Modello logico d’interconnessione
Alla luce di quanto sopra, gli attori utilizzati per la costruzione del “caso d’uso” sono: Banca Mittente Banca Destinataria Directory Si evidenzia inoltre che l’esecuzione delle attività di seguito descritte (Cfr. sequence e activity diagram) presuppone l’implementazione, da parte di ciascuna Banca, di uno specifico workflow applicativo, necessario all’effettivo svolgimento delle attività riportate. Le modalità di implementazione di tale workflow dipenderanno dal contesto tecnologico di riferimento di ciascuna Banca, in funzione del quale le attività descritte potranno essere svolte direttamente dalla Banca, dalla relativa STD o da un soggetto terzo (Centro Servizi, Gestore punto di accesso Nuova Architettura etc.). Fermo restando che la tratta “Azienda – Banca” è funzionalmente di pertinenza della Banca stessa, l’obiettivo del caso d’uso è quello di evidenziare le principali attività in carico ai vari attori bancari e di fornire una visione complessiva del workflow applicativo da implementare. 2.2.1.1 Sequence diagram La seguente Figura riporta il sequence diagram del caso d’uso, unitamente ad una descrizione sintetica delle attività svolte; la descrizione di dettaglio di ciascuna attività è riportata nel seguito del paragrafo.
Titolo:
Nuova Architettura CBI
Codice
PORTING-MO-001 Versione
00.07.09
Tipologia Documento:
Porting degli attuali Servizi CBI nella Nuova Architettura
Data
09-07-2010
Pagina
12/59
Banca DestinatariaBanca Mittente Directory
8: Invio query di indirizzamento sul Directory
(opzionale)
File
9: Esecuzione query10: Invio “indirizzo” Banca Destinataria
XML
13: Ricezione messaggio+file
12: Invio file+messaggio
XML FileXML File
18: Diagnostica applicativa supporti logici (diagnostica attuale formale)20: Invio messaggio stato
avanzamento(OK)/ errori rilevati(KO)
XML
16: Predisposizione messaggio di avanzamento / di errore
19: Predisposizione stato avanzamento/ errori rilevati
XML
1: Predisposizione supporti logici
7: Verifica informazioni di indirizzamento disponibili
11: Ricezione indirizzo Banca Destinataria
2: Diagnostica applicativa supporti logici(attuale diagnostica formale)
4: Predisposizione messaggio XML associato al file
3: Predisposizione e diagnostica file
5. Diagnostica coerenza file-messaggio
6. Diagnostica messaggio XML
17: Invio messaggio stato avanzamento (OK) / errori rilevati (KO)
14: Diagnostica messaggio XML (vedi 6)
15: Verifica omogeneitàfile e coerenza file-messaggio (vedi 3 e 5)
Figura 2 – Sequence diagram
Descrizione delle attività: 1 - 2: La Banca Mittente predispone e diagnostica i supporti logici da inviare (attuale diagnostica formale dei
supporti logici).
3 - 6: Predisposti i supporti logici, la Banca Mittente provvede alla predisposizione ed alla diagnostica del file fisico e, quindi, alla creazione del messaggio XML con le informazioni sui supporti logici contenuti nel file. La Banca Mittente diagnostica il messaggio XML predisposto e verifica la coerenza tra file e messaggio, in termini di puntatori e referenze messaggio-file.
7-11: La Banca Mittente verifica la completezza delle informazioni di indirizzamento a propria disposizione. In caso di verifica positiva, provvede all’invio del “file+messaggio” (Cfr. punto 12). Nel caso in cui le informazioni di indirizzamento non siano già disponibili alla Banca Mittente, quest’ultima provvede all’invio al directory di una query specifica di indirizzamento; Tale query viene elaborata dal Directory e la relativa risposta viene quindi restituita alla Banca Mittente (indirizzo di Rete Logica della Banca Destinataria corrispondente al Servizio di porting).
12: Ottenute tutte le informazioni necessarie all’indirizzamento, la Banca Mittente invoca la primitiva “send file+messaggio” per l’invio del file e del messaggio associato verso il Destinatario.
13 - 17: Ricevuto file e messaggio, la Banca Destinataria provvede ad eseguire la diagnostica del messaggio XML e la verifica di congruenza dei riferimenti messaggio – file. Nel caso di errori, invia un messaggio XML verso la Banca Mittente contente la descrizione degli errori rilevati (KO), sospendendo l’elaborazione del messaggio XML e del relativo file. Nel caso in cui non vi siano errori la Banca Mittente predispone ed invia un messaggio XML di stato d’avanzamento (OK).
Titolo:
Nuova Architettura CBI
Codice
PORTING-MO-001 Versione
00.07.09
Tipologia Documento:
Porting degli attuali Servizi CBI nella Nuova Architettura
Data
09-07-2010
Pagina
13/59
18 - 20: Eseguita l’attuale diagnostica formale sui supporti logici, la Banca Destinataria predispone un messaggio XML di stato di avanzamento (OK)/notifica errori rilevati (KO) e lo invia verso la Banca Mittente.
2.2.1.2 Activity Diagram Le figure seguenti riportano, in accordo alle attività previste dal sequence diagram, l’activity diagram relativo al caso d’uso descritto, unitamente alla descrizione delle attività rappresentate sul diagramma.
Banca Destinataria
Banca Destinataria
Banca MittenteBanca MittenteDirectory
1.Predisposizione supporti logici
1.Predisposizione supporti logici
9.Esecuzione query
10.Invio indirizzo Banca Destinataria
2.Diagnostica applicativa supporti logici (attuale diagnostica formale)
2.Diagnostica applicativa supporti logici (attuale diagnostica formale)
3: Predisposizione e diagnostica file
3: Predisposizione e diagnostica file
4: Predisposizione messaggio XML associato
al file
4: Predisposizione messaggio XML associato
al file
7: Verifica informazioni di indirizzamento disponibili7: Verifica informazioni di indirizzamento disponibili
8: Invio query di indirizzamento sul
Directory
8: Invio query di indirizzamento sul
Directory
11: Ricezione indirizzo Banca Destinataria
11: Ricezione indirizzo Banca Destinataria
12: Invio file+messaggio12: Invio file+messaggio
Info disponibili
NO
SI
5: Diagnostica coerenza file-messaggio
5: Diagnostica coerenza file-messaggio
6: Diagnostica messaggio XML
6: Diagnostica messaggio XML
Figura 3 – Activity diagram – Parte 1 La Banca Mittente predispone i supporti logici da inviare, eseguendo i relativi controlli diagnostici (attuale diagnostica formale).
Titolo:
Nuova Architettura CBI
Codice
PORTING-MO-001 Versione
00.07.09
Tipologia Documento:
Porting degli attuali Servizi CBI nella Nuova Architettura
Data
09-07-2010
Pagina
14/59
Completata tale attività, la Banca Mittente predispone il file fisico ed il messaggio XML associato, verifica la completezza delle informazioni di indirizzamento disponibili e, in caso di verifica positiva, provvede ad avviare la fase di invio di file+messaggio. Nel caso in cui le informazioni d’indirizzamento non fossero complete, la Banca Mittente provvede ad inviare al Directory una query di indirizzamento al fine di ottenere tali informazioni; elaborata tale richiesta, il Directory provvede ad inviare l’indirizzo della Banca Destinataria verso la Banca Mittente. Ottenute le informazioni per l’indirizzamento, la Banca Mittente provvede quindi all’invio del file+messaggio.
Banca Destinataria
Banca Destinataria
Banca MittenteBanca MittenteDirectory
13: Ricezione messaggio+file13: Ricezione
messaggio+file
14: Diagnostica messaggio XML (vedi 6)
14: Diagnostica messaggio XML (vedi 6)
13: Verifica omogeneitàfile e coerenza file-
messaggio (vedi 3 e 5)
Errori rilevati
14: Predisposizione e invio messaggio di
errore
SI
NO
16: Diagnostica applicativa supporti
logici (attuale diagnostica formale)
16: Diagnostica applicativa supporti
logici (attuale diagnostica formale)
17: Predisposizione stato avanzamento/
errori rilevati
17: Predisposizione stato avanzamento/
errori rilevati
18: Invio messaggio stato avanzamento/
errori rilevati
18: Invio messaggio stato avanzamento/
errori rilevati
15: Invio messaggio stato avanzamento15: Invio messaggio stato avanzamento
Figura 4 – Activity diagram - Parte 2
La Banca Destinataria, ricevuti file e messaggio, provvede ad eseguire la diagnostica del messaggio XML e la verifica di congruenza rispetto al contenuto del file. Nel caso di errori, invia un messaggio XML verso la Banca Mittente contenente la descrizione degli errori rilevati, sospendendo l’elaborazione del messaggio XML e del relativo file (Cfr. Par. successivi per le regole di comportamento). Nel caso in cui non vi siano errori la Banca Destinataria predispone ed invia un messaggio XML di stato d’avanzamento.
Titolo:
Nuova Architettura CBI
Codice
PORTING-MO-001 Versione
00.07.09
Tipologia Documento:
Porting degli attuali Servizi CBI nella Nuova Architettura
Data
09-07-2010
Pagina
15/59
La Banca Destinataria esegue la diagnostica dei supporti logici e invia un messaggio XML di stato di avanzamento/errori rilevati verso la Banca Mittente. 2.2.1.3 Considerazioni su Sequence e Activity diagram Al fine di completare la descrizione del Servizio “PORTING ATTUALI TRACCIATI” rappresentata dal sequence e dall’activity diagram, e ricordando quanto già espresso precedentemente al Capitolo 2.1 - ovvero che la responsabilità delle attività di diagnostica è in capo alla Banca, fermo restando la facoltà di quest’ultima di delegare tale ad un soggetto terzo (Gestore del Punto d’Accesso, STD etc.) - deve essere comunque evidenziato che: - ogni Banca Mittente ha l’obbligo di garantire alla Banca Destinataria la rispondenza di quanto inviato agli
standard in uso tramite un diagnostico certificato (in accordo ai requisiti definiti da ACBI) ed evidenziando nel messaggio le informazioni relative a tale diagnostico
- la Banca Destinataria ha il diritto di ricevere flussi conformi agli standard in uso e diagnosticati tramite un diagnostico certificato (in accordo ai requisiti definiti dal Consorzio CBI)
2.3 INVOCAZIONE DI SERVIZIO Facendo riferimento al caso d’uso sopra descritto, in estrema sintesi - rispetto alle procedure oggi in essere - la Banca Mittente dovrà prevedere:
nuovi criteri di omogeneità dei flussi creazione e gestione del messaggio XML predisposizione e gestione di workflow per il Servizio diagnostica del messaggio XML
In particolare il processo seguirà i seguenti passi:
Titolo:
Nuova Architettura CBI
Codice
PORTING-MO-001 Versione
00.07.09
Tipologia Documento:
Porting degli attuali Servizi CBI nella Nuova Architettura
Data
09-07-2010
Pagina
16/59
3a.Predisposizione e diagnostica file
1.Predisposizione supporti logici
1.Predisposizione supporti logici
2.Diagnostica supporti logici (attuale diagnostica formale)
3b.Costruzione del messaggio XML (contiene i riferimenti applicativi al file)
5.Spedizione file+messaggio
6.Ricezione dalla rete di ok di trasmissione file+messaggio
3c.Diagnostica messaggio XML
7.Attesa risposta applicativa stato avanzamento/errori rilevati
4.Verifica coerenza file-messaggio
8.Attesa risposta applicativa stato avanzamento/errori rilevati
Figura 5 – Processo invio “messaggio + file” Rispetto alle procedure oggi in essere, la Banca Destinataria dovrà gestire un processo con i seguenti passi:
Titolo:
Nuova Architettura CBI
Codice
PORTING-MO-001 Versione
00.07.09
Tipologia Documento:
Porting degli attuali Servizi CBI nella Nuova Architettura
Data
09-07-2010
Pagina
17/59
1: Ricezione messaggio+file
1: Ricezione messaggio+file
2: Diagnostica messaggio XML
2: Diagnostica messaggio XML
3: Verifica omogeneità file e coerenza file-messaggio
Errori rilevati4: Invio messaggio di errore4: Invio messaggio di erroreSI
NO
6: Diagnostica supporti logici (diagnostica attuale formale)
6: Diagnostica supporti logici (diagnostica attuale formale)
7: Predisposizione stato avanzamento/ errori
rilevati
7: Predisposizione stato avanzamento/ errori
rilevati
8: Invio messaggio stato avanzamento/
errori rilevati
8: Invio messaggio stato avanzamento/
errori rilevati
5: Invio messaggio stato avanzamento5: Invio messaggio stato avanzamento
Figura 6 – Processo ricezione “messaggio + file” 2.3.1 Regole per la creazione del supporto logico Gli standard previsti per la creazione del supporto logico sono quelli già in essere per gli attuali Servizi CBI. In particolare si confermano i criteri di omogeneità definiti per la creazione del supporto. 2.3.2 Regole per la creazione del file All’interno di un file fisico la Banca può1, discrezionalmente, inserire uno o più supporti logici. I supporti logici devono essere omogenei per:
1 Per lo scambio di flussi informativi tra Banche si raccomanda la minimizzazione del numero di file fisici (per ragioni legate alla performance). In particolare, per quanto riguarda i flussi informativi destinati alla Clientela la Banca Passiva è tenuta ad operare con criteri di omogeneità per Banca Proponente/Destinataria.
Titolo:
Nuova Architettura CBI
Codice
PORTING-MO-001 Versione
00.07.09
Tipologia Documento:
Porting degli attuali Servizi CBI nella Nuova Architettura
Data
09-07-2010
Pagina
18/59
- tipo supporto (es. “PC”, “RH”); - destinatario “logico” (es. Banca Passiva per i flussi “PC”, Banca Proponente per i flussi “RH”); - soggetto di riferimento del destinatario “logico” (es. STD, GPA); - indirizzo di Rete Logica del soggetto di riferimento; - applicazione della firma digitale. Per i file contenenti supporti logici non firmati, il numero massimo di supporti logici da includere nel file “fisico” è fissato a 1500. Tale limite garantisce che i successivi messaggi di stato avanzamento abbiano una dimensione massima di 1 MB. Per i file contenenti supporti logici firmati, il numero massimo degli stessi (comunque non superiore a 1500) non è definito a priori ma è in funzione del rispetto della dimensione di 1 MB del messaggio di accompagnamento del file dove i supporti logici sono referenziati e dove è presente – codificata in base64 – la busta contenente la firma digitale. Si osserva che, alla data, la rete logica CBI non consente la veicolazione di file la cui dimensione superi 2GB (cfr. specifiche del fornitore di rete), pertanto l’aggregazione dei supporti logici nei file deve essere effettuata tenendo in considerazione anche tale limite. Si evidenzia come, in funzione delle informazioni di indirizzamento disponibili a ciascuna Banca, le attività di predisposizione del file potranno prevedere uno o più accessi al Directory al fine di verificare il rispetto dei criteri di omogeneità definiti. Per semplicità di rappresentazione tali accessi non sono riportati sui diagrammi ma possono essere derivati direttamente da quanto su di essi riportato (cfr. Punti 8-9-10 del sequence diagram o punti 8-9-10-11 dell’activity diagram). Al fine di semplificare la verifica d’integrità del file, l’ordine dei supporti logici che lo costituiscono dovrà essere lo stesso di quello riportato nel messaggio XML (Cfr. Par. 2.3.3.2 per i dettagli) e la corrispondenza tra i campi “Nome supporto” nel messaggio XML e nel file dovrà essere di tipo 1:1. In particolare, il file dovrà iniziare con il record di testa del primo supporto logico referenziato dal messaggio XML e terminare con il record di coda dell’ultimo (Cfr. Standard Tecnici attuali servizi CBI per le regole di composizione dei record di testa/coda). L’assegnazione del “Nome supporto” dovrà inoltre rispettare i criteri di univocità definiti (univocità per “Nome supporto”, “Tipologia flusso”, “Data creazione”, “Mittente” e “Destinatario”) con un periodo di “storico” pari a 180 giorni di calendario. In considerazione del fatto che non esiste alcuna correlazione tra la data di creazione del supporto logico e la data in cui lo stesso è effettivamente inviato alla controparte, la verifica di univocità deve essere effettuata nell’ambito dei 180 giorni di calendario precedenti alla data in cui il controllo stesso è effettuato dalla banca e/o soggetto tecnico delegato e non alla data di creazione del supporto logico. Sebbene il periodo entro il quale si deve effettuare il controllo di univocità delle chiavi identificative sia di 180 giorni di calendario, si raccomanda di garantire l’univocità dei supporti logici per un periodo più ampio al fine di facilitare eventuali attività di storicizzazione e riconciliazione degli stessi anche a lungo termine.
Titolo:
Nuova Architettura CBI
Codice
PORTING-MO-001 Versione
00.07.09
Tipologia Documento:
Porting degli attuali Servizi CBI nella Nuova Architettura
Data
09-07-2010
Pagina
19/59
2.3.2.1 Esempi sui criteri di omogeneità Di seguito vengono mostrati alcuni esempi sull’applicazione dei criteri di omogeneità sui supporti logici. Esempio
Scenario File da predisporre
Flusso SL1 da Banca Passiva BS1 ad Azienda AZ1 AZ1 ha come Banca Proponente BR2 BR2 si avvale dei servizi della STD STD1 per erogare i servizi ad AZ1
File 1
Flusso SL2 da Banca Passiva BS1 ad Azienda AZ2 AZ2 ha come Banca Proponente BR2 BR2 si avvale dei servizi della STD STD2 per erogare i servizi ad AZ2
File 2
Nel caso in cui BS1 produca un unico file fisico contenente i supporti logici SL1 ed SL2, uno dei due sarebbe recapitato al destinatario fisico errato, anche se la Banca Proponente indicata è la stessa. 2.3.3 Regole per la creazione del messaggio La Banca deve creare il messaggio XML secondo i criteri e gli standard già previsti per i nuovi Servizi CBI. Si faccia riferimento alla relativa documentazione per le specifiche di dettaglio (cfr. “STPG-MO-001 Nuovi Servizi - Parte Generale”); nel seguito del paragrafo vengono riportate le considerazioni specifiche per il servizio “Porting”. 2.3.3.1 Creazione “Header di E2E di Servizio” In linea con quanto già descritto nel documento “STPG-MO-001 - Nuovi Servizi Parte Generale”, le regole di composizione dell’Header E2E di Servizio per il servizio Porting prevedono che il destinatario “logico” di un flusso Banca/Cliente sia la Banca Proponente dell’Azienda, la quale provvederà poi a disaggregare i flussi in base al Codice SIA dell’Azienda. In modo analogo, il mittente “logico” previsto nella tratta Cliente/Banca è la Banca Proponente dell’Azienda, che provvederà in questo caso ad aggregare i flussi diretti verso la stessa Banca Passiva. Di seguito vengono mostrati alcuni scenari esemplificativi, in cui: AZ1 è un Cliente CBI della Banca Proponente BR1 BR1 accede alla NACBI mediante un GPA GPA1 (in alternativa si può prevedere una STD STD1) BS1 è una Banca Passiva ed accede alla NACBI mediante un GPA GPA2 (in alternativa si può prevedere
una STD STD2)
Scenario Hdr Campi Richiesta di Servizio
Mittente Fisico CUC GPA1 Header di Tratta Destinatario Fisico CUC GPA2
Mittente Logico CUC BR1 Tipo SdR Mittente GPA Id SdR Mitt CUC GPA1 Destinatario Logico CUC BS1 Tipo SdR Destinatario GPA
Flussi diretti da Azienda AZ1 a Banca Passiva BS1
Header E2E
Id SdR Dest CUC GPA2
Titolo:
Nuova Architettura CBI
Codice
PORTING-MO-001 Versione
00.07.09
Tipologia Documento:
Porting degli attuali Servizi CBI nella Nuova Architettura
Data
09-07-2010
Pagina
20/59
Scenario Hdr Campi Richiesta di Servizio
Mittente Fisico CUC GPA2 Header di Tratta Destinatario Fisico CUC GPA1
Mittente Logico CUC BS1 Tipo SdR Mittente GPA Id SdR Mitt CUC GPA2 Destinatario Logico CUC BR1 Tipo SdR Destinatario GPA
Flussi diretti da Banca Passiva BS1 ad Azienda AZ1
Header E2E
Id SdR Dest CUC GPA1 2.3.3.2 Creazione “Body di Servizio” In Allegato C sono riportate le specifiche per la strutturazione del “Body di servizio“ unitamente alla descrizione dello schema XML. Nella costruzione del messaggio, l’ordine dei supporti logici referenziati (campo “Nome supporto”) dovrà essere lo stesso di quello riportato nel file. Si evidenzia inoltre come ad ogni messaggio debba corrispondere uno ed un solo file fisico.
2.4 STATI DI AVANZAMENTO Il sequence diagram relativo al “Caso d’uso” descrive i messaggi XML scambiati tra Banca Mittente e Banca Destinataria durante l’esecuzione di una richiesta di Servizio. La Banca Mittente (es. Banca Proponente nel caso di “PORTING-PC”, Banca Passiva nel caso di “PORTING-RH”) invia un messaggio XML + file verso la Banca Destinataria (es. Banca Passiva nel caso di “PORTING-PC”, Banca Proponente nel caso di “PORTING-RH” – cfr. punto 12 sequence diagram) che provvede a: - eseguire la diagnostica del messaggio XML; - verificare l’omogeneità del file e la coerenza file-messaggio. Dopodiché, la Banca Mittente predispone e invia un primo messaggio di avanzamento/errori rilevati (cfr. punto 17) verso la Banca Mittente. Nel caso in cui il file sia stato ricevuto correttamente e l’associazione tra i supporti logici dichiarati nel messaggio XML e quelli contenuti nel file sia corretta, la Banca Destinataria esegue la diagnostica applicativa dei supporti logici (attuale diagnostica formale) e invia successivamente un secondo messaggio di avanzamento verso la Banca Mittente (cfr. punto 20). L’identificazione e la correlazione dei vari messaggi (richiesta di servizio più i 2 messaggi di stato avanzamento) necessaria per l’espletamento del servizio avviene attraverso il campo “Nome file” all’interno del blocco “Info file” (presente sia nel messaggio XML di richiesta di servizio sia nei messaggi XML di stato avanzamento), riportati nel “body di servizio” (Cfr. Allegato C per i dettagli). Si evidenzia altresì come ogni messaggio XML scambiato avrà sempre un proprio IDE2E univoco e distinto; in considerazione del fatto che l’IDT è legato all’IDE2E, ogni messaggio avrà un proprio IDT univoco e distinto. In particolare l'Header E2E del messaggio di risposta dovrà essere rigenerato in coerenza con il nuovo Header di Tratta, prevedendo un identificativo diverso, data diversa, soggetto mittente e ricevente invertiti rispetto al messaggio originario.
Titolo:
Nuova Architettura CBI
Codice
PORTING-MO-001 Versione
00.07.09
Tipologia Documento:
Porting degli attuali Servizi CBI nella Nuova Architettura
Data
09-07-2010
Pagina
21/59
Si faccia riferimento all’Allegato C per le specifiche di strutturazione del messaggio di “richiesta di servizio” e del relativo messaggio di “stato d’avanzamento”/“errori rilevati”. Nei seguenti paragrafi vengono descritti, in dettaglio, i controlli da eseguire per l’invio dei 2 messaggi di avanzamento, unitamente alle regole da seguire per la loro composizione. 2.4.1 Controlli e regole di composizione del 1° messaggio di avanzamento Ricevuto il file + messaggio XML dalla Banca Mittente, la Banca Destinataria dovrà eseguire i seguenti controlli: Diagnostica messaggio XML (parsing)2 Verifica coerenza messaggio/file:
- verifica congruenza e omogeneità dei supporti logici in base a quanto dichiarato nel messaggio XML: o coerenza tag “Nome servizio” (cfr. Header di Tratta e Header di Servizio – es. “PORTING-
PC”) e tag “Tipologia flusso” (es. “PC”); in questo caso l’errore riguarda una incoerenza all’interno del messaggio XML e verrà segnalato attraverso il messaggio d’errore “general purpose” (cfr. Par. 4.4.4);
o coerenza dei tag “Nome servizio”, “Tipologia flusso” (presenti nel messaggio XML) e dei campi “tipo record” riportati nel record di testa di tutti i supporti logici contenuti nel file
- verifica di coerenza tra i supporti logici referenziati nel messaggio XML e quelli contenuti nel file, mediante confronto tra campi secondo quanto riportato nella seguente tabella:
Flussi da Banca Proponente a Banca Passiva
Messaggio XML Record di testa del supporto logico <SIACd> mittente (pos. 4-8) <ABICd> ricevente (pos. 9-13) <CreDt> data creazione (pos. 14-19) <SppNm> nome supporto (pos. 20-39)
Flussi da Banca Passiva a Banca Proponente Messaggio XML Record di testa del supporto logico <SIACd> ricevente (pos. 9-13) <ABICd> mittente (pos. 4-8) <CreDt> data creazione (pos. 14-19) <SppNm> nome supporto (pos. 20-39)
Per i soli flussi dispositivi, verifica coerenza tra Codice ABI della Banca (Banca Passiva) contenuto in ogni blocco “Info supporto” del messaggio XML e CUC della Banca Destinataria (Banca Passiva) riportato nell’Header di Servizio3. Si fa notare come tale controllo garantisca l’omogeneità dei supporti logici relativamente al destinatario “logico” cui gli stessi sono indirizzati (Banca Passiva)
Verifica omogeneità dei supporti logici per “soggetto di riferimento” del destinatario logico (STD/GPA) Verifica omogeneità dei supporti logici relativamente all’utilizzo della firma digitale e alla tipologia di
firma utilizzata (valore del tag <SngTyp>). (cfr. paragrafo 7.2)
2 Ad eccezione di casi particolari di errore (segnalati attraverso il primo messaggio di stato avanzamento), a fronte del riscontro di errori di parsing nel messaggio XML, viene inviato un messaggio di errore “general purpose” descritto nel documento “Nuovi Standard Tecnici – Parte generale”. In caso di errori non previsti dal workflow del servizio (es. errori di accesso al messaggio XML, etc.), l’errore dovrà essere comunque segnalato utilizzando il messaggio “general purpose” descritto nel documento “Nuovi Standard Tecnici – Parte generale”. 3 Tale controllo non è previsto nel caso di ricezione di flussi informativi nell’ambito della tratta Banca Passiva – Cliente.
Titolo:
Nuova Architettura CBI
Codice
PORTING-MO-001 Versione
00.07.09
Tipologia Documento:
Porting degli attuali Servizi CBI nella Nuova Architettura
Data
09-07-2010
Pagina
22/59
Per i soli flussi firmati digitalmente, controllo del mittente fisico per accertarsi che lo stesso risulti abilitato dal CBI all’immissione in rete di supporti logici firmati con la specifica tipologia di firma (cfr. paragrafo 7.1)
Nel caso di esito positivo dei suddetti controlli (ossia supporti logici referenziati dal messaggio XML in corrispondenza 1:1 con quelli presenti nel file, il quale termina dopo l’ultimo supporto logico referenziato nel messaggio XML), le regole di composizione del messaggio 17 prevedono l’invio verso la Banca Mittente di un messaggio contenente solo il blocco di informazioni “Info file” con stato “Ricevuto” (Cfr. Appendice C per i dettagli). In caso di esito negativo di tali verifiche, il file viene scartato e il workflow della Banca Destinataria si chiude con l’invio del messaggio 17 costruito come segue: In caso di errori rilevati sul file:
- blocco “Info file” presente, con stato “Errori rilevati” (+ codice d’errore specifico); - blocco “Info supporto” assente
In caso di errori rilevati sul supporto logico: - blocco “Info file” presente, con stato “Errori rilevati” (+ codice d’errore specifico); - blocco “Info supporto” presente, con stato “Errori rilevati” (+ codice d’errore specifico)
Relativamente alle regole di costruzione del messaggio 17, si evidenzia che: In caso di disallineamento tra messaggio XML e file, si fa riferimento a quanto riportato nel messaggio
XML per la rilevazione e la segnalazione degli errori In caso di errore sul singolo supporto logico, dovrà essere segnalato solo il 1° errore rilevato (una sola
occorrenza del blocco “SendSts” nel messaggio 17) Il sequence diagram che segue mette in evidenza i possibili stati d’avanzamento del file e dei supporti logici inclusi nel messaggio 17 di risposta.
Banca DestinatariaBanca Mittente Directory
13: Ricezione messaggio+file
12: Invio file+messaggio
XML FileXML File
16: Predisposizione messaggio di avanzamento / di errore
XML
11: Ricezione indirizzo Banca Destinataria
17: Invio messaggio stato avanzamento (OK) / errori rilevati (KO)
14: Diagnostica messaggio XML (vedi 6)15: Verifica omogeneitàfile e coerenza file-messaggio (vedi 3 e 5)
1°
me
ss
agg
io
Stato avanzamento file
Ricevuto Errori rilevati
- Errore diagnostica msg XML- File non trovato- File inutilizzabile- Limite massimo supporti logici superato- Supporti non omogenei, non corrisp. o
inutilizzabili
Stato avanzamento supporti logici
Errori rilevati- Supporto non omogeneo per “tipologia
flusso”- Supporto non omogeneo per “destinatario”- Supporto non omogeneo per “applicazione
firma digitale”- Supporto non presente nel file- Supporto non presente nel msg XML- Supporto logico inutilizzabile- ABI e CUC Banca Passiva non coerenti
Se disponibili le informazioni sui supporti logici
La tabella riportata di seguito mostra, per ogni stato d’avanzamento relativo al file, i possibili stati di avanzamento inerenti i supporti logici.
Titolo:
Nuova Architettura CBI
Codice
PORTING-MO-001 Versione
00.07.09
Tipologia Documento:
Porting degli attuali Servizi CBI nella Nuova Architettura
Data
09-07-2010
Pagina
23/59
Stato avanzamento file Stato avanzamento singoli supporti logici (Cfr. blocco “Info supporto”)
Ricevuto BLOCCO DI INFORMAZIONE ASSENTE Errori rilevati
- Errore diagnostica msg XML - File non trovato - File inutilizzabile - Limite massimo supporti logici
superato
BLOCCO DI INFORMAZIONE ASSENTE
Errori rilevati - Supporti non omogenei, non
corrispondenti o inutilizzabili
Errori rilevati - Supporto non omogeneo per “tipologia
flusso” - Supporto non omogeneo per “destinatario” - Supporto non omogeneo per “applicazione
firma digitale” - Supporto non presente nel file - Supporto non presente nel msg XML - Supporto logico inutilizzabile - ABI e CUC Banca Passiva non coerenti
Come specificato, in caso di disallineamento tra messaggio XML e file, si deve fare riferimento al messaggio XML. In caso di errore sul controllo di corrispondenza si possono verificare 2 casi: se il supporto logico è presente nel messaggio XML ma non è presente nel file, nel blocco "Info supporto"
del messaggio 17 si indica il "nome supporto" riportato nell'XML, specificando il codice d'errore "Supporto non presente nel file"
se il supporto logico è presente nel file ma non è presente nel messaggio XML, nel blocco "Info supporto" del messaggio 17 si indica il "nome supporto" riportato nel file, specificando il codice d'errore "Supporto non presente nel msg XML".
2.4.2 Controlli e regole di composizione del 2° messaggio di avanzamento
In caso di esito positivo di tutti i controlli previsti per il messaggio 17, la Banca Destinataria esegue la diagnostica applicativa dei supporti logici (attuale diagnostica formale e verifica della firma digitale4 se presente) e invia il relativo messaggio di avanzamento (cfr. punto 20 del sequence diagram), costruito come segue: Blocco “Info file” presente, con stato “Ricevuto” Una occorrenza del blocco “Info supporto” per ogni supporto logico rilevato nel file, con stato
“Diagnostica supporto logico OK”/”Errori rilevati (+ dettagli errore) Per i soli flussi informativi non indirizzati verso Market Place5, in aggiunta alla diagnostica applicativa e ai fini della generazione del 2° messaggio di avanzamento, la Banca Destinataria deve, per ogni supporto logico, effettuare il controllo di congruenza tra la Banca Proponente (ricavata dal codice SIA destinatario) e il destinatario logico (Banca Proponente) dichiarato nell’apposito campo presente nell’Header di Servizio del messaggio XML. I soli supporti per i quali tale controllo restituisce esito negativo devono essere scartati utilizzando l’apposito codice di errore 058 (Banca Proponente non coerente con anagrafica clienti) .
4 Si rimanda al paragrafo 7 per dettagli sulle modalità di composizione del 2° messaggio di stato avanzamento in caso di errore nella verifica della firma 5 Si rammenta che i flussi indirizzati verso Market Place sono riconoscibili da specifici valori presenti in appositi campi contenuti nel record di testa dei supporti logici
Titolo:
Nuova Architettura CBI
Codice
PORTING-MO-001 Versione
00.07.09
Tipologia Documento:
Porting degli attuali Servizi CBI nella Nuova Architettura
Data
09-07-2010
Pagina
24/59
I soli supporti per i quali il codice SIA destinatario non risulti censito nell’anagrafica di riferimento (nodo cliente assente sul Directory) devono essere scartati utilizzando l’apposito codice di errore 042 (soggetto non aderente)6. In caso di errori rilevati, dovranno essere segnalati da 1 a 3 errori (+ dettagli errore) per ciascun supporto logico. Il sequence diagram che segue mette in evidenza i possibili stati d’avanzamento del file e dei supporti logici inclusi nel messaggio 20 di risposta.
Banca DestinatariaBanca Mittente Directory
18: Diagnostica applicativa supporti logici (diagnostica attuale formale)20: Invio messaggio stato
avanzamento(OK)/ errori rilevati(KO)19: Predisposizione stato avanzamento/ errori rilevati
Ricevuto Diagnostica supporto logico ok Errori rilevati
- Errori su supporto logico (+ Dettagli errore)2°m
essa
gg
io
Per quanto riguarda invece il messaggio sullo stato d’avanzamento al punto 20 del sequence diagram, lo stato di avanzamento file sarà sempre “Ricevuto”, come riportato di seguito.
Stato avanzamento file Stato avanzamento supporti logici
Ricevuto Diagnostica supporto logico ok Errori rilevati
- Errori su supporto logico (+ dettagli errore)
2.5 CONSIDERAZIONI SU INVIO SUPPORTI LOGICI “F4”, “R4” A seguito della ricezione di un flusso F4 o di un flusso R4, la Banca Destinataria (Banca Passiva) dovrà comportarsi come segue:
predisporre ed inviare il messaggio 20 (Cfr. sequence diagram) dopo aver eseguito i controlli attualmente in carico ai Soggetti Veicolatori (messaggio obbligatorio); in funzione del risultato di tali controlli, potrà verificarsi uno dei tre scenari riportati:
1. Nessun errore riscontrato a fronte dei controlli attualmente in carico ai Soggetti Veicolatori e nessun
errore riscontrato dalla Banca Passiva a seguito dei propri controlli applicativi su tutti i campi dei supporti logici:
la Banca Destinataria invia il messaggio 20 dove non si segnala alcun errore; la Banca Destinataria esegue gli attuali controlli “Banca Passiva” e predispone il flusso A4, in
accordo alle attuali regole, senza segnalare alcun errore; la Banca Destinataria invia il flusso A4 attraverso il servizio “PORTING-A4”, inclusi i messaggi
di stato d’avanzamento previsti
6 Per la lista completa dei codici di errore disponibili si faccia riferimento al documento CBI-STD-001
Titolo:
Nuova Architettura CBI
Codice
PORTING-MO-001 Versione
00.07.09
Tipologia Documento:
Porting degli attuali Servizi CBI nella Nuova Architettura
Data
09-07-2010
Pagina
25/59
2. Nessun errore riscontrato a fronte dei controlli attualmente in carico ai Soggetti Veicolatori ed errori
riscontrati dalla Banca Passiva a seguito degli attuali controlli “Banca Passiva”: la Banca Destinataria invia il messaggio 20 dove non si segnala alcun errore; a seguito di errori riscontrati a fronte dei controlli “Banca Passiva” predispone il flusso A4, in
accordo alle attuali regole, con la segnalazione degli errori; la Banca Destinataria invia il flusso A4 attraverso il servizio “PORTING-A4”, inclusi i messaggi
di stato d’avanzamento previsti
3. Riscontro di errori a fronte dei controlli attualmente in carico ai Soggetti Veicolatori:
gli attuali controlli in carico ai Soggetti Veicolatori passano in carico alla Banca Destinataria; la Banca Destinataria invia sempre un messaggio 20 con “esito positivo” e prosegue con le
elaborazioni successive (Cfr. Par. 6.3 documento CBI-F24-001); solo in caso di supporti logici duplicati o incongruenze tra tipo record di testa e tipo record di coda, la Banca Destinataria dovrà generare un messaggio 20 con la segnalazione dell’errore senza proseguire con le elaborazioni successive;
la Banca Destinataria, tranne che in caso di supporti logici duplicati, dovrà sempre generare un flusso “A4”, attraverso il servizio “PORTING-A4”, sia in caso di esito positivo che in presenza di errori.
2.6 CONSIDERAZIONI SU INVIO SUPPORTI LOGICI “Q4”, “A4” A seguito della ricezione di un flusso Q4 o A4, la Banca Destinataria (Banca Proponente) dovrà comportarsi come segue:
predisporre ed inviare il messaggio 20 (Cfr. sequence diagram) dopo aver eseguito i controlli attualmente in carico ai Soggetti Veicolatori (messaggio obbligatorio)7; in funzione del risultato di tali controlli, potrà verificarsi uno dei tre scenari riportati:
1. Nessun errore riscontrato a fronte dei controlli attualmente in carico ai Soggetti Veicolatori e nessun
errore riscontrato dalla Banca Proponente a seguito dei propri controlli applicativi su tutti i campi dei supporti logici:
la Banca Destinataria invia il messaggio 20 dove non si segnala alcun errore
2. Nessun errore riscontrato a fronte dei controlli attualmente in carico ai Soggetti Veicolatori ed errori riscontrati dalla Banca Ricevente a seguito degli attuali controlli “Banca Proponente”:
la Banca Destinataria invia il messaggio 20 dove non si segnala alcun errore; a seguito di errori riscontrati a fronte dei controlli “Banca Proponente” la banca segnala
l’errore attraverso il Tavolo Operativo.
3. Riscontro di errori a fronte dei controlli attualmente in carico ai Soggetti Veicolatori: gli attuali controlli in carico ai Soggetti Veicolatori passano in carico alla Banca Destinataria; la Banca Destinataria invia un messaggio 20 con la segnalazione dell’errore senza proseguire
con le elaborazioni successive.
7 Se il flusso risulta illeggibile, si invia un apposito messaggio di errore “general pur pose”
Titolo:
Nuova Architettura CBI
Codice
PORTING-MO-001 Versione
00.07.09
Tipologia Documento:
Porting degli attuali Servizi CBI nella Nuova Architettura
Data
09-07-2010
Pagina
26/59
2.7 CONSIDERAZIONI SU INVIO SUPPORTI LOGICI “I4” La veicolazione dei flussi “I4” (pagamento di deleghe F24 Internet) sulla Nuova Architettura CBI avviene secondo le stesse regole previste per gli altri servizi “Porting” (cfr. sequence diagram Par. 2.2.1.1). Come illustrato nel sequence diagram di riferimento, il 2° messaggio di stato avanzamento (20) viene predisposto in seguito alla diagnostica applicativa. Tuttavia, a differenza degli altri servizi “Porting”, nel caso dei flussi “I4”, al fine di predisporre il 2° messaggio di stato avanzamento (20), la Banca Destinataria (Passiva) dovrà effettuare unicamente i controlli previsti per il “record di testa”; in caso di esito negativo degli stessi, la Banca Destinataria (Passiva) segnalerà gli errori attraverso il messaggio 20.
Titolo:
Nuova Architettura CBI
Codice
PORTING-MO-001 Versione
00.07.09
Tipologia Documento:
Porting degli attuali Servizi CBI nella Nuova Architettura
Data
09-07-2010
Pagina
27/59
3 Diagnostica Al fine di garantire la correttezza dei flussi (messaggi e file/supporti) veicolati, ciascuna Banca dovrà implementare un processo di diagnostica per la verifica di file e messaggi. La segnalazione di eventuali problemi/errori riscontrati dovrà avvenire attraverso il messaggio XML “Stato di avanzamento” (cfr. Capitolo 2.4), come illustrato dal sequence diagram del servizio. Le segnalazioni di errore non previste dal workflow di servizio dovranno essere effettuate utilizzando il messaggio standard di “segnalazioni errori” descritto nel documento “STPG-MO-001 - Nuovi Servizi Parte Generale”.
3.1 DIAGNOSTICA SUL MESSAGGIO Relativamente ai controlli sul messaggio, la Banca deve effettuare i controlli sulla strutturazione del messaggio XML e quelli sui singoli tag del messaggio stesso secondo i criteri e gli standard già previsti per i nuovi Servizi CBI (Cfr. Allegato STAA-ST-00Y per i dettagli sui controlli da effettuare).
3.2 DIAGNOSTICA SUL FILE I controlli da effettuare riguardano il rispetto delle regole di creazione del file descritte al Par. 2.3.1.2 (es. criteri di omogeneità).
3.3 DIAGNOSTICA SUL SUPPORTO LOGICO I controlli da effettuare sul supporto logico (diagnostica applicativa) sono quelli previsti dagli attuali standard tecnici CBI che prevedono controlli di tipo “V” (validità) e di tipo “F” (formali), per la definizione dei quali si rimanda al documento CBI-STD-001 in vigore alla data.
Titolo:
Nuova Architettura CBI
Codice
PORTING-MO-001 Versione
00.07.09
Tipologia Documento:
Porting degli attuali Servizi CBI nella Nuova Architettura
Data
09-07-2010
Pagina
28/59
4 Regole di governance Al momento della ricezione del file + messaggio XML, deve essere fatto oggetto di controllo: - l’univoca correlazione tra messaggio e file fisico (corretto puntamento tra messaggio e file); - l’omogeneità dei supporti logici all’interno del file fisico8; - la corrispondenza 1:1 tra i supporti logici contenuti nel file e quelli contenuti nel messaggio XML (l’ordine
dei supporti logici riportato nel file deve essere lo stesso di quello riportato nel messaggio XML – Cfr. Par. 2.3.2).
Nel caso in cui vengano segnalati degli errori nella prima fase delle verifiche (diagnostica messaggio XML e coerenza file-messaggio) segnalati con il 1° messaggio di avanzamento (cfr. punto 17 sequence diagram), l’elaborazione sul ricevente si interrompe ed il 2° messaggio di stato di avanzamento non viene generato. In particolare, nel caso in cui il 1° messaggio di avanzamento riporti un errore (AdvSts diverso da RCVD), il file si intende rifiutato dal ricevente e nessuno dei supporti logici in esso contenuto sarà oggetto di ulteriore processing da parte del ricevente stesso; solo nel caso in cui il 1° messaggio di stato di avanzamento riporti un esito di ricezione positiva del file (AdvSts pari a RCVD), il file si intende ricevuto da parte del destinatario, il quale procederà alla esecuzione del diagnostico attuale sui supporti logici contenuti. Durante l'esecuzione della diagnostica applicativa il 2° messaggio di avanzamento riporterà sempre il medesimo stato di ricevuto per il file (AdvSts pari a RCVD); relativamente ai supporti logici, quelli rifiutati (AdvSts pari a ERRR con la codifica del codice dell’errore rilevato) non subiranno alcun ulteriore processing da parte del ricevente mentre i supporti logici accettati (AdvSts pari a RCVD) verranno sottoposti all'esecuzione dell'opportuno processo elaborativo.
4.1 MANCATO RISPETTO DELLE TEMPISTICHE DI INVIO DEI MESSAGGI DI AVANZAMENTO Relativamente alle tempistiche di invio dei messaggi di avanzamento (Cfr. Capitolo 6 per i dettagli sugli SLA), si assume che: - la ricezione di ACK19 rappresenta per il mittente una garanzia sulla consegna da parte della Rete - l’orologio di riferimento per la misura degli SLA è rappresentato dalla giornata applicativa In particolare, nel caso in cui non si riceva uno dei messaggi di avanzamento previsti (cfr. punto 17/20 del sequence diagram) all'interno degli SLA definiti per il servizio, il Mittente deve intraprendere le seguenti azioni:
segnalazione al Performance Management invio notifica al Tavolo Operativo che dovrà attivare le segnalazioni necessarie (es. una per ogni
Destinatario, al termine della giornata applicativa, comprendente la descrizione delle anomalie) la richiesta di servizio sarà considerata inoltrata e ad esecuzione ritardata. A riguardo viene
effettuata un'ulteriore segnalazione al Performance Management il mittente dovrà essere in grado di gestire eventuali messaggi inviati in ritardo per almeno 5 giorni
lavorativi; oltre tale limite il workflow di servizio potrà essere considerato chiuso e il mittente non sarà obbligato a gestire ulteriori messaggi ricevuti
non sarà necessario il rinvio dei flussi per la risoluzione dei problemi, il mittente potrà attivarsi con SIA in caso di mancata ricezione di
ACK210, e con la Banca in caso di ricezione di ACK2.
8 Cfr. paragrafo 2.3.2. 9 Conferma di presa in carico del messaggio XML + file, inviata alla Banca Mittente dal proprio nodo (Cfr. documentazione SIA per i dettagli) 10 Notifica di recapito di messaggio XML + file, inviata dal nodo della Banca Destinataria alla Banca Mittente (Cfr. documentazione SIA per i dettagli)
Titolo:
Nuova Architettura CBI
Codice
PORTING-MO-001 Versione
00.07.09
Tipologia Documento:
Porting degli attuali Servizi CBI nella Nuova Architettura
Data
09-07-2010
Pagina
29/59
4.2 MANCATO RISPETTO DELLA SEQUENZA DI INVIO DEI MESSAGGI DI AVANZAMENTO Nel caso di mancato rispetto, da parte della Banca Destinataria, della sequenza d’invio dei messaggi di avanzamento (cfr. punti 17 e 20 sequence diagram), la Banca Mittente dovrà:
chiudere il workflow applicativo in base alle informazioni contenute nel messaggio 20 ignorare il messaggio 17 ricevuto fuori sequenza (o in ritardo, anche se all’interno degli SLA) segnalare il mancato rispetto della sequenza di invio o la mancata ricezione del messaggio 17 al
Performance Management
4.3 CASI SPECIFICI DI ERRORE 4.3.1 File non trovato Nel caso in cui la Banca Destinataria non riesca a recuperare il file referenziato dal messaggio, dovrà:
Inviare una segnalazione alla Banca Mittente utilizzando il messaggio di avanzamento previsto (Cfr. Punto 17 del sequence diagram)
Eseguire una segnalazione al Performance Management
In caso di evidenza di errori derivanti dall’utilizzo del sincronizzatore, la Banca Destinataria dovrà inoltre provvedere a contattare la SIA per definire le modalità di risoluzione del problema. 4.3.2 Non omogeneità dei supporti logici Nel caso in cui la Banca Destinataria rilevi supporti logici non omogenei, la richiesta di Servizio deve essere considerata come non completa. La Banca Destinataria dovrà inviare un messaggio di stato d’avanzamento (cfr. punto 17 sequence diagram) riportante l’errore “Supporti non omogenei”. Oltre a ciò, obbligatorio, il Tavolo Operativo della Banca Destinataria potrà mettersi in comunicazione – tramite canali alternativi – con il Tavolo Operativo della Banca Mittente per la gestione dell’evento. A fronte del messaggio riportante l’errore, la Banca Mittente dovrà inviare nuovamente la richiesta di servizio. 4.3.3 Supporti logici non referenziati Nel caso in cui si rilevino incongruenze tra le referenze all’interno del messaggio ed i supporti logici contenuti nel file fisico (o viceversa), la richiesta di Servizio deve essere considerata dalla Banca Destinataria come non completa. In accordo alle regole di composizione del messaggio di avanzamento 17 (cfr. Par. 2.4.1), la Banca Destinataria dovrà inviare un messaggio di stato d’avanzamento (cfr. punto 17 sequence diagram) riportante l’errore/i: - “Supporto logico non presente nel file” unitamente all’indicazione del supporto logico referenziato
all’interno del messaggio, ma non presente nel file fisico; - “Supporto logico non presente nel messaggio XML” unitamente all’indicazione del supporto logico
presente nel file fisico, ma non referenziato all’interno del messaggio XML.
Titolo:
Nuova Architettura CBI
Codice
PORTING-MO-001 Versione
00.07.09
Tipologia Documento:
Porting degli attuali Servizi CBI nella Nuova Architettura
Data
09-07-2010
Pagina
30/59
Oltre a questa modalità, obbligatoria, il Tavolo Operativo del Destinatario potrà mettersi in comunicazione – tramite canali alternativi – con il Tavolo Operativo del Mittente per la gestione dell’evento. A fronte del messaggio riportante l’errore, la Banca Mittente dovrà inviare nuovamente la richiesta di servizio. 4.3.4 Errori di diagnostica applicativa su alcuni supporti logici Nel caso in cui si rilevino errori su alcuni supporti logici contenuti nel file fisico durante la fase di diagnostica applicativa dei supporti logici (cfr. punto 18 sequence diagram), la richiesta di Servizio verrà comunque processata dalla Banca Destinataria. In particolare, la Banca Destinataria proseguirà l’elaborazione per i supporti logici corretti, segnalando quelli diagnosticati correttamente e quelli su cui sono stati rilevati errori (+ dettagli sull’errore – Cfr. struttura messaggio d’avanzamento).
4.4 CASI GENERALI DI ERRORE 4.4.1 Non univocità della correlazione file-messaggio Nel caso di correlazione file-messaggio non univoca (es. duplicazione IUF), la richiesta di Servizio deve essere considerata dalla Banca Destinataria come non completa. La Banca Destinataria dovrà inviare un messaggio d’errore “general purpose” prevedendo un codice d’errore specifico “Correlazione file-messaggio non univoca”. Oltre a ciò, obbligatorio, il Tavolo Operativo della Banca Destinataria potrà mettersi in comunicazione – tramite canali alternativi – con il Tavolo Operativo della Banca Mittente per la gestione dell’evento. A fronte del messaggio riportante l’errore, la Banca Mittente dovrà inviare nuovamente la richiesta di servizio. 4.4.2 Messaggio ricevuto illeggibile Nel caso in cui il messaggio ricevuto risultasse illeggibile, la Banca Destinataria dovrà generare un messaggio d’errore “general purpose” (Cfr. Doc. “STPG-MO-001 Nuovi Servizi Parte Generale” per la descrizione della struttura del messaggio) prevedendo un codice d’errore specifico e inserendo le informazioni ricavabili dalla Rete Logica: - mittente fisico - destinatario fisico - UDR (User Data Remote) 4.4.3 Supporti logici duplicati Nel caso in cui la Banca Destinataria rilevi un supporto logico duplicato (secondo la chiave di univocità costituita dai campi: nome supporto, tipo supporto, data creazione, mittente e destinatario), dovrà trattare il primo e scartare il secondo, indipendentemente dal fatto siano contenuti in file fisici differenti.
Titolo:
Nuova Architettura CBI
Codice
PORTING-MO-001 Versione
00.07.09
Tipologia Documento:
Porting degli attuali Servizi CBI nella Nuova Architettura
Data
09-07-2010
Pagina
31/59
4.4.4 Incoerenza “Nome servizio” e “Tipologia flusso” nel messaggio XML Nel caso di incoerenza tra tag “Nome servizio” (cfr. Header di Tratta e Header di Servizio – es. “PORTING-PC”) e tag “Tipologia flusso” (es. “PC”) all’interno del “Body di Servizio”, la Banca Destinataria dovrà generare un messaggio d’errore “general purpose” prevedendo un codice d’errore specifico “Incoerenza tra le informazioni presenti nel messaggio XML”. A fronte del messaggio riportante l’errore, la Banca Mittente dovrà inviare nuovamente la richiesta di servizio. 4.4.5 Mancata corrispondenza nel 1° messaggio di avanzamento Nel caso in cui le informazioni riportate nel messaggio 17 (cfr. sequence diagram) non corrispondano con quelle indicati nel messaggio di richiesta (es. campo “Nome file” errato, “Tipologia flusso” non corrispondente - cfr. punto 12 sequence diagram), la Banca Mittente (cfr. par. 2.2.1 – “Attori identificati”) dovrà:
scartare il messaggio 17 inviato dalla Banca Destinataria inviare una segnalazione specifica al Tavolo Operativo attendere il messaggio 17 corretto (nel caso in cui il messaggio 17 corretto non venga inviato, ma
venga inviato il messaggio 20 corretto, il workflow viene comunque chiuso in base alle informazioni contenute nel messaggio 20 – cfr. Par. 4.2).
4.4.6 Mancata corrispondenza nel 2° messaggio di avanzamento Nel caso in cui i supporti logici referenziati nel messaggio 20 (cfr. sequence diagram) non siano in corrispondenza 1:1 con quelli indicati nel messaggio di richiesta (cfr. punto 12 sequence diagram), la Banca Mittente (cfr. par. 2.2.1 – “Attori identificati”) dovrà:
scartare il messaggio 20 inviato dalla Banca Destinataria inviare una segnalazione specifica al Tavolo Operativo attendere il messaggio 20 corretto per la chiusura del workflow applicativo (nel caso in cui il
messaggio 20 corretto non venga inviato, il workflow viene comunque chiuso dopo 5 giorni lavorativi)
Si precisa che nel messaggio 20 i supporti logici referenziati possono essere inseriti in un ordine differente rispetto a quello seguito nella richiesta di servizio corrispondente.
4.5 RECUPERO DEI FLUSSI IN CASO DI ERRORE 4.5.1 Errore imputabile al soggetto ricevente Nel caso in cui il Soggetto destinatario di una richiesta di servizio, a fronte della ricezione di un flusso corretto, lo considera errato a causa di un proprio errore applicativo, possono aversi tre scenari nei quali il ricevente:
1. chiude il workflow tramite l'invio di un messaggio di errore “general purpose” 2. risponde con un primo messaggio di stato avanzamento (msg 17) KO 3. risponde con un secondo messaggio di stato avanzamento (msg 20) KO per un errore di anagrafica
o diagnostica I tre diversi scenari sono accomunati dal fatto che il ricevente ha in ogni caso a disposizione il flusso corretto e può pertanto procedere al suo recupero.
Titolo:
Nuova Architettura CBI
Codice
PORTING-MO-001 Versione
00.07.09
Tipologia Documento:
Porting degli attuali Servizi CBI nella Nuova Architettura
Data
09-07-2010
Pagina
32/59
In questi casi il recupero dei supporti logici rimane in carico, salvo diverso accordo tra le parti, al ricevente, ovvero all'attore che ha commesso l'errore. Il recupero deve comunque essere frutto di una azione congiunta tra le parti secondo le modalità operative di seguito illustrate in dipendenza del soggetto che per primo rileva l'errore. Nel caso in cui l’anomalia venga inizialmente rilevata dal ricevente, lo stesso è tenuto ad informare la controparte, tramite l'invio di una mail al Tavolo Operativo ed in tempi compatibili con i livelli di servizio associati all'erogazione del servizio oggetto di errore. In ogni caso il processo di gestione (recupero/rispedizione/blocco definitivo del flusso) dei dati deve essere preliminarmente concordato con il mittente. Qualora il ricevente, in accordo con la controparte, proceda al recupero del flusso, deve informare il mittente (mediante apposita mail inviata al Tavolo Operativo) circa i tempi necessari per modificare le proprie applicazioni e sanare l'anomalia. Se, di contro, è il mittente che per primo rileva l’errore, lo stesso deve informare via mail la controparte dell'errore riscontrato e, salvo contestazioni, può considerare che il destinatario provvederà con celerità al recupero dei dati e alla modifica delle applicazioni. La gestione del recupero dei flussi nella tratta tra Banca e Cliente, non rientrando nella sfera di competenza di ACBI, non può essere normata in sede associativa. 4.5.2 Errore imputabile al soggetto mittente In caso in cui un workflow si chiuda con un errore imputabile al mittente, è quest’ultimo che deve procedere al reinvio della richiesta di servizio tramite l’inoltro di una nuova richiesta che comporta obbligatoriamante: - la sistemazione delle cause di scarto - la generazione di nuovi identificativi univoci per la richiesta di servizio. Si precisa che il Mittente non è obbligato, nella rispedizione dei supporti logici corretti, a generare nuovi identificativi univoci per i supporti logici11. 4.5.3 Gestione delle contestazioni Nel caso in cui a seguito dell'interazione tra mittente e destinatario non si pervenga alla definizione delle responsabilità, le controparti devono attivare un processo di innalzamento della contesa che porti al coinvolgimento di ACBI. La Segreteria Tecnica, previa analisi dell’errore riscontrato, si farà carico della definizione delle responsabilità decidendo se l’errore sia imputabile al mittente o al ricevente. Il responsabile sarà quindi tenuto ad attivare il processo di recupero previsto.
11 Il controllo di univocità degli identificativi dei supporti logici è effettuato dal Ricevente solo a valle della generazione del 2° messaggio di avanzamento (20), riportante esito positivo della diagnostica. Pertanto, un supporto logico può essere scartato per “duplicato” solo a seguito della generazione del 2° messaggio di avanzamento (20), riportante esito positivo della diagnostica
Titolo:
Nuova Architettura CBI
Codice
PORTING-MO-001 Versione
00.07.09
Tipologia Documento:
Porting degli attuali Servizi CBI nella Nuova Architettura
Data
09-07-2010
Pagina
33/59
5 Individuazione indirizzo di erogazione del Servizio Porting Le modalità di indirizzamento dei messaggi/file sulla Nuova Architettura sono descritte nel documento “DIRECTORY-MO-001 Requisiti Directory”. Con riferimento alla struttura del Directory, si evidenzia come, esclusivamente per l’indirizzamento dei flussi Porting, gli attributi “Operatività CBI” e “Gestione eccezioni” del nodo Cliente non debbano essere controllati. Nel seguito del paragrafo vengono tuttavia riportate considerazioni specifiche relative alle modalità/regole di indirizzamento per la veicolazione degli attuali tracciati sulla Nuova Architettura (“Porting”). A riguardo, ciascuna Banca dovrà esporre nel Directory i servizi “porting” nello spazio dei nomi registrati da ACBI in appositi nodi di quarto livello, come di seguito indicato: Per i servizi esposti nel ruolo di Banca Passiva
i nodi relativi ai servizi esposti sono riportati sotto il nodo di terzo livello “ou=servizi non profilati”; i nomi dei Servizi da utilizzare (Cfr. blocco “Info sul servizio” dell’Header E2E) sono definiti in base
alla tipologia di supporto logico veicolato, come indicato nella tabella seguente:
Nome Servizio “cn=..” Descrizione PORTING-IR R.I.D. PORTING-IM M.AV PORTING-IB Ri.Ba PORTING-AL Allineamento Elettronico Archivi R.I.D. PORTING-PC Pagamento Italia PORTING-PE Bonifico Estero PORTING-AP Pagamento Effetti PORTING-AI Avviso Impagati PORTING-AB Pagamento Bollettino Bancario
PORTING-SL-D Struttura Libera da Utente (Dispositiva) PORTING-F4 Pagamento Deleghe F24 PORTING-I4 Pagamento Deleghe F24 Internet PORTING-R4 Revoca Deleghe F24
Per i servizi esposti nel ruolo di Banca Proponente
i nodi relativi ai servizi esposti sono riportati sotto i nodi di terzo livello relativi ai "servizi profilati", con i nomi dei profili definiti ed associati ai singoli nodi Azienda;
i nomi dei Servizi da utilizzare (Cfr. blocco “Info sul servizio” dell’Header E2E) sono definiti in base alla tipologia di supporto logico veicolato, come indicato nella tabella seguente:
Nome Servizio “cn=..” Descrizione PORTING-EIR Esito R.I.D. PORTING-EIM Esito M.AV PORTING-EIB Esito Ri.Ba PORTING-EAL Esito Allineamento Elettronico Archivi R.I.D. PORTING-BB Bollettino Bancario PORTING-EP Esito di pagamento PORTING-AV Avvisatura Effetti
Titolo:
Nuova Architettura CBI
Codice
PORTING-MO-001 Versione
00.07.09
Tipologia Documento:
Porting degli attuali Servizi CBI nella Nuova Architettura
Data
09-07-2010
Pagina
34/59
PORTING-RH Rendicontazione saldi e movimenti di c/c PORTING-RA Rendicontazione conti anticipi PORTING-EC Estratto conto periodico PORTING-DT Dossier Titoli PORTING-RP Rendicontazione di Portafoglio
PORTING-SL-I Struttura Libera da Banca (Informativa) PORTING-A4 Accettazione/Rifiuti Deleghe F24 PORTING-Q4 Quietanza Deleghe F24
Si evidenzia come, nel caso di flussi in cui sia presente il “qualificatore Marketplace”, l’indirizzamento si differenzia a seconda che le disposizioni originarie siano di pagamento o di incasso. In particolare:
esito disposizioni di pagamento (es. “PORTING-EP”): la Banca Passiva invia l’esito verso la Banca Gateway e l’indirizzo di Rete Logica a cui inviare l’esito viene trovato consultando il Directory nel ramo dei servizi della Banca Gateway, sotto il profilo specifico identificato dal Codice del Marketplace e presente nell’apposito campo contenuto nei supporti logici con le disposizioni di pagamento originarie. Tale codice è altresì presente all’interno dei supporti logici di esito (record 10, pos. 109-113). Ogni Banca Gateway ha infatti l’obbligo di esporre sul Directory uno specifico profilo per ogni marketplace servito, indicando nel nome del profilo il codice assegnato al marketplace stesso. La stringa identificativa del profilo servizio è fatta nel seguente modo: PROFILO MARKETPLACE XXXXX dove XXXXX rappresenta il codice assegnato al MP12 (cfr doc DIRECTORY-PO-001).
esito disposizioni di incasso (es. “PORTING-EIR”): la Banca Passiva invia l’esito verso la
Banca Proponente e l’indirizzamento del flusso di esito viene risolto consultando il Directory nel ramo dei servizi della Banca Proponente.
Si evidenzia come le modalità di indirizzamento sopra descritte si riferiscano soltanto agli “esiti” delle richieste provenienti da Marketplace; per l’indirizzamento dei messaggi di stato avanzamento si utilizza il campo “Return Address” indicato nell’Header di Tratta (cfr. Par. 4.1.1 documento “STPG-MO-001 - Nuovi Servizi Parte Generale”).
6 Livelli di servizio La veicolazione dei flussi dispositivi è soggetta ad un termine massimo generale di 30 minuti primi, avendo a riferimento la tratta Banca Mittente (“Banca Proponente”) – Banca Destinataria (“Banca Passiva”). Tale termine (attuativo del comma 10.2.5 delle Norme del Servizio) è calcolato avendo a riferimento i due momenti temporali di cui ai commi 10.2.6 e 10.2.7 delle Norme del Servizio. Si precisa al riguardo quanto segue:
1) Si definisce “ricezione” ai sensi del comma 10.2.6 l’istante in cui si verificano entrambe le condizioni seguenti: - il flusso inviato dal cliente è a completa disposizione della Banca Proponente; - il cliente ha autorizzato l’inoltro del flusso verso la Banca Passiva. Si osserva che la Banca Proponente è tenuta a comunicare l’istante di effettiva disponibilità dei flussi autorizzati all’invio, prima che sugli stessi vengano effettuate eventuali elaborazioni.
2) La “messa a disposizione” della Banca Passiva di cui al comma 10.2.7 prescinde dall’utilizzo della Rete CBI per la veicolazione dei flussi tra le due banche Mittente e Destinataria, per cui la previsione generale di tale comma è valida anche nel caso di flussi destinati ad una Banca Passiva attestata sul
12 Si precisa che non è consentito definire codici marketplace contenenti uno o più caratteri pari a “blank”.
ATTENZIONE: quanto evidenziato in giallo in questo paragrafo entra in vigore il 1° novembre 2010 (cfr. tabella delle revisioni)
Titolo:
Nuova Architettura CBI
Codice
PORTING-MO-001 Versione
00.07.09
Tipologia Documento:
Porting degli attuali Servizi CBI nella Nuova Architettura
Data
09-07-2010
Pagina
35/59
medesimo soggetto tecnico di cui si avvale la Banca Proponente e nel caso di coincidenza tra Banca Proponente e Banca Passiva.
3) Il termine temporale massimo è altresì calcolato avendo a riguardo l’effettiva disponibilità del Servizio, ovvero al netto degli orari ufficiali di chiusura e/o di eventi eccezionali e/o cause di forza maggiore.
La giornata applicativa per il servizio Porting rappresenta l’orologio di riferimento per la misura degli SLA: la trasmissione e la ricezione dei flussi va dal Lunedì al Sabato dalle ore 01:00 alle ore 23:00, eccetto festività nazionali previste. I livelli di servizio per il Servizio Porting sono stati definiti partendo dalla individuazione dei punti di rilevazione delimitanti l’inizio e/o fine di un intervallo temporale soggetto a controllo. Si precisa come tali punti di rilevazione coincidano solo con un sottoinsieme di quanto richiesto alle Banche, in termini di logging, a supporto del performance management e della governance. La figura seguente - a partire dalla sequenza di attività in carico alla Banca Destinataria ed esposta al Capitolo 2.3 del presente documento - evidenzia i punti di rilevazione identificati.
1: Ricezione messaggio+file
1: Ricezione messaggio+file
2: Diagnostica messaggio XML
2: Diagnostica messaggio XML
3: Verifica omogeneità file e coerenza file-messaggio
Errori rilevati4: Invio messaggio di errore4: Invio messaggio di erroreSI
NO
6: Diagnostica supporti logici (diagnostica attuale formale)
6: Diagnostica supporti logici (diagnostica attuale formale)
7: Predisposizione stato avanzamento/ errori
rilevati
7: Predisposizione stato avanzamento/ errori
rilevati
8: Invio messaggio stato avanzamento/
errori rilevati
8: Invio messaggio stato avanzamento/
errori rilevati
5: Invio messaggio stato avanzamento5: Invio messaggio stato avanzamento
1
2
3
Figura 7 – Punti di rilevazione – Banca Destinataria
In maggior dettaglio, i punti di rilevazione sono così definiti:
1) Completamento, con esito positivo, della chiamata “receive” alla Rete Logica per la ricezione di un file+messaggio;
Titolo:
Nuova Architettura CBI
Codice
PORTING-MO-001 Versione
00.07.09
Tipologia Documento:
Porting degli attuali Servizi CBI nella Nuova Architettura
Data
09-07-2010
Pagina
36/59
2) Presa in carico, con esito positivo, da parte della Rete Logica della chiamata “send” per l’invio di un messaggio;
3) Presa in carico, con esito positivo, da parte della Rete Logica della chiamata “send” per l’invio di un messaggio.
Le figura seguente mostra - a partire dalla sequenza di attività in carico alla Banca Destinataria ed esposta al Capitolo 2.3 del presente documento - gli intervalli significativi per le rilevazioni temporali e la denominazione ad essi associata.
1: Ricezione messaggio+file
1: Ricezione messaggio+file
2: Diagnostica messaggio XML
2: Diagnostica messaggio XML
3: Verifica omogeneità file e coerenza file-messaggio
Errori rilevati4: Invio messaggio di errore4: Invio messaggio di erroreSI
NO
6: Diagnostica supporti logici (diagnostica attuale formale)
6: Diagnostica supporti logici (diagnostica attuale formale)
7: Predisposizione stato avanzamento/ errori
rilevati
7: Predisposizione stato avanzamento/ errori
rilevati
8: Invio messaggio stato avanzamento/
errori rilevati
8: Invio messaggio stato avanzamento/
errori rilevati
5: Invio messaggio stato avanzamento5: Invio messaggio stato avanzamento
ΔT1 ΔT2
Figura 8 – Intervalli temporali soggetti a SLA – Banca Destinataria Per ciò che riguarda i flussi di carattere dispositivo inviati alla Banca Destinataria si è fissato il seguente intervallo massimo:
- T2 = entro 1 ora. Similmente, per quanto riguarda i flussi informativi, si sono definiti i seguenti intervalli temporali massimi:
- T1 = entro 1 ora; - T2 = entro 2 ore.
Gli intervalli sopra definiti hanno validità fino alla fine del Periodo di Transizione13, in seguito potranno essere ricalibrati subendo riduzioni.
13 Cfr. Circolare CBI 4/2005 del 16 giugno 2005.
Titolo:
Nuova Architettura CBI
Codice
PORTING-MO-001 Versione
00.07.09
Tipologia Documento:
Porting degli attuali Servizi CBI nella Nuova Architettura
Data
09-07-2010
Pagina
37/59
La figura seguente - a partire dalla sequenza di attività in carico alla Banca Mittente ed esposta al Capitolo 2.3 del presente documento - evidenzia i punti di rilevazione identificati.
1: Ricezione messaggio+file
1: Ricezione messaggio+file
2: Diagnostica messaggio XML
2: Diagnostica messaggio XML
3: Verifica omogeneità file e coerenza file-messaggio
Errori rilevati4: Invio messaggio di errore4: Invio messaggio di erroreSI
NO
6: Diagnostica supporti logici (diagnostica attuale formale)
6: Diagnostica supporti logici (diagnostica attuale formale)
7: Predisposizione stato avanzamento/ errori
rilevati
7: Predisposizione stato avanzamento/ errori
rilevati
8: Invio messaggio stato avanzamento/
errori rilevati
8: Invio messaggio stato avanzamento/
errori rilevati
5: Invio messaggio stato avanzamento5: Invio messaggio stato avanzamento
4
5
6
Figura 9 – Punti di rilevazione – Banca Mittente In maggior dettaglio, i punti di rilevazione sono così definiti:
4) Ricezione della “notify” di Rete Logica a seguito di richiesta di “send”, con esito positivo, di file+messaggio;
5) Completamento, con esito positivo, della “receive” di Rete Logica per la ricezione di un messaggio;
6) Completamento, con esito positivo, della “receive” di Rete Logica per la ricezione di un messaggio.
La figura seguente mostra - a partire dalla sequenza di attività in carico alla Banca Mittente ed esposta al Capitolo 2.3 del presente documento - gli intervalli significativi per le rilevazioni temporali e la denominazione ad essi associata.
Titolo:
Nuova Architettura CBI
Codice
PORTING-MO-001 Versione
00.07.09
Tipologia Documento:
Porting degli attuali Servizi CBI nella Nuova Architettura
Data
09-07-2010
Pagina
38/59
3a.Predisposizione e diagnostica file
1.Predisposizione supporti logici
1.Predisposizione supporti logici
2.Diagnostica supporti logici (attuale diagnostica formale)
3b.Costruzione del messaggio XML (contiene i riferimenti applicativi al file)
5.Spedizione file+messaggio
6.Ricezione dalla rete di ok di trasmissione file+messaggio
3c.Diagnostica messaggio XML
7.Attesa risposta applicativa stato avanzamento/errori rilevati
4.Verifica coerenza file-messaggio
8.Attesa risposta applicativa stato avanzamento/errori rilevati
ΔT4 ΔT5
T4
Figura 10 – Intervalli temporali soggetti a SLA – Banca Mittente Per ciò che riguarda i flussi di carattere dispositivo inviati dalla Banca Mittente si sono fissati i seguenti intervalli massimi:
- T5 = T2 (a meno di tolleranze dovute ai tempi di trasporto sulla Rete Logica). Similmente, per quanto riguarda i flussi informativi, si sono definiti i seguenti intervalli temporali massimi:
- T4 = entro le ore 05:00 (GMT+1) presso il Cliente; - T4 = T1 (a meno di tolleranze dovute ai tempi di trasporto sulla Rete Logica); - T5 = T2 (a meno di tolleranze dovute ai tempi di trasporto sulla Rete Logica).
Gli intervalli sopra definiti hanno validità fino alla fine del Periodo di Transizione, in seguito verranno ricalibrati subendo riduzioni.
Titolo:
Nuova Architettura CBI
Codice
PORTING-MO-001 Versione
00.07.09
Tipologia Documento:
Porting degli attuali Servizi CBI nella Nuova Architettura
Data
09-07-2010
Pagina
39/59
7 Firma digitale Per le specifiche tecniche da adottare per l’utilizzo della Firma digitale si faccia riferimento al documento tecnico FIRMA-MO-001.
7.1 CONTROLLO DEL MITTENTE FISICO DEI FLUSSI FIRMATI L’immissione sulla Rete dei flussi firmati è consentita ai soli mittenti fisici autorizzati dal CBI (cfr. doc. FIRMA-MO-001). In fase di ricezione di un flusso firmato deve pertanto essere effettuato il controllo del mittente fisico, producendo apposito scarto se il CUC dello stesso non rientra nella lista dei soggetti abilitati all’utilizzo della tipologia di firma rilevata. L’eventuale scarto deve essere effettuato dalla Banca destinataria a livello di intero flusso utilizzando il primo messaggio di stato avanzamento (messaggio 17). Il body di servizio di tale messaggio deve essere strutturato così come illustrato nella figura seguente:
Info file
• Tipologia supporti logici• Nome file
(0..n)Info supporto
Stato invio• Stato avanzamento• Codice d’errore
Body di servizio: statoavanzamento
Info su diagnostico
• Banca utente• Versione diagnostico utilizzata• Soggetto verificatore• Data e ora diagnostica
• Tipo messaggio
ERRR
Blocco assente
1
PF5
Le regole di composizione del primo messaggio di stato avanzamento sono le seguenti:
- Campo “Tipo messaggio” posto al valore 1 (primo messaggio di stato avanzamento) - Campo “Stato avanzamento” (presente nel blocco “Stato invio”) valorizzato con “ERRR” - Campo “Codice di errore” presente e posto al valore PF5 (supporti logici firmati digitalmente inviati
da un mittente fisico non autorizzato) - Blocco “Info supporto” assente
7.2 CONTROLLO DI OMOGENEITÀ PER APPOSIZIONE DELLA FIRMA DIGITALE Coerentemente a quanto definito nel paragrafo 2.4.1 del presente documento, l’apposizione della firma digitale e la tipologia di firma utilizzata rappresentano criteri di omogeneità per la composizione di tutti i messaggi di richiesta di servizio. Per ogni richiesta caratterizzata da più supporti logici, il riferimento per la verifica di omogeneità è rappresentato dal primo supporto logico: se è firmato lo devono essere tutti i successivi con la stessa tipologia di firma, se non è firmato la firma non può essere apposta su alcun supporto logico seguente.
Titolo:
Nuova Architettura CBI
Codice
PORTING-MO-001 Versione
00.07.09
Tipologia Documento:
Porting degli attuali Servizi CBI nella Nuova Architettura
Data
09-07-2010
Pagina
40/59
Qualora il criterio di omogeneità non venga rispettato lo scarto deve essere effettuato dalla Banca destinataria a livello di intero flusso utilizzando il primo messaggio di stato avanzamento (messaggio 17) il cui body di servizio deve essere strutturato così come illustrato nella figura seguente:
Info file
• Tipologia supporti logici• Nome file
(0..n)Info supporto
• Codice SIA Azienda di riferimento• ABI Banca di riferimento• Data creazione• Nome supporto
Stato invio
• Stato avanzamento• Codice d’errore
Stato invio
• Stato avanzamento• Codice d’errore
Stato invio• Stato avanzamento• Codice d’errore
Body di servizio: stato avanzamento
Info su diagnostico
• Banca utente• Versione diagnostico utilizzata• Soggetto verificatore• Data e ora diagnostica
Dettagli errore (0..3)
• Tipo messaggio
ERRR
ERRR
PSL5
1
PF5
Blocco assente
Titolo:
Nuova Architettura CBI
Codice
PORTING-MO-001 Versione
00.07.09
Tipologia Documento:
Porting degli attuali Servizi CBI nella Nuova Architettura
Data
09-07-2010
Pagina
41/59
Si precisa come il blocco “Info supporto” debba essere valorizzato solo per il primo supporto logico che viola il criterio di omogeneità dettato dal primo supporto logico contenuto nel file. Le regole di composizione del primo messaggio di stato avanzamento possono pertanto essere sintetizzate nel modo seguente:
- Campo “Tipo messaggio” posto al valore 1 (primo messaggio di stato avanzamento) - Campo “Stato avanzamento” (presente nel blocco “Stato invio”) valorizzato con “ERRR” - Campo “Codice di errore” presente e posto al valore PF5 (supporti logici non omogenei) - Blocco “Info supporto” riferito al primo supporto logico non omogeneo valorizzato seguente modo:
- Campo “Stato avanzamento” (presente nel blocco “Stato invio”) pari a “ERRR” - Campo “Codice di errore” presente e posto al valore PSL5 - Blocco “Dettagli errore” assente
7.3 VERIFICA DELLA FIRMA SUI SINGOLI SUPPORTI LOGICI Per ogni supporto logico firmato la Banca destinataria è tenuta ad effettuare i due seguenti controlli, aggiuntivi rispetto ai diagnostica applicata su tutti i flussi: - verifica che la modalità di apposizione firma dichiarata nel campo “Tipo di firma” sia ammessa per i
Servizi Porting (cfr. doc. FIRMA-MO-001). - verifica che la modalità di apposizione firma dichiarata nel campo “Tipo di firma” sia la stessa utilizzata
nella busta di pertinenza). - verifica di correttezza di ogni busta di firma. Il campo <Sgnt> codificato in base64 deve rappresentare
una busta “leggibile”, ovvero conforme alle specifiche del tipo di firma utilizzata - verifica della firma secondo le modalità previste (cfr. documento FIRMA-MO-001).
Si osserva che non è fissata alcuna sequenza predefinita tra controlli di diagnostica ordinari e controlli sulla firma digitale. I controlli sulla firma possono pertanto essere preposti o posposti a quelli di diagnostica dei supporti logici. Qualora almeno uno di tali controlli fallisca, lo scarto del singolo supporto logico deve essere effettuato utilizzando l’apposito codice di errore disponibile nell’appendice C del documento CBI-STD-001. Con riferimento al secondo messaggio di stato avanzamento, le regole di composizione del blocco “Info supporto”, in corrispondenza ad ogni supporto per il quale viene rilevato un errore di verifica della firma digitale possono pertanto essere sintetizzate come segue:
- Campo “Stato avanzamento” (presente nel blocco “Stato invio”) valorizzato con “ERRR” - Campo “Codice di errore” presente e posto al valore PSL8 - Una occorrenza del blocco “Dettagli errore” con i campi valorizzati nel modo seguente:
- Campo “Numero disposizione” posto al valore “0” (errore generalizzato su tutto il supporto) - Campo “Tipo record” pari alla tipologia del supporto riportata nel record di testa (es. PC) - Campo “Posizione inizio” posta a 1 - Campo “Posizione fine” posta a 120 - Campo “Codice di errore” pari al valore 100 (cfr. doc. CBI-STD-001, Appendice C)
Possono essere presenti eventuali altre occorrenza del blocco “Dettagli errore” qualora si rilevino anche errori legati alla diagnostica del supporto logico. Quanto appena espresso viene illustrato nella figura seguente:
Titolo:
Nuova Architettura CBI
Codice
PORTING-MO-001 Versione
00.07.09
Tipologia Documento:
Porting degli attuali Servizi CBI nella Nuova Architettura
Data
09-07-2010
Pagina
42/59
N.B. La valorizzazione indicata è da intendersi in corrispondenza ad ogni supporto per il quale viene rilevato l’errore sulla firma. Possono inoltre essere presenti altre occorrenza del blocco “Dettagli errore” qualora si rilevino anche errori legati alla diagnostica del supporto logico.
Info file
• Tipologia supporti logici• Nome file
(0..n)Info supporto
• Codice SIA Azienda di riferimento• ABI Banca di riferimento• Data creazione• Nome supporto
Stato invio
• Stato avanzamento• Codice d’errore
Stato invio
• Stato avanzamento• Codice d’errore
Stato invio• Stato avanzamento• Codice d’errore
Body di servizio: statoavanzamento
Info su diagnostico
• Banca utente• Versione diagnostico utilizzata• Soggetto verificatore• Data e ora diagnostica
Dettagli errore
• Numero disposizione/rendicontazione• Tipo record• Posizione inizio• Posizione fine• Codice d’errore
(0..3)
• Tipo messaggio
RCVD
0
Record di testa
1
120
100
ERRR
PSL8
2
Valori riferiti ai dettagli errore su
firma digitale
Titolo:
Nuova Architettura CBI
Codice
PORTING-MO-001 Versione
00.07.09
Tipologia Documento:
Porting degli attuali Servizi CBI nella Nuova Architettura
Data
09-07-2010
Pagina
43/59
8 Allegati
8.1 ALLEGATO A – CRITERI DI IDENTIFICAZIONE UNIVOCA DI MESSAGGIO E FILE
I criteri per l’identificazione univoca del file e del relativo messaggio sono quelli descritti nel documento “STPG-MO-001 Nuovi Servizi - Parte Generale”.
8.2 ALLEGATO B - POPOLAMENTO DEL DIRECTORY A FINI DI “PORTING” Al fine di consentire l’effettiva attivazione del servizio “Porting”, le Banche dovranno completare le procedure operative e propedeutiche all’assegnazione dell’Identificativo Univoco CBI (CUC), unitamente a fornire gli elenchi relativi ai Codici Azienda (Codice SIA) censite in CBI e delle relative Banche Proponenti. Il dettaglio di tali procedure (attori coinvolti, attività, tempistiche) è descritto nel documento “CBI–Assegnazione CUC – attività propedeutiche”, cui si rimanda per approfondimenti.
8.3 ALLEGATO C – STRUTTURA DEI MESSAGGI XML D’INVIO FILE/STATO D’AVANZAMENTO
8.3.1 Considerazioni generali La messaggistica XML a supporto della funzione di Porting è sviluppata in accordo con le linee guida utilizzate per la costruzione della messaggistica per le nuove funzioni CBI. Sono pertanto previsti i seguenti blocchi di informazione principali: - Header di tratta; - Header E2E di Servizio; - Body di servizio. Per i dettagli sulla struttura dell’Header di tratta e dell’Header E2E di Servizio, si faccia riferimento agli Excel “STPG-ST-001 Controlli Header di tratta” e “STPG-ST-002 Controllo Header E2E” e agli Schemi XSD “CBIHdrTrt” e “CBIHdrSrv”, contenuti nella Parte Generale. Per i dettagli sulla struttura del Body di servizio, si faccia invece riferimento agli Excel “STAA-ST-001 Invio file” e “STAA-ST-002 stato avanzam” e agli Schemi XSD “CBIPrtAdvSts” e “CBIPrtSrvRq”, rispettivamente per il messaggio XML accompagnatorio del file di richiesta e per il messaggio di stato avanzamento (cfr. punti 17 e 20 sequence diagram). 8.3.2 Struttura 8.3.2.1 Header di tratta Per le specifiche del blocco d’informazioni “Header di tratta” si faccia riferimento al documento “STPG-MO-001 Nuovi Servizi - Parte Generale”. 8.3.2.2 Header di Servizio Per le specifiche del blocco d’informazioni “Header di Servizio” si faccia riferimento al documento “STPG-MO-001 Nuovi Servizi - Parte Generale”. Ai fini del Servizio “PORTING ATTUALI TRACCIATI”, nei blocchi “Mittente” e “Destinatario” dell’Header E2E di Servizio devono essere indicati solo gli Identificativi CBI della Banca Mittente e di quella Destinataria (tag “Identificativo univoco Mittente/Destinatario”).
Titolo:
Nuova Architettura CBI
Codice
PORTING-MO-001 Versione
00.07.09
Tipologia Documento:
Porting degli attuali Servizi CBI nella Nuova Architettura
Data
09-07-2010
Pagina
44/59
8.3.2.3 Body di Servizio 8.3.2.3.1 Struttura del messaggio XML di “Richiesta di servizio” La struttura logica del “body di servizio” del messaggio di “Richiesta di servizio” (ossia del messaggio XML di accompagnamento all’invio del file) è caratterizzata da quattro blocchi principali: Blocco “Info file”: contiene le informazioni identificative del file, incluso il nome file; Blocco “Info diagnostico”: contiene le informazioni sul diagnostico utilizzato per la verifica del flusso; Blocco “Info supporto”: contiene il dettaglio delle informazioni sui supporti logici contenuti all’interno
del file; Blocco “Firma”: se presente contiene le informazioni sulla firma digitale apposta sul singolo supporto
logico.
Header E2E di servizio
Header di tratta
Messaggio XML
Info file
• Tipologia supporti logici• Nome file
(1..n)Info supporto
• Codice SIA Azienda di riferimento• ABI Banca di riferimento• Data creazione• Nome supporto
Info su diagnostico
• Banca utente• Versione diagnostico utilizzata• Soggetto verificatore• Data e ora diagnostica
Body di servizio
Firma supporto
• Tipo firma• Piattaforma di riferimento• Riferimento temporale• Firma
(0..10)
Descrizione dello schema XML a) Info file <FleInfo>
Presenza: [1..1] Definizione: Blocco obbligatorio contenente le informazioni generali sul file associato al messaggio. Tipo: FileInformation
Titolo:
Nuova Architettura CBI
Codice
PORTING-MO-001 Versione
00.07.09
Tipologia Documento:
Porting degli attuali Servizi CBI nella Nuova Architettura
Data
09-07-2010
Pagina
45/59
Il blocco Info file è composto dai seguenti elementi:
a.1. Tipologia flusso a.2. Nome file
a.1. Tipologia flusso <FlwTyp>
Presenza: [1..1] Definizione: Descrizione della tipologia di supporti logici inviati così come classificati negli attuali standard tecnici CBI (es. PC, RH, etc.) Tipo: FlowType (Max35Text)
a.2. Nome file <FleNm>
Presenza: [1..1] Definizione: Contiene l’identificativo univoco del file inviato – IUF (fare riferimento al documento “STPG-MO-001 Nuovi Servizi - Parte Generale”) Tipo: FileIdentifier
b) Info su diagnostica <DiagInfo>
Presenza: [1..1] Definizione: Blocco obbligatorio che contiene le informazioni sul diagnostico e sulla diagnostica eseguita. Tipo: DiagnosticFileInformation Il blocco è composto dai seguenti elementi:
b.1. Banca utente b.2. Versione diagnostico utilizzata b.3. Soggetto verificatore b.4. Data diagnostica
b.1. Banca utente <UsrBnk>
Presenza: [0..1] Definizione: CUC della Banca “owner” della diagnostica Tipo: CBIIdentifier
b.2. Versione diagnostico utilizzata <DiagVers> Presenza: [1..1] Definizione: Versione del kit di certificazione pubblicato da ACBI per cui il diagnostico ha effettuato la certificazione Tipo: Max35Text
b.3. Soggetto verificatore <ChkSbj> Presenza: [1..1] Definizione: CUC del soggetto che effettua la diagnostica (es. Banca, STD o GPA) Tipo: CBIIdentifier
b.4. Data diagnostica <ChkDt> Presenza: [1..1] Definizione: Data in cui è stata effettuata la diagnostica Tipo: ISODate
c) Info supporto <SppInfo>
Titolo:
Nuova Architettura CBI
Codice
PORTING-MO-001 Versione
00.07.09
Tipologia Documento:
Porting degli attuali Servizi CBI nella Nuova Architettura
Data
09-07-2010
Pagina
46/59
Presenza: [1..n] Definizione: Blocco obbligatorio contenente le informazioni sui supporti logici contenuti nel file inviato. Tipo: SupportInformation Il blocco Info supporto è composto dai seguenti elementi:
c.1. Codice SIA Azienda di riferimento c.2. ABI Banca di riferimento c.3. Data creazione c.4. Nome supporto c.5. Firma supporto
c.1. Codice SIA Azienda di riferimento <SIACd>
Presenza: [1..1] Definizione: Campo che identifica il Codice SIA dell’azienda cliente di riferimento mittente della disposizione nel caso di flussi dispositivi o destinataria nel caso di flussi di esito o informativi; è quello riportato nel “Record di testa” del supporto logico. Tipo: SIAIdentifier (Alfanumerico)
c.2. ABI Banca di riferimento <ABICd >
Presenza: [1..1] Definizione: Codice ABI della Banca di riferimento destinataria del supporto logico nel caso di flussi dispositivi; mittente nel caso di flussi informativi o di esito; è quello riportato nel “Record di testa” del supporto logico. Tipo: ABIIdentifier (Numerico)
c.3. Data creazione <CreDt>
Presenza: [1..1] Definizione: Data di creazione del supporto logico. Tipo: ISODate Note: É ottenuto dal corrispondente campo nel record di testa/record di coda attraverso una conversione di tipo applicativo. Nonostante le specifiche W3C consentano di indicare anche il Time Zone, si precisa che tale dettaglio non deve essere inserito. Infatti, poiché tale campo viene utilizzato quale chiave di correlazione tra supporti referenziati nelle richieste di servizio e relativi stati di avanzamento, l’eventuale presenza del Time Zone potrebbe creare problemi di gestione del workflow in corrispondenza del cambio di orario (solare legale).
c.4. Nome supporto <SppNm>
Presenza: [1..1] Definizione: Nome del supporto logico. Tipo: Max20Text
c.5. Firma supporto <SgnInfo>
Presenza: [0..10] Definizione: Blocco facoltativo che contiene le informazioni sull’eventuale firma digitale applicata al supporto. Il blocco <SgnInfo> è composto dai seguenti elementi:
c.5.1. Tipo firma c.5.2. Piattaforma di riferimento c.5.4. Riferimento temporale c.5.5. Firma
Titolo:
Nuova Architettura CBI
Codice
PORTING-MO-001 Versione
00.07.09
Tipologia Documento:
Porting degli attuali Servizi CBI nella Nuova Architettura
Data
09-07-2010
Pagina
47/59
c.5.1. Tipo firma <SgnTyp>
Presenza: [1..1] Definizione: Valore codificato che descrive il tipo di firma applicata al supporto. Può assumere i seguenti valori definiti nel documento FIRMA –MO-001. Tipo: SignatureType
c.5.2. Piattaforma di riferimento <RefPlt> Presenza: [1..1] Definizione: Descrizione della piattaforma utilizzata per la generazione della firma. Può assumere i valori definiti nel documento FIRMA–MO-001. Tipo: ReferencePlatform
c.5.3. Riferimento temporale <DtRef>
Presenza: [1..1] Definizione: Istante temporale in cui sono state completate le verifiche sulla firma e sul certificato utilizzato per la firma da parte della Banca Proponente (cfr. “FIRMA-MO-001”). Tipo: ISODateTime
c.5.4. Firma <Sgnt>
Presenza: [1..1] Definizione: Tag che contiene la firma (costruita in accordo a quanto specificato dal tag “Tipo firma”). Tipo: P7M. Nota: In questo tag dovrà essere inserita, codificata in Base64, la busta generata dal processo di firma. Il tipo dato riportato nello schema XML per il tipo di dato “P7M” è “xs:base64Binary” .
Controlli Per il dettaglio su Facoltatività/Obbligatorietà e sui controlli (Formali, Validità etc.) da applicare al messaggio XML si rimanda al documento Excel “STAA-ST-001”. 8.3.2.3.2 Struttura del messaggio Stato d’avanzamento La struttura logica del “body di servizio” del messaggio di stato d’avanzamento è caratterizzata da cinque blocchi principali: Blocco “Info file”: contiene le informazioni identificative del file, ed il relativo “stato di avanzamento”
(o eventuali codici d’errore); Blocco “Info diagnostico”: contiene le informazioni sul diagnostico utilizzato per la verifica del
messaggio e del contenuto applicativo del file; Blocco “Info supporto”: contiene il dettaglio delle informazioni sui supporti logici contenuti all’interno
del file ed i relativi “stati di avanzamento” (o eventuali codici d’errore); Blocco “Stato invio”: contiene le informazioni sullo stato di avanzamento e/o errori rilevati; Blocco “Dettagli errore”: contiene i dettagli degli errori rilevati sul supporto logico.
Titolo:
Nuova Architettura CBI
Codice
PORTING-MO-001 Versione
00.07.09
Tipologia Documento:
Porting degli attuali Servizi CBI nella Nuova Architettura
Data
09-07-2010
Pagina
48/59
Info file
• Tipologia supporti logici• Nome file
(0..n)Info supporto
• Codice SIA Azienda di riferimento• ABI Banca di riferimento• Data creazione• Nome supporto
Header E2E di servizio
Header di tratta
Messaggio XML
Stato invio
• Stato avanzamento• Codice d’errore
Stato invio
• Stato avanzamento• Codice d’errore
Stato invio• Stato avanzamento• Codice d’errore
Body di servizio: stato avanzamento
Info su diagnostico
• Banca utente• Versione diagnostico utilizzata• Soggetto verificatore• Data e ora diagnostica
Dettagli errore
• Numero disposizione/rendicontazione• Tipo record• Posizione inizio• Posizione fine• Codice d’errore
(0..3)
• Tipo messaggio
Descrizione dello schema XML a) Tipo messaggio <MsgTyp>
Presenza: [1..1] Definizione: Flag che indica se si tratta del 1° o del 2° messaggio di avanzamento Tipo: MsgTypFlg1 Può assumere i seguenti valori
Valore Descrizione 1 1° messaggio d’avanzamento 2 2° messaggio d’avanzamento
b) Info file <FleInfo> Presenza: [1..1] Definizione: Blocco obbligatorio contenente le informazioni generali sul file cui il messaggio di avanzamento si riferisce. Contiene le stesse informazioni del messaggio originario accompagnatorio del file. Tipo: FileInformation Il blocco Info file è composto dai seguenti elementi:
Titolo:
Nuova Architettura CBI
Codice
PORTING-MO-001 Versione
00.07.09
Tipologia Documento:
Porting degli attuali Servizi CBI nella Nuova Architettura
Data
09-07-2010
Pagina
49/59
b.1. Tipologia supporti logici b.2. Nome file b.3. Stato invio
b.1. Tipologia supporti logici <FlwTyp>
Presenza: [1..1] Definizione: Descrizione della tipologia di supporti logici inviati così come classificati negli attuali standard tecnici CBI (es. PC, RH, etc.) Tipo: FlowType
b.2. Nome file <FleNm>
Presenza: [1..1] Definizione: Contiene l’identificativo univoco del file inviato – IUF (fare riferimento al documento “STPG-MO-001 Nuovi Servizi - Parte Generale”) Tipo: FileIdentifier
b.3. Stato invio <SendSts>
Presenza:[1..1] Definizione: Blocco obbligatorio che contiene le informazioni sullo stato di avanzamento dell’invio del file. Tipo: SendingInformation1 Il blocco è composto dai seguenti elementi:
b.4.1. Stato avanzamento b.4.2. Codice d’errore
b.4.1. Stato avanzamento <AdvSts>
Presenza: [1..1] Definizione: Stato di avanzamento dell’invio del file. Tipo: AdvancingStatusType Può assumere i seguenti valori: Valore Descrizione Dettagli RCVD Received Il file ed il messaggio XML associato sono
stati ricevuti correttamente ERRR Errori rilevati Sono stati rilevati errori sul file o sul
messaggio XML associato (Cfr. campo successivo per i dettagli)
… <ulteriori codifiche da valutare>
b.4.2. Codice d’errore <FleErrCd>
Presenza: [0..1] (diventa obbligatorio se rilevati errori) Definizione: Codice errore durante l’invio del messaggio XML e del file. Tipo: FileErrorCode1 Può assumere i seguenti valori:
Cod. Err.
Descrizione Dettagli 1° msg (Cfr. punto 17 sequenc
2° msg (Cfr. punto 20 sequenc
Titolo:
Nuova Architettura CBI
Codice
PORTING-MO-001 Versione
00.07.09
Tipologia Documento:
Porting degli attuali Servizi CBI nella Nuova Architettura
Data
09-07-2010
Pagina
50/59
e diagram)
e diagram)
PF1 Errore msg XML Processo di validazione del messaggio XML non completato; codice da utilizzare per errori relativi a lunghezza o formato dei campi (tag)
X
PF2 File non trovato Messaggio XML ricevuto correttamente ma file non trovato, oppure nome file errato
X
PF3 File inutilizzabile Messaggio XML ricevuto correttamente ma file inutilizzabile (corrotto, illeggibile, etc.)
X
PF4 Limite massimo supporti logici superato
Numero di supporti logici inclusi nel file e presenti nel messaggio di richiesta superiore al limite definito
X
PF5 Supporti logici non omogenei, non corrispondenti, inutilizzabili o invio non autorizzato
Errore sui supporti logici: non corrispondenti a quelli indicati nel msg XML, non omogenei o inutilizzabili (incompleto, corrotto, illeggibile, etc.). Supporti logici firmati digitalmente inviati da un mittente fisico non autorizzato
X
…. … <ulteriori codifiche da valutare>
Note: Un supporto logico è definito come la sequenza di record che vanno dal record di testa (compreso) fino al relativo record di coda (compreso). Un supporto logico così individuato è definito come un supporto logico integro presente nel file. Il file deve contenere solo supporti logici integri, senza alcun record "estraneo" tra un supporto logico e l'altro; questo significa che dopo il record di coda di un supporto logico integro deve essere presente il record di testa del successivo supporto logico integro oppure la fine del file. Se durante la fase di individuazione di un supporto logico viene incontrata la fine del file e non il record di coda del supporto logico stesso, il supporto logico non è integro. Il file si considera integro se inizia con un supporto logico integro (il primo record del file deve essere il record di testa del primo supporto logico) e termina con un supporto logico integro (l'ultimo record del file deve essere il record di coda dell'ultimo supporto logico).
c) Info su diagnostica <DiagInfo>
Presenza: [1..1] Definizione: Blocco obbligatorio che contiene le informazioni sul diagnostico e sulla diagnostica eseguita Tipo: DiagnosticInformation
Titolo:
Nuova Architettura CBI
Codice
PORTING-MO-001 Versione
00.07.09
Tipologia Documento:
Porting degli attuali Servizi CBI nella Nuova Architettura
Data
09-07-2010
Pagina
51/59
Il blocco è composto dai seguenti elementi:
c.1. Banca utente c.2. Versione diagnostico utilizzata c.3. Soggetto verificatore c.4. Data diagnostica
c.1. Banca utente <UsrBnk>
Presenza: [0..1] Definizione: CUC della Banca “owner” della diagnostica Tipo: CBIIdentifier
c.2. Versione diagnostico utilizzata <DiagVers>
Presenza: [1..1] Definizione: Versione del kit di certificazione pubblicato da ACBI per cui il diagnostico ha effettuato la certificazione Tipo: Max35Text
c.3. Soggetto verificatore <ChkSbj>
Presenza: [1..1] Definizione: CUC del soggetto che effettua la diagnostica del messaggio e del contenuto applicativo del file (es. Banca, STD o GPA) Tipo: CBIIdentifier
c.4. Data diagnostica <ChkDt>
Presenza: [1..1] Definizione: Data in cui è stata effettuata la diagnostica Tipo: ISODate
d) Info supporto <SppInfo>
Presenza: [0..n] Definizione: Blocco contenente le informazioni sul singolo supporto logico ottenute a valle del controllo di congruenza tra file ricevuto e messaggio accompagnatorio o a valle della diagnostica applicativa dei supporti logici Tipo: SupportInformation Note: Il blocco diventa obbligatorio nel caso in cui siano disponibili le informazioni relative ai supporti logici Il blocco Info supporto è composto dai seguenti elementi:
d.1. Codice SIA Azienda di riferimento d.2. ABI Banca di riferimento d.3. Data creazione d.4. Nome supporto d.5. Stato invio
d.1. Codice SIA Azienda di riferimento <SIACd>
Presenza: [1..1] Definizione: Campo che identifica il Codice SIA dell’azienda di riferimento; è quello riportato nel “Record di testa” del supporto logico cui il messaggio di avanzamento si riferisce.
Titolo:
Nuova Architettura CBI
Codice
PORTING-MO-001 Versione
00.07.09
Tipologia Documento:
Porting degli attuali Servizi CBI nella Nuova Architettura
Data
09-07-2010
Pagina
52/59
Tipo: SIAIdentifier (Alfanumerico)
d.2. ABI Banca di riferimento <ABICd> Presenza: [1..1] Definizione: Codice ABI della Banca di riferimento; è quello riportato nel “Record di testa” del supporto logico cui il messaggio di avanzamento si riferisce. Tipo: ABIIdentifier (Numeric)
d.3. Data creazione <CreDt>
Presenza: [1..1] Definizione: Data di creazione del supporto logico cui il messaggio di avanzamento si riferisce. Note: Nonostante le specifiche W3C consentano di indicare anche il Time Zone, si precisa che tale dettaglio non deve essere inserito. Infatti, poiché tale campo viene utilizzato quale chiave di correlazione tra supporti referenziati nelle richieste di servizio e relativi stati di avanzamento, l’eventuale presenza del Time Zone potrebbe creare problemi di gestione del workflow in corrispondenza del cambio di orario (solare legale). Tipo: ISODate
d.4. Nome supporto <SppNm>
Presenza: [1..1] Definizione: Nome del supporto logico cui il messaggio di avanzamento si riferisce. Tipo: Max20Text
d.5. Stato invio <SendSts>
Presenza: [1..1] Definizione: Blocco obbligatorio che contiene le informazioni sullo stato di avanzamento del singolo supporto logico cui il messaggio di avanzamento si riferisce. Tipo: SendingInformation2 Il blocco è composto dai seguenti elementi:
d.5.1. Stato avanzamento d.5.2. Codice d’errore d.5.3. Dettagli errore
d.5.1. Stato avanzamento <AdvSts>
Presenza: [1..1] Definizione: Stato di avanzamento dell’invio del singolo supporto logico cui il messaggio di avanzamento si riferisce. Tipo: AdvancingStatusType
Può assumere i seguenti valori:
Valore Descrizione Dettagli ACTC AcceptedTechnica
lValidation Diagnostica supporto logico ok
ERRR Errori rilevati Sono stati rilevati errori sul supporto logico (Cfr. campo successivo per i dettagli)
… <ulteriori codifiche da valutare>
Titolo:
Nuova Architettura CBI
Codice
PORTING-MO-001 Versione
00.07.09
Tipologia Documento:
Porting degli attuali Servizi CBI nella Nuova Architettura
Data
09-07-2010
Pagina
53/59
d.5.2. Codice d’errore <LgSpErrCd> Presenza: [0..1] (diventa obbligatorio se rilevati errori) Definizione: Codice errore durante l’invio del supporto logico. Tipo: FileErrorCode2 Può assumere i seguenti valori: Cod. Err. Descrizione Dettagli 1° msg
(Cfr. punto 17 sequence diagram)
2° msg (Cfr. punto 20 sequence diagram)
PSL1 Supporto non presente nel messaggio XML
Supporto logico presente nel file fisico ma non dichiarato nel messaggio XML
X
PSL2 Supporto non presente nel file
Supporto logico dichiarato nel messaggio XML ma non presente nel file fisico associato
X
PSL3 Supporto logico non omogeneo per “tipologia flusso”
Tipo supporto logico non coerente con il tipo di flusso
X
PSL4 Supporto logico non omogeneo per per “destinatario”
Supporto logico non indirizzato al destinatario corretto
X
PSL5 Supporto logico non omogeneo per “applicazione firma digitale”
Supporto logico non omogeneo per applicazione della firma digitale
X
PSL6 Supporto logico inutilizzabile
Supporto logico inutilizzabile (incompleto, corrotto, illeggibile, etc.)
X
PSL7 ABI e CUC Banca Passiva non coerenti
Codice ABI B. Passiva in “Info supporto” e CUC B. Passiva nell’HE2E non coerenti
X
PSL8 Errori su supporto logico
Errori sul singolo supporto logico
X
…. … <ulteriori codifiche da valutare>
d.5.3. Dettagli errore <ErrDtl>
Presenza: [0..3] (diventa obbligatorio se rilevati errori applicativi sul singolo supporto logico) Definizione: Dettaglio degli errori applicativi e di diagnostica rilevati sul singolo supporto logico. Tipo: ErrorDetailsInformation Il blocco dettagli errore è composto dai seguenti elementi:
Titolo:
Nuova Architettura CBI
Codice
PORTING-MO-001 Versione
00.07.09
Tipologia Documento:
Porting degli attuali Servizi CBI nella Nuova Architettura
Data
09-07-2010
Pagina
54/59
d.5.3.1. Numero disposizione d.5.3.2. Tipo record d.5.3.3. Posizione inizio d.5.3.4. Posizione fine d.5.3.5. Codice d’errore
d.5.3.1. Numero disposizione <NmDsp> Presenza: [1..1] Definizione: Progressivo della disposizione/rendicontazione su cui è stato rilevato l’errore Tipo: NonNegativeIntegerNumber
d.5.3.2. Tipo record <RcTyp>
Presenza: [1..1] Definizione: Tipologia di record su cui è stato rilevato l'errore Tipo: Max2Text (Cfr. tabella attuali standard tecnici CBI)
d.5.3.3. Posizione inizio <PstStrt>
Presenza: [1..1] Definizione: Posizione di inizio su cui è stato rilevato l’errore Tipo: PositiveIntegerNumber
d.5.3.4. Posizione fine <PstNeg>
Presenza: [1..1] Definizione: Posizione di fine su cui è stato rilevato l’errore Tipo: PositiveIntegerNumber
d.5.3.5. Codice d’errore <ErrCd>
Presenza: [1..1] Definizione: Errore rilevato sulla disposizione del supporto logico. Le possibili codifiche sono state definite sulla base delle attuali segnalazioni di errore scambiate tra Centri Applicativi (Cfr. Appendice C del documento CBI-STD-001 per i dettagli). Tipo: ErrorDetailsCode Può assumere i seguenti valori:
Cod. Err. Descrizione errore <Cfr doc. CBI-STD-001> <Cfr doc. CBI-STD-001>
…. <ulteriori codifiche da valutare>
Controlli Per il dettaglio su Facoltatività/Obbligatorietà e sui controlli (Formali, Validità etc.) da applicare al messaggio XML si rimanda al documento Excel “STAA-ST-002”.
Titolo:
Nuova Architettura CBI
Codice
PORTING-MO-001 Versione
00.07.09
Tipologia Documento:
Porting degli attuali Servizi CBI nella Nuova Architettura
Data
09-07-2010
Pagina
55/59
8.4 ALLEGATO D – ESEMPI DI XML Esempio di messaggio XML (Header di Tratta definito nel namespace “HTRT” + Header di Servizio definito nel namespace “HE2E”+ Body di Servizio definito nel namespace “BODY”) di “accompagnamento file”. <?xml version="1.0" encoding="UTF-8"?> <!--Sample XML file generated by XML Spy v4.3 U (http://www.xmlspy.com)--> <CBIPrtSrvRq xmlns="urn:CBI:xsd:CBIPrtSrvRq.001.03" xmlns:BODY="urn:CBI:xsd:CBIBdyPrtSrvRq.001.03" xmlns:HE2E="urn:CBI:xsd:CBIHdrSrv.001.04" xmlns:HTRT="urn:CBI:xsd:CBIHdrTrt.001.04" xmlns:SGNT="urn:CBI:xsd:CBISgnInf.001.02" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="urn:CBI:xsd:CBIPrtSrvRq.001.03"> <CBIHdrTrt> <HTRT:IdCBISndrf>0000012J</HTRT:IdCBISndrf> <HTRT:IdCBIRcvrf>0000007U</HTRT:IdCBIRcvrf> <HTRT:SrvNm>PORTING-RH</HTRT:SrvNm> <HTRT:IdMsgTrt>0000024O0000025S0000024O000000000000000000010000024O123456789</HTRT:IdMsgTrt> <HTRT:XMLCrtDt>2001-12-17T09:32:50-05:00</HTRT:XMLCrtDt> <HTRT:RtrnAddrl>88503NCB01PR</HTRT:RtrnAddrl> </CBIHdrTrt> <CBIHdrSrv> <HE2E:SrvInfo> <HE2E:SrvNm>PORTING-RH</HE2E:SrvNm> <HE2E:IdE2EMsg>0000024O0000025S0000024O00000000000000000001</HE2E:IdE2EMsg> <HE2E:XMLCrtDt>2001-12-17T09:32:50-05:00</HE2E:XMLCrtDt> </HE2E:SrvInfo> <HE2E:Sender> <HE2E:IdCBISend>0000024O</HE2E:IdCBISend> <HE2E:SendTyp>Banca Passiva</HE2E:SendTyp> <HE2E:CBIRefrSend>0000012J</HE2E:CBIRefrSend> </HE2E:Sender> <HE2E:Receiver> <HE2E:IdCBIRecv>0000025S</HE2E:IdCBIRecv> <HE2E:RecvTyp>Banca Proponente</HE2E:RecvTyp> <HE2E:CBIRefrRecv>0000007U</HE2E:CBIRefrRecv> </HE2E:Receiver> <HE2E:DiagInfo> <HE2E:UsrBnk>0000024O</HE2E:UsrBnk> <HE2E:DiagVers>CBI_5.2</HE2E:DiagVers> <HE2E:ChkSbj>0000012J</HE2E:ChkSbj> <HE2E:ChkDt>2001-12-17T09:32:55-05:00</HE2E:ChkDt> </HE2E:DiagInfo> <HE2E:CongrInfo> <HE2E:SrvBdyNb>0001</HE2E:SrvBdyNb> </HE2E:CongrInfo> </CBIHdrSrv> <CBIBdyPrtSrvRq> <BODY:FleInfo> <BODY:FlwTyp>RH</BODY:FlwTyp> <BODY:FleNm>0000012J000000000000000000001</BODY:FleNm> </BODY:FleInfo>
Titolo:
Nuova Architettura CBI
Codice
PORTING-MO-001 Versione
00.07.09
Tipologia Documento:
Porting degli attuali Servizi CBI nella Nuova Architettura
Data
09-07-2010
Pagina
56/59
<BODY:DiagInfo> <BODY:UsrBnk>0000024O</BODY:UsrBnk> <BODY:DiagVers>CBI_5.2</BODY:DiagVers> <BODY:ChkSbj>0000012J</BODY:ChkSbj> <BODY:ChkDt>2001-12-17</BODY:ChkDt> </BODY:DiagInfo> <BODY:SppInfo> <BODY:SIASndCd>AAAAA</BODY:SIASndCd> <BODY:ABICd>05040</BODY:ABICd> <BODY:CreDt>2001-12-17</BODY:CreDt> <BODY:SppNm>supporto1</BODY:SppNm> <BODY:SgnInfo> <SGNT:SgnTyp>1</SGNT:SgnTyp> <SGNT:RefPlt>A</SGNT:RefPlt> <SGNT:DtRef>2001-12-17T09:30:58-05:00</SGNT:DtRef> <SGNT:Sgnt>String</SGNT:Sgnt> </BODY:SgnInfo> </BODY:SppInfo> <BODY:SppInfo> <BODY:SIASndCd>AAAAA</BODY:SIASndCd> <BODY:ABICd>05040</BODY:ABICd> <BODY:CreDt>2001-12-17</BODY:CreDt> <BODY:SppNm>supporto2</BODY:SppNm> </BODY:SppInfo> </CBIBdyPrtSrvRq> </CBIPrtSrvRq> Esempio di messaggio XML (Header di Tratta definito nel namespace “HTRT” + Header di Servizio definito nel namespace “HE2E”+ Body di Servizio definito nel namespace “BODY”) di “conferma ricezione file/supporto”, corrispondente al 1° messaggio di avanzamento (17) previsto dal workflow “Porting” (Cfr. Par. 2.2.1.1). <?xml version="1.0" encoding="UTF-8"?> <CBIPrtAdvSts xmlns="urn:CBI:xsd:CBIPrtAdvSts.001.03" xmlns:BODY="urn:CBI:xsd:CBIBdyPrtAdvSts.001.03" xmlns:HE2E="urn:CBI:xsd:CBIHdrSrv.001.04" xmlns:HTRT="urn:CBI:xsd:CBIHdrTrt.001.04" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="urn:CBI:xsd:CBIPrtAdvSts.001.03"> <CBIHdrTrt> <HTRT:IdCBISndrf>0000007U</HTRT:IdCBISndrf> <HTRT:IdCBIRcvrf>0000012J</HTRT:IdCBIRcvrf> <HTRT:SrvNm>PORTING-RH</HTRT:SrvNm> <HTRT:IdMsgTrt>0000025S0000024O0000025S000000000000000000020000025S232323234</HTRT:IdMsgTrt> <HTRT:XMLCrtDt>2001-12-18T09:32:50-05:00</HTRT:XMLCrtDt> <HTRT:RtrnAddrl>88503HCB01PR</HTRT:RtrnAddrl> </CBIHdrTrt> <CBIHdrSrv> <HE2E:SrvInfo> <HE2E:SrvNm>PORTING-RH</HE2E:SrvNm> <HE2E:IdE2EMsg>0000025S0000024O0000025S00000000000000000002</HE2E:IdE2EMsg>
Titolo:
Nuova Architettura CBI
Codice
PORTING-MO-001 Versione
00.07.09
Tipologia Documento:
Porting degli attuali Servizi CBI nella Nuova Architettura
Data
09-07-2010
Pagina
57/59
<HE2E:XMLCrtDt>2001-12-18T09:32:55-05:00</HE2E:XMLCrtDt> </HE2E:SrvInfo> <HE2E:Sender> <HE2E:IdCBISend>0000025S</HE2E:IdCBISend> <HE2E:SendTyp>Banca Proponente</HE2E:SendTyp> <HE2E:CBIRefrSend>0000007U</HE2E:CBIRefrSend> </HE2E:Sender> <HE2E:Receiver> <HE2E:IdCBIRecv>0000024O</HE2E:IdCBIRecv> <HE2E:RecvTyp>Banca Passiva</HE2E:RecvTyp> <HE2E:CBIRefrRecv>0000012J</HE2E:CBIRefrRecv> </HE2E:Receiver> <HE2E:DiagInfo> <HE2E:UsrBnk>0000025S</HE2E:UsrBnk> <HE2E:DiagVers>CBI_5.2</HE2E:DiagVers> <HE2E:ChkSbj>0000007U</HE2E:ChkSbj> <HE2E:ChkDt>2001-12-18T09:32:55-05:00</HE2E:ChkDt> </HE2E:DiagInfo> <HE2E:CongrInfo> <HE2E:SrvBdyNb>0001</HE2E:SrvBdyNb> </HE2E:CongrInfo> </CBIHdrSrv> <CBIBdyPrtAdvSts> <BODY:MsgTyp>1</BODY:MsgTyp> <BODY:FleInfo> <BODY:FlwTyp>RH</BODY:FlwTyp> <BODY:FleNm>0000012J000000000000000000001</BODY:FleNm> <BODY:SendSts> <BODY:AdvSts>RCVD</BODY:AdvSts> </BODY:SendSts> </BODY:FleInfo> <BODY:DiagInfo> <BODY:UsrBnk>0000025S</BODY:UsrBnk> <BODY:DiagVers>CBI_5.2</BODY:DiagVers> <BODY:ChkSbj>0000007U</BODY:ChkSbj> <BODY:ChkDt>2001-12-18</BODY:ChkDt> </BODY:DiagInfo> </CBIBdyPrtAdvSts> </CBIPrtAdvSts> Esempio di messaggio XML (Header di Tratta definito nel namespace “HTRT” + Header di Servizio definito nel namespace “HE2E”+ Body di Servizio definito nel namespace “BODY”) di “conferma ricezione file/supporto”, corrispondente al 2° messaggio di avanzamento (20) previsto dal workflow “Porting” (Cfr. Par. 2.2.1.1). <?xml version="1.0" encoding="UTF-8"?> <CBIPrtAdvSts xmlns="urn:CBI:xsd:CBIPrtAdvSts.001.03" xmlns:BODY="urn:CBI:xsd:CBIBdyPrtAdvSts.001.03" xmlns:HE2E="urn:CBI:xsd:CBIHdrSrv.001.04" xmlns:HTRT="urn:CBI:xsd:CBIHdrTrt.001.04" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="urn:CBI:xsd:CBIPrtAdvSts.001.03"> <CBIHdrTrt> <HTRT:IdCBISndrf>0000007U</HTRT:IdCBISndrf>
Titolo:
Nuova Architettura CBI
Codice
PORTING-MO-001 Versione
00.07.09
Tipologia Documento:
Porting degli attuali Servizi CBI nella Nuova Architettura
Data
09-07-2010
Pagina
58/59
<HTRT:IdCBIRcvrf>0000012J</HTRT:IdCBIRcvrf> <HTRT:SrvNm>PORTING-RH</HTRT:SrvNm> <HTRT:IdMsgTrt>0000025S0000024O0000025S000000000000000000030000025S345656456</HTRT:IdMsgTrt> <HTRT:XMLCrtDt>2001-12-18T17:32:50-05:00</HTRT:XMLCrtDt> <HTRT:RtrnAddrl>88503HCB01PR</HTRT:RtrnAddrl> </CBIHdrTrt> <CBIHdrSrv> <HE2E:SrvInfo> <HE2E:SrvNm>PORTING-RH</HE2E:SrvNm> <HE2E:IdE2EMsg>0000025S0000024O0000025S00000000000000000003</HE2E:IdE2EMsg> <HE2E:XMLCrtDt>2001-12-18T09:32:50-05:00</HE2E:XMLCrtDt> </HE2E:SrvInfo> <HE2E:Sender> <HE2E:IdCBISend>0000025S</HE2E:IdCBISend> <HE2E:SendTyp>Banca Proponente</HE2E:SendTyp> <HE2E:CBIRefrSend>0000007U</HE2E:CBIRefrSend> </HE2E:Sender> <HE2E:Receiver> <HE2E:IdCBIRecv>0000024O</HE2E:IdCBIRecv> <HE2E:RecvTyp>Banca Passiva</HE2E:RecvTyp> <HE2E:CBIRefrRecv>0000012J</HE2E:CBIRefrRecv> </HE2E:Receiver> <HE2E:DiagInfo> <HE2E:UsrBnk>0000025S</HE2E:UsrBnk> <HE2E:DiagVers>CBI_5.2</HE2E:DiagVers> <HE2E:ChkSbj>0000007U</HE2E:ChkSbj> <HE2E:ChkDt>2001-12-18T17:32:55-05:00</HE2E:ChkDt> </HE2E:DiagInfo> <HE2E:CongrInfo> <HE2E:SrvBdyNb>0001</HE2E:SrvBdyNb> </HE2E:CongrInfo> </CBIHdrSrv> <CBIBdyPrtAdvSts> <BODY:MsgTyp>2</BODY:MsgTyp> <BODY:FleInfo> <BODY:FlwTyp>RH</BODY:FlwTyp> <BODY:FleNm>0000012J000000000000000000001</BODY:FleNm> <BODY:SendSts> <BODY:AdvSts>RCVD</BODY:AdvSts> </BODY:SendSts> </BODY:FleInfo> <BODY:DiagInfo> <BODY:UsrBnk>0000025S</BODY:UsrBnk> <BODY:DiagVers>CBI_5.2</BODY:DiagVers> <BODY:ChkSbj>0000007U</BODY:ChkSbj> <BODY:ChkDt>2001-12-18</BODY:ChkDt> </BODY:DiagInfo> <BODY:SppInfo> <BODY:SIASndCd>AAAAA</BODY:SIASndCd> <BODY:ABICd>05040</BODY:ABICd> <BODY:CreDt>2001-12-17</BODY:CreDt> <BODY:SppNm>supporto1</BODY:SppNm>
Titolo:
Nuova Architettura CBI
Codice
PORTING-MO-001 Versione
00.07.09
Tipologia Documento:
Porting degli attuali Servizi CBI nella Nuova Architettura
Data
09-07-2010
Pagina
59/59
<BODY:SendSts> <BODY:AdvSts>ACTC</BODY:AdvSts> </BODY:SendSts> </BODY:SppInfo> <BODY:SppInfo> <BODY:SIASndCd>AAAAA</BODY:SIASndCd> <BODY:ABICd>05040</BODY:ABICd> <BODY:CreDt>2001-12-17</BODY:CreDt> <BODY:SppNm>supporto2</BODY:SppNm> <BODY:SendSts> <BODY:AdvSts>ERRR</BODY:AdvSts> <BODY:LgSpErrCd>PSL5</BODY: LgSpErrCd > <BODY:ErrDtl> <BODY:NmDsp>4</BODY:NmDsp> <BODY:RcTyp>61</BODY:RcTyp> <BODY:PstStrt>53</BODY:PstStrt> <BODY:PstEnd>57</BODY:PstEnd> <BODY:ErrCd>012</BODY:ErrCd> </BODY:ErrDtl> </BODY:SendSts> </BODY:SppInfo> </CBIBdyPrtAdvSts> </CBIPrtAdvSts>
8.5 ALLEGATO E – STRUTTURAZIONE DEGLI IDENTIFICATIVI UNIVOCI E QUALIFICATORI DI TIPO MESSAGGIO
Con riferimento alle regole di strutturazione degli identificativi univoci di file e messaggi veicolati sulla rete CBI (cfr. doc. STPG-MO-001 – Nuovi Servizi Parte Generale), viene fornita la lista dei qualificatori tipo messaggio (QTM) da utilizzarsi nell’ambito del workflow che caratterizza l’erogazione dei servizi Porting. Tipo di messaggio fisico Qualificatore Tipo Messaggio (QTM) Richiesta di servizio 01 Primo messaggio di stato avanzamento 17 Secondo messaggio di stato avanzamento 20
Fine del Documento