How the SRC VTA Works
The SRC VTA manages subscriber accounts using a rule-driven event-processing system that can prioritize the actions taken for certain conditions. The SRC VTA is triggered by events, such as the logging in of subscribers, the use of network services, or the changing of account balances. These events can cause actions, such as updating account balances, starting or stopping network services, or running scripts to perform external actions.
The SRC VTA processes external events based on its configuration. The SRC VTA configuration is made up of:
Each SRC VTA event corresponds to one subscriber and contains some attributes. The SRC VTA supports the following types of events:
Service and subscriber-tracking events from the SAE; for example, start or stop tracking events.
Account update events triggered by updating database accounts.
Callback events triggered by an SRC VTA API call.
An event handler defines how the SRC VTA processes an event. SRC VTA event handlers consist of:
Type of event—Tracking, update, or callback event; for example, a subscriber start–tracking event or a service start–tracking event.
Priority—Priority at which event handlers are evaluated and executed. Event handlers are evaluated and executed from high to low priority.
Condition—Condition that the event handler evaluates to determine whether the event handler should handle the event.
Actions—List of actions to be performed by the event handler.
You can set up multiple event handlers to process events. For example, the first event handler could retrieve the balance for a quota account, and the next event handler could refill the quota account, depending on whether the condition of the second event handler is met.
Figure 1 shows the event handler model. The SRC VTA processes an event as follows:
The event handler with the highest priority receives the event, determines whether the event’s type is the same as the event type of the event handler, and determines whether the event satisfies the condition of the event handler.
If the condition is met, the SRC VTA performs the corresponding actions based on the event attributes. An action invokes a function and provides the parameters required by that function to the processor.
When an event handler finishes processing an event, the next applicable event handler according to the priority of the event handler processes the event.
You specify actions that the SRC VTA takes in response to events; for example, updating an account balance, starting a service, or stopping a service. An action is modeled as a call to a function. If an event matches the type and condition requirements of the event handler, then all actions defined for the event handler process the event, one after another, in the order the actions are configured.
An action can update event attributes or add new attributes to an event for subsequent processing of the same event by another action in the same event handler, or by actions in subsequent event handlers. The updated attributes can also be used to change whether the event satisfies a subsequent event handler’s condition.
An action configuration includes the following:
Function—Function that the action invokes
Parameter—Parameters and corresponding values to be passed to the function
Processors implement the functions that receive and process events. The SRC VTA has four processors:
Db-engine processor—Acts as a proxy to a database
Mailer processor—Sends e-mail notifications when certain events occur
SAE proxy processor—Acts as a proxy to the SAE. (Requires no configuration)
The db-engine processor acts as a proxy to the external database. You can use the functions provided by the db-engine processor to:
Calculate the use of network resources for a service.
Calculate the interim accounting interval for each service based on a subscriber’s remaining resources and use of the service.
Terminate an SRC VTA session. This feature is usually used at the end of a billing period so that you can finish collecting data for the current billing period and start a new SRC VTA session for the new billing period. Depending on what practices you use for terminating SRC VTA sessions, you may choose to optimize the way the SRC VTA terminates sessions.
If an SRC VTA session is terminated while the SAE is in the middle of a service session, the SAE service session can split into two or more SRC VTA sessions. This process works fine if you are not frequently terminating a large number of SRC VTA sessions. However, in some cases, you may choose to terminate SRC VTA sessions on a regular basis—for example, every 24 hours. In this case, the SAE session can last a long time and can result in hundreds of SRC VTA sessions. When this occurs, processing an interim accounting event can be slow because the SRC VTA needs to find and read many records. To improve the processing time in these environments, you can optimize the SRC VTA database.
The SRC VTA db-engine retrieves the list of accounts for a specified subscriber instead of retrieving the account information every time for each subscriber.
To optimize SRC VTA database operations when you are terminating large numbers of SRC VTA sessions on a regular basis, you can set the sessions-terminated-frequently option under the [edit shared vta group name processor db-engine] hierarchy level. When this option is set, the SRC VTA creates a special VTA session. Instead of finding and reading all session records, the SRC VTA needs to read from and write to only the special VTA session record.
Setting the sessions-terminated-frequently option is an irreversible act. You can set this option to true, but you cannot change it back to false.
To use the sessions-terminated-frequently optimization feature with a set of SRC VTAs, you must follow this specific process:
- All C Series Controllers running SRC VTAs must be running SRC software release 4.3.x or later; otherwise, you must upgrade the system.
- Send all SAE events to only one SRC VTA.
- Wait until the removed SRC VTAs (from Step 2) have finished processing events in their event queues.
- Set the sessions-terminated-frequently option to true.
- Wait until all SRC VTAs have reacted to the option being set. The SRC VTA information log displays the following message: “DBEngine will assume VTA sessions are terminated frequently.”
- Resume distributing SAE events to all SRC VTAs.
SAE Proxy Processor
The SAE proxy processor is a proxy to the SAE external interface that resolves the subscriber interface based on the event types to which functions are applied.
If a function is applied to SAE subscriber-tracking or service-tracking events, the processor finds the SAE reference in the event message.
There is an exception if the current-subscriber-only parameter is set to false. In this case, the function finds subscribers in all SAEs with the NIC.
If a function is applied to other events, the processor uses the subscriber’s ID in the event as the key for the NIC to find the SAE reference. The SRC VTA uses the SAE reference and the subscriber-id-solution option that you specify under the VTA group to look up the SAE and the subscriber.
You can use the functions provided by the SAE proxy processor to:
Set an interim interval for a service.
Set a service session timeout for a subscription.
Set a session timeout for a subscriber.
Start a subscription to a service. You can specify the parameter substitutions to use when the service is started.
Stop a subscription to a service. You can include a reason for stopping the subscription. When the service is stopped, the reason is sent to the billing system so it can differentiate between service stops.
The SAE proxy processor does not require configuration. To use the functions provided by the SAE proxy processor, you configure an action that calls the respective function for the event handler.
You can use the functions provided by the mailer processor to set up the SRC VTA to send e-mail notifications when certain events occur. You can specify that e-mail notifications be sent to subscribers, system administrators, or an automated billing system.
External scripts are executable programs, such as shell scripts, that are available on the SRC VTA’s host. Each external script can perform a task and return a value. If the script returns a value, the value can be added to the current event as an event attribute.