technical specification template · web viewaccording to the evolution of the national and european...

Gloria!Snam – Jarvis Trading

Technical Specification

Author: [Jarvis Trading Team]Date: [2020.02.17]Version: [1.1]

[Jarvis Trading – Technical Specification]

Summary

1 INTRODUCTION................................................................................................................................................ 31.1 Scope................................................................................................................................................................31.2 Purpose of the document................................................................................................................................31.3 References.......................................................................................................................................................31.4 Acronyms.........................................................................................................................................................3

2 BUSINESS TO BUSINESS INTEGRATION..............................................................................................................3Introduction...................................................................................................................................................................32.1 Communication Protocol.................................................................................................................................42.2 Operations details............................................................................................................................................52.3 Edig@s Data Format........................................................................................................................................52.3.1 Structure of Edig@s messages.........................................................................................................................62.3.1.1 NOMINT Message – Nomination sent to Snam by Clients...............................................................................62.3.1.2 NOMRES Message – Assignment Confirmation sent to Clients by SNAM......................................................132.3.1.3 ACKNOW Message – Acknoledgement sent by SRG.......................................................................................222.3.1.3.1 Acknowledgement Reason list...............................................................................................................282.4 Public Message Structure – AS4.....................................................................................................................292.4.1 Message exchange model..............................................................................................................................292.4.2 AS4 message format......................................................................................................................................302.4.2.1 User Message.................................................................................................................................................302.4.2.2 Payload..........................................................................................................................................................302.4.2.3 Messagge Compression..................................................................................................................................302.4.3 Profile Configuration......................................................................................................................................30

3 SECURITY........................................................................................................................................................ 313.1 Transport Layer Security................................................................................................................................323.2 Message Layer Security..................................................................................................................................32

4 APPENDICE A: TECHNICAL REQUIREMENT.......................................................................................................324.1 XML File Scheme............................................................................................................................................324.2 Test Book Integration Test.............................................................................................................................33

of 33


1 Introduction

1.1 Scope

According to the evolution of the national and European Natural Gas market context and in order to meet the EU guidelines on the interoperability of information exchanges between commercial Partners, which require the adoption of common solutions for the exchange of data between the managers of the Transportation systems and their Counterparts, the new Jarvis commercial portal will be equipped with the AS4 Standard with Edig@s format for the management of data exchanges in the context of the Balancing Trading process.Down below the types of exchanges actually identified in the EU:

document-based data exchange: data is collected into files, automatically sent among the involved systems. integration-based data exchange: data is sent directly though integration among the systems.

With this document Snam wants to illustrate the new communication modalities with its Clients interconnected according to Edig@s specifications which follow communications in AS4 Standard.

1.2 Purpose of the document

Purpose of the document is to describe the technological developments introduced on the Jarvis Trading module portal which optimize the communication exchange between the gas market operators, relating to following areas:

Nomination process: introduction of NOMINT and NOMRES messages, to manage ‘Offerte’ and ‘Transazioni’;

Acknowledgement: introduction of ACKNOW message to notify the reception of the NOMINT message or to notify application/semantic errors.

The following paragraphs will illustrate the information fluxes from Jarvis system Trading module to the Customer systems using the UML formalism and will providethe functional specifications of the layouts.In summary, the purposes of the document are:

Describe the main transactions in terms of action sequence, relationships among the messages and the used methods;

provide a clear and consistent functional description of the individual track fields; provide the functional rules for the correct filling of the fields.

1.3 References

Le Edig@s Message Implementation Guidelines, related to every single message, are available here: http://www.edigas.org.

1.4 Acronyms

Terms Description

CLIENTI Consisting of Shipper, Trader, National Carriers, LNG Terminals, Stacker, Market Operators and Clearing House

EIC Energy Identification CodesPSV Virtual Exchange Point

2 Business to Business Integration

Introduction

In order to incorporate the regulatory changes, the Jarvis Integration Layer will be equipped to support Edig@s communications in XML format.

of 33

http://www.edigas.org./


The intervention optimizes and expands the integration and usability capabilities of the system by the Users of the Transport Service (Balancing Users, Storage Companies, Regasification Companies, Foreign and National Transport Companies) through the adoption of commod solutions for data exchange.

The integration Layer which governs the interconnection between Jarvis system and the Partner system, will be equipped with a more flexible architecture in order to meet the needs of different Partners by preparing for: support transport channels such as HTTPS and AS4 support XML data format.

Figure 1: Integration Layer for B2B Communications

The main components of the new integration architecture are: F5 Networks Traffic Manager: ensures application security and reachability through Load Balancer Service Tibco Gateway Server: enables fast and secure transmission of documents and messages. The architecture

provides a server for each type of transport (AS4, HTTPS) Tibco Interior: service request manager Enterprise Service Bus: characterized by private processes that parse and dispatch the requests to the Jarvis

portal

The architecture uses the Secure HTTP communication protocol and the Secure AS4 HTTP protocol in following ways: from Partner System to Jarvis System: HTTPS Communication- from Jarvis System to Partner System: HTTPS Communication -.

Business Applications or Business Partners wishing to interact with the Jarvis platform must acquire the digital certificate of Snam Rete Gas.

2.1 Communication Protocol

The communication protocol for data exchange in Edig@s format will be AS4.

of 33


2.2 Operations details

The details regarding the operations that will be implemented for each partner are provided below:

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 Edig@s Data Format

Exchange of Edig@s XML messages in version 5.1 is foreseen.The communicatio between Snam (Transporter) and the Partner provides for the preparation and exchange of Standard Messages Edig@s according precise paths provided by EASEE (European Association for the Streamlining of Energy Exchange – gas). The intervention involves following transactions:

NOMINT – Nomination Document: message sent to Snam by the Partner; NOMRES – Nomination Response: message sent to the Partner by Snam; ACKNOW – Acknoledgement: message sent to the Partner by Snam.

About data exchange via Edig@s protocol, two areas should be distinguished:

B2B Inbound flows with Partner User systems invoking services exposed by Snam's Jarvis system:

The Business Partner will manage the communication with Snam through HTTPS protocol. Snam will provide the digital certificate necessary to connect to Jarvis system.

The Integration Layer will take care of the decripting and verification of the certificate, the identification of the Partner and the type of request and will parse and dispatch the document through private processes.

B2B Outbound flows with Snam's Jarvis system sending communications to Partner Users' systems:

In this case the Partner will and URL to Snam with that Jarvis system will have to call up for communication and digital certificate to allow HTTPS communication. The integration layer is responsible for the composition of the envelope, encryption and signature of the message, routing of the envelope to the F5 Network which will take care of propagating the message to the Partner system.

All flows have been structured in asynchronous mode, so the system that sends the message does not have to wait for a reply, however this can arrive later or in a non-simultaneous way.

Partner Users have the possibility to send the Offers for purchase or sale generated directly within their company system to the Jarvis system Trading module of Snam using the Edig@s standard where, the reception and management of these messages, involves two key components:

the Integration Layer, that performs syntactic and formal verifications on the received messages; the “Jarvis” Engine, that performs "Business" checks on the content of messages received (identification, points,

type of transit, etc.).After the message verification by the Engine, the system sends a response to the Partner Users, an Edig@s message which contains the result of the checks carried out (accepted or rejected offers, receipt notifications indicating the reasons for the rejection).Below the prospectus of the transactions that will be prepared, in terms of types, versions and releases:

of 33


Process Message Type Content Communication Flow Type

Sending Offer generated in your Company System.

NOMINT 01G Offer for Purchase/Sale Edig@s V5.1 R3 XML Inbound

Sending Transaction generated by the match of two offers

NOMRES 08G Generated Transaction Edig@s V5.1 R3 XML Outbound

Acknowledgement ACKNOW 294 Receipt confirmation of a message and notification of an application error

Edig@s V5.1 R2 XML Outbound

Codifications

The coding of the XML file must be carried out according to the ISO-8859-1 specifications.

General warnings for the filling of the fields

All fields indicated as 'Mandatory' (as indicated below in the functional description tables of the fields) are required for the loading of the message.

Edig@s recommends the use of the UTC (Universal Time Coordinated) standard as the reference time zone for the formulation of dates and times.The date and time fields are expressed in the ISO 8601 format:

YYYY-MM-DDThh:mm:ssZ – format used to express a single date (Es. 2015-12-03T04:00:47Z) YYYY-MM-DDThh:mmZ/ yyyy-mm-ddThh:mmZ – format used to define a time interval (Es.

2015-12-03T04:00Z/2015-12-04T06:00Z)where YYYY represents the year, MM the month, DD the day, hh the hour, mm the minutes and ss the seconds.

2.3.1 Structure of Edig@s messages

2.3.1.1 NOMINT Message – Nomination sent to Snam by Clients

NOMINT Message (Nomination Document) is the way in which Clients communicate their Offers for Purchase and / or Sale to a Counterparty to Snam.The Integration layer will have a new inbound flow for the acquisition of the offers to be sent to the Jarvis Trading module system. The service is designed to manage the following use case through a single path:

- receipt of the Daily Offers in the Jarvis Trading module (including both Offers made for the current Gas Day and the higher one) in the Purchase or in Transfer referring to Gas Days in the interval [G; G + 30], generated in Client's business system;

- receipt of the Multi-day Offers in the Jarvis Trading module in Purchase or in Transfer referring to Gas Days in the interval [G + 1; G + 30], generated in the Client's business system.

- According to current volumes, a NOMINT message is expected containing about 2000 offers.

The Jarvis Trading module system, owner of the creation of the Bilateral Transactions and of the Balances calculation, saves the offers received through specific Edig@s, after checking the Credit Limit for the Counterparty in Sale, the validity of the conditions of access to the PSV of the parties involved and compliance with the system deadlines, generating the Transactions and adjusting the Credit Limit for the Purchasing Counterparty.

of 33


The message information model is shown below:

Figure 1: Edig@s Message Management – Information model NOMINT

In following paragraphs, the details for each section regarding the valorisation expected by Snam are reported.The fields prepared by the layout are subject to:

- syntactic validation carried out by the Integration Layer: the message will be rejected if it isn’t conforming to XML schemes in terms of format of the fields and allowed values. Failure to pass these checks prevents the message from spreading to the Jarvis Trading module platform;

- semantic validation carried out by the Jarvis module Trading system. The rejection of the messages will be notified by the Jarvis Trading module system to the Customers by sending an ACKNOW message, invalidating the entire NOMINT message previously conveyed, discarding all or part of the offers contained therein which, if necessary, must be retransmitted with the appropriate adjustments.

Nomination_Document Section

The first section consists in the header of the message and contains information that uniquely identifies the NOMINT message conveyed, i.e. sender and recipient identified by previously shared code, identification and version of the message, and the period of validity of the offers.Only one occurrence of ‘Nomination_Document’ per message is required. The release attribute must contain the value "3".

Path Section: Nomination_Document Mandatory sect. : YesN. occurences: 1

Field Name Mandatory

Field Format Size

Domain value Notes

Identification Yes string 35 - Message identifier generated by the Sender.See the "naming convention" defined in the following table.

Version Yes integer 3 - Message version having value "1" and increased with each retransmission.Es. <version>1</version>

Type Yes codeList 3 01G (Nomination)

Type of appointment. The only allowed value is "01G".Syntactic validation by xsd scheme is provided.Es. <type>01G</type>

of 33


CreationDateTime Yes dateTime[YYYY-MM-

DDThh:mm:ssZ]

- - Date of creation of the message.Es. <creationDateTime>2015-12-03T04:00:47Z</creationDateTime>

ValidityPeriod Yes string[YYYY-MM-

DDThh:mmZ/ yyyy-mm-

ddThh:mmZ]

- - Indicates the period in which the offers are contained: GG start of period / GG end of period.Es -> :{"validityPeriod ": 2019-02-28T05:00Z/2019-03-08T05:00Z }

ContractReference Yes string 35 - Use default value of "JARVIS_TRADING", otherwise the message will be discarded. Es. <contractReference>JARVIS_TRADING</contractReference>

ContractType No codeList 3 NOT USEDJarvis will not take into account any valorization

Issuer_MarketParticipant.identification Yes string 16 - Identify the Sender. The codingScheme parameter must be filled with "305" for Clients who have an EIC Code and with "ZSO" for Clients who only have an 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 Yes codeList 3 ZSH Only offers sent by Clients are allowed.

Recipient_MarketParticipant.identification Yes string 16 - Snam identifier, "21X-IT-A-A0A0A-7" is the only admissible value. The codingScheme parameter must be filled with "305".Es -> :{"recipient_MarketParticipant.identification codingScheme='305'": 21X-IT-A-A0A0A-7}

codingScheme 3 305 (EIC Code)

Recipient_MarketParticipant.marketRole Yes codeList 3 ZSO (System Operator)

Receiver qualifierShould have "ZSO" value.Es. <recipient_MarketParticipant.marketRole.code>ZSO</recipient_MarketParticipant.marketRole.code>

ApplicationContext No string 16 - NOT USEDJarvis will not take into account any valorization


of 33


Down below the “naming convention” needed for the filling of the “Identification”.

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

Example <identification>NOMINT_TRADING201911040000121Z000000000004A</identification>

Token Descrizione

[EDIG@S_Message] Edig@s message. To be filled with “NOMINT_TRADING”

[GG] Gas Day, have format YYYYMMDD

[IDTRANS] Own identifier from the sending system, identified by 5 digits (XXXXX)

[IDENTIFIER_SENDER] Identifies the unique "EIC Code" for each Partner User or the "IS-U Code".The "IS-U Code" has to be provided only when EIC Code is absent.

ConnectionPointInformation Section

ConnectionPointInformation Section allows the definition of the virtual gas exchange point. This element is required for the validity of the message itself. The message is structured in order to receive a single occurrence of ConnectionPointInformation, through a single NOMINT message.

Path section: Nomination_Document\ConnectionPointInformation

Mandatory sect: Yes N. occurences: 1

Field Name Mandatory Field Format Size Domain value Notes

Identification Yes string 35 - Exchange point identification, the only admissible value is "SCAMBIGAS". The codingScheme should be filled with “ZSO”.Es -> :{"identification codingScheme='ZSO'": SCAMBIGAS }

codingScheme 3 ZSO (IS-U Code)

MeasureUnit Yes codeList 3 MWZ (MWh/d) Unit for measuring gas quantity, only admissible value "MWZ".Es.<measureUnit.code>MWZ</measureUnit.code>.

NominationType Section

NominationType Section allows to discriminate between ConnectionPoints that allow gas convey in one direction (single sided) or in two directions (double sided). Jarvis Trading module will accept the two-way transit typology for the only ConnectionPoint conveyed; the negative outcome of the check will be notified to the Client by an application reject (ACKNOW message).

Path section: Nomination_Document\ConnectionPointInformation\NominationType Mandatory sect: Yes N. occurences: 1


Field Format Size Domain value Notes

Type Yes codeList 3 A02 (Double sided)

Type of transit, the only admissible value is "A02"

of 33


(double side nomination).Es. <type>A02</type>

Account Section

The Account segment reports the Clients involved in the exchange. Since the management of the "Balancing Groups" on the Italian Gas Market is not conceived, the information reported in this section must be consistent with the "Issuer Identification" (Sender) and "Recipient Identification" (Receiver) indicated in the message header.

Path section: Nomination_Document\ConnectionPointInformation\NominationType\Account

Mandatory sect: Yes N. occurences: 1..N

Field Name Mandatory Field Format Size

Domain value

Notes

InternalAccount Yes string 35 Indicates the code of the Customer sender. Valued as "issuer_MarketParticipant.identification". The codingScheme parameter must be filled with "305" for Customers who have an EIC Code and with "ZSO" for Customers who only have IS-U Code.Es -> :{"InternalAccount='305'":26X00000012091-Q}


InternalAccountTso Yes string 16 Indicates the internal TSO (Snam)Valued as “recipient_MarketParticipant.identification”, the only admissible value is "21X-IT-A-A0A0A-7". Parameter codingScheme should be filled with “305”.Es -> :{"recipient_MarketParticipant.identification codingScheme='305'": 21X-IT-A-A0A0A-7}


ExternalAccount Yes string 35 Indicates the customer counterparty to the offer sent.The codingScheme parameter must be filled with "305" for Customers who have an EIC Code and with "ZSO" for Customers who only have an IS-U Code.Es. <externalAccount codingScheme="305">21X9876543211010</externalAccount>


ExternalAccountTso No string 16NOT USEDJarvis will not take into account any valorizationcodingScheme 3 305 (EIC

Code)

Period Section

Period section allows to indicate the quantities of gas exchanged for each Gas Day. The offers can be: Daily: referring to a single Gas Day within the interval [Current Gas Day; Current Gas Day +30]; Multi-day: referring to a continuous array of Gas Days within the range [Current Gas Day + 1; Current Gas Day

+30].

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


Field Name Mandatory Field Format Size Domain value

Notes

TimeInterval Yes String - Indicates the Gas Day of the current offer. In the

of 33


[YYYY-MM-DDThh:mmZ/

yyyy-mm-ddThh:mmZ]

case of a multi-day offer, it indicates the Gas Day contained in the period.Jarvis will carry out a consistency check with respect to the ValidityPeriod, under penalty of rejecting the offer. In particular, the communicated TimeInterval must all be contained in the indicated ValidityPeriod.Es. <timeInterval>2019-04-10T04:00Z/2019-04-11T04:00Z</timeInterval>

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

Specifies the flow direction, only admissible values "Z02","Z03".Logic of the actions: - If Z02 -> Purchase- if Z03 -> SaleEs. <direction.code>Z02 </direction.code>

Quantity.Amount Yes Decimal 17 Quantity of the offer. Unsigned value always referred to the single Gas Day, the maximum length includes the decimal ".".In addition, the maximum number of decimal places accepted is: 3.Es.<quantity.amount>750.100</quantity.amount>

Priority_Status.code No codeList 3 NOT USEDJarvis will not take into account any valorization

Decomposition_Quantity Section

Decomposition_Quantity section allows to distribute the appointment quantities by specifying the type of service (interruptible, non-interruptible, ...). Jarvis Trading module will not take this component into account.

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

Mandatory sect: No N. occurences: 0..N


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

NOT USEDJarvis will not take into account any valorization

Amount No decimal 17 NOT USEDJarvis will not take into account any valorization

Application discard cases

A message will be discarded even if the file is well-formed and valid, but checks carried out by Jarvis system Trading module proves that the layout is not consistent with the specifications shown below:

Offers with “Issuer_MarketParticipant.marketRole” different from “ZSH” (Shipper) Offers that have different unit of measure from “MWZ” (MegaWattora per day) Offers with “NominationType” different from A02 (Double Sided) Offers with “InternalAccount” and “Issuer_MarketParticipant.identification” valued in a different way Offers with “InternalAccountTSO” and “Recipient_MarketParticipant.identification” valued in a different way Offers with “Identication” of “ConnectionPoint“ different from " SCAMBIGAS ".

of 33


Offers with Gas Day incoherent from the ValidityPeriod reported in the head message Offers with a TimeInteval that doesn’t cover all the Gas Day Offers with “Direction.code” different from “Z02” or “Z03” Check on the capacity of the Credit Limit in case of offers in CESSION (if the transferring customer generates an

offer with an economic value greater than its own Credit Limit, the system will discard the offer)

Check on the system deadlines when a NOMINT message arrives

In case of error, Jarvis Trading module prepares itself to manage the partial or total rejection of the volumes nominated for Account\Period.

Under such circumstances, the discarded Account\Period will be reported to the other party by sending an Acknowledgment message with the relative motivation.

Example of a NOMINT Edig@s message containing offers for sale and purchase by the Client vs. other clientsMulti-day offer type<?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><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>

of 33


</ns0:Period></ns0:Account></ns0:NominationType></ns0:ConnectionPoint></ns0:Nomination_Document>

Single-day offer type<?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><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>

of 33


2.3.1.2 NOMRES Message – Assignment Confirmation sent to Clients by SNAM

The NOMRES message (Nomination Response) is sent to Clients by Snam in response to a NOMINT message whenever the match occurs between two complementary offers pertaining to the Client and relating to the creation of a Transaction. The Integration layer will be accompanied by a new outbound flow for the propagation of the message from the Jarvis system Trading module to Client’s corporate system.

The message information model is shown below:

Figure 2: Edig@s Message Management – Information model NOMRES

In following paragraphs, the details for each section are illustrated.

NominationResponse_Document Section

The first section represents the header of the message and contains information that uniquely identifies the message, i.e. sender and recipient identified by previously shared code, identification and version of the message, and the period of validity of the transaction.There is only one occurrence of ‘NominationResponse_Document’ per message. The release attribute will be valued with “3”.

Path section: NominationResponse_Document Mandatory sect: Yes N. occurences: 1


Field Format

Size

Domain value

Notes

Identification Yes string 35 - Message identifier generated by Snam.See the "naming convention" defined in the following tableEs. <ns0:identification>NOMRES_TRADING201904190004217X100A100R03017</ns0:identification>

Version Yes Integer 3 - Message version having value "1" and increased with each retransmission.Es. <version>1</version>

Type Yes codeList 3 08G (Confirmation notice)

Message type, only admissible value “08G” (Confirmation notice)Es. <type>08G</type>

CreationDateTime Yes dateTime - - Creation date of the message.

of 33


[YYYY-MM-

DDThh:mm:ssZ]

Es. creationDateTime>2019-04-19T09:15:06Z</creationDateTime>

ValidityPeriod Yes string[YYYY-MM-

DDThh:mmZ/ yyyy-

mm-ddThh:m

mZ]

- -

Identifies the Gas Day of the matched offer(s).Es. <validityPeriod>2019-04-19T04:00Z/2019-04-20T04:00Z</validityPeriod>

ContractReference Yes string 35 - The default value "JARVIS_TRADING" will be sent.Es.<contractReference>JARVIS_TRADING</contractReference>

ContractType No codeList 3 NOT USEDJarvis will not compile the field

Issuer_MarketParticipant.identification

Yes string 16 - Identifies the Sender's EIC-Code (Snam), compiled with with "21X-IT-A-A0A0A-7". The codingScheme parameter must have value "305".Valued with the code specified in the "Recipient_MarketParticipant.identification" of the source NOMINT.Es -> :{"recipient_MarketParticipant.identification codingScheme='305'": 21X-IT-A-A0A0A-7}

codingScheme

3 305 (EIC Code)

Issuer_MarketParticipant.marketRole

Yes codeList 3 ZSO (System Operator)

Sender qualifier have value "ZSO".Es. <issuer_MarketParticipant.marketRole.code>ZSO</issuer_MarketParticipant.marketRole.code>

Recipient_MarketParticipant.identification

Yes string 16 -

Identifies the Receiver (Customer to whom the Transaction is being communicated). The codingScheme parameter will be valued with "305" for Customers who have an EIC Code and with "ZSO" for Customers who have an IS-U Code.Es <recipient_MarketParticipant.identification codingScheme="305">21X1234567899090</recipient_MarketParticipant.identification>

codingScheme

3 305 (EIC Code)ZSO (System Operator)

Recipient_MarketParticipant.marketRole

Yes codeList 3 ZSH Receiver qualifier. The field will always be valued with "ZSH"Es. <recipient_MarketParticipant.marketRole.code>ZSH</recipient_MarketParticipant.marketRole.code>

ApplicationContext No string 16 -NOT USEDJarvis will not compile the field

codingScheme

3 305 (EIC Code)

Nomination_Document.identification

Yes string 35 - NOMINT ID through which the offer was sent and then matched on Jarvis.If the message NOMINT source does not exist, it is valued with the string "DEFAULT".Es. <Nomination_Document.identification>NOMINT_TRADING2019041900

of 33


00121Z000000000004A</Nomination_Document.identification>

Nomination_Document.version

Yes string 3 - NOMINT version through which the offer was sent and then matched on Jarvis.Es. <nomination_Document.version>1</nomination_Document.version>

Down below the “naming convention” for the compilation of the “Identification” field.

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

Example <identification>NOMRES_trading20190419000121Z000000000004A</identification>

Token Descrizione

[EDIG@S_Message] Edig@s message. Should be filled with “NOMRES_TRADING”

[GG] Gas Day, identified with the format YYYYMMDD

[IDTRANS] Own identifier from the sender system (Snam), identified by 5 digits (XXXXX)

[IDENTIFIER_SENDER] Identifies the "Codice EIC" unique to each Partner User or the "Codice IS-U".The “Codice IS-U” should be used only in absence of the Codice EIC

ConnectionPoint Section

The ConnectionPoint section identifies the virtual gas exchange points. Mandatory valorization of this element is required for the purposes of the validity of the message itself. The message structure is set up to receive a single occurrence of ConnectionPointInformation, through a single NOMRES message.

Path section: NominationResponse_Document\ConnectionPoint




Identification Yes 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 Yes codeList 3 MWZ (MWh/d)

Unità di misura Qtà transazione, valorizzato con MWZ.Es. <measureUnit.code>MWZ</measureUnit.code>

NominationType Section

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

Path section: NominationResponse_Document\ConnectionPoint\NominationType




of 33


Type Yes codeList 3 A02 (Double sided)

Type of transit.Have the value reported in the source NOMINT.Es. <type>A02</type>

Account Section

The Account segment reports the Clients involved in the exchange. Since the management of the "Balancing Groups" on the Italian Gas Market is not conceived, the information reported in this section must be consistent with the "Issuer Identification" (Sender) and "Recipient Identification" (Receiver) indicated in the message header.

Path section: NominationResponse_Document\ConnectionPoint\NominationType\Account

Mandatory sect: Yes

N. occurences: 1..N



InternalAccount Yes string 35 - Indicates the internal TSO Client (Snam), valued with the code present into the "Recipient_MarketParticipant.identification " of the NOMINT source.Es. <internalAccount codingScheme="305">21X1234567899090</internalAccount>


InternalAccountTso No string 16 - Indicates the internal TSO (Snam), having value "21X-IT-A-A0A0A-7 The codingScheme parameter must have value “305”.Es. <internalAccountTso codingScheme="305">21X-IT-A-A0A0A-7 </internalAccountTso>


ExternalAccount No string 35 - Indicates the Client counterparty in the Transaction. Parameter codingScheme must have value “305” for Clients having EIC Code and “ZSO” for Clients who have only the IS-U Code.Es. <externalAccount codingScheme="ZSO">ABC</externalAccount>


ExternalAccountTso No string 16 NOT USEDJarvis will not compile the field


InformationOriginTimeseries Section

The section reports the status of the Transaction quantities. Only the confirmed quantities (Type 16G) will be sent.

of 33


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




Type Yes codeList 3 16G (Confirmed) Type of volumes.Only confirmed volumes (16G) will be sent.Es. <type>16G</type>

Period Section

Period section indicates the quantities of gas exchanged for each Gas Day. The offers offered can be of typology: Daily: referring to a single Gas Day within the interval [Current Gas Day; Current Gas Day +30]; Multi-day: referring to a continuous array of Gas Days within the range [Current Gas Day + 1; Current Gas Day

+30].

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



Field Format Size Domain value

Notes

TimeInterval Yes string[YYYY-MM-

DDThh:mmZ/ yyyy-mm-ddThh:mmZ]

- Indicates the Gas Day of the conveyed transaction. In the case of a multi-day Transaction, it indicates the Gas Day contained in the period.Es. <timeInterval>2019-04-10T04:00Z/2019-04-11T04:00Z</timeInterval>

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

Specifies the direction of flow, the only admissible values are "Z02","Z03".Logic of the actions: - If Z02 -> Purchase- if Z03 -> SaleEs. <direction.code>Z02 </direction.code>

Quantity.Amount Yes decimal 17 Quantity of the offer. Unsigned value always referred to the single Gas Day, the maximum length includes the decimal ".".In addition, the maximum number of decimal places accepted is: 3.Es.<quantity.amount>750.100</quantity.amount>

Decomposition_Quantity Section

Decomposition_Quantity section allows to confirm the apportioned quantities distributed, specifying the type of service (interruptible, non-interruptible, ...). Jarvis will not take this detail into account.

of 33


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

Mandatory sect: No N. occurences: 0..N


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

NOT USEDJarvis will not compile the field

Amount Yes decimal 17 NOT USEDJarvis will not compile the field

Status Section

Status section is mandatory: will be used to convey the generated Transaction code.

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

Mandatory sect: No N. occurences: 1



Reason.code Yes codeList 3 12G (Settled)

Have value "12G" (Settled).Es. <code>12G</code>

Reason.text No string 512 - Compiled with the code of the Transaction conveyed.Es.< text>T-APR01101/19</ text>

of 33


Complete example of a NOMRES Edig@ containing Transactions in assignment and purchase by the Partner User vs. other Partner UsersMulti-day Transaction Type

<?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 33


<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>

Daily Transaction Type

<?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 33


<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>

Figure 3 - NOMRES example – Sending Transactions via Edig@s

2.3.1.3 ACKNOW Message – Acknoledgement sent by SRG

ACKNOW message (Acknoledgement Document) is sent by Snam to Clients and has a dual use: notify the receipt of a "Nomination Document" message on the Jarvis Trading module platform; report an application or semantic error detected during the processing of the message on the Jarvis Trading

module system.In case of errors, Jarvis is expected to send a single ACKNOW message to the counterpart in reference to a specific NOMINT message.

The information model of the message is shown below:

of 33


Figure 4 - Edig@s Message Management – Information model ACKNOW

In following paragraphs, the details for each section are illustrated.

Acknowledgement_Document Section

The first section represents the header of the message and contains information that uniquely identifies the l’acknowledgement i.e., sender and recipient identified by previously shared code, identification and version of the message, and the period of validity of the transaction.There is only one occurrence of ‘Acknowledgement_Document’ per message.

Path section: Acknowledgement_Document Mandatory sect: Yes N. occurences: 1



Identification Yes string 35 - Message identifier generated by Snam.See the "naming convention" defined in the following table

Version No Integer 3 - Message version having value "1" and increased with each retransmission.Es. <version>1</version>

Type Yes codeList 3 294 (Application error and acknowledgement)

Message type. Only admissible value “294’” Es. <type>294</type>

CreationDateTime Yes dateTime[YYYY-MM-

DDThh:mm:ssZ]

- - Creation date of the message. Es.<creationDateTime>2019-04-19T09:15:06Z</creationDateTime>

ValidityPeriod No string[YYYY-MM-

DDThh:mmZ/ yyyy-mm-

ddThh:mmZ]

- - Identifies the validity range received via NOMINT, regardless of any rejections.Es. <validityPeriod>2019-04-19T04:00Z/2019-04-20T054:00Z</validityPeriod>

of 33


ContractReference No string 35 - NOT USEDJarvis will not compile the field

ContractType No codeList 3 NOT USEDJarvis will not compile the field

Issuer_MarketParticipant.identification Yes string 16 - Identifies the Sender’s l’EIC-Code (SRG), having value "21X-IT-A-A0A0A-7".Valued with the code specified in the "Recipient_MarketParticipant.identification " of the NOMINT source.Es.<issuer_MarketParticipant.identification codingScheme="305">21X-IT-A-A0A0A-7 </issuer_MarketParticipant.identification>


Issuer_MarketParticipant.marketRole.code Yes codeList 3 ZSO (System Operator)

Sender qualifier have always value “ZSO”.Es.<issuer_MarketParticipant.marketRole.code>ZSO</issuer_MarketParticipant.marketRole.code>

Recipient_MarketParticipant.identification Yes string 16 - Identifies the Receiver. Parameter codingScheme will have value “305” for the Clients having an EIC Code and with “ZSO” for Clients having IS-U Code.Valued with the code specified in the "Issuer_MarketParticipant.identification " of the NOMINT source.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 Receiver Qualifier. Field will have value “ZSH” in response to a NOMINTEs.<recipient_MarketParticipant.marketRole.code>ZSO</recipient_MarketParticipant.marketRole.code>

ApplicationContext No string 16 - NOT USEDJarvis will not compile the codingScheme 3 305 (EIC Code)

of 33


fieldReceiving_Document.identification No string 35 - Identifier of the received

NOMINT message for which a notification has to be sent. Es.<receiving_Document.identification>NOMINT_TRADING201904190000121Z000000000004A </receiving_Document.identification>

Receiving_Document.version No string 3 - Version of the received NOMINT message for which a notification has to be sent.Es.<receiving_Document.version>1</receiving_Document.version>

Receiving_Document.type No string 3 - NOT USEDJarvis will not compile the field

Receiving_Document.creationDateTime No dateTime[YYYY-MM-

DDThh:mm:ssZ]

- NOT USEDJarvis will not compile the field

Receiving_Document.payloadName No string 150

- NOT USEDJarvis will not compile the field

Down below the “naming convention” for the compilation of the “Identification” field.

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

Example <identification>ACKNOW_trading201904190000121Z000000000004A</identification>

Token Descrizione

[EDIG@S_Message] Edig@s message. Should be filled with “ACKNOW”

[GG] Gas Day, identified with the format YYYYMMDD

[IDTRANS] Own identifier from the sender system (Snam), identified by 5 digits (XXXXX)

[IDENTIFIER_SENDER] Identifies the "Codice EIC" unique for each UdB or the "Codice IS-U".The “Codice IS-U” should be used only in absence of the Codice EIC

Reason Section

Reason section provides textual information that allows to detail the type of notification (processing and saving of all offers contained in the message of NOMINT or the rejection of the full NOMINT message). This component is mandatory and a message is sent with only one occurrence of the section ‘Reason’.

Path section: Acknowledgement_Document\Reason Mandatory sect: Yes N. occurences: 1


Code Yes codeList 3 List of codes Reason Code notification.

of 33


shown in the paragraph 2.3.1.3.1 - Acknow

Es. <code>01G</code>

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

Rejection_ConnectionPoint Section

Rejection_ConnectionPoint section can be used in case of partial rejection, to clarify the detail of the offer rejected by the Jarvis system (Trading module).

Path section: Acknowledgement_Document\Rejection_ConnectionPoint Mandatory sect.: No N. occurences: 0..1


Identification Yes string 35 - Exchange point identifier, has value "SCAMBIGAS". Parameter codingScheme must have value “ZSO”.Es -> :{"identification codingScheme='ZSO'": SCAMBIGAS

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

Reason Section

Reason section specific of the Rejection_ConnectionPoint component, it provides textual information that allows to detail the reasons of the rejection.

Path section: Acknowledgement_Document\Rejection_ConnectionPoint\Reason Mandatory sect: No N. occurences: 1..N


Code Yes codeList 3 Codes list shown in paragraph 2.3.1.3.1 - Acknow

Reason Code notification.Es. <code>01G</code>

Text Yes string 512 - Notification description.The logical key that identifies the offer will be specified in the text. It consists of:"ExternalAccount" (indicates the Counterparty to the offer) - TimeInterval (indicates the Gas Day of the offer) - Direction.code (indicates the Buy / Sell Action).Es. <text>The message has been processed and

of 33


accepted</text>

Complete example of an acknowledgement Edig@s – notification of the receiving messages without discards<?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>

Complete example of an acknowledgement Edig@s – notification of the receiving messages with partial discards<?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><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>

of 33


<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>

Figure 5 – ACKNOW Example – Reception Notification of NOMINT messages with partial discards

2.3.1.3.1 Acknowledgement Reason list

Down below the reasons conceived by the Jarvis Trading Module system.

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 error

Semantic error - the value "Recipient_MarketParticipant.marketRole" is invalid and must be equal to "ZSO".

41G Semantic error

Semantic 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-

of 33


A0A0A-7".41G Semantic

errorSemantic 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.

Table 1 - Reason Code List related to ACKNOW messages

2.4 Public Message Structure – AS4

According to the requirements of the European Commission, Snam will prepare an HTTPS service for the communication of Offers and Transactions in Edog@s format using the AS4 protocol. The following information provides indications for the implementation of a system that intends to use this service. For any clarification, refer to the document available at the following link:

[ENTSOG] AS4_Usage_Profile.pdf The AS4 protocol is a cross-platform communication protocol used for the safe and reliable exchange of business messages. To define the format and parameters of the AS4 model, we will refer to the AS4 PROFILE according to the ENTSOG specifications. The AS4 ENTSOG profile is based on the AS4 profile of the OASIS Version 1.0 standard.

2.4.1 Message exchange model

Data exchange transactions with SNAM systems will be One-Way Push and will take place through asynchronous notification according to the model shown in the image below.

of 33

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


2.4.2 AS4 message format

Figure 2 - ebMS3/AS4 Standard Message

Nota: Wsr e wsrm are not used, since not required from protcol AS4

The image shows the standard format of an AS4 message.Below we illustrate the segments and fields indicated and the requirements for the exchange of messages.

2.4.2.1 User Message

AS4 defines the SOAP header of ebMS3 messages, which contains the XML UserMessage structure, which provides metadata necessary for the exchange of payloads.A single UserMessage segment is required within the AS4 message and the complete configuration of the P-mode parameters included in the General and BusinessInfo segments is required.In particular, the MessageId field should be uniquely compiled.

of 33


2.4.2.2 Payload

XML payloads are required to be converted into binary format and sent as separate MIME-part attachments and not in the SOAP Body, which must remain unchanged.

2.4.2.3 Messagge Compression

The AS4 model supports the compression of XML messages, about that:Parameter PMode[1].PayloadService.CompressionType should be filled with application/gzip. (Note that GZIP is the only compressed format supported by AS4).

2.4.3 Profile Configuration

For a clear understanding of each field belonging to the Envelope AS4, please refer to paragraph 2.3 Usage Profile of the document [ENTSOG] A S4_Usage_Profile.pdf (link in par.2.3).

In addition to what indicated in the document above, the User Message Element and Signal Message Element schemes are provided.

User-Message Element - Scheme

Signal Message Element - Scheme

of 33


NOTA: The identification data of the individual user will be provided on different channels.

3 Security

This chapter provides the specifications related to the security levels managed by the AS4 protocol in SNAM's B2B - EDIGAS services.

3.1 Transport Layer Security

The use of Transport Layer Security (TLS) guarantees a confidential exchange of messages and mutual authentication of the counterparties involved in the exchange.Server authentication takes place via certificate, which allows the client to verify the recipient of the message in advance.According to the ENTSOG specifications:

The use of old deprecated SSL 2.0 and SSL 3.0 versions is denied.The use of TLS versions 1.0 and 1.1 is not recommended.We recommend the use of the TLS 1.2 version

Support is required for TLSSP cipher suites published by the IANA / IETF.

For all details, refer to paragraphs 2.6.2.1 and 2.3.4.2 of the below document at the link provided (paragraph 2.3).

For compatibility with the TIBCO Business Connect application, used on SNAM systems, it is also required to check the compatibility of the certificate with those indicated in the following document.

3.2 Message Layer Security

To ensure the protection of AS4 messages, the profile requires the use of Web Service Security version 1.1.1 OASIS standard, profiled in ebMS3 and AS4:

Web Services Security SOAP Message Security [WSSSMS]. 311

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

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

of 33


The AS4 profile requires the use of an X.509 certificate for the encryption and signing of messages.The signature of AS4 messages is defined on the W3C XML Signature recommendation standard.The AS4 profile can be configured to use digest and signature algorithms based on specific identifiers indicated by the standard.In particular, Version 1.1 of the W3C XML specifications provides specific identifiers for SHA2 algorithms.For these AS4 specifications, refer to paragraphs 2.6.2.2 and 2.3.4.3 in the document present at the link provided (paragraph 2.3).The document provides information on the minimum requirements relating to the choice of certificates, in particular:

Minimum public RSA key size of 2048 bits Signature algorithm based on a minimum hashing algorithm SHA-256 Minimum Recommended validity: 3 years The certificate must be given by a Certification Authority that meets the requirements specified in [EN

319 411-1]

4 Appendice A: Technical Requirement

4.1 XML File Scheme

The attached updated XSD schema and CodeList which incorporate the following values:

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

The Test Book will be provided in a second phase at the same time as the Certification Session.

of 33

technical specification template · web viewaccording to the evolution of the national and european...

Documents