Events
The SIF Infrastructure Specification includes the concept of Events through a Publish/Subscribe model, where Service Consumers can subscribe to events such as create, update, and delete issued by Service Providers during provisioning. An event in this context represents a single change in data within a system that can potentially impact multiple data systems. Service Providers, whether Utility, Object, or Functional, generate change Event messages whenever internal data is created, updated, or deleted.
These Events are pivotal as they capture a singular modification in the data, and they play a crucial role in synchronizing external systems with the internal data of the Service Provider. Notably, each change Event message can report data changes for one or more objects, allowing a single multi-object change Request to generate a corresponding multi-object Event.
Publishing Events
To create an event using an HTTP POST where:
The Service Provider, issues a "create" request to the eventsConnector URL within its environment.
The global elements (messageId, timestamp, zoneId, contextId, serviceType, serviceSubType, serviceName, authorization, messageType, eventAction, fingerprint) are contained "outside the payload" as HTTP Headers.
The body of the HTTP POST is the data being conveyed adhering to whatever standard or other format as required.
The HTTP POST request includes the Provider's authorization token, zoneId and contextId, and the Service name which must all be checked for access as a group.
If authorized, the eventsConnector returns an HTTP status of 202 ("Accepted") to the Publisher in the form of an HTTP Response, completing the exchange.
Key parameters (particularly: zoneId, contextId, serviceType, serviceSubType, serviceName, and messageType) are used to "scope" the Event, so that subscribed Consumers can be located.
If no subscribed Consumers are found, the processing is completed.
If subscribed Consumers are found, the Event is replicated and delivered to the Queue of every subscribing Consumer specified.
Note:
The eventsConnector URL is unique to the Service Provider and is allocated at the time of provisioning.
The create operation, when successful, delivers the published event to the assigned Queue of every valid Subscribing Consumer.
The Event types are "create," "update," or "delete."
This process ensures secure and authorized event creation, replication, and delivery to subscribing Consumers in the described Brokered Architecture.
Bundeling & Responses
A key scalability feature is the ability to package changes to multiple objects within a single change Request or Event. This is particularly useful during reporting periods, reducing the number of Events issued. Multi-object Requests and Responses are supported, with individual objects reporting their change status. Ordering is not guaranteed in multi-object Responses.
Success for an individual object operation in create and update Requests implies setting values for mandatory elements and specified optional elements supported by the Service Provider. Even if unsupported optional elements remain unchanged, the Request is considered successful. Partial failures may occur in multi-object change Requests, such as Create, Update, or Delete, when the Service Provider processes each object change individually. Examples include mismatched object ID values in a Delete request.
This event-centric framework is designed to enhance data interoperability, allowing for efficient communication between different educational software applications and systems.
Management
Events arrive through queues based on prior subscriptions for data matching certain criteria. These can be better understood and managed through further reading.