Notifications and Triggers

The Caplin Platform provides an API for the creation of triggers that sends notifications to Caplin Trader’s Alerts API (the client API) when the condition specified in the trigger is met. For example, a user could request to be notified when the price of a particular instrument rises above a defined threshold. Notifications can also be generated by back-end DataSources (independent of triggers). These notifications are also sent to the client API. Examples include system status messages that can be sent to specific users, or personal email alerts. See the Alerts API documentation for more details.

Notifications

The client Notifications API allows notifications to be delivered to listening components. It provides an interface for notifying listeners of the following events:

  • When a new notification has been added by the back-end system.

  • When a new notification has been removed by the back-end system.

  • When the notification service has become unavailable (or available).

See the NotificationServiceEvents for more details on defining these events.

The interface also exposes a dismiss method that enables display components to dismiss notifications. Once a notification has been dismissed, all listeners are informed of the removal. This allows listening components on the client side to maintain the current state. Also, the Caplin Platform stores the state of notifications, so users logging in via multiple devices will have a synchronised list of notifications.

Triggers

The Alerts API includes interfaces for notifying listeners of the following events:

  • When a new trigger is added by the back-end system.

  • When a trigger has been removed by the back-end system.

  • When the trigger service has become unavailable (or available).

See the TriggerServiceEvents for more details on defining these events. When a trigger is triggered (because e.g. the price condition is met), the Trigger object’s state is changed by the TriggerService from active to triggered. The listening component is notified of this by the Trigger itself, not the TriggerService. The interface also exposes create and dispose methods so that components can create and dispose triggers.

Workbench tools

Workbench tools are provided as a framework for managing triggers and notifications. Here you can define the data conditions for the trigger mechanism. It also enables you to view and test the mechanisms and subsequent notifications on display components using stubs:

Workbench tools

Stubs are used to implement the TriggerService and NotificationService interfaces, and are facilitated by the workbench framework. Fixtures are also provided so that Verifier acceptance tests can be written for display components in your app that use the trigger or notification services.


See also: