Test commands, Registration of a listener, Deletion or loss of the listeners' list – CIRCUTOR EDS Series User Manual
Page 4: Maintenance of the listeners' list (alive), Reception of events
EDS
M98237501-03-13A
cords.xml?begin=01032011
000000?end=31032011000000? id=event_name
...
…
-
main: field identifying the XML as a request
-
recordGroup: field that groups all the recordings of an event
-
id: event identifier
-
record: identifies each record
-
date: event date and time
-
eventId: event identifier
-
annotation: event annotation
-
value: event value
ON: active event
OFF: inactive event
ACK: event acknowledged
4.3.7.- Device events
Returns the information about recorded events of one or more
devices between the dates “begin” y “end”. Each device for
which information is required must be included as ?id=device
cords.xml?begin=010320110000
00?end=31032011000000?id=event_name?
cords.xml?begin=01032011
000000?end=31032011000000?id=event_name?
When only the date is required, the format is DDMMYYYY;
when the date and time are required, the format is
DDMMYYYYHHMMSS. Both the date and the time must be
expressed in Universal Coordinated Time.
…
...
…
-
main: field identifying the XML as a request
-
recordGroup: field that groups all the recordings of an event.
-
device: device the records make reference to
-
record: identifies each recording
-
dateTime: event date and time
-
field: identifies each field
-
id: Identifier
-
value: event value
4.3.8.- Active Events
EDS has an XML active events service whose aim is to
enable an external agent or integration system to be
registered as a listener and record the events or alarms that
occur in the device.
The device keeps a distribution list of active users, to which it
sends events that take place locally via the creation of
incidents.
4.3.8.1.- Test commands
Before initiating implementation of the active events system,
there are a number of PUT type test requests between the
listener and the producer (remote engine) and vice versa, the
aim of which is to test and ensure connectivity between both
systems.
The listener can send the request with the following message
body to check connectivity with the remote search engine
(producer):
ip_listener
-
ip_listener defines the listener's IP, to which the producer
sends the response request
-
port: defines the listener's port, to which the producer
sends the response request
When the producer (remote search engine) receives the test
request from the listener, it returns the following request:
http://ip_listener:port/services/user/testProducer.xml
request to which the listener must reply with "received" (200).
4.3.8.2.- Registration of a listener
Any agent or listener who wants to register in a remote search
engine, or producer who wants to receive the incidents
recorded by the search engine in real time, must carry out the
following PUT request to the producer with this format:
http://ip_producer:port/services/user/listener.xml
This request must contain the following body in the message,
in which the listener and the type of data to be received are
defined:
ip_listener
-
ip_listener the listener's IP is defined, to which the
producer sends the events that are created
-
port: defines the listener's port, to which the producer
sends the events that are created
The all section defines the type of information that is to be
accessed (True / False).
-
True:) indicates to the producer that all the active events
list available must be sent
-
False:) indicates to the producer that only the events that
took place since the last request must be sent
4.3.8.3.- Deletion or loss of the listeners' list
The producer can completely or partially lose or eliminate the
listeners' list for different reasons:
-
The listener does not answer: when new events or
changes in these events take place, the producer
instantaneously informs all listeners on the list. When the
producer is faced with a communication problem with a
listener, a total of fifty retries are made to send information.
If the listener does not respond to these requests, the
producer deregisters the listener from the distribution list.
-
The producer has rebooted or has temporarily stopped
operating: if the producer receives an update or generates
a reset for any reason, (firmware, update, loss of power
supply, etc), the entire listeners' list is lost and from then on
stops sending events to the previously associated listeners.
4.3.8.4.- Maintenance of the listeners' list (alive)
Given that there are several reasons why the listeners' list
might be totally or partially affected, the external integration
system needs to implement an (alive) test system against the
producer to ensure that the IP is kept active for a long period
in the distribution list.
It is recommended that the test system is automatic and with
a periodicity of no more than 10 minutes between each test
frame dispatch. The (alive) test system is based on the
updating of the listener IP, again against the producer,
although only the event changes are requested (False):
http://ip_producer:port/services/user/listener.xml
This request must contain the following body in the message,
in which the listener and the type of data to be received are
again defined:
ip_listener
-
If the external integration application has remained inactive
for a long period of time, a request to the producer asking
for the entire list of active events is recommended using a
True request. This way the listener again has all the
information lost during the period of inactivity.
4.3.8.5.- Reception of events
When there is any change in the events, the request that the
producer creates against the listeners' distribution list giving
information about the events is PUT type with the following
Syntax:
http://ip_oyente:port/services/user/producer.xml
The request contains the following information in XML format
in the body of the message: information about the events
produced:
disabledDateTime >
…
-
all: all the events (True) or changes(False)
-
event-id: producer and identifier of the event
-
whyFired: ACTIVATION, DEACTIVATION
Notes referring to the active events:
-
Note: if the producer has implemented http authentication
by user and password, it must be implemented in the
listener by the user.
4.3.9.- Forcing of variables
This request is used to send the variable forcing order (or
writing) to the system. The request should include the name of
the device that wants to make the request. It is important to
incorporate the authentication data when this is necessary.
...
-
forceVariables: field identifying the XML as a request
-
forceVar: Information from each variable to be forced
-
forceName: variable name in device.variable format
-
field: identifies each field