There are 5 basic operations available from the client subscriber:
- Open websocket
- Request currently active alarms
- Request specific alarms based on sequence ID
- Request the latest sequence ID
- Close websocket
The websocket is built on reliable transport so as long as the websocket is up, no alarms are lost. However, to aid in baselining the currently active alarms and to support retrieval of any missing alarms, operations #2 through #4 above are available over the websocket to aid in resychronization. Either can be requested via the same websocket with a websocket send() command, once the websocket session is successfully established. With this inherent functionality, there is no need to use the REST API to retrieve alarms or request resubmission of alarms.
where “request” is the JSON object, and ws is the websocket object.
For requesting active alarms, the request JSON object is represented as:
When this action is requested, the current alarm stream is paused until the set of currently active alarms is sent. Currently active alarms have a sequence ID of “-1”.
For requesting missing alarms by sequence IDs the JSON request includes 3 key/values as below:
where “data” is a stringified list of of sequence IDs and/or range of sequence IDs. Eg, [“2”, “4-6”]. When this action is requested, the missing alarms are sent along with the current alarm stream. LATEST is provided as a means to send all alarms from the starting sequenceId up to the current sequenceId.
For requesting the latest sequence ID, the JSON request is structured as below:
The response back from Orchestrator will include a sequenceId = -2, along with the latest Sequence ID.
Note that another method for requesting missing alarms can be achieved by using the Orchestrator REST APIs – this method, however, would require additional authentication and cookie management as this session is independent of the websocket session.
Updated 9 months ago