ISO 21622-3:2024

International
Standard
ISO 21622-3
First edition
Irrigation techniques — Remote
2024-03
monitoring and control for
irrigation —
Part 3:
Interoperability
Reference number
© ISO 2024
All rights reserved. Unless otherwise specified, or required in the context of its implementation, no part of this publication may
be reproduced or utilized otherwise in any form or by any means, electronic or mechanical, including photocopying, or posting on
the internet or an intranet, without prior written permission. Permission can be requested from either ISO at the address below
or ISO’s member body in the country of the requester.
ISO copyright office
CP 401 • Ch. de Blandonnet 8
CH-1214 Vernier, Geneva
Phone: +41 22 749 01 11
Email: copyright@iso.org
Website: www.iso.org
Published in Switzerland
ii
Contents Page
Foreword . vi
Introduction . vi
1 Scope . 1
2 Normative reference . 1
3 Terms and definitions . 2
4 Interoperability I: System architecture . 4
4.1 Levels and components of an interoperable architecture . 4
4.2 Interface specifications . 6
5 Interoperability II: exchange of data from irrigation entities . 20
5.1 General outline . 20
5.2 Static data of the irrigation entities . 20
5.3 Structure of an irrigation entity identifier (EntityID) . 28
5.4 Properties . 28
5.5 Entity events . 35
6 Interoperability III: Exchange of data from procedural elements performed in
irrigation entities . 37
6.1 General outline . 37
6.2 Statuses and actions . 37
6.3 Types of Operation recipes . 37
6.4 Types of Unit Procedure recipes . 56
6.5 Types of Procedure recipes . 58
6.6 Report . 59
6.7 Procedural element events . 62
Annex A (normative) Management interface with SOAP 1.2 . 64
A.1 Overview . 64
A.2 Requirements . 64
A.3 Implementation classes for web services . 66
A.4 Implementation classes for authorization server . 87
A.5 WSDL . 88
Annex B (normative) Subsystem interface with SOAP 1.2 . 104
B.1 Overview . 104
B.2 Requirements . 104
B.3 Implementation classes for web services . 106
B.4 Implementation classes for authorization server . 121
B.5 WSDL . 122
Annex C (normative) Event interface with SOAP 1.2 . 135
C.1 Overview . 135
C.2 Requirements . 135
C.3 Implementation classes for web services . 137
C.4 Implementation classes for authorization server . 140
C.5 WSDL . 140
Annex D (informative) Interoperability test protocol. 144
D.1 Overview . 144
D.2 General description . 144
D.3 IT infraestructure . 145
iii
D.4 Test bed description . 146
D.5 Test procedure . 148
D.6 Tests over subsystems . 151
D.7 Tests over coordination brokers . 235
D.8 Tests over management information systems . 243
D.9 Tests report . 245
Annex E (informative) Coordination broker software requirement specifications . 247
E.1 Overview . 247
E.2 Data model . 249
E.3 Minimal functions — Coordination broker . 255
E.4 Desirable functions . 259
E.5 Specific requirements . 267
E.6 Request management . 285
E.7 Cases of use . 294
Annex F (normative) Management interface with REST . 295
F.1 Overview . 295
F.2 Requirements . 295
F.3 Implementation method for web services . 297
F.4 ComplexType definition . 307
F.5 Implementation methods for authorization . 321
F.6 WADL . 322
F.7 ComplexTypeF . 325
Annex G (normative) Subsystem interface with REST . 334
G.1 Overview . 334
G.2 Requirements . 334
G.3 Implementation method for web services . 336
G.4 ComplexType definition . 342
G.5 Implementation methods for authorization . 353
G.6 WADL . 354
G.7 ComplexTypeG . 356
Annex H (normative) Event interface with REST . 363
H.1 Overview . 363
H.2 Requirements . 363
H.3 Implementation methods for web services — NewEvent method . 364
H.4 ComplexType definition . 365
H.5 Implementation methods for authorization . 368
H.6 WADL . 369
H.7 ComplexTypeH . 370
Bibliography . 371

iv
Foreword
ISO (the International Organization for Standardization) is a worldwide federation of national
standards bodies (ISO member bodies). The work of preparing International Standards is normally
carried out through ISO technical committees. Each member body interested in a subject for which a
technical committee has been established has the right to be represented on that committee.
International organizations, governmental and non-governmental, in liaison with ISO, also take part in
the work. ISO collaborates closely with the International Electrotechnical Commission (IEC) on all
matters of electrotechnical standardization.
The procedures used to develop this document and those intended for its further maintenance are
described in the ISO/IEC Directives, Part 1. In particular, the different approval criteria needed for the
different types of ISO document should be noted. This document was drafted in accordance with the
editorial rules of the ISO/IEC Directives, Part 2 (see www.iso.org/directives).
ISO draws attention to the possibility that the implementation of this document may involve the use of
(a) patent(s). ISO takes no position concerning the evidence, validity or applicability of any claimed
patent rights in respect thereof. As of the date of publication of this document, ISO had not received
notice of (a) patent(s) which may be required to implement this document. However, implementers are
cautioned that this may not represent the latest information, which may be obtained from the patent
database available at www.iso.org/patents. ISO shall not be held responsible for identifying any or all
such patent rights.
Any trade name used in this document is information given for the convenience of users and does not
constitute an endorsement.
For an explanation of the voluntary nature of standards, the meaning of ISO specific terms and
expressions related to conformity assessment, as well as information about ISO's adherence to the
World Trade Organization (WTO) principles in the Technical Barriers to Trade (TBT), see

www.iso.org/iso/foreword.html.
This document was prepared by Technical Committee ISO/TC 23, Tractors and machinery for
agriculture and forestry, Subcommittee SC 18, Irrigation and drainage equipment and systems.
A list of all parts in the ISO 21622 series can be found on the ISO website.
Any feedback or questions on this document should be directed to the user’s national standards body. A
complete listing of these bodies can be found at www.iso.org/members.html.

v
Introduction
The purpose of this document is to allow interoperability between the different elements of an
irrigation system that exist side by side in the same installation. The introduction of a standard in
irrigation control systems will lead to improvements in irrigation programming practice and establish a
clear separation between decision making and decision implementation.
This document establishes the specification and location of communication interfaces to be
implemented in order to enable the data exchange on commercial products, as well as its integration in
an interoperable architecture.
This document defines the mechanisms to exchange and integrate data from remote monitoring and
control systems (RMCS) for irrigation, making it available to any management information system (MIS)
with permissions.
A manufacturer can adopt this document in all the described levels or specifically in one of them,
implementing only the speficications of application to its product.
— The application of this document to a subsystem (RMCS) involves:
a) the implementation of the architecture defined at Clause 4, including the subsystem and the
event interfaces, exclusively with the actions supported by this subsystem. Clauses 5 and 6 are
related to the kinds of irrigation entities that can be controlled and/or monitored. Its data will
be available to any consumer with permissions that implements the defined interface.
b) the implementation of one of the proposed technologies for the subsystem and the event
interfaces. The available implementations are described in the Annexes B or G for subsystem
interface, and Annexes C or H for event interface. The developer can use any of these sets
(Annexes B and C, or Annexes G and H) to implement this document. The implementation can be
validated using the tests for subsystems. included in the Annex D.
— The application of this document to a management information system (MIS) involves:
a) the implementation of the architecture defined at Clause 4, including the management interface,
exclusively with the actions supported by this MIS. To access data from a subsystem the MIS
requires permissions.
b) the implementation of one of the proposed technologies for the management interface. The
available implementations are described in the Annexes A or F. The developer can use any of the
two to implement the standard. The implementation can be validated using the tests for MIS.
included in the Annex D.
— The application of this document to a coordination broker involves:
a) the implementation of the architecture defined at Clause 4 and all its interfaces.
b) the implementation of the interfaces performed using all the technologies used in the
implementation annexes (Annexes A, B, C, F, G and H). The implementations can be validated
using the tests for coordination brokers, included in the Annex D.
c) Annex E, defines two sets of functionalities for the development of a coordination broker.
vi
INTERNATIONAL STANDARD ISO 21622-3:2024(E)

Irrigation techniques — Remote monitoring and control
for irrigation systems —
Part 3:
Interoperability
1 Scope
This document establishes requirements for interoperability among systems developed for
management and/or control of irrigation facilities. It can be applied under any technological platform
and irrigation system, regardless of the water management scheme, with the exception of irrigation
mobile machinery, including centre pivots and linear irrigation machines. Due to the dynamic nature of
these machines, associated control systems and specific safety requirements, the applicability of
exchangeable data for irrigation mechanical move systems was not fully determined at the time of this
publication.
This document does not define hardware or software requirements for any of the systems to which it
applies. It only concerns externally visible interfaces and places no restriction on the underlying
implementations. It has been designed to avoid interference with proprietary solutions subjected to
intellectual property. From the point of view of the data exchange, and to guarantee interoperability
based on the previous premises, this document defines three communication interfaces (interface with
management, interface with events and interface with subsystems) and the architecture to which these
interfaces apply. Three levels of architecture has been defined to accommodate these interfaces:
— The Management Level, where any MIS conforming with this document is located. Out of all
available data exchange methods, each MIS only implements those required to execute its
functionalities.
— The Higher Control Level: coordination. At this level is performed the data integration among RMCS
and the access control to it. A software element, called coordination broker, ensures this integration
and allows the use of different technologies in its interfaces.
— The Lower Control Level: RMCS. These can also be referred to as irrigation subsystems. The RMCS
perform the duties of the irrigation entity(s) under its control.
A coordination broker can be developed as a product by any of these manufacturers or by an
independent developer using the standard specifications for this kind of software.
2 Normative reference
The following documents are referred to in the text in such a way that some or all of their content
constitutes requirements of this document. For dated references, only the edition cited applies. For
undated references, the latest edition of the referenced document (including any amendments) applies.
ISO 8601, Data elements and interchange formats. Information interchange — Representation of dates
and times
3 Terms and definitions
For the purposes of this document, the following terms and definitions apply.
ISO and IEC maintain terminological databases for use in standardization at the following addresses:
— ISO Online browsing platform: available at https://www.iso.org/obp
— IEC Electropedia: available at http://www.electropedia.org/
3.1
action
application of a method (3.7) to exchange data leading to accomplish typical irrigation duties
3.2
coordination broker
message broker pattern aplication responsible for the mapping of irrigation entities, for the collection
and consolidation of their data, and for the management of the procedural elements (3.13) executed by
them
Note 1 to entry: It shall conform with the management, subsystems (3.20) and events interfaces.
3.3
interface with events
functional connection that enables the exchange of information about events (according to IEC 62682)
between the coordination broker (3.2) and the subsystems (3.20)
3.4
interface with management
functional connection that enables the exchange of information between MIS applications and the
coordination broker (3.2)
3.5
interface with subsystems
functional connection that enables the exchange of information between the coordination broker (3.2)
and the subsystems (3.20)
3.6
message broker pattern
architectural software pattern for message validation, transformation and routing
Note 1 to entry: A message broker is a software product designed as an intermediary to facilitate interactions
between third-party applications. The message broker can also be called interface engine or integration broker.
3.7
method
mechanisms established for the exchange of data between interoperable systems
3.8
MIS application
computer program aimed at administrative and/or Operational decision-making in the irrigation
entities
Note 1 to entry: A MIS is a tool acquired for an organization (like a User Community or an Irrigator) to execute one
or more of the following specific functions (This list is descriptive and not restrictive.):
— administrative control;
— accounting control;
— maintenance;
— behavior modeling;
— operational management; and
— any other purpose aiming at improving decision-making.
3.9
optional conditioned parameter
parameter (3.12) that can be used once a conditioning parameter of an action (3.1) is set up
3.10
optional conditioning parameter
parameter (3.12) set up as a part of an action (3.1), that requires the activation of one or more
additional required or optional conditioned parameters (3.9)
3.11
optional parameter
parameter (3.12) that is not required but can be activated for an action (3.1) without requiring the
support of additional parameters
3.12
parameter
basic information contained by an action (3.1) in the interfaces
3.13
procedural element
specific application of a recipe in an irrigation entity
3.14
procedural model
representation of the reality used to describe the different parts [procedural elements (3.13)] of the
process to be performed by the elements included in the physical model
3.15
property
required attribute to define an irrigation entity
Note 1 to entry: Note the difference between a parameter, which characterizes an action (3.1), and a property,
which characterizes an entity
3.16
required parameter
parameter that shall be included when an action (3.1) is set up
3.17
required conditioned parameter
parameter required when an action (3.1) is set up including an optional or required conditioning
parameter
3.18
physical model
representation of the reality used to describe the relations, dependences and hierarchy among the
physical assets designed to perform a process
Note 1 to entry: The model is divided in seven levels, being the three upper levels focused on administrative
purposes and the four lower levels in the process to be performed.
3.19
standard history
recorded set of values of a property (3.15) covering a daily time interval and recorded according to a
predefined frequency
3.20
subsystem
term used by RMCS in terms of interoperability
Note 1 to entry: A remote monitoring and control system for irrigation (RMCS), is a set of hardware devices and
software programs used to monitor and/or control – according to predefined parameters or user decisions – one
or more irrigation entities. Typical components of a RMCS include:
— control software, linking data transmission/acquisition and process control;
— devices controlling or monitoring irrigation entities;
— other intermediate devices required for data integration and/or communication purposes.
4 Interoperability I: System architecture
4.1 Levels and components of an interoperable architecture
4.1.1 General
The levels and components are presented in Figure 1.

Figure 1 — Levels and components of an interoperable architecture
These architecture levels can be used by irrigators or user communities. Both uses the architecture
defined in this document to integrate those management tools and subsystems involved in the
management and control of his/her/its own property irrigation entities.
However, it is possible to enable other permissions to facilitate the exchange of data with third parties,
always with the prior authorization of the data owner.
4.1.2 Control level
The control level comprises:
— the coordination broker; and
— one or more subsystems.
The subsystem interface is established between these two components.
4.1.2.1 Subsystem
The control of an irrigation entity, understood as the acquisition and continuous monitoring of process
variables, execution of operations, changes of set points and emergency stops, among others, is always
performed at the subsystem level.
4.1.2.2 Coordination broker
The coordination broker performs the following basic functions:
— mapping irrigation entities and their association to the subsystems controlling them;
— establishing an abstraction layer so that MIS applications do not require information on the
subsystems responsible for each irrigation entity;
— collecting and consolidating properties, histories, events and procedural elements inherent to
irrigation entities;
— coordinating subsystems, providing them with the information they may require, regardless of its
origin;
— managing access permissions among the different components integrated in the interoperable
architecture; and
— managing the access to irrigation entities and available methods for any component integrated in
the interoperable architecture.
4.1.3 Management level
This level comprises all computer applications necessary for the efficient operation of the hydraulic
infrastructure, as well as the processes required for the optimum use of water and energy. MIS
applications retrieves the data they require from the control level.
The management interface is stablished between the management level and the upper control level.
4.2 Interface specifications
4.2.1 General
All data exchanged between the architecture levels defined shall be in accordance with the
specifications included in this document.
The specifications in this document are not tied to any specific implementation, and only establish the
foundations and minimum criteria required to guarantee an effective interoperability performance. The
application of this document requires a specific communications protocol at the choice of the
manufacturer or developer and adapted to its particular needs. The communication protocol, as well as
the security criteria for all the defined interfaces, shall be in accordance with the proposed
implementation annexes, Annexes A, B, C for SOAP Web Services or Annexes F, G or H for REST Web
Services, depending on the communication protocol selected by the manufacturer.
4.2.2 Data access authorizations
All the interfaces defined in this document shall be secured using authorization systems appropriate for
the technology or protocol to be implemented in order to identify the data consumer. The
implementation annexes establish the security requirements to be applied in each case.
Any data consumer wishing to use a certain interface shall authenticate itself. The authentication
methods to be used for interface access are those described in the implementation annexes.
From its user interface, and in addition to the authorization requirements established, any element of
the interoperable architecture (MIS applications, coordination brokers and subsystems) should manage
the access permissions for authorized consumers when using its interfaces, allowing:
— the creation of new permissions;
— the deletion of permissions; and
— the modification of this permissions.
This permissions for a data consumer can include access levels restrictions related to:
— the accessible irrigation entities; and
— the allowed methods from those defined for each interface.
Any action not meeting these conditions should be denied.
4.2.3 Irrigation entity identification
The access to any irrigation entity, in all levels of the interoperable architechture, shall be performed
using its EntityID, in order to guarantee its univoque identification. This identifier shall be unique
among the irrigation entities of an irrigation system.
When introducing or modifiying an irrigation entity, shall be checked that no duplicate irrigation entity
identifiers (EntityIDs) exist.
4.2.4 Common methods to management and subsystem interfaces
4.2.4.1 General
Unless otherwise stated, all defined parameters are required and shall be separated by commas.
4.2.4.2 Writing a property of an entity (Write method)
Table 1 — Input parameters of the Write method
Input
Name Type Description Specification
ActionID string ID of the action. Contains a character string that identifies the
action. Generated and known by the element
executing the method.
EntityID string ID of the entity where Contains a character string that corresponds to an
the user wishes to irrigation entity. This is a unique ID within the
execute the action. system.
PropertyName PropertyName Name of the property Contains one of the possible names from the list
on which the action of entity properties.
shall be executed.
Value string Value of the property Contains a character string with the fields
to be written. corresponding to the value of the property to be
written, separated by commas. Only used for non
read-only properties.
Table 2 — Output parameters of the Write method
Output
Name Type Description Specification
ActionID string ID of the action. Same parameter included in action input.
Response string Response obtained. Contains two fields separated by commas:
Value1, Value2
Where:
Value1: closed list of integer numbers identifying
the response. Possible values: 0, 1, 2, 3, 4 and 5.
Value2: closed list with explanatory texts
corresponding to each Value1:
If Value1=0, “Action successfully executed”.
Generated at recipient.
If Value1=1, “Execution error”. Generated at
recipient.
If Value1=2, “Lexical error”. Generated at
recipient.
If Value1=3, “Not supported”. Generated at
recipient.
If Value1=4, “Communication error”. Generated by
coordination when communication with reception
subsystem is not obtained.
If Value1=5, “Coordination error”. Generated by
coordination when there is a failure in the
Output
Name Type Description Specification
application.
Value2 might be extended using a hyphen with as
many explanatory texts as errors can be
discriminated by a subsystem or a coordination
broker.
Properties admitting Write method are specified for each entity type. The Response shall have
Value1=3 when executed on a read-only property (see Table 26).
4.2.4.3 Reading a property of an entity (Read method)
For the reading of the properties, it is the decision of the subsystem if it returns data stored in the
database of its control application or if it forces communication with its remote controller(s) or
terminal(s).
Table 3 — Input parameters of the Read method
Input
Name Type Description Specification
ActionID string ID of the action. Contains a character string that identifies the
action. Generated and known by the element
executing the method.
EntityID string ID of the entity where the Contains a character string that corresponds to a
user wishes to execute the irrigation entity. It is a unique ID within the
action. system.
PropertyName Property Name of the property on Contains one of the possible names from the list of
Name which the action shall be properties of the entity.
executed.
Table 4 — Output parameters of the Read method
Output
Name Type Description Specification
ActionID string ID of the action. Same element included in action input.
Response string Response obtained. Contains two fields separated by commas:
Value1, Value2
Where:
Value1: closed list of integer numbers identifying
the response. Possible values: 0, 1, 2, 3, 4 and 5.
Value2: closed list with explanatory texts
corresponding to each Value1:
If Value1=0, “Action successfully executed”.
Generated at recipient.
If Value1=1, “Execution error”. Generated at
recipient.
If Value1=2, “Lexical error”. Generated at
recipient.
If Value1=3, “Not supported”. Generated at
Output
Name Type Description Specification
recipient.
If Value1=4, “Communication error”. Generated by
coordination when communication with reception
subsystem is not obtained.
If Value1=5, “Coordination error”. Generated by
coordination when there is a failure in the
application.
If Value1=6, “Unavailable”. Generated at recipient
for a request about a supported but not in use
property.
Value2 might be extended using a hyphen with as
many explanatory texts as errors can be
discriminated by a subsystem or a coordination
broker.
Value string The value corresponding Contains a string of fields separated by commas
to the property requested. with the value corresponding to the property
requested, respecting its format.
TimeStamp string Date/time when the read Date when the value was generated at source,
value was generated. using coordinated universal time (UTC) ISO 8601
format YYYYMMDDhhmmss±hhmm.
4.2.4.4 Reading the standard history of a property (ReadStandHist method)
The preparation of the standard history is performed at the control level. The values included in the
standard history represents the ones registered during a natural day, establishing three different
number of daily values samples: 24 (hourly sample), 48 (half hourly sample) or 96 (quarter hourly
sample). The Response should have Value1=2 in requests for the current day.
Table 5 — Input parameters of the ReadStandHist method
Input
Name Type Description Specification
ActionID string ID of the action. Contains a character string that identifies
the action. Generated and known by the
element executing the method.
EntityID string ID of the entity where the Contains a character string that corresponds
user wishes to execute the to an irrigation entity. It is a unique ID
action. within the system.
PropertyName PropertyName Name of the property on Contains one of the possible names from the
which the action shall be list of properties of the entity.
executed.
Date string Date for which execution Date of the historic values in coordinated
of the action is requested. universal time (UTC) ISO 8601 format 3.17
MMDDhhmmss±hhmm.
NumHist integer Number of samples The number of samples per day have one of
contained in the daily the following values:
standard history
24, 48 or 96.
requested.
The default value is 24.
Input
Name Type Description Specification
Statistics string Name of the statistical Type of statistical variable for the
variable for which the calculation of the standard history. It
standard history is contains one of the following listed values:
generated.
— last
— average
— minimum
— maximum
The default value is last.
Table 6 — Output parameters of the ReadStandHist method
Output
Name Type Description Specification
ActionID string ID of the action. Same element included in action input.
Response string Response obtained. See Reponse in Table 2.
HistStandard string The list of values of the Contains a string of fields separated by commas
Values standard history, with the value corresponding to the statistical
according to the input value requested for the property, respecting its
parameters. format. Each piece of data contains two fields:
value and timestamp of the value at source.
4.2.4.5 Creating a procedural element (CreateRecipe method)
Table 7 — Input parameters of the CreateRecipe method
Input
Name Type Description Specification
ActionID string ID of the action. Contains a string that identifies the action.
Generated and known by the element executing
the method.
ProceduralID string ID of the procedural Contains a string that corresponds to procedural
element that is being element. It is a unique ID within the system.
created via the action.
EntityID string ID of the entity where the Contains a string that corresponds to a irrigation
user wishes to execute the entity. It is a unique ID within the system.
action.
EntityType EntityType Entity type from those Type of entity on which the user wishes to execute
listed. the action.
RecipeType RecipeType Type of procedural Type of procedural element to be created in the
element to be created. irrigation entity identified by EntityID. See
operation recipe types in Table 47.
Attending to the selected RecipeType, specific input parameters are required. Optional parameters can also be
introduced. The required and optional parameters of all recipe types have been defined in 7.3, 7.4 and 7.5.

Table 8 — Output parameters of the CreateRecipe method
Output
Name Type Description Specification
ActionID string ID of the action. Same element included in action input.
Response string Response obtained. See Response in Table 2.
The Response shall have Value1=3 – Not supported when the CREATERECIPE method includes:
— one or more optional parameters not supported by the subsystem controlling the irrigation entity;
or
— a recipe type not supported by the subsystem controlling the irrigation entity.
4.2.4.6 Stopping a procedural element (StopRecipe method)
Table 9 — Input parameters of the StopRecipe method
Input
Name Type Description Specification
ActionID string ID of the action. Contains a string that identifies the action.
Generated and known by the element executing
the method.
ProceduralID string ID of the procedural Contains a string that corresponds to the unique
element that is being ID of the porcedural element to be stopped.
stopped by means of the
action.
EntityID string ID of the entity where the Contains a string that corresponds to an irrigation
user wishes to execute the entity. It is a unique ID within the system.
action.
Table 10 — Output parameters of the StopRecipe method
Output
Name Type Description Specification
ActionID string ID of the action. Same element included in action input.
Response string Response obtained. See Response in Table 2.

4.2.4.7 Reading procedural element report (ReadReport method)
Table 11 — Input parameters of the ReadReport method
Input
Name Type Description Specification
ActionID string ID of the action. Contains a string that identifies the action.
Generated and known by the element executing
the method.
EntityID string ID of the entity where the Contains a string that corresponds to a irrigation
user wishes to execute the entity. It is a unique ID within the system.
action.
ProceduralID string ID of the procedural Contains a string that corresponds to the
element for which the procedural element. It is a unique ID within the
report is required. system.
InstanceNumber integer Number of the instance of Contains an integer that corresponds to the
the procedural element for operation instance required, being:
which the report is
— 0, to obtain the original operation report.
required.
— 1 to n, to obtain the report of an instance of
the original operation.
If is not specified, the default value is “0”.
Table 12 — Output parameters of the ReadReport method
Output
Name Type Description Specification
ActionID string ID of the action. Same element included in action input.
Response string Response obtained. See Response in Table 2.
Report string Set of data collected with Returns the resulting values for a procedural
the structure of a report. element at the moment of the request. The values
shall be separated by commas:
The structure of the report shall be in accordance
with 6.2.
If it is a partial report, the value EndCondition
shall be null.
Status Status Status of the Procedural Contains one of the values of Table 45.
element.
...