The Kaa Notifications subsystem enables messages delivery from the Kaa cluster to endpoints (EP). Unlike configuration data that represents the desired EP state, notifications can be thought of as calls for a dynamic EP response. For example, a notification may cause a client application to show a message in the UI (user-defined notification), or initiate immediate or delayed EP configuration synchronization with the Operations server (system notification).
The Kaa Notifications functionality allows transfer of any data to endpoints. The structure of data that is carried by notifications is defined by a notifications data schema configured into the Kaa server and built into Kaa endpoints. The notifications data schema is defined similarly to the endpoint profile data schema. In addition to the user-defined schema and its version, notifications are characterized by type that can be either system or user. System notifications are processed by the endpoint implementation; and user notifications are handed over to the client code via the endpoint API.
Since the requirements to the data structure may evolve during the lifetime of a Kaa-based system, a Kaa server can be configured to simultaneously handle notification data schemas of multiple versions. In such event, a notification object would have multiple schema versions associated with it along with the actual notification data versions - structured accordingly. To deliver such notification to an endpoint, the server would choose the schema version matching the one that the endpoint supports.
Topics and subscriptions
Topics provide a means for segregating Kaa notifications within an application. Every notification in the system must be associated with a topic. The topic subscription status of an endpoint determines whether or not the endpoint has a chance to receive a notification.
It is possible that some of the topics configured within the application are not accessible to all endpoints. Each topic created in Kaa must be assigned to one or more endpoint groups (global by default). In order for an endpoint to receive notifications associated with a topic, the endpoint must belong to at least one group that has the topic assigned to it.
Topics can be optional or mandatory. An endpoint can choose which optional topics to subscribe to. Mandatory topic notifications are delivered in an enforced manner. It is the responsibility of the client code to set appropriate listeners to the topics the endpoint is subscribed to.
Notification pipelines manage individual notifications within a topic. A notification remains queued in the pipeline until its TTL expires, after which the notification is dropped. The notification pipeline type specifies the scope of notifications delivery. It can be either multicast (targeted to unbounded number of endpoints) or unicast (targeted to a single specific endpoint).
Whenever a notification is sent to a topic it gets added to the corresponding pipeline with a unique sequential index per pipeline. Endpoints independently maintain their position in every pipeline by remembering the last sequential index per pipeline that they received.
Whenever a notification is sent to a topic it gets added to the corresponding pipeline with a unique ID. Endpoints independently maintain their pipeline by reporting all received notification IDs. The server removes the notification from the pipeline once it receives a receipt confirmation from the endpoint. Sending a unicast notification requires specifying the endpoint and topic IDs. The endpoint must be subscribed to the specified topic, otherwise an error will be returned.