Technical Specification Template · Web viewIntroduzione Al fine di recepire i cambiamenti...

Gloria!Snam – Jarvis Trading

Technical Specification

Author: [Gruppo di Lavoro Jarvis Trading]Date: [2020.02.17]Version: [1.1]

[Jarvis Trading – Technical Specification]

Sommario

1 INTRODUZIONE................................................................................................................................................ 31.1 Obiettivi............................................................................................................................................................31.2 Scopo...............................................................................................................................................................31.3 Riferimenti.......................................................................................................................................................31.4 Acronimi...........................................................................................................................................................3

2 INTEGRAZIONE BUSINESS TO BUSINESS............................................................................................................ 3Introduzione..................................................................................................................................................................32.1 Protocollo di comunicazione............................................................................................................................52.2 Formato dati Edig@s........................................................................................................................................52.2.1 Struttura dei Messaggi Edig@s.........................................................................................................................62.2.1.1 Messaggio NOMINT – Nomination inviata a Snam dai Clienti..........................................................................62.2.1.2 Messaggio NOMRES – Conferma Nomina inviata da SNAM ai Clienti............................................................152.2.1.3 Messaggio ACKNOW – Acknoledgement inviato da SRG................................................................................242.2.1.3.1 Elenco causali di Acknowledgement......................................................................................................302.3 Public Message Structure – AS4.....................................................................................................................312.3.1 Modello dello scambio messaggi...................................................................................................................312.3.2 Formato del messaggio AS4...........................................................................................................................322.3.2.1 User Message.................................................................................................................................................322.3.2.2 Payload..........................................................................................................................................................332.3.2.3 Compressione dei Messaggi...........................................................................................................................332.3.3 Configurazione Profilo....................................................................................................................................33

3 SICUREZZA...................................................................................................................................................... 343.1 Transport Layer Security................................................................................................................................343.2 Message Layer Security..................................................................................................................................34

4 APPENDICE A: TECHNICAL REQUIREMENT.......................................................................................................354.1 XML Schema File............................................................................................................................................354.2 Test Book Integration Test.............................................................................................................................35

of 36


1 Introduzione

1.1 Obiettivi

Coerentemente all’evoluzione del contesto nazionale ed europeo del mercato del Gas Naturale ed al fine di soddisfare le linee guida UE sul tema dell’interoperabilità degli scambi informativi tra Partner commerciali, che impongono l’adozione di soluzioni comuni per lo scambio dei dati tra i gestori dei sistemi di Trasporto e le loro Controparti, il nuovo portale commerciale Jarvis sarà dotato dello Standard AS4 con formato Edig@s per la gestione degli scambi dei dati in ambito al processo di Trading di Bilanciamento.Si riportano di seguito le tipologie di scambio identificate dall’UE:

scambio dati basato su documenti: i dati sono raccolti all'interno di un file e scambiati in modo automatico tra i rispettivi sistemi informatici;

scambio dei dati integrato: i dati sono scambiati tra due applicazioni direttamente sui rispettivi sistemi informatici.

Con questo documento Snam vuole dunque illustrare le nuove modalità di comunicazione con i propri Clienti interconnessi secondo specifiche Edig@s che susseguono alle comunicazioni in Standard AS4.

1.2 Scopo

Scopo del documento è descrivere le evoluzioni tecnologiche introdotte sul portale Jarvis modulo Trading che ottimizzano lo scambio delle comunicazioni tra gli operatori del mercato del gas, relativamente ai seguenti ambiti:

Nomination process: introduzione messaggi NOMINT e NOMRES per gestire ‘Offerte’ e ‘Transazioni’;

Acknowledgement: introduzione messaggio ACKNOW per notificare la ricezione del messaggio NOMINT oppure per comunicare eventuali errori applicativi/semantici.

Nei successivi paragrafi verranno illustrati i flussi di informazioni che transitano dal sistema Jarvis modulo Trading verso i sistemi dei Clienti mediante il formalismo UML e verranno fornite le specifiche funzionali dei tracciati.In sintesi, le finalità del documento sono:

descrivere le transazioni in termini di sequenza azioni, relazioni tra messaggi e metodi; fornire una descrizione funzionale chiara e consistente dei singoli campi dei tracciati; fornire le regole funzionali per la corretta valorizzazione dei campi.

1.3 Riferimenti

Le Edig@s Message Implementation Guidelines relative a ciascun messaggio in ambito sono disponibili sul sito http://www.edigas.org.

1.4 Acronimi

Termine Descrizione

CLIENTI Insieme di Shipper, Trader, Trasportatori Nazionali, Rigassificatori, Stoccatori, Operatori di Mercato e Clearing House

EIC Energy Identification CodesPSV Punto di Scambio Virtuale

of 36

http://www.edigas.org./


2 Integrazione Business to Business

Introduzione

Al fine di recepire i cambiamenti normativi, l’Integration Layer di Jarvis verrà predisposto a supportare le comunicazioni Edig@s in formato XML.L’intervento evolutivo ottimizza ed amplia le capacità di integrazione e di fruibilità del sistema da parte degli Utenti del Servizio di Trasporto (Utenti del Bilanciamento, Imprese di Stoccaggio, Imprese di Rigassificazione, Imprese di Trasporto Estere e Nazionali) mediante l’adozione di soluzioni comuni per lo scambio dei dati.

L’integration Layer che governa l’interconnessione tra il sistema di Jarvis ed il sistema dei Partner, verrà dotato di una architettura più flessibile al fine di soddisfare le esigenze di differenti Partner predisponendosi a: supportare i canali di trasporto HTTPS e AS4 supportare il formato di dati XML.

Figura 1: Integration Layer per le Comunicazioni B2B

Le principali componenti coinvolte nella nuova architettura di integrazione sono: F5 Networks Traffic Manager: garantisce sicurezza e raggiungibilità delle applicazioni mediante Load Balancer

Service Tibco Gateway Server: abilita trasmissione sicure e rapide di documenti e messaggi. L’architettura prevede la

predisposizione di un server per ciascuna di tipologia di trasporto (AS4, HTTPS) Tibco Interior: gestore delle richieste di servizio Enterprise Service Bus: caratterizzato da processi privati che effettuano il parsing e dispatching delle richieste

verso il portale Jarvis

L’architettura utilizza il protocollo di comunicazione HTTP Sicuro ed il protocollo AS4 HTTP Sicuro secondo le seguenti modalità:

dal Sistema Partner verso il Sistema Jarvis: Comunicazione HTTPS dal Sistema Jarvis vs Sistema Partner: Comunicazione HTTPS.

of 36


Le Business Application oppure i Business Partner che intendono interagire con la piattaforma di Jarvis, dovranno dotarsi del certificato digitale di Snam Rete Gas.

2.1 Protocollo di comunicazione

Il protocollo di comunicazione per gli scambi dati in formato Edig@s sarà l’AS4.

2.2 Dettagli operations

Di seguito si riportano i dettagli delle operation che verranno implementate per ogni Partner:

NameInitiating Role

Responding Role

Service Service Type p-mode id action

NOMINT_TRADINGZSO ZSO

A06http://edigas.org/service http://www.edigas/request/5.1/NOMINT

http://docs.oasis-open.org/ebxml-msg/as4/200902/action

ACKNOW_TRADING

ZSO ZUFA11

http://edigas.org/service

http://www.edigas/response/5.1/ACKNOW


NOMRES_TRADING

ZSO ZSOA06

http://edigas.org/service http://www.edigas/request/5.1/NOMRES


2.3 Formato dati Edig@s

È previsto lo scambio di messaggi EDIG@S-XML in versione 5.1La comunicazione tra Snam (Trasportatore) ed i Partner prevede la predisposizione e lo scambio di Messaggi Standard EDIG@S secondo tracciati definiti dalla EASEE (European Association for the Streamlining of Energy Exchange – gas). L’intervento evolutivo interessa le seguenti transazioni:

NOMINT – Nomination Document: messaggio inviato dall’utente Partner a Snam; NOMRES – Nomination Response: messaggio inviato da Snam all’utente Partner; ACKNOW – Acknoledgement: messaggio inviato da Snam all’utente Partner.

Limitatamente allo scambio dati mediante protocollo Edig@s, è opportuno distinguere due ambiti:

Flussi B2B inbound con i sistemi degli Utente Partner che invocano i servizi esposti dal sistema Jarvis di Snam:

Il Business Partner dovrà gestire la comunicazione verso Snam mediante l’utilizzo del protocollo HTTPS. Snam fornirà sia il certificato digitale necessario per la connessione verso il sistema Jarvis.

L’Integration Layer ha in carico il decripting e la verifica del certificato, l’identificazione del Partner e della tipologia di richiesta, parsing e dispatching del documento mediante processi privati.

Flussi B2B outbound con il sistema Jarvis di Snam che invia comunicazioni ai sistemi degli Utenti Partner:

In questo caso il Partner dovrà fornire a Snam una URL applicativa che il sistema di Jarvis dovrà richiamare per la comunicazione ed un certificato digitale per consentire la comunicazione HTTPS. L’integration Layer ha in carico la composizione dell’envelope, criptaggio e firma del messaggio, routing dell’envelope verso F5 Network che si occuperà di propagare il messaggio al sistema Partner.

Tutti i flussi sono stati previsti in modalità asincrona, il sistema che spedisce il messaggio non resta in attesa di risposta tuttavia questa può arrivare in un secondo momento ovvero in modo non simultaneo.

Gli Utenti Partner hanno la possibilità di inviare le Offerte in acquisto o in cessione generate direttamente all’interno del proprio sistema aziendale verso il sistema Jarvis modulo Trading di Snam utilizzando lo standard EDIG@S dove, la ricezione e gestione di tali messaggi, coinvolge due componenti fondamentali:

of 36


l’Integration Layer, che si occupa della verifica sintattica e formale dei messaggi ricevuti; l’Engine “Jarvis”, che esegue delle verifiche “di Business” sul contenuto dei messaggi ricevuti (identificativi, punti,

tipologia transito, etc.).A valle della verifica dei messaggi da parte dell’Engine, il sistema invia ai sistemi degli Utenti Partner una response, ovvero un messaggio EDIG@S che contiene il risultato delle verifiche effettuate (offerte accettate oppure rifiutate, notifiche di ricezione con l’indicazione dei motivi dello scarto).

Si riporta di seguito il prospetto informativo delle transazioni che verranno allestite, in termini di tipologie, versioni e release

Processo Messaggio Type Contenuto Comunicazione Tipo flusso

Invio Offerta generata nel proprio Sistema Aziendale.

NOMINT 01G Offerta in Acquisto/Cessione Edig@s V5.1 R3 XML Inbound

Invio Transazione generata dal match di due offerte

NOMRES 08G Transazione generata Edig@s V5.1 R3 XML Outbound

Acknowledgement ACKNOW 294 Conferma ricezione messaggio e notifica errore applicativo

Edig@s V5.1 R2 XML Outbound

Codifica

La codifica del file XML deve essere effettuata secondo le specifiche ISO-8859-1.

Avvertenze Generali per la valorizzazione dei campi

Tutti i campi indicati come ‘Mandatory’ (come indicato più avanti nelle tabelle di descrizione funzionale dei campi) sono vincolanti per il caricamento del messaggio.

Edig@s raccomanda l’utilizzo dello standard UTC (Universal Time Coordinated) come fuso orario di riferimento per la formulazione di date ed ore.I campi data ed ora sono espressi nel formato ISO 8601 e precisamente:

YYYY-MM-DDThh:mm:ssZ – formato utilizzato per esprimere una singola data (Es. 2015-12-03T04:00:47Z) YYYY-MM-DDThh:mmZ/ yyyy-mm-ddThh:mmZ – Formato utilizzato per definire un intervallo temporale (Es.

2015-12-03T04:00Z/2015-12-04T06:00Z)dove YYYY rappresenta l’anno, MM il mese, DD il giorno, hh l’ora, mm i minuti e ss i secondi.

2.3.1 Struttura dei Messaggi Edig@s

2.3.1.1 Messaggio NOMINT – Nomination inviata a Snam dai Clienti

Il messaggio NOMINT (Nomination Document) rappresenta lo strumento mediante il quale i Clienti comunicano a Snam le proprie Offerte in Acquisto e/o in Cessione verso una Controparte.Il layer di Integrazione verrà corredato di un nuovo flusso inbound per l’acquisizione delle offerte da trasmettere al sistema Jarvis modulo Trading. Il servizio si predispone per gestire mediante un unico tracciato, il seguente caso d’uso:

- ricezione nel sistema Jarvis modulo Trading delle Offerte di tipo Giornaliera (include sia le Offerte fatte per il Giorno Gas in corso che superiori) in Acquisto o in Cessione riferite a Giorni Gas nell’intervallo [G; G+30], generate nel sistema aziendale del Cliente;

of 36


- ricezione nel sistema Jarvis modulo Trading delle Offerte di tipo Multigiornaliera in Acquisto o in Cessione riferite a Giorni Gas nell’intervallo [G+1; G+30], generate nel sistema aziendale del Cliente.

- Secondo i volumi attuali si prevede un messaggio di NOMINT contenente circa 2000 offerte.

Il sistema Jarvis modulo Trading, owner della creazione delle Transazioni Bilaterali e del calcolo dei Saldi, salva a sistema le offerte ricevute mediante specifiche EDIG@S, previo controllo del Credit Limit per la Controparte in Cessione, della validità delle condizioni di accesso al PSV delle parti coinvolte e del rispetto delle deadline di sistema, generando le Transazioni e provvedendo all’adeguamento del Credit Limit per la Contraparte in Acquisto.

Si riporta di seguito l’information model del messaggio:

Figura 1: Gestione Messaggi EDIG@S – Information model NOMINT

Riportiamo nei paragrafi successivi il dettaglio per ciascuna sezione relativamente alla valorizzazione attesa da Snam.I campi predisposti da tracciato sono soggetti a:

- validazione sintattica effettuata dall’Integration Layer: il messaggio verrà rigettato nel caso non risulti conforme agli schemi XML in termini di formato dei campi e valori ammessi. Il mancato superamento di tali controlli impedisce la propagazione del messaggio alla piattaforma Jarvis modulo Trading;

- validazione semantica effettuata dal sistema Jarvis modulo Trading. Lo scarto dei messaggi verrà notificato dal sistema Jarvis modulo Trading ai Clienti mediante l’invio di un messaggio ACKNOW, invalidando l’intero messaggio di NOMINT precedentemente veicolato, scartando tutte o parte delle offerte in esso contenute che, eventualmente, dovranno essere ritrasmesse con le opportune rettifiche.

Sezione Nomination_Document

La prima sezione rappresenta la testata del messaggio e contiene informazioni che identificano in modo univoco il messaggio di NOMINT veicolato, ovvero mittente e destinatario identificati mediante codice preventivamente condiviso, identificativo e versione del messaggio, ed il periodo di validità delle offerte.È richiesta una sola occorrenza di ‘Nomination_Document’ per messaggio. L’attributo release dovrà contenere il value “3”.

Path sezione: Nomination_Document Sez. obbligatoria: Si N. occorrenze: 1

Field Name Mandatory Field Format Size Domain value Notes

Identification Si string 35 - Identificativo messaggio generato dal Sender.Si veda la “naming convention” definita nella tabella successiva.

Version Si integer 3 - Versione del messaggio valorizzato con “1” ed incrementato ad ogni

of 36


ritrasmissione.Es. <version>1</version>

Type Si codeList 3 01G (Nomination)

Tipologia nomina. Unico valore ammesso è “01G”. È prevista la validazione sintattica da schema xsd.Es. <type>01G</type>

CreationDateTime Si dateTime[YYYY-MM-

DDThh:mm:ssZ]

- - Data di creazione del messaggio.Es. <creationDateTime>2015-12-03T04:00:47Z</creationDateTime>

ValidityPeriod Si string[YYYY-MM-DDThh:mmZ/ yyyy-mm-ddThh:mmZ]

- - Indica il periodo nel quale le offerte veicolate sono contenute: GG inizio periodo/GG fine periodo.Es -> :{"validityPeriod ": 2019-02-28T05:00Z/2019-03-08T05:00Z }

ContractReference Si string 35 - Valorizzare con default “JARVIS_TRADING”, diversamente il messaggio verrà scartato. Es. <contractReference>JARVIS_TRADING</contractReference>

ContractType No codeList 3 NOT USEDJarvis non terrà conto dell’eventuale valorizzazione

Issuer_MarketParticipant.identification

Si string 16 - Identifica il Sender. Il parametro codingScheme deve essere valorizzato con “305” per i Clienti che dispongono di un EIC Code e con “ZSO” per i Clienti che dispongono solo di IS-U Code.Es. <issuer_MarketParticipant.identification codingScheme="305">21X1234567899090</issuer_MarketParticipant.identification>

codingScheme 3 305 (EIC Code)ZSO (IS-U Code)

Issuer_MarketParticipant.marketRole

Si codeList 3 ZSH Sono consentite solo le offerte inviate dal Cliente.

Recipient_MarketParticipant.identification

Si string 16 - Identificativo Snam, unico valore ammesso

codingScheme 3 305 (EIC Code)

of 36


"21X-IT-A-A0A0A-7". Il parametro codingScheme deve essere valorizzato con “305”.

Recipient_MarketParticipant.marketRole

Si codeList 3 ZSO (System Operator)

Qualificatore del Receiver Valorizzare con “ZSO”.Es. <recipient_MarketParticipant.marketRole.code>ZSO</recipient_MarketParticipant.marketRole.code>

ApplicationContext No string 16 - NOT USEDJarvis non terrà conto dell’eventuale valorizzazione


Si riporta di seguito la “naming convention” richiesta per la valorizzazione del campo “Identification”.

Sintassi "NOMINT_TRADING"+[GG]+[IDTRANS]+[IDENTIFIER_SENDER]

Esempio <identification>NOMINT_TRADING201911040000121Z000000000004A</identification>

Token Descrizione

[EDIG@S_Message] Messaggio EDIG@S. Da valorizzare con “NOMINT_TRADING”

[GG] Giorno Gas, identificato con il formato YYYYMMDD

[IDTRANS] Identificativo proprio dal sistema mittente, individuato da 5 cifre (XXXXX)

[IDENTIFIER_SENDER] Identifica il "Codice EIC" univoco per ciascuno Utente Partner oppure il "Codice IS-U".L’utilizzo del “Codice IS-U” è da prevedere solamente in assenza di Codice EIC.

Sezione ConnectionPointInformation

La sezione ConnectionPointInformation consente di esplicitare il punto di scambio virtuale del gas. È richiesta la valorizzazione obbligatoria di tale elemento ai fini della validità del messaggio stesso. La struttura del messaggio si predispone per ricevere una sola occorrenza di ConnectionPointInformation, mediante un unico messaggio NOMINT.

Path sezione: Nomination_Document\ConnectionPointInformation

Sez. obbligatoria: Si N. occorrenze: 1


Identification Si string 35 - Identificativo punto di scambio, unico valore ammesso è “SCAMBIGAS”. Il parametro codingScheme deve essere valorizzato con “ZSO”.

codingScheme 3 ZSO (IS-U Code)

of 36


Es -> :{"identification codingScheme='ZSO'":

MeasureUnit Si codeList 3 MWZ (MWh/d) Unità di misursa quantità gas, unico valore ammesso "MWZ".Es.<measureUnit.code>MWZ</measureUnit.code>.

Sezione NominationType

La sezione NominationType consente di discriminare tra ConnectionPoint che consentono di veicolare gas in una unica direzione (single sided) oppure in due direzioni (double sided). Jarvis modulo Trading accetterà per l’unico ConnectionPoint veicolato la tipologia di transito bidirezionale; l’esito negativo del check verrà notificato al Cliente mediante scarto applicativo (invio messaggio ACKNOW).

Path sezione: Nomination_Document\ConnectionPointInformation\NominationType Sez. obbligatoria: Si N. occorrenze: 1

Field Name Mandatory

Field Format Size Domain value Notes

Type Si codeList 3 A02 (Double sided)

Tipologia di transito, unico valore ammesso "A02" (double side nomination).Es. <type>A02</type>

Sezione Account

Il segmento Account riporta i Clienti coinvolti nello scambio. Non essendo prevista la gestione dei “Balancing Group” nel Mercato del Gas Italiano, le informazioni riportate in tale sezione dovranno essere coerenti con “Issuer Identification” (Sender) e “Recipient Identification” (Receiver) indicati nella testata del messaggio.

Path sezione: Nomination_Document\ConnectionPointInformation\NominationType\Account

Sez. obbligatoria: Si N. occorrenze: 1..N



InternalAccount Si string 35 Indica il codice del Cliente sender. Valorizzazione come “issuer_MarketParticipant.identification”. Il parametro codingScheme deve essere valorizzato con “305” per i Clienti che dispongono di un EIC Code e con “ZSO” per i Clienti che dispongono solo di IS-U Code.Es -> :{"InternalAccount='305'":26X00000012091-Q}


of 36


InternalAccountTso Si string 16 Indica il TSO interno (Snam)Valorizzare come “recipient_MarketParticipant.identification”,unico valore ammesso "21X-IT-A-A0A0A-7". Il parametro codingScheme deve essere valorizzato con “305”.Es -> :{"recipient_MarketParticipant.identification codingScheme='305'": 21X-IT-A-A0A0A-7}


ExternalAccount Si string 35 Indica il Cliente controparte dell’offerta veicolata.Il parametro codingScheme deve essere valorizzato con “305” per i Clienti che dispongono di un EIC Code e con “ZSO” per i Clienti che dispongono solo di IS-U Code.Es. <externalAccount codingScheme="305">21X9876543211010</externalAccount>


ExternalAccountTso No string 16 NOT USEDJarvis non terrà conto dell’eventuale valorizzazione


Sezione Period

La sezione Period consente di indicare per ciascun Giorno Gas le quantità di gas scambiate. Le offerte veicolate possono essere di tipologia:

Giornaliera: riferita ad un singolo Giorno Gas compreso nell’intervallo [Giorno Gas corrente; Giorno Gas corrente +30];

Multigiornaliera: riferita ad un array continuo di Giorni Gas compresi nell’intervallo [Giorno Gas corrente+1; Giorno Gas corrente +30].

Path sezione: Nomination_Document\ConnectionPointInformation\NominationType\Account\Period




TimeInterval Si String[YYYY-MM-DDThh:mmZ/ yyyy-mm-ddThh:mmZ]

- Indica il Giorno Gas dell'offerta veicolata. In caso di offerta multigiornaliera indica il Giorno Gas contenuto nel

of 36


periodo.Jarvis effettuerà un controllo di coerenza rispetto al ValidityPeriod, pena lo scarto dell’offerta. In particolare i TimeInterval comunicati dovranno essere tutti contenuti nel ValidityPeriod indicato.Es. <timeInterval>2019-04-10T04:00Z/2019-04-11T04:00Z</timeInterval>

Direction.code Si codeList 3 Z02 (Input)Z03 (Output)

Specifica la direzione del flusso, unici valori ammessi "Z02","Z03".Logica determinazione azione offerta: - If Z02 -> Acquisto- if Z03 -> CessioneEs. <direction.code>Z02 </direction.code>

Quantity.Amount Si Decimal 17 Qtà dell’offerta. Valore senza segno sempre riferito al singolo Giorno Gas, la lunghezza massima include il “.” decimale.Inoltre, il massimo numero di cifre decimali accettato è: 3.Es.<quantity.amount>750.100</quantity.amount>

Priority_Status.code No codeList 3 NOT USEDJarvis non terrà conto dell’eventuale valorizzazione

Sezione Decomposition_Quantity

La sezione Decomposition_Quantity consente di ripartire le quantità di nomina specificando la tipologia di servizio (interrompibile, non interrompibile, …). Jarvis modulo Trading non terrà conto di tale componente.

Path sezione:Nomination_Document\ConnectionPointInformation\NominationType\Account\Period\Decomposition_Quantity

Sez. obbligatoria: No N. occorrenze: 0..N


Type No codeList 3 ZXD (Firm)ZXE (Makeup)ZXF (Interruptible)ZXG (Conditional)

NOT USEDJarvis non terrà conto dell’eventuale valorizzazione

of 36


Amount No decimal 17 NOT USEDJarvis non terrà conto dell’eventuale valorizzazione

Casistiche di scarto applicativo

È previsto che un messaggio venga scartato anche nel caso in cui il file sia ben formato e valido, ma dai controlli effettuati dal sistema Jarvis modulo Trading il tracciato non risulti coerente con le specifiche di seguito riportate:

Offerte con “Issuer_MarketParticipant.marketRole” diverso da “ZSH” (Shipper) Offerte che riportano unità di misura diversa da “MWZ” (MegaWattora al giorno) Offerte con “NominationType” diverso da A02 (Double Sided) Offerte con “InternalAccount” e “Issuer_MarketParticipant.identification” valorizzati in modo differente Offerte con “InternalAccountTSO” e “Recipient_MarketParticipant.identification” valorizzati in modo differente Offerte con “Identication” del “ConnectionPoint“ diverso da " SCAMBIGAS ". Offerte con Giorno Gas incoerente rispetto al ValidityPeriod riportato in testata Offerte con un TimeInteval che non copre tutto il Giorno Gas Offerte con “Direction.code” diverso da “Z02” o “Z03” Controllo sulla capacità del Credit Limit in caso di offerte in CESSIONE (qualora il Cliente cedente generi

un’offerta con valorizzazione economica maggiore del proprio Credit Limit, il sistema scarterà l’offerta)

Controllo sulle deadline di sistema alla ricezione del messaggio di NOMINT

In caso di errore, Jarvis modulo Trading si predispone per gestire lo scarto parziale o totale dei volumi nominati per Account\Period.

In tali circostanze, gli Account\Period in scarto verranno segnalati alla controparte mediante l’invio di un messaggio di Acknowledgement con relativa motivazione.

Esempio completo di NOMINT Edig@s contenente offerte in cessione e acquisto da parte del Cliente vs. altri Clienti

Offerta di tipo Multi-giornaliera<?xml version="1.0" encoding="UTF-8"?><ns0:Nomination_Document xmlns:ns0="urn:easeegas.eu:edigas:nominationandmatching:nominationdocument:5:1" release="3"><ns0:identification>NOMINT_TRADING20190419000014499</ns0:identification><ns0:version>1</ns0:version><ns0:type>01G</ns0:type><ns0:creationDateTime>2019-04-19T09:15:06Z</ns0:creationDateTime><ns0:validityPeriod>2019-04-21T04:00Z/2019-04-24T04:00Z</ns0:validityPeriod><ns0:contractReference>JARVIS_TRADING</ns0:contractReference><ns0:issuer_MarketParticipant.identification codingScheme="ZSO">4499</ns0:issuer_MarketParticipant.identification><ns0:issuer_MarketParticipant.marketRole.code>ZSH</ns0:issuer_MarketParticipant.marketRole.code><ns0:recipient_MarketParticipant.identification codingScheme="305">21X-IT-A-A0A0A 7</ns0:recipient_MarketParticipant.identification><ns0:recipient_MarketParticipant.marketRole.code>ZSO</ns0:recipient_MarketParticipant.marketRole.code><ns0:ConnectionPoint><ns0:identification codingScheme="ZSO">SCAMBIGAS </ns0:identification><ns0:measureUnit.code>MWZ</ns0:measureUnit.code><ns0:NominationType><ns0:type>A02</ns0:type>

of 36


<ns0:Account><ns0:internalAccount codingScheme="ZSO">4499</ns0:internalAccount><ns0:internalAccountTso codingScheme="305">21X-IT-A-A0A0A-7</ns0:internalAccountTso><ns0:externalAccount codingScheme="305">26X00000012091-Q</ns0:externalAccount><ns0:Period><ns0:timeInterval>2019-04-21T04:00Z/2219-04-22T04:00Z</ns0:timeInterval><ns0:direction.code>Z03</ns0:direction.code><ns0:quantity.amount>50.1</ns0:quantity.amount></ns0:Period><ns0:Period><ns0:timeInterval>2019-04-22T04:00Z/2019-04-23T04:00Z</ns0:timeInterval><ns0:direction.code>Z03</ns0:direction.code><ns0:quantity.amount>150.5</ns0:quantity.amount></ns0:Period><ns0:Period><ns0:timeInterval>2019-04-23T04:00Z/2019-04-24T04:00Z</ns0:timeInterval><ns0:direction.code>Z03</ns0:direction.code><ns0:quantity.amount>500</ns0:quantity.amount></ns0:Period></ns0:Account></ns0:NominationType></ns0:ConnectionPoint></ns0:Nomination_Document>

Offerta di tipo Giornaliera<?xml version="1.0" encoding="UTF-8"?><ns0:Nomination_Document xmlns:ns0="urn:easeegas.eu:edigas:nominationandmatching:nominationdocument:5:1" release="3"><ns0:identification>NOMINT_TRADING20190419000014498</ns0:identification><ns0:version>1</ns0:version><ns0:type>01G</ns0:type><ns0:creationDateTime>2019-04-19T09:15:06Z</ns0:creationDateTime><ns0:validityPeriod>2019-04-20T04:00Z/2019-04-24T04:00Z</ns0:validityPeriod><ns0:contractReference>JARVIS_TRADING</ns0:contractReference><ns0:issuer_MarketParticipant.identification codingScheme="ZSO">4499</ns0:issuer_MarketParticipant.identification><ns0:issuer_MarketParticipant.marketRole.code>ZSH</ns0:issuer_MarketParticipant.marketRole.code><ns0:recipient_MarketParticipant.identification codingScheme="305">21X-IT-A-A0A0A 7</ns0:recipient_MarketParticipant.identification><ns0:recipient_MarketParticipant.marketRole.code>ZSO</ns0:recipient_MarketParticipant.marketRole.code><ns0:ConnectionPoint><ns0:identification codingScheme="ZSO">SCAMBIGAS</ns0:identification><ns0:measureUnit.code>MWZ</ns0:measureUnit.code><ns0:NominationType><ns0:type>A02</ns0:type><ns0:Account><ns0:internalAccount codingScheme="ZSO">4499</ns0:internalAccount><ns0:internalAccountTso codingScheme="305">21X-IT-A-A0A0A-7</ns0:internalAccountTso><ns0:externalAccount codingScheme="305">17X100A100R03017</ns0:externalAccount><ns0:Period><ns0:timeInterval>2019-04-23T04:00Z/2019-04-24T04:00Z</ns0:timeInterval><ns0:direction.code>Z02</ns0:direction.code>

of 36


<ns0:quantity.amount>750.1</ns0:quantity.amount></ns0:Period></ns0:Account><ns0:Account><ns0:internalAccount codingScheme="ZSO">4499</ns0:internalAccount><ns0:internalAccountTso codingScheme="305">21X-IT-A-A0A0A-7</ns0:internalAccountTso><ns0:externalAccount codingScheme="305">26X00000012091-Q</ns0:externalAccount><ns0:Period><ns0:timeInterval>2019-04-20T04:00Z/2219-04-21T04:00Z</ns0:timeInterval><ns0:direction.code>Z03</ns0:direction.code><ns0:quantity.amount>55.5</ns0:quantity.amount></ns0:Period></ns0:Account></ns0:NominationType></ns0:ConnectionPoint></ns0:Nomination_Document>

2.3.1.2 Messaggio NOMRES – Conferma Nomina inviata da SNAM ai Clienti

Il messaggio NOMRES (Nomination Response) viene inviato da Snam ai Clienti in risposta ad un messaggio NOMINT ogniqualvolta si verifica il match tra due offerte complementari di competenza del Cliente e relativa alla creazione di una Transazione. Il layer di Integrazione verrà corredato di un nuovo flusso outbound per la propagazione del messaggio dal sistema Jarvis modulo Trading al sistema aziendale del Cliente.Si riporta di seguito l’information model del messaggio:

Figura 2: Gestione Messaggi EDIG@S – Information model NOMRES

Riportiamo nei paragrafi successivi il dettaglio per ciascuna sezione.

Sezione NominationResponse_Document

La prima sezione rappresenta la testata del messaggio e contiene informazioni che identificano in modo univoco il messaggio, ovvero mittente e destinatario identificati mediante codice preventivamente condiviso, identificativo e versione del messaggio, ed il periodo di validità transazione.È prevista una sola occorrenza di ‘NominationResponse_Document’ per messaggio. L’attributo release conterrà il value “3”.

of 36


Path sezione: NominationResponse_Document Sez. obbligatoria: Si N. occorrenze: 1


Identification Si string 35 - Identificativo messaggio generato da Snam.Si veda la “naming convention” definita nella tabella successivaEs. <ns0:identification>NOMRES_TRADING201904190004217X100A100R03017</ns0:identification>

Version Si Integer 3 - Versione del messaggio valorizzato con “1” ed incrementato ad ogni ritrasmissione.Es. <version>1</version>

Type Si codeList 3 08G (Confirmation notice)

Tipologia messaggio, unico valore ammesso 08G (Confirmation notice)Es. <type>08G</type>


DDThh:mm:ssZ]

- - Data di creazione messaggio. Es. creationDateTime>2019-04-19T09:15:06Z</creationDateTime>

ValidityPeriod Si string[YYYY-MM-DDThh:mmZ/ yyyy-mm-ddThh:mmZ]

- - Identifica il Giorno Gas della Offerta/e matchata/e veicolate.Es. <validityPeriod>2019-04-19T04:00Z/2019-04-20T04:00Z</validityPeriod>

ContractReference Si string 35 - Verrà inviato il valore di default “JARVIS_TRADING”. Es.<contractReference>JARVIS_TRADING</contractReference>

ContractType No codeList 3 NOT USEDJarvis non valorizzerà il campo


Si string 16 - Identifica l’EIC-Code del Sender (Snam),valorizzato con "21X-IT-A-A0A0A-7". Il parametro codingScheme deve essere valorizzato con “305”.Valorizzato con il codice specificato nel "Recipient_MarketParticipant.identification " del


of 36


NOMINT sorgente.Es -> :{"recipient_MarketParticipa

Issuer_MarketParticipant.marketRole


Qualificatore del Sender, valorizzato con "ZSO".Es. <issuer_MarketParticipant.marketRole.code>ZSO</issuer_MarketParticipant.marketRole.code>


Si string 16 - Identifica il Receiver (Cliente al quale si sta comunicando la Transazione). Il parametro codingScheme verrà valorizzato con “305” per i Clienti che dispongono di un EIC Code e con “ZSO” per i Clienti che dispongono di IS-U Code.Es <recipient_MarketParticipant.identification codingScheme="305">21X1234567899090</recipient_MarketParticipant.identification>

codingScheme 3 305 (EIC Code)ZSO (System Operator)

Recipient_MarketParticipant.marketRole

Si codeList 3 ZSH Qualificatore del Receiver. Il campo verrà sempre valorizzato con “ZSH”Es. <recipient_MarketParticipant.marketRole.code>ZSH</recipient_MarketParticipant.marketRole.code>

ApplicationContext No string 16 - NOT USEDJarvis non valorizzerà il campo


Nomination_Document.identification

Si string 35 - Identificativo NOMINT mediante il quale è stata inviato l’offerta poi matchata su Jarvis. Se il messaggio NOMINT sorgente non esiste valorizzato con la stringa "DEFAULT".Es. <Nomination_Document.identification>NOMINT_TRADING201904190000121Z000000000004A</Nomination_Document.iden

of 36


tification>

Nomination_Document.version

Si string 3 - Versione NOMINT mediante il quale è stata inviato l’offerta poi matchata su Jarvis.Es. <nomination_Document.version>1</nomination_Document.version>


Sintassi "NOMRES_TRADING"+[GG]+[IDTRANS]+[IDENTIFIER_SENDER]

Esempio <identification>NOMRES_trading20190419000121Z000000000004A</identification>

Token Descrizione

[EDIG@S_Message] Messaggio EDIG@S. Da valorizzare con “NOMRES_TRADING”


[IDTRANS] Identificativo proprio dal sistema mittente (Snam), individuato da 5 cifre (XXXXX)

[IDENTIFIER_SENDER] Identifica il "Codice EIC" univoco per ciascuno Utente Partner oppure il "Codice IS-U".L’utilizzo del “Codice IS-U” è da prevedere solamente in assenza di Codice EIC

Sezione ConnectionPoint

La sezione ConnectionPoint identifica i punti di scambio virtuale del gas. È richiesta la valorizzazione obbligatoria di tale elemento ai fini della validità del messaggio stesso. La struttura del messaggio si predispone per ricevere una sola occorrenza di ConnectionPointInformation, mediante un unico messaggio NOMRES.

Path sezione: NominationResponse_Document\ConnectionPoint



Identification Si string 35 - Identificativo punto di scambio, valorizzato con "SCAMBIGAS”. Il parametro codingScheme deve essere valorizzato con “ZSO”.Es -> :{"identification codingScheme='ZSO'": SCAMBIGAS

codingScheme 3 ZSO (IS-U Code)

MeasureUnit Si codeList 3 MWZ (MWh/d) Unità di misura Qtà transazione, valorizzato con MWZ.Es. <measureUnit.code>MWZ</measureUnit.code>

Sezione NominationType

La valorizzazione di tale informazione scaturisce da quanto riportato nel messaggio di NOMINT sorgente.

of 36


Path sezione: NominationResponse_Document\ConnectionPoint\NominationType




Type Si codeList 3 A02 (Double sided)

Tipologia di transito.Valorizzato con quanto riportato nel NOMINT sorgente.Es. <type>A02</type>

Sezione Account

Il segmento Account riporta i Clienti coinvolti nello scambio. Non essendo prevista la gestione dei “Balancing Group” nel Mercato del Gas Italiano, le informazioni riportate in tale sezione dovranno essere coerenti con “Issuer Identification” (Sender) e “Recipient Identification” (Receiver) indicati nella testata del messaggio.

Path sezione: NominationResponse_Document\ConnectionPoint\NominationType\Account




InternalAccount Si string 35 - Indica il Cliente del TSO interno (Snam), valorizzato con il codice specificato nel "Recipient_MarketParticipant.identification " del NOMINT sorgente.Es. <internalAccount codingScheme="305">21X1234567899090</internalAccount>


InternalAccountTso No string 16 - Indica il TSO interno (Snam), valorizzato con "21X-IT-A-A0A0A-7". Il parametro codingScheme deve essere valorizzato con “305”.Es. <internalAccountTso codingScheme="305">21X-IT-A-A0A0A-7 </internalAccountTso>


ExternalAccount No string 35 - Indica il Cliente controparte nella Transazione. Il parametro codingScheme deve essere valorizzato con “305” per i Clienti che dispongono di un EIC


of 36


Code e con “ZSO” per i Clienti che dispongono solo di IS-U Code.

ExternalAccountTso No string 16 NOT USEDJarvis non valorizzerà il campo


Sezione InformationOriginTimeseries

La sezione riporta lo stato delle quantità delle Transazioni. È prevista la trasmissione delle sole quantità confermate (Type 16G).

Path sezione: NominationResponse_Document\ConnectionPoint\NominationType\Account\InformationOriginTimeseries




Type Si codeList 3 16G (Confirmed) Tipologia volumi.Verranno inviati solo i volumi confermati (16G).Es. <type>16G</type>

Sezione Period

La sezione Period consente di indicare per ciascun Giorno Gas le quantità di gas scambiate. Le offerte veicolate possono essere di tipologia:

Giornaliera: riferita ad un singolo Giorno Gas compreso nell’intervallo [Giorno Gas corrente; Giorno Gas corrente +30];

Multigiornaliera: riferita ad un array continuo di Giorni Gas compresi nell’intervallo [Giorno Gas corrente+1; Giorno Gas corrente +30].

Path sezione: NominationResponse_Document\ConnectionPoint\NominationType\Account\InformationOriginTimeseries\Period




TimeInterval Si string[YYYY-MM-DDThh:mmZ/ yyyy-mm-ddThh:mmZ]

- Indica il Giorno Gas della transazione veicolata. In caso di Transazione multigiornaliera indica il Giorno Gas contenuto nel periodo.Es. <timeInterval>2019-04-10T04:00Z/2019-04-11T04:00Z</timeInterval>

Direction.code Si codeList 3 Z02 (Input) Specifica la direzione del

of 36


Z03 (Output) flusso, unici valori ammessi "Z02","Z03".Logica determinazione azione offerta: - If Z02 -> Acquisto- if Z03 -> CessioneEs. <direction.code>Z02 </direction.code>

Quantity.Amount Si decimal 17 Qtà della Transazione. Valore senza segno sempre riferito al singolo Giorno Gas, la lunghezza massima include il “.” decimale.Inoltre, il massimo numero di cifre decimali accettato è: 3.Es.<quantity.amount>750.100</quantity.amount>

Sezione Decomposition_Quantity

La sezione Decomposition_Quantity consente di confermare le quantità di nomina ripartite, specificando la tipologia di servizio (interrompibile, non interrompibile, …). Jarvis non terrà conto di tale dettaglio.

Path sezione:NominationResponse_Document\ConnectionPoint\NominationType\Account\InformationOriginTimeseries\Period\DecompositionQuantity

Sez. obbligatoria: No N. occorrenze: 0..N


Type Si codeList 3 ZXD (Firm)ZXE (Makeup)ZXF (Interruptible)ZXG (Conditional)

NOT USEDJarvis non valorizzerà il campo

Amount Si decimal 17 NOT USEDJarvis non valorizzerà il campo

Sezione Status

La sezione Status risulta essere obbligatoria: verrà utilizzata per veicolare il codice della Transazione generata.

Path sezione: NominationResponse_Document\ConnectionPoint\NominationType\Account\InformationOriginTimeseries\Period\Status

Sez. obbligatoria: No N. occorrenze: 1



Reason.code Si codeList 3 12G (Settled)

Valorizzato con "12G" (Settled).Es. <code>12G</code>

of 36


Reason.text No string 512 - Valorizzato con il codice della Transazione veicolata.Es.< text>T-APR01101/19</ text>

of 36


Esempio completo di NOMRES Edig@s contenente Transazioni in cessione e acquisto da parte dell’Utente Partner vs. altri Utenti Partner Transazione di tipo Multi-giornaliera

<?xml version="1.0" encoding="UTF-8" standalone="yes"?><ns0:NominationResponse_Document xmlns:ns0="urn:easeegas.eu:edigas:nominationandmatching:nominationresponsedocument:5:1" release="3"><ns0:identification>NOMRES_TRADING201904190004217X100A100R03017</ns0:identification><ns0:version>1</ns0:version><ns0:type>08G</ns0:type><ns0:creationDateTime>2019-04-19T12:04:13Z</ns0:creationDateTime><ns0:validityPeriod>2019-04-21T04:00Z/2019-04-24T04:00Z</ns0:validityPeriod><ns0:contractReference>JARVIS_TRADING</ns0:contractReference><ns0:issuer_MarketParticipant.identification codingScheme="305">21X-IT-A-A0A0A-7</ns0:issuer_MarketParticipant.identification><ns0:issuer_MarketParticipant.marketRole.code>ZSO</ns0:issuer_MarketParticipant.marketRole.code><ns0:recipient_MarketParticipant.identification codingScheme="ZSO">4499</ns0:recipient_MarketParticipant.identification><ns0:recipient_MarketParticipant.marketRole.code>ZSH</ns0:recipient_MarketParticipant.marketRole.code><ns0:nomination_Document.identification>NOMINT_TRADING20190419000014499</ns0:nomination_Document.identification><ns0:nomination_Document.version>1</ns0:nomination_Document.version><ns0:ConnectionPoint><ns0:identification codingScheme="305">SCAMBIGAS</ns0:identification><ns0:measureUnit.code>MWZ</ns0:measureUnit.code><ns0:NominationType><ns0:type>A02</ns0:type><ns0:Account><ns0:internalAccount codingScheme="305">21X-IT-A-A0A0A-7</ns0:internalAccount><ns0:internalAccountTso codingScheme="305">21X-IT-A-A0A0A-7</ns0:internalAccountTso><ns0:externalAccount codingScheme="305">26X00000012091-Q</ns0:externalAccount><ns0:externalAccountTso codingScheme="305"/><ns0:InformationOrigin_TimeSeries><ns0:type>16G</ns0:type><ns0:Period><ns0:timeInterval>2019-04-21T04:00Z/2019-04-22T04:00Z</ns0:timeInterval><ns0:direction.code>Z03</ns0:direction.code><ns0:quantity.amount>50.1</ns0:quantity.amount></ns0:Period><ns0:status><ns0:code>12G</ns0:code><ns0:text>T-APR1210001/19</ns0:text></ns0:status><ns0:Period><ns0:timeInterval>2019-04-22T04:00Z/2019-04-23T04:00Z</ns0:timeInterval><ns0:direction.code>Z03</ns0:direction.code><ns0:quantity.amount>150.1</ns0:quantity.amount></ns0:Period><ns0:status>

of 36


<ns0:code>12G</ns0:code><ns0:text>T-APR1210001/19</ns0:text></ns0:status><ns0:Period><ns0:timeInterval>2019-04-23T04:00Z/2019-04-24T04:00Z</ns0:timeInterval><ns0:direction.code>Z03</ns0:direction.code><ns0:quantity.amount>500</ns0:quantity.amount></ns0:Period><ns0:status><ns0:code>12G</ns0:code><ns0:text>T-APR1210001/19</ns0:text></ns0:status></ns0:InformationOrigin_TimeSeries></ns0:Account></ns0:NominationType></ns0:ConnectionPoint></ns0:NominationResponse_Document>

Transazione di tipo giornaliera

<?xml version="1.0" encoding="UTF-8" standalone="yes"?><ns0:NominationResponse_Document xmlns:ns0="urn:easeegas.eu:edigas:nominationandmatching:nominationresponsedocument:5:1" release="3"><ns0:identification>NOMRES_TRADING201904190004217X100A100R03022</ns0:identification><ns0:version>1</ns0:version><ns0:type>08G</ns0:type><ns0:creationDateTime>2019-04-19T14:04:13Z</ns0:creationDateTime><ns0:validityPeriod>2019-04-19T04:00Z/2019-04-24T04:00Z</ns0:validityPeriod><ns0:contractReference>JARVIS_TRADING</ns0:contractReference><ns0:issuer_MarketParticipant.identification codingScheme="305">21X-IT-A-A0A0A-7</ns0:issuer_MarketParticipant.identification><ns0:issuer_MarketParticipant.marketRole.code>ZSO</ns0:issuer_MarketParticipant.marketRole.code><ns0:recipient_MarketParticipant.identification codingScheme="ZSO">4499</ns0:recipient_MarketParticipant.identification><ns0:recipient_MarketParticipant.marketRole.code>ZSH</ns0:recipient_MarketParticipant.marketRole.code><ns0:nomination_Document.identification>NOMINT_TRADING20190419000014498</ns0:nomination_Document.identification><ns0:nomination_Document.version>1</ns0:nomination_Document.version><ns0:ConnectionPoint><ns0:identification codingScheme="305">SCAMBIGAS</ns0:identification><ns0:measureUnit.code>MWZ</ns0:measureUnit.code><ns0:NominationType><ns0:type>A02</ns0:type><ns0:Account><ns0:internalAccount codingScheme="305">21X-IT-A-A0A0A-7</ns0:internalAccount><ns0:internalAccountTso codingScheme="305">21X-IT-A-A0A0A-7</ns0:internalAccountTso><ns0:externalAccount codingScheme="305">17X100A100R03017</ns0:externalAccount><ns0:externalAccountTso codingScheme="305"/>

of 36


<ns0:InformationOrigin_TimeSeries><ns0:type>16G</ns0:type><ns0:Period><ns0:timeInterval>2019-04-23T04:00Z/2019-04-24T04:00Z</ns0:timeInterval><ns0:direction.code>Z02</ns0:direction.code><ns0:quantity.amount>750.1</ns0:quantity.amount></ns0:Period><ns0:status><ns0:code>12G</ns0:code><ns0:text>T-APR1210099/19</ns0:text></ns0:status></ns0:InformationOrigin_TimeSeries></ns0:Account><ns0:Account><ns0:internalAccount codingScheme="305">21X-IT-A-A0A0A-7</ns0:internalAccount><ns0:internalAccountTso codingScheme="305">21X-IT-A-A0A0A-7</ns0:internalAccountTso><ns0:externalAccount codingScheme="305">26X00000012091-Q</ns0:externalAccount><ns0:externalAccountTso codingScheme="305"/><ns0:InformationOrigin_TimeSeries><ns0:type>16G</ns0:type><ns0:Period><ns0:timeInterval>2019-04-20T04:00Z/2019-04-21T04:00Z</ns0:timeInterval><ns0:direction.code>Z03</ns0:direction.code><ns0:quantity.amount>55.5</ns0:quantity.amount></ns0:Period><ns0:status><ns0:code>12G</ns0:code><ns0:text>T-APR1210095/19</ns0:text></ns0:status></ns0:InformationOrigin_TimeSeries></ns0:Account></ns0:NominationType></ns0:ConnectionPoint></ns0:NominationResponse_Document>

Figura 3 - Esempio NOMRES – Invio Transazioni via Edig@s

2.3.1.3 Messaggio ACKNOW – Acknoledgement inviato da SRG

Il messaggio ACKNOW (Acknoledgement Document) viene inviato da Snam ai Clienti ed ha un duplice utilizzo: notificare la ricezione di un messaggio di “Nomination Document” sulla piattaforma Jarvis modulo Trading; notificare un errore applicativo oppure semantico rilevato in fase di elaborazione del messaggio sul sistema Jarvis

modulo Trading.In caso di errori, è previsto che Jarvis invii un unico messaggio ACKNOW alla controparte in riferimento ad uno specifico messaggio di NOMINT.

Si riporta di seguito l’information model del messaggio:

of 36


Figura 4 - Gestione Messaggi EDIG@S – Information model ACKNOW

Riportiamo nei paragrafi successivi il dettaglio per ciascuna sezione.

Sezione Acknowledgement_Document

La prima sezione rappresenta la testata del messaggio e contiene informazioni che identificano in modo univoco l’acknowledgement, ovvero mittente e destinatario identificati mediante codice preventivamente condiviso, identificativo e versione del messaggio, informazioni relative al messaggio trasmesso dalla controparte e per il quale si vuole inviare una notifica, ed il periodo di validità.È prevista una sola occorrenza di ‘Acknowledgement_Document’ per messaggio.

Path sezione: Acknowledgement_Document Sez. obbligatoria: Si N. occorrenze: 1


Identification Si string 35 - Identificativo messaggio generato da Snam.Si veda la “naming convention” definita nella tabella successiva

Version No Integer 3 - Versione del messaggio valorizzato con “1” ed incrementato ad ogni ritrasmissione.Es. <version>1</version>

Type Si codeList 3 294 (Application error and acknowledgement)

Tipologia messaggio.Sono gestite solamente le tipologie ‘294’.Es. <type>294</type>


DDThh:mm:ssZ]

- - Data di creazione messaggio. Es.<creationDateTime>2019-04-19T09:15:06Z</creationDateTime>

ValidityPeriod No string[YYYY-MM-DDThh:mmZ/ yyyy-mm-ddThh:mmZ]

- - Identifica il range di validità ricevuto tramite NOMINT, a prescindere da eventuali scarti.Es. <validityPeriod>2019-04-19T04:00Z/2019-04-

of 36


20T054:00Z</validityPeriod>

ContractReference No string 35 - NOT USEDJarvis non valorizzerà il campo

ContractType No codeList 3 NOT USEDJarvis non valorizzerà il campo


Si string 16 - Identifica l’EIC-Code del Sender (SRG), valorizzato con "21X-IT-A-A0A0A-7".Valorizzato con il codice specificato nel "Recipient_MarketParticipant.identification " del NOMINT sorgente.Es.<issuer_MarketParticipant.identification codingScheme="305">21X-IT-A-A0A0A-7 </issuer_MarketParticipant.identification>


Issuer_MarketParticipant.marketRole.code


Qualificatore del Sender. Verrà valorizzato sempre con “ZSO”.Es.<issuer_MarketParticipant.marketRole.code>ZSO</issuer_MarketParticipant.marketRole.code>


Si string 16 - Identifica il Receiver. Il parametro codingScheme verrà valorizzato con “305” per i Clienti che dispongono di un EIC Code e con “ZSO” per i Clienti che dispongono di IS-U Code.Valorizzato con il codice specificato nel "Issuer_MarketParticipant.identification " del NOMINT sorgente.Es. <recipient_MarketParticipant.identification codingScheme="305">21X1234567899090</recipient_MarketParticipant.identification>

codingScheme 3 305 (EIC Code)ZSO (System Operator)

Recipient_MarketParticipant.marketRole.code

No codeList 3 ZSH Qualificatore del Receiver. Il campo verrà valorizzato con “ZSH” in risposta ad un NOMINT

of 36


Es.<recipient_MarketParticipant.marketRole.code>ZSO</recipient_MarketParticipant.marketRole.code>

ApplicationContext No string 16 - NOT USEDJarvis non valorizzerà il campo


Receiving_Document.identification

No string 35 - Identificativo del messaggio di NOMINT ricevuto per il quale si vuole inviare una notifica. Es.<receiving_Document.identification>NOMINT_TRADING201904190000121Z000000000004A </receiving_Document.identification>

Receiving_Document.version

No string 3 - Versione del messaggio di NOMINTricevuto per il quale si vuole inviare una notifica.Es.<receiving_Document.version>1</receiving_Document.version>

Receiving_Document.type No string 3 - NOT USEDJarvis non valorizzerà il campo

Receiving_Document.creationDateTime

No dateTime[YYYY-MM-

DDThh:mm:ssZ]

- NOT USEDJarvis non valorizzerà il campo

Receiving_Document.payloadName

No string 150 - NOT USEDJarvis non valorizzerà il campo


Sintassi "ACKNOW_TRADING"+[GG]+[IDTRANS]+[IDENTIFIER_SENDER]

Esempio <identification>ACKNOW_trading201904190000121Z000000000004A</identification>

Token Descrizione

[EDIG@S_Message] Messaggio EDIG@S. Da valorizzare con “ACKNOW”


[IDTRANS] Identificativo proprio dal sistema mittente, individuato da 5 cifre (XXXXX)

[IDENTIFIER_SENDER] Identifica il "Codice EIC" univoco per ciascuno UdB oppure il "Codice IS-U".L’utilizzo del “Codice IS-U” è da prevedere solamente in assenza di Codice EIC

of 36


Sezione Reason

La sezione Reason fornisce informazioni testuali che consentono di dettagliare la tipologia di notifica (elaborazione e salvataggio di tutte le offerte contenute nel messaggio di NOMINT o scarto totale del messaggio di NOMINT). Tale componente risulta obbligatoria ed è previsto l’invio di un messaggio con una sola occorrenza della sezione ‘Reason’.

Path sezione: Acknowledgement_Document\Reason Sez. obbligatoria: Si N. occorrenze: 1


Code Si codeList 3 Elenco codici riportato nel paragrafo 2.3.1.3.1 - Elenco causali diAcknow

Codice causale notifica.Es. <code>01G</code>

Text No string 512 - Descrizione notifica.Es. <text>The message has been processed and accepted</text>

Sezione Rejection_ConnectionPoint

La sezione Rejection_ConnectionPoint può essere usata in caso di scarto parziale, per esplicitare il dettaglio dell’offerta scartata dal sistema Jarvis (modulo Trading).

Path sezione: Acknowledgement_Document\Rejection_ConnectionPoint Sez. obbligatoria: No N. occorrenze: 0..1


Identification Si string 35 - Identificativo punto di scambio, valorizzato con "SCAMBIGAS". Il parametro codingScheme deve essere valorizzato con “ZSO”.Es -> :{"identification codingScheme='ZSO'": SCAMBIGAS

codingScheme 3 305 (EIC code)ZSO (System Operator)

Sezione Reason

La sezione Reason specifica della componente Rejection_ConnectionPoint, fornisce informazioni testuali che consentono di dettagliare le motivazioni dello scarto.

Path sezione: Acknowledgement_Document\Rejection_ConnectionPoint\Reason Sez. obbligatoria: No N. occorrenze: 1..N


Code Si codeList 3 Elenco codici riportato nel paragrafo 2.3.1.3.1 - Elenco causali diAcknow

Codice causale notifica.Es. <code>01G</code>

of 36


Text Si string 512 - Descrizione notifica.Nel testo sarà specificata la chiave logica che identifica l'offerta. Essa costituita da: "ExternalAccount" (indica la Controparte dell'offerta) - TimeInterval (indica il GionoGas dell'offerta) - Direction.code (indica l'Azione di acquisto/vendita).Es. <text>The message has been processed and accepted</text>

Esempio completo di acknowledgement Edig@s - notifica ricezione messaggio privo di scarti<?xml version="1.0" encoding="UTF-8"?><ns0:Acknowledgement_Document xmlns:ns0="urn:easeegas.eu:edigas:general:acknowledgementdocument:5:1" release="2"> <ns0:identification>ACKNOW_TRADING201904190000121Z000000000004A</ns0:identification> <ns0:version>1</ns0:version> <ns0:type>294</ns0:type> <ns0:creationDateTime>2019-04-19T010:15:06Z</ns0:creationDateTime> <ns0:validityPeriod>2019-04-19T04:00Z/2019-04-24T04:00Z</ns0:validityPeriod> <ns0:issuer_MarketParticipant.identification codingScheme="305">21X-IT-A-A0A0A-7</ns0:issuer_MarketParticipant.identification> <ns0:issuer_MarketParticipant.marketRole.code>ZSO</ns0:issuer_MarketParticipant.marketRole.code> <ns0:recipient_MarketParticipant.identification codingScheme="305">4499</ns0:recipient_MarketParticipant.identification><ns0:recipient_MarketParticipant.marketRole.code>ZSO</ns0:recipient_MarketParticipant.marketRole.code> <ns0:receiving_Document.identification>NOMINT_TRADING20190419000014499</ns0:receiving_Document.identification> <ns0:receiving_Document.version>1</ns0:receiving_Document.version> <ns0:Reason> <ns0:code>01G</ns0:code> <ns0:text>The message has been processed and accepted</ns0:text> </ns0:Reason></ns0:Acknowledgement_Document>

Esempio completo di acknowledgement Edig@s - notifica ricezione messaggio con scarti parziali<?xml version="1.0" encoding="UTF-8"?><ns0:Acknowledgement_Document xmlns:ns0="urn:easeegas.eu:edigas:general:acknowledgementdocument:5:1" release="2"><ns0:identification>ACKNOW_TRADING201904190000121Z000000000004A</ns0:identification><ns0:version>1</ns0:version><ns0:type>294</ns0:type><ns0:creationDateTime>2019-04-19T010:15:06Z</ns0:creationDateTime><ns0:validityPeriod>2019-04-19T04:00Z/2019-04-24T04:00Z</ns0:validityPeriod><ns0:issuer_MarketParticipant.identification codingScheme="305">21X-IT-A-A0A0A-7</ns0:issuer_MarketParticipant.identification><ns0:issuer_MarketParticipant.marketRole.code>ZSO</ns0:issuer_MarketParticipant.marketRole.code><ns0:recipient_MarketParticipant.identification codingScheme="305">4499</ns0:recipient_MarketParticipant.identification><ns0:recipient_MarketParticipant.marketRole.code>ZSO</ns0:recipient_MarketParticipant.marketRole.code><ns0:receiving_Document.identification>NOMINT_TRADING20190419000014488</ns0:receiving_Document.identification><ns0:receiving_Document.version>1</ns0:receiving_Document.version>

of 36


<ns0:Rejection_ConnectionPoint> <ns0:identification codingScheme="305">SCAMBIGAS</ns0:identification><ns0:Reason><ns0:code>41G</ns0:code><ns0:text>Semantic error - for Offer "26X00000012091-Q"- "2019-04-20T05:00Z/2019-04-21T05:00Z" - "Z02" : the value "ZSO" is uncorrect, the "codingScheme" value is inconsistent.</ns0:text></ns0:Reason><ns0:Reason><ns0:code>41G</ns0:code><ns0:text>Semantic error - for Offer "17X100A100R03017"- "2019-04-17T05:00Z/2019-04-18T05:00Z" - "Z02" : the value "2019-04-17T05:00Z/2019-04-18T05:00Z" must be within the validity period.</ns0:text></ns0:Reason><ns0:Reason><ns0:code>41G</ns0:code><ns0:text>Semantic error - for Offer "17X100A100R03017"- "2019-04-21T05:00Z/2019-04-22T05:00Z" - "Z02" : the value "750.1" deficient gas</ns0:text></ns0:Reason></ns0:Rejection_ConnectionPoint></ns0:Acknowledgement_Document>

Figura 5 - Esempio ACKNOW - Notifica ricezione NOMINT con scarti parziali

2.3.1.3.1 Elenco causali di Acknowledgement

Si riportano di seguito le causali previste dal sistema Jarvis modulo Trading.

Code Text Reason/Text01G Processed

and accepted

The message has been processed and accepted

48G Other error Other error - A not further specified error has been found in the message. Please re-try to send nominations.

41G Semantic error

Syntactical error - "CreationDateTime" must be specified in the format "YYYY-MM-DDThh:mm:ssZ".

40G Syntactical error

Syntactical error - "ValidityPeriod" must be specified in the format "[YYYY-MM-DDThh:mmZ/yyyy-mm-ddThh:mmZ]".

40G Syntactical error

Semantic error - "ValidityPerdiod" must cover all the Gas Day.

04G Recieved after deadline

Semantic error - the value "ContractReference" is invalid and must be equal to "JARVIS_TRADING".

41G Semantic error

Semantic error - the value "Issuer_MarketParticipant.identification" is uncorrect: the "codingScheme" value is invalid and must be equal to "305" or "ZSO".

41G Semantic error

Semantic error - the value "Issuer_MarketParticipant.identification" is uncorrect: the value doesn't exist.

41G Semantic error

Semantic error - the value "Issuer_MarketParticipant.marketRole" is invalid and must bee equal to "ZSH" or "ZSY".

41G Semantic error

Semantic error - the value "Recipient_MarketParticipant.identification" is uncorrect: the "codingScheme" value is invalid and must be equal to "305".

41G Semantic error

Semantic error - the value "Recipient_MarketParticipant.identification" is invalid and must be equal to "21X-IT-A-A0A0A-7".

41G Semantic Semantic error - the value "Recipient_MarketParticipant.marketRole" is invalid and must be

of 36


error equal to "ZSO".41G Semantic

errorSemantic error - the value "IdentificationPoint" is uncorrect: the "codingScheme" value is invalid and must be equal to "305" or "ZSO".

41G Semantic error

Semantic error - the value "IdentificationPoint" is uncorrect: the value must be equal to "SCAMBIGAS".

41G Semantic error

Semantic error - the value "MeasureUnit" is invalid and must be equal to "MWZ".

41G Semantic error

Semantic error - the value "NominationType" is invalid and must be equal to "A02".

41G Semantic error

Semantic error - for the offer composed by the key "ExternalAccount - TimeInterval - DirectionCode" the "Internal Account" is uncorrect and must be equal to "issuer_MarketParticipant.identification".

41G Semantic error

Semantic error - for the offer composed by the key "ExternalAccount - TimeInterval - DirectionCode" the value "InternalAccountTso" is uncorrect and must be equal to "21X-IT-A-A0A0A-7".

41G Semantic error

Semantic error - for the offer composed by the key "ExternalAccount - TimeInterval - DirectionCode" the value "codingScheme" for "ExternalAccount" is uncorrect and must be equal to "305" or "ZSO".

41G Semantic error

Semantic error - for the offer composed by the key "ExternalAccount - TimeInterval - DirectionCode" the value "ExternalAccount" doesn't exist.

41G Semantic error

Semantic error - for the offer composed by the key "ExternalAccount - TimeInterval - DirectionCode" the value "TimeInterval" must be within the "ValidityPeriod".

41G Semantic error

Semantic error - for the offer composed by the key "ExternalAccount - TimeInterval - DirectionCode" the value "TimeInterval" must cover all the Gas Day.

41G Semantic error

Semantic error - for the offer composed by the key "ExternalAccount - TimeInterval - DirectionCode" the value "TimeInterval" must be specified in the format "[YYYY-MM-DDThh:mmZ/YYYY-MM-DDThh:mmZ]".

41G Semantic error

Semantic error - for the offer composed by the key "ExternalAccount - TimeInterval - DirectionCode" the value "Direction.code" is uncorrect and must be equal to "Z02" or "Z03".

41G Semantic error

Semantic error - for the offer composed by the key "ExternalAccount - TimeInterval - DirectionCode" the Credit Limit cannot cover the specified quantity amount.

41G Semantic error

Semantic error - for the offer composed by the key "ExternalAccount - TimeInterval - DirectionCode" the "Quantity" cannot be equal to "0" or null.

41G Semantic error

Semantic error - The message received contains at least one semantic error for one or more nominations. However, the nominations that have passed all checks, have been accepted.

41G Semantic error

Syntactical error - The message received contains at least one syntactical error for one or more nominations. However, the nominations that have passed all checks, have been accepted.

Tabella 1 - Elenco Reason Code relativi al messaggio ACKNOW

2.4 Public Message Structure – AS4

In conformità con quanto richiesto dalla Commissione Europea, Snam predisporrà un servizio HTTPS per la comunicazione di Offerte e Transazioni in formato EDIGAS utilizzando il protocollo AS4. Le informazioni che seguono, forniscono le indicazioni per l’implementazione di un sistema che intenda usufruire di tale servizio. Per qualsiasi chiarimento si faccia riferimento al documento disponibile al seguente link:

[ENTS OG] AS4_Usage_Profile.pdf Il protocollo AS4 è un protocollo di comunicazione cross-platform utilizzato per lo scambio sicuro e affidabile di messaggi di business. Per definire il formato ed i parametri del modello AS4 faremo riferimento al PROFILO AS4 secondo le specifiche ENTSOG. Il profilo AS4 ENTSOG si basa sul Profilo AS4 dello standard OASIS Versione 1.0.

of 36

http://www.entsog.eu/public/uploads/files/publications/INT%20Network%20Code/2015/int0488%20131206%20as4%20usage%20profile%20v2r0.pdf


2.4.1 Modello dello scambio messaggi

Le transazioni di scambio dati con i sistemi SNAM saranno di tipo One-Way Push, avverranno tramite notifica asincrona secondo il modello mostrato nell’immagine sottostante.

2.4.2 Formato del messaggio AS4

Figura 2 - ebMS3/AS4 Standard Message

Nota: Wsr e wsrm non sono utilizzati, poiché non richiesti dal protocollo AS4

L’immagine mostra il formato standard di un messaggio AS4.Di seguito andiamo ad illustrare i segmenti ed i campi indicati ed i requisiti per lo scambio dei messaggi.

2.4.2.1 User Message

AS4 definisce la testata SOAP dei messaggi ebMS3, che contiene la struttura XML UserMessage, la quale fornisce metadati necessari per lo scambio dei payload.E’ richiesto un singolo segmento UserMessage all’interno del messaggio AS4 e viene richiesta la configurazione completa dei parametri P-mode inclusi nei segmenti General e BusinessInfo.Si richiede in particolare la valorizzazione del campo MessageId in maniera univoca.

of 36


2.4.2.2 Payload

Si richiede che i payload XML siano convertiti in formato binary e vengano inviati come allegati MIME-part distinti e non nel SOAP Body che dovrà rimanere non valorizzato.

2.4.2.3 Compressione dei Messaggi

Il modello AS4 supporta la compressione dei messaggi XML, a tal proposito:Il parametro PMode[1].PayloadService.CompressionType deve essere valorizzato con application/gzip. (Si noti che GZIP è l’unico formato compresso supportato da AS4).

2.4.3 Configurazione Profilo

Per una chiara comprensione di ciascun campo appartenente all’Envelope AS4, si faccia al paragrafo 2.3 Usage Profile del documento [ENTSOG] A S4_Usage_Profile.pdf (link in alto par.2.3).

In aggiunta a quanto indicato nel documento di cui sopra, si forniscono gli schemi dello User Message Element e del Signal Message Element.

User-Message Element - Schema

Signal Message Element - Schema

of 36


NOTA: I dati identificativi del singolo utente verranno forniti su differente canale.

3 Sicurezza

Questo capitolo fornisce le specifiche relative ai livelli di sicurezza gestisti dal protocollo AS4 nei servizi B2B - EDIGAS di SNAM.

3.1 Transport Layer Security

L’utilizzo del Transport Layer Security (TLS) garantisce uno scambio confidenziale dei messaggi e l’autenticazione reciproca delle controparti coinvolte nello scambio.L’autenticazione del server avviene tramite certificato, che permette al client di verificare il destinatario del messaggio preventivamente.In conformità con le specifiche ENTSOG:

Si nega l’utilizzo di vecchie versioni SSL 2.0 ed SSL 3.0 deprecate.Si sconsiglia l’utilizzo delle versioni TLS 1.0 ed 1.1.Si consiglia l’utilizzo della versione TLS 1.2

Si richiede il supporto alle cipher suite TLSSP pubblicate dallo IANA/IETF.

Per tutti i dettagli si faccia riferimento ai paragrafi 2.6.2.1 e 2.3.4.2 del documento presente al link fornito (paragrafo 2.3).

Si richiede inoltre per compatibilità con l’applicazione TIBCO Business Connect, in uso sui sistemi SNAM, di verificare la compatibilità del certificato con quelli indicati nel seguente documento.

3.2 Message Layer Security

Per garantire la protezione dei messaggi AS4, il profilo richiede l’uso del Web Service Security versione 1.1.1 standard OASIS, profilato in ebMS3 ed AS4:

Web Services Security SOAP Message Security [WSSSMS]. 311

Web Services Security X.509 Certificate Token Profile [WSSX509]. 312

of 36


Web Services Security SOAP Message with Attachments (SwA) Profile [WSSSWA].

Il profilo AS4 richiede l’utilizzo di un certificato X.509 per il criptaggio e la firma dei messaggi.La firma dei messaggi AS4 è definita sullo standard W3C XML Signature recommendation. Il profilo AS4 può essere configurato per l’utilizzo di algoritmi digest e di firma basati su specifici identificativi indicati dallo standard.In particolare, la Versione 1.1 delle specifiche W3C XML fornisce specifici identificativi per algoritmi SHA2.Per queste specifiche AS4, si faccia riferimento ai paragrafi 2.6.2.2 e 2.3.4.3 nel documento presente al link fornito (paragrafo 2.3). Il documento fornisce indicazioni sui requisiti minimi relativi alla scelta dei certificati, in particolare:

Dimensione minima della chiave RSA pubblica di 2048 bit Algoritmo di firma basato su un algoritmo di hashing minimo SHA-256 Periodo di validità minimo raccomandato: 3 anni Il certificato deve essere rilasciato da una Certification Authority che rispetti i requisiti specificati nel [EN

319 411-1]

4 Appendice A: Technical Requirement

4.1 XML Schema File

Si allegano schema XSD e CodeList aggiornate che recepiscono i seguenti valori:

Field Name Code Value Messaggi Edig@s impattati

MeasureUnit MWZ (MWh/d) NOMINT, NOMRES,

Recipient_MarketParticipant.identification ZSO (System Operator) ACKNOW

4.2 Test Book Integration Test

Il Test Book sarà fornito in una seconda fase contestualmente alla Sessione di Certificazione.

of 36

Technical Specification Template · Web viewIntroduzione Al fine di recepire i cambiamenti...

Documents

Transcript of Technical Specification Template · Web viewIntroduzione Al fine di recepire i cambiamenti...