IEC TS 62325-504:2015

IEC TS 62325-504 ®
Edition 1.0 2015-05
TECHNICAL
SPECIFICATION
colour
inside
Framework for energy market communications –
Part 504: Utilization of web services for electronic data interchanges on the
European energy market for electricity
All rights reserved. Unless otherwise specified, no part of this publication may be reproduced or utilized in any form
or by any means, electronic or mechanical, including photocopying and microfilm, without permission in writing from
either IEC or IEC's member National Committee in the country of the requester. If you have any questions about IEC
copyright or have an enquiry about obtaining additional rights to this publication, please contact the address below or
your local IEC member National Committee for further information.

IEC Central Office Tel.: +41 22 919 02 11
3, rue de Varembé Fax: +41 22 919 03 00
CH-1211 Geneva 20 info@iec.ch
Switzerland www.iec.ch
About the IEC
The International Electrotechnical Commission (IEC) is the leading global organization that prepares and publishes
International Standards for all electrical, electronic and related technologies.

About IEC publications
The technical content of IEC publications is kept under constant review by the IEC. Please make sure that you have the
latest edition, a corrigenda or an amendment might have been published.

IEC Catalogue - webstore.iec.ch/catalogue Electropedia - www.electropedia.org
The stand-alone application for consulting the entire The world's leading online dictionary of electronic and
bibliographical information on IEC International Standards, electrical terms containing more than 30 000 terms and
Technical Specifications, Technical Reports and other definitions in English and French, with equivalent terms in 15
documents. Available for PC, Mac OS, Android Tablets and additional languages. Also known as the International
iPad. Electrotechnical Vocabulary (IEV) online.

IEC publications search - www.iec.ch/searchpub IEC Glossary - std.iec.ch/glossary
The advanced search enables to find IEC publications by a More than 60 000 electrotechnical terminology entries in
variety of criteria (reference number, text, technical English and French extracted from the Terms and Definitions
committee,…). It also gives information on projects, replaced clause of IEC publications issued since 2002. Some entries
and withdrawn publications. have been collected from earlier publications of IEC TC 37,

77, 86 and CISPR.
IEC Just Published - webstore.iec.ch/justpublished

Stay up to date on all new IEC publications. Just Published IEC Customer Service Centre - webstore.iec.ch/csc
details all new publications released. Available online and If you wish to give us your feedback on this publication or
also once a month by email. need further assistance, please contact the Customer Service
Centre: csc@iec.ch.
IEC TS 62325-504 ®
Edition 1.0 2015-05
TECHNICAL
SPECIFICATION
colour
inside
Framework for energy market communications –

Part 504: Utilization of web services for electronic data interchanges on the

European energy market for electricity

INTERNATIONAL
ELECTROTECHNICAL
COMMISSION
ICS 33.200 ISBN 978-2-8322-2694-0

– 2 – IEC TS 62325-504:2015 © IEC 2015
CONTENTS
FOREWORD . 4
1 Scope . 6
2 Normative references . 6
3 Terms, definitions and namespaces . 7
3.1 Terms and definitions . 7
3.2 Namespaces . 8
4 Conformance . 8
4.1 General . 8
4.2 Client application conformance . 8
4.3 Server conformance . 9
5 Service definitions . 9
5.1 List messages . 9
5.1.1 General . 9
5.1.2 Service Request . 10
5.1.3 Service Response . 11
5.1.4 Functional requirements . 12
5.2 Get Message . 12
5.2.1 General . 12
5.2.2 Service Request . 12
5.2.3 Service Response . 12
5.2.4 Functional requirements . 12
5.3 Put Message . 13
5.3.1 General . 13
5.3.2 Service Request . 13
5.3.3 Service Response . 13
5.3.4 Functional requirements . 13
5.4 Query Data . 14
5.4.1 General . 14
5.4.2 Service Request . 14
5.4.3 Service Response . 14
5.4.4 Functional requirements . 14
6 Applying IEC 61968-100 . 15
6.1 Integration Pattern . 15
6.1.1 General . 15
6.1.2 List Service. 16
6.1.3 Get Service . 16
6.1.4 Put Service . 16
6.2 Service mapping . 17
6.2.1 General . 17
6.2.2 Header values . 17
6.2.3 Request values . 18
6.2.4 Response values . 18
6.2.5 Payload values . 18
7 Schema definitions . 18
7.1 Common definitions . 18
7.2 List message . 19

7.3 QueryData message . 20
7.4 QueryData List of data types . 21
8 Service Provider WSDL abstract definitions . 21
9 Service Provider WSDL SOAP binding . 22
10 Security . 23
Annex A (normative) XML schema for common IEC 62325-504 messages . 25
Annex B (informative) Message examples . 27
B.1 List . 27
B.1.1 Basic example – Request . 27
B.1.2 Basic example – Response: . 27
B.2 Get . 29
B.2.1 General . 29
B.2.2 Basic example . 29
B.3 Put . 32
B.3.1 Basic example . 32
B.3.2 Example with binary data . 33
B.4 Query Data . 34
B.4.1 List of data types example . 34
B.4.2 Server Timestamp Request example. 35
B.4.3 Server Parameter Limits Request example . 36
B.4.4 Generic Query example . 37
B.5 Fault . 38
B.5.1 SOAP 1.2 . 38
B.5.2 SOAP 1.1 . 39
B.6 Digital signature . 39
B.6.1 Basic example . 39
Annex C (informative) Java code examples . 42
C.1 Sign . 42
C.2 Verify . 43
Annex D (informative) Regarding near real-time communications . 44
Annex E (informative) Regarding clients and servers configurations . 45

Figure 1 – List Service Sequence Diagram . 16
Figure 2 – Get Service Sequence Diagram . 16
Figure 3 – Put Service Sequence Diagram . 17
Figure 4 – MessageList schema structure . 20
Figure 5 – QueryData schema structure . 21
Figure 6 – ParameterList schema structure . 21
Figure 7 – WSDL structure . 23
Figure B.1 – List and Get Sequence Diagram . 29

– 4 – IEC TS 62325-504:2015 © IEC 2015
INTERNATIONAL ELECTROTECHNICAL COMMISSION
____________
FRAMEWORK FOR ENERGY MARKET COMMUNICATIONS –

Part 504: Utilization of web services for
electronic data interchanges on the European
energy market for electricity
FOREWORD
1) The International Electrotechnical Commission (IEC) is a worldwide organization for standardization comprising
all national electrotechnical committees (IEC National Committees). The object of IEC is to promote
international co-operation on all questions concerning standardization in the electrical and electronic fields. To
this end and in addition to other activities, IEC publishes International Standards, Technical Specifications,
Technical Reports, Publicly Available Specifications (PAS) and Guides (hereafter referred to as “IEC
Publication(s)”). Their preparation is entrusted to technical committees; any IEC National Committee interested
in the subject dealt with may participate in this preparatory work. International, governmental and non-
governmental organizations liaising with the IEC also participate in this preparation. IEC collaborates closely
with the International Organization for Standardization (ISO) in accordance with conditions determined by
agreement between the two organizations.
2) The formal decisions or agreements of IEC on technical matters express, as nearly as possible, an international
consensus of opinion on the relevant subjects since each technical committee has representation from all
interested IEC National Committees.
3) IEC Publications have the form of recommendations for international use and are accepted by IEC National
Committees in that sense. While all reasonable efforts are made to ensure that the technical content of IEC
Publications is accurate, IEC cannot be held responsible for the way in which they are used or for any
misinterpretation by any end user.
4) In order to promote international uniformity, IEC National Committees undertake to apply IEC Publications
transparently to the maximum extent possible in their national and regional publications. Any divergence
between any IEC Publication and the corresponding national or regional publication shall be clearly indicated in
the latter.
5) IEC itself does not provide any attestation of conformity. Independent certification bodies provide conformity
assessment services and, in some areas, access to IEC marks of conformity. IEC is not responsible for any
services carried out by independent certification bodies.
6) All users should ensure that they have the latest edition of this publication.
7) No liability shall attach to IEC or its directors, employees, servants or agents including individual experts and
members of its technical committees and IEC National Committees for any personal injury, property damage or
other damage of any nature whatsoever, whether direct or indirect, or for costs (including legal fees) and
expenses arising out of the publication, use of, or reliance upon, this IEC Publication or any other IEC
Publications.
8) Attention is drawn to the Normative references cited in this publication. Use of the referenced publications is
indispensable for the correct application of this publication.
9) Attention is drawn to the possibility that some of the elements of this IEC Publication may be the subject of
patent rights. IEC shall not be held responsible for identifying any or all such patent rights.
The main task of IEC technical committees is to prepare International Standards. In
exceptional circumstances, a technical committee may propose the publication of a technical
specification when:
• the required support cannot be obtained for the publication of an International Standard,
despite repeated efforts, or
• the subject is still under technical development or where, for any other reason, there is the
future but no immediate possibility of an agreement on an International Standard.
Technical specifications are subject to review within three years of publication to decide
whether they can be transformed into International Standards.
IEC 62325-504, which is a technical specification, has been prepared by IEC technical
committee 57: Power systems management and associated information exchange.

The text of this technical specification is based on the following documents:
Enquiry draft Report on voting
57/1520/DTS 57/1567/RVC
Full information on the voting for the approval of this technical specification can be found in
the report on voting indicated in the above table.
This publication has been drafted in accordance with the ISO/IEC Directives, Part 2.
A list of all parts in the IEC 62325 series, published under the general title Framework for
energy market communications, can be found on the IEC website.
The committee has decided that the contents of this publication will remain unchanged until
the stability date indicated on the IEC website under "http://webstore.iec.ch" in the data
related to the specific publication. At this date, the publication will be
• transformed into an International standard,
• reconfirmed,
• withdrawn,
• replaced by a revised edition, or
• amended.
A bilingual version of this publication may be issued at a later date.

IMPORTANT – The 'colour inside' logo on the cover page of this publication indicates
that it contains colours which are considered to be useful for the correct
understanding of its contents. Users should therefore print this document using a
colour printer.
– 6 – IEC TS 62325-504:2015 © IEC 2015
FRAMEWORK FOR ENERGY MARKET COMMUNICATIONS –

Part 504: Utilization of web services for
electronic data interchanges on the European
energy market for electricity
1 Scope
This part of IEC 62325, which is a technical specification, defines the services needed to
support the electronic data interchanges between different actors on the European Energy
Market for Electricity (EME) in a fast (near-realtime), and secure way. At the same time, this
Technical Specification can also be applied to integration problems outside the scope of
IEC 62325-451, such as to the integration of gas market systems or general enterprise
integration.
Web Services (in WSDL) will be specified for the defined services, applying the Basic Web
Service Pattern implementation profile from IEC 61968-100.
The services needed to support the electronic data interchange on the European energy
market for electricity are:
• List Messages. This service is used by a client application identified with the credentials of
an EME Actor to request a list of messages available on the server for retrieval.
• Get Message. This service is used by a client application identified with the credentials of
an EME Actor to request a specific message available on the server.
• Put Message. This service is used by a client application to send a message, usually
providing data related to a Market Participant in the energy market for electricity, to the
server for processing.
2 Normative references
The following documents, in whole or in part, are normatively referenced in this document and
are indispensable for its application. For dated references, only the edition cited applies. For
undated references, the latest edition of the referenced document (including any
amendments) applies.
IEC 61968-100, Application integration at electric utilities – System interfaces for distribution
management – Part 100: Implementation profiles
IEC 62325-451-1, Framework for energy market communications – Part 451-1:
Acknowledgement business process and contextual model for CIM European market
ISO/IEC 40210, Information technology – W3C SOAP Version 1.2 Part 1: Messaging
Framework (Second Edition)
WSDL, Web Services Description Language (WSDL) 1.1
XML Schema 1.0, XML Schema Language Part 1: Structure, W3C Recommendation 28
October 2004; XML Schema Language Part 2: Data Types, W3C Recommendation 28
October 2004
XML Signature Syntax and Processing (Second Edition) http://www.w3.org/TR/xmldsig-core

RFC 6176, Prohibiting SSL 2.0 http://tools.ietf.org/html/rfc6176
RFC 5280, Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List
(CRL) Profile http://tools.ietf.org/rfc/rfc5280
RFC 6818, Updates to the Internet X.509 Public Key Infrastructure Certificate and Certificate
Revocation List (CRL) Profile http://tools.ietf.org/rfc/rfc6818
RFC 4346, The Transport Layer Security (TLS) Protocol V1.1 http://www.ietf.org/rfc/rfc4346
3 Terms, definitions and namespaces
For the purposes of this document, the following terms and definitions apply.
3.1 Terms and definitions
3.1.1
message identification
alphanumeric string that represents the name of a message in the system
3.1.2
version
number that represents the message version
Note 1 to entry: The range of values is from 1 to 999.
3.1.3
application time interval
time interval when the message payload applies
3.1.4
server timestamp
date when the message is received by the server (input messages) or when it is made
available by the server (output messages).
3.1.5
message type
type of the message payload as defined in IEC 62325-451-n (Schedule_MarketDocument,
Acknowledgement_MarketDocument, etc.)
Note 1 to entry: As a general rule the message type is the local name of xml root element.
3.1.6
message code
number identifying a message in the server in a unique way
Note 1 to entry: For a given pair of message codes “x” and “y”, if “y” > “x” then “y” is a newer message. If “y” < “x”
then “y” is an older message. Finally if “y” = “x”, then both messages are the same.
3.1.7
data owner
person or entity that is responsible for the information contained in the message (payload)
Note 1 to entry: Usually corresponds with the sender_MarketParticipant.mRID field in the IEC 62325-451-n series.
3.1.8
data provider
person or entity that is responsible for establishing a connection with the server and sending
the message (payload)
– 8 – IEC TS 62325-504:2015 © IEC 2015
3.1.9
M/O/C
Mandatory / Optional / Choice (choose one)
Note 1 to entry: Cn indicates “Choice n” and if several optional attributes have the same number “n” in Cn, it
means all of them shall be present if this is the selected choice.
3.1.10
status
indication of the acceptance or validity of a message as per 61968-100
Note 1 to entry: The status of messages without Acknowledgement (publication or incoming message still being
processed) will be “OK”.
Note 2 to entry: In exchanges where IEC 62325-451-1 applies, the “fully accepted reason code” is associated with
a status “OK”. The rest of the reason codes are associated with “FAILED”.
3.2 Namespaces
This Technical Specification uses these prefixes and namespaces (see XML Schema 1.0
Parts 1 and 2):
a) cmsg (urn:iec62325.504:messages:1:0): The target namespace of the messages defined
in this Technical Specification.
b) wss (urn:iec62325.504:wss:1:0): The WSDL target namespace for this Technical
Specification.
This Technical Specification refers to these other prefixes and namespaces:
a) wsdl (http://schemas.xmlsoap.org/wsdl): This contains the W3C WSDL 1.1 schema.
b) xs (http://www.w3.org/2001/XMLSchema): This contains the W3C XML Schema definition.
c) soap (http://schemas.xmlsoap.org/wsdl/soap): This contains the W3C SOAP bindings for
WSDL 1.1.
d) soap12 (http://schemas.xmlsoap.org/wsdl/soap12): This contains the W3C SOAP bindings
for WSDL 1.2 (see ISO/IEC 40210).
e) ds (http://www.w3.org/2000/09/xmldsig#): This contains the XML Digital Signature Schema
nd
definitions (see XML Signature Syntax and Processing 2 Edition).
f) msg (http://www.iec.ch/TC57/2008/schema/message): This contains the IEC 61968-100
schema definitions.
4 Conformance
4.1 General
This clause specifies the conformance requirements for a client application and a server to
conform to this Technical Specification.
4.2 Client application conformance
In order to conform to this Technical Specification a client application shall:
a) Support the following services as a client:
• List Messages and all of the mandatory aspects of this service as specified in Clause 5
• Get Message and all of the mandatory aspects of this service as specified in Clause 5
• Put Message and all of the mandatory aspects of this service as specified in Clause 5.
b) Send and receive XML Instance documents according to the XML Schema specified in
Clause 7 in this Technical Specification for the services listed in a).
c) Use the WSDL definitions, SOAP bindings, and operations specified in Clauses 8 and 9.

d) Be able to access the server via HTTPS, using a client digital certificate recognized by the
server for the purposes of establishing the https communication and creating the digital
signature as specified in Clause 10.
4.3 Server conformance
In order to conform to this Technical Specification a server shall:
a) Support the following services as a server:
• List Messages and all of the mandatory aspects of this service as specified in Clause 5
• Get Message and all of the mandatory aspects of this service as specified in Clause 5
• Put Message and all of the mandatory aspects of this service as specified in Clause 5.
b) Send and receive XML Instance documents according to the XML Schema specified in
Clause 7 in this Technical Specification for the services listed in a).
c) Use the WSDL definitions, SOAP bindings, and operations specified in Clauses 8 and 9.
d) Provide access to the server via HTTPS, and be able to asses that the client digital
certificate is valid and that the digital signature as specified in Clause 10 is correct.
5 Service definitions
5.1 List messages
5.1.1 General
The List Messages service is used to obtain a list of available messages for the client
according to a given filter (parameters).
The main filter shall be one of the following:
• Application Date of the returned messages
• Server Timestamp of the returned messages
• internal numerical Code of the returned messages
Additional optional filters include:
• Message Identification
• Message Type
• Data Owner
The returned list of messages shall comply with the main filter selected and also with all the
optional filters requested, and shall include the following information related to each message:
• Internal numerical code representing the message in the server
• Message Identification
• Message Version
• Status
• Application Time Interval
• Server Timestamp
• Message Type
• Data Owner
– 10 – IEC TS 62325-504:2015 © IEC 2015
5.1.2 Service Request
Parameter Name Type M/O/C Description
StartTime dateTime C1 Specifies that the list of messages returned
shall only include messages whose end of
their Application TimeInterval (Document
TimeInterval) or Server Timestamp comes
after the provided date.
EndTime dateTime C1 Specifies that the list of messages returned
shall only include messages whose start of
their Application TimeInterval or
ServerTimestamp (when the message was
received or published in the server) comes
before the provided date.
IntervalType String C1 Indicates whether the StartTime and
EndTime refer to Application TimeInterval or
to Server Timestamp. Permitted values:
“Application” (default), “Server”.
Code number C2 Specifies that the list of messages returned
shall only include messages with an internal
identification number higher than the
provided code. This means that the list will
contain messages that are newer to the given
one.
For optimization purposes, if this filter is
used, only messages available since the
00.00 of D-1 (day before) are guaranteed to
be included in the response list.
MessageIdentification string O Specifies that the list of messages returned
shall only include messages whose Message
Identification is compliant with the pattern
provided in this parameter. (“*” can be used
as a wildcard).
MsgType string O Specifies that the list of messages returned
shall only include messages of the provided
type.
Owner string O Specifies that the list of messages returned
shall only include messages belonging to the
provided Owner.
5.1.3 Service Response
If there is no message according to the provided filters, the service shall return an empty list.
Otherwise, a list of message descriptors will be returned. Each message descriptor shall
include the following parameters:
Parameter Name Type M/O/C Description
Code Position Type M Specifies the internal identification
(number) number of the message
MessageIdentification Identification Type M Specifies the Message Identification.
(string) Messages defined in IEC 62325 Part
451-X series include this information.
For additional messages not included in
that standard, the server shall have a
way of assigning a
MessageIdentification to those
messages.
MessageVersion VersionType O Specifies the Message Version.
Messages defined in IEC 62325 Part
451-X series include this information.
For additional messages not included in
that standard, the server may have a
way of assigning a Message Version to
those messages.
Status String O Specifies the status of messages.
Corresponds with the main reason code
of the Acknowledgement message
associated with this message as per IEC
62325-451-1. Possible values are: OK,
FAILED. The status value “OK”
corresponds with the IEC 62325-451-1
ReasonCode “A01”, and the status value
“FAILED” corresponds with the rest of
ReasonCodes.
ApplicationTimeInterval.Start dateTime M Specifies the start of the message
Application Time Interval. Messages
defined in IEC 62325 Part 451-X series
include this information. For additional
messages not included in that standard,
the server shall have a way of assigning
an Application TimeInterval to those
messages.
ApplicationTimeInterval.End dateTime O Specifies the end of the message
Application Time Interval. Messages
defined in IEC 62325 Part 451-X series
include this information. For additional
messages not included in that standard,
the server shall have a way of assigning
an Application TimeInterval to those
messages.
When this information is missing, the
message Application Time Interval is
“from ApplicationTimeIntervalStart on”
without an explicit end.
ServerTimestamp MessageDateTime M Specifies the server timestamp (when
Type the message was received or published
in the server) of the message.
Type LongIdentification M Specifies the Message Type (see Terms
Type (string) and definitions).
Owner LongIdentification M Specifies the Data Owner of the
Type (string) message.
– 12 – IEC TS 62325-504:2015 © IEC 2015
5.1.4 Functional requirements
Confidentiality rules of the European energy market for electricity shall be observed, thus the
list of messages available to a client will only include those messages to which he/she is
entitled (either completely or partially).
A client shall be able to see all his available previously submitted messages to the server,
their responses sent from the server (acknowledgements), and any publications that are
available to the client.
When the service is called with an invalid filter (e.g. malformed application dates) a Fault
message shall be returned.
5.2 Get Message
5.2.1 General
The Get Messages service is used to obtain the message associated to the given parameter
(filter).
The filter shall be one of the following:
• Message identification and version
• Message code
• Queue indication
5.2.2 Service Request
Parameter Name Type M/O/C Description
MessageIdentification Identification Type C1 Specifies the Message Identification of the
(string) requested message.
MessageVersion VersionType C1O Specifies the Message Version of the
requested message. If more than one
message in the server have the same
MessageIdentification and MessageVersion,
the most recent one will be returned. If the
requested message has no version this
parameter is optional.
Code Position Type C2 Specifies the internal identification number
(number) of the requested message.
Queue String C3 Indicates that the server will decide which
message will be returned. Its value shall be
“NEXT”.
5.2.3 Service Response
Parameter Name Type M/O/C Description
[First child of Payload] 1 C1 The XML message that is being returned to the client.
Any
BinaryContent Base64Binary C2 Optionally binary content may also be returned
depending on the type of the requested message.
BinaryName String C2 Optionally, the name of the requested binary file.

5.2.4 Functional requirements
Only one message will be retrieved for each Get Message service invocation.
_______________
Any: any document with any namespace.

A client shall be able to retrieve all his available previously submitted messages to the server,
their responses sent from the server (acknowledgements), and any publications that are
available to the client.
Servers are entitled to filter parts of the retrieved xml message for confidentiality reasons,
when that message, which is available for retrieval, includes information that should not be
available to the client.
If the retrieved message is a binary File, then the content is expressed as base 64 encoded
wrapped by the tag “BinaryContent”.
When the service is called with an invalid message (e.g. missing or invalid code) a Fault
message will be returned.
If a user requests a message to which he/she is not entitled, the system will return a Fault
message as if he/she had requested a non-existing message.
The Queue parameter can be used when the server keeps an ordered list of messages for
each client to retrieve. A server not supporting this feature will return a fault message.
5.3 Put Message
5.3.1 General
The Put Message service is used to send a message to the server for further processing
following the rules of the European energy markets for electricity.
A series of standard XML messages related to the European energy market for electricity are
defined in the IEC 62325-451-n series, but this Technical Specification allows servers to
process additional XML messages not defined in said series.
Optionally, binary files may also be sent, if supported by the server.
5.3.2 Service Request
Parameter Name Type M/O/C Description
[First child of Payload] 2 C1 The XML message that is being sent to the server.
Any
BinaryContent Base64Binary C2 Optionally binary content may also be sent to the server.
BinaryName String C2 Optionally, the name of the binary file sent to the server.

5.3.3 Service Response
The response from the server will be in the form of an XML message indicating the technical
and/or functional acceptance or rejection of the message. For the messages described in the
IEC 62325-451-n series, the response from the server should be an acknowledgement
message as defined in IEC 62325-451-1.
5.3.4 Functional requirements
For each XML message received the server needs to be able to identify each individual
message. The IEC 62325-451-n series define such a way via the elements
DocumentIdentification and optionally DocumentVersion.

_______________
Any: any document with any namespace.

– 14 – IEC TS 62325-504:2015 © IEC 2015
The server will perform simple validations:
• A user cannot send two (or more) messages with the same identification (e.g. Document
Identification and Version). However, another user could send messages with the same
identification that other user sent before.
• A user cannot send a message whose Version is lower than another message that has
been sent previously with the same Identification by the same user.
If there is not enough information in the sent message to create a proper response
(incomplete XML or missing tags), a Fault message will be issued instead.
If a user is not authorized to send a specific message, a Fault message shall be returned.
5.4 Query Data
5.4.1 General
The non-mandatory Query Data Service can be used by clients to request specific data from
the server using different query parameters.
The server does not need to have the response XML message ready before the service
invocation, and can create a specific message in response to each request as needed.
5.4.2 Service Request
Parameter Name Type M/O Description
DataType String M Indicates the type of data being requested.
StartTime dateTime O Specifies that the returned message shall
only include data whose Application Date is
after the provided date.
EndTime dateTime O Specifies that the returned message shall
only include data whose Application Date is
before the provided date.
3 String O Specifies additional parameters for the
Any
service.
5.4.3 Service Response
Parameter Name Type M/O/C Description
QueryData gop:QueryData M Wraps the XML message that is being returned to the
client and the parameters used in the request.

5.4.4 Functional requirements
Only one message will be retrieved for each Query Data service invocation.
When the service is called with invalid parameters (e.g. malformed application dates) a Fault
message will be returned.
A list of basic datatypes to be supported if this service is implemented is shown below:
_______________
Any: Any other parameter indicated with the pairs “name” and “value” with the element Option in the message
header.
DataType value M/O Description
“listOfDataTypes” M The server will return a list of valid DataTypes that can be used for this
service on this server.
“serverTimestamp” M The server will return the Server Timestamp in UTC time.
“parameterLimits” O The server will return its operational limits for parameters used in the List,
Get, Put services, such as maximum message size, maximum number of
queried days in the list service, etc. If there is no a specific limit for a
given parameter, the response will not include such limit value.
If the user breaches one of the specified limits, the server will return a
Fault message instead of the Response of the operation used.
The following non comprehensive list of parameter names should be used
to indicate such limits:
• MaxNumMessagesInListResponse: Maximum number of messages that
will be returned in a list operation response.
• NumberOfDaysForLowCodeInListResponse: Number of days that are
guarantee to be included in the response list when the request has
used a small code value (typically 0). According to this specification,
the default value for this parameter limit is 1 (all messages available
from 00:00 of D-1).
• MaxApplicationTimeIntervalInDaysInListRequest: Maximum number of
days that a request for Application time interval type can span.
• MaxServerTimeIntervalInDaysInListRequest: Maximum number of days
that a request for Server time interval type can span.
• MaxPayloadSizeInMBInPutRequest: Maximum size, in Megabytes, that
message payload content can have. Messages with bigger size will be
rejected.
• MaxGetRequestPerMinute: Number of Get operations per minute that a
user can execute.
• MaxPutRequestPerMinute: Number of Put operations per minute that a
user can execute.
• MaxListRequestPerMinute: Number of List operations per minute that a
user can execute.
• MaxQueryRequestPerMinute: Number of Query Data operations per
minute that a user can execute.
• MaxMessageAgeInDays: Max number of days that a message will be
accessible by this Technical Specification operations.
• MaxDiffServerTimestampInSeconds: If set, the server will reject
messages that do not meet the following criteria:
CT – ST + MD >= 0
Being CT the current server time, ST the msg:serverTimestamp
indicated in the request message and MD this parameter value.
Other parameters may be added.

In order to ensure non-repudiation, the service response will include the parameters used in
the invocation along with the response.
6 Applying IEC 61968-100
6.1 Integration Pattern
6.1.1 General
The interactions between Client and Server described in this Technical Specification
correspond with the IEC 61968-100 use case “Simple Request/Reply” supported by the “Basic
Web Service Integration Pattern”.

– 16 – IEC TS 62325-504:2015 © IEC 2015
This does not preclude the implementation of other Integration Patterns to support additional
use cases such us “Request/Reply with ESB”, “Events” etc.
The server will expose in a WSDL a single operation “request” that will serve as the single
entry point for the services described in this Technical Specification.
In Figures 1 to 3 the request/reply exchange between client and server is shown, including the
type of message sent, the IEC 61968-100 verb and noun used, and the payload when
applicable.
6.1.2 List Service
Client Server
RequestMessage("get", "MessageList")
ResponseMessage("reply", "MessageList", )
IEC
Figure 1 – List Service Sequence Diagram
6.1.3 Get Service
In this example, a message of type “Publication_MarketDocument” is requested:
Client Server
RequestMessage("get", "Any")
ResponseMessage("reply", "Publication_MarketDocument", )
IEC
Figure 2 – Get Service Sequence Diagram
6.1.4 Put Service
In this example, a message of type “Publication_MarketDocument” is sent to the server:

Client Server
RequestMessage("change", "Publication_MarketDocument", )
ResponseMessage("reply", "Acknowledgement_MarketDocument",
...