The event stream is a streaming data source that provides a serialized history of Socotra system events. It is useful for situations like:
Triggering integration processes, such as printing and sending an invoice after it is issued
Created automated processes, such as a renewal process after a policy nears expiration
Capturing data changes for maintaining an external database that includes Socotra data
We recommend waiting at least 5 seconds after receipt of an event to perform follow-up entity fetches by locator, since events are emitted independently of data persistence routines.
See the Event Stream API topic for information about how to implement this feature.
The event stream is a paged mechanism. Start by querying for events, and then if more records are needed, requery using the pagingToken
from the previous response to fetch more records.
For the first call to fetch events, do not include a pagingToken
; instead include at least one filter criterion, such as startTimestamp
will always include a pagingToken
. You can use the pagingToken
to get additional results for the same query. When making a call using the pagingToken
, omit the original filter criteria. The pagingToken
lasts forever: even if you reached the end of the result set, you can save the pagingToken
to check for more results later.
On each call to the Event Stream, a different pagingToken
may be returned.
There are two event stream query endpoints: Fetch Events and Fetch Attributed Events. The difference is that the latter endpoint will include the username
of the user that initiated the event as part of the EventResponse.
The event stream contract is to return objects of type EventResponse, each of which contains an EventStreamData object. Each actual data type returned will be a subtype of EventStreamData depending on what kind of event it is. The type can be identified using the type
property on the EventResponse that contains the data.
Transaction Effective Events
Transaction Effective Events are available for all major transactions and indicate that the previously issued transaction has come into effect. These events will supplement the existing transaction lifecycle action events create, update, quote, issue and discard. Effective events for back-dated transactions will be emitted at the next scheduled execution of the event trigger job.
Policy Termination and Expiration
event fires only for policies that expire when they reach their policy’seffectiveContractEndTimestamp
. It will not fire when policies end due to cancellation.The
event will fire for both manual cancellations and automatic cancellations due to lapse, unless the system is configured to use Legacy Lapsing and Reinstatement. Lapses can be distinguished from manual cancellations using thecancellationName
property.If a cancellation is issued for a future effective date, the
event will be fired immediately. There will be no additional event at that future effective date.The
event will not fire for policies that have been cancelled.The
event is a legacy event and is not fired unless using legacy cancellation processes. Use thecancellation.issue