Real-Time Notifications

Design Considerations

Support Backwards Compatibility across versions

This design follows the rules for backwards compatibility by controlling the message interfaces of the Web service methods. A new field in the message to support a new enhancement will contain default values and will not be required.

Avoid maintaining contract with multiple clients and versions

Controlling the implementation of the methods as well as the implementation of the notification Web service allows us to make changes on our end without having to support each client’s customized implementation. This is true across clients as well as across versions.

Get/Post Services are available to the consumer 24/7

Anthology Inc. implements all the Get and Post methods. They are contained within an LMS site if there is a need to expose the services outside a firewall or they can be included in the Anthology Web Site together with other Anthology services.

Provide quick start solution to clients

The clients is supplied with source code for a notification Web service, implemented by Anthology Inc. The Notification project includes ‘hooks’ in the source code where the client can make requests for data as well as acknowledge the receipt of data.

The Get Registration Actions and the Acknowledge Registration Actions APIs are currently not supported by the notification Web service.

Do not force Client to implement all functionality

If the client does not write code to ‘hook’ into the provided methods, the service will simply ignore those transactions.

Implementation of Real-Time Notifications

Real-Time notification is accomplished through the implementation of the following components:

  • Database tables and triggers on specific Insert and Update events.

  • A Windows notification service to poll notification events, gather data, and notify the client’s notification Web service.

  • A client notification Web service. (Anthology Inc. provides the framework.)

  • Web services to post and retrieve data.

Implementation of Real-Time Notifications

Sequence of Events

The following sequence illustrates the events and flow of data involved in a real-time notification transaction.

Real-Time Notifications - Sequence of Events

  1. The process begins when an Application, such as Anthology Student, Anthology Portal, an Integration project, or a Customer Application inserts or updates a row in a Anthology Student table. A Anthology Student authorized user can also manually change the status of a record to a ‘Ready’ status. 

  2. Insert and Update triggers have been implemented to track changes to strategic rows which may require an LMS client’s real-time notification. The triggers accomplish two tasks.

    • Mark the Status of the row to ‘R’ Ready.
    • Add entries into a Notifications table.

  3. For SQL 2000, a Windows service periodically checks for the presence of rows in the notifications table. For SQL 2005, a Service Broker request mechanism is implemented. The polling time is configurable in the Windows Service.

  4. The Windows notification service is responsible for gathering all the necessary information needed by a client to make a call to one of the ‘GET’ Web services (see Message Fields and Client Endpoints).

  5. This information is then aggregated and packaged into a notification request.

  6. The Windows service is designed to support multiple LMS vendors. Each vendor has a row in the SyLmsVendor table in Anthology Student. Each Vendor has an entry in the row for a URL that points to the Vendor’s Notification Web service.

  7. The notification request may contain several notifications of different types, but there is only one trip to the LMS Vendor notification Web service.

  8. The Vendor’s notification Web service receives a request from the Windows service. It uses the information in the request message to create and prepare ‘GET’ requests and in-messages.

  9. The Vendor’s notification Web service calls the corresponding Service Catalog methods and retrieves the data.

  10. The Anthology business process marks all the selected data rows with a status of ‘T’ Transmitted.

  11. After receiving the data, the Vendor’s notification Web service calls the corresponding Service Catalog methods and acknowledges receipt of the data.

  12. The Anthology business process marks all the selected data rows with a status of ‘P’ Processed.