LogiSense's eventing system is an event-driven framework for creating and managing business processes and system integrations. The eventing system and queues use a publish and subscribe model. Many times an action in the billing system is the trigger for a sequence of business processes. The eventing system publishes registered events (create, update, and delete events for platform objects) to a queue (or queues) configured for the event. Those queues are in turn subscribed to and when an event is added, the subscriber will process the event. This processing could be notifying a person or external system of the changes, performing a custom calculation, or sending to another queue for further processing.
Available Events
Below is a list of commonly used events:
Event | Description |
|---|---|
Service State Transition | Triggered on a service state transition (Preactive->Active, Active->Suspended …) |
Account Status Change | Triggered when the status of an account changes |
Account Cancellation | Triggered when an account has been cancelled |
Bill Run Started | Triggered when a bill run is initiated |
Bill Run Completed | Triggered when a bill run is completed |
Invoice Posted | Triggered when an invoice has been posted |
Invoice Overdue | Triggered when an invoice has breached its payment terms |
Invoice Delivery | Triggered when an invoice has been delivered |
Invoice Delivery Date + xt | Triggered x days after invoice delivery and at a certain time t. x = days and t = time are configurable |
Refund | Triggered when a refund has been processed on the account |
Credit Processed | Triggered when a credit has been processed on the account |
Contract Under Commit | Triggered when a contract under commit occurs. This can be done per commit tier. |
Dormant Usage Identifier | Triggered when a Usage Identifier is dormant (i.e. has no usage associated with it). |
Package Cancellation | Triggered when a package has been cancelled |
Usage Threshold Exceeded | Triggered when a bucket tier has been used up |
Parameters
Parameters are name value pairs that provide additional information about the event. Parameters are contextual and dependent on the underlying event object. For example, on a service state transition notification it is possible to provide the corresponding service name as a token. However on a bill run it is not possible to provide a service name as there are multiple accounts and services that can be associated with a bill run.
Parameters can be extended to include data sources and their values to the callout. Data source extensions to parameters are dependent on a contextual relationship between the event object and the data source.