When a Clientsubscribes for Events, the Notificationof transitions will begin at the time of the Subscription. The currently existing state will not be reported. This means for example that Clientsare not informed of currently Active Alarmsuntil a new state change occurs.
Clientscan obtain the current state of all Condition instances that are in an interesting state, by requesting a Refreshfor a Subscription. It should be noted that Refreshis not a general replay capability since the Serveris not required to maintain an Eventhistory.
Clientsrequest a Refreshby calling the ConditionRefresh Method. The Serverwill respond with a RefreshStartEventType Event. This Eventis followed by the Retained Conditions. The Servermay also send new Event Notificationsinterspersed with the RefreshrelatedEvent Notifications. After the Serveris done with the Refresh, a RefreshEndEventis issued marking the completion of the Refresh. Clientsshall check for multiple Event Notificationsfor a ConditionBranchto avoid overwriting a new state delivered together with an older state from the Refreshprocess. If a ConditionBranchexists, then the current Conditionshall be reported. This is True even if the only interesting item regarding the Conditionis that ConditionBranchesexist. This allows a Clientto accurately represent the current Conditionstate.
A Clientthat wishes to display the current status of Alarms and Conditions(known as a “current Alarm display”) would use the following logic to process Refresh Event Notifications. The Clientflags all Retained Conditionsas suspect on reception of the Eventof the RefreshStartEventType. The Clientadds any new Eventsthat are received during the Refresh without flagging them as suspect. The Clientalso removes the suspect flag from any Retained Conditionsthat are returned as part of the Refresh. When the Clientreceives a RefreshEndEvent, the Clientremoves any remaining suspect Events, since they no longer apply.
The following items should be noted with regard to ConditionRefresh:
- As described in 4.4some systems require that previous states of a Conditionare preserved for some time. Some Servers– in particular if they require acknowledgement of previous states – will maintain separate ConditionBranchesfor prior states that still need attention.
ConditionRefreshshall issue Event Notificationsfor all interesting states (current and previous) of a Conditioninstance and Clientscan therefore receive more than one Eventfor a Conditioninstance with different BranchIds.
- Under some circumstances a Servermay not be capable of ensuring the Clientis fully in sync with the current state of Condition instances. For example, if the underlying system represented by the Serveris reset or communications are lost for some period of time the Servermay need to resynchronize itself with the underlying system. In these cases, the Servershall send an Eventof the RefreshRequiredEventTypeto advise the Clientthat a Refreshmay be necessary. A Clientreceiving this special Eventshould initiate a ConditionRefreshas noted in this clause.
- To ensure a Clientis always informed, the three special EventTypes(RefreshEndEventType, RefreshStartEventTypeand RefreshRequiredEventType) ignore the Eventcontent filtering associated with a Subscriptionand will always be delivered to the Client.
- ConditionRefresh applies to a Subscription. If multiple Event Notifiers are included in the same Subscription, all Event Notifiersare refreshed.