[Contents] [Prev] [Next] [Index] [Report an Error] [No Frames]


How the VTA Works

The VTA manages subscriber accounts using a rule-driven event-processing system that can prioritize the actions taken for certain conditions. The 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.

A VTA processes external events based on its configuration. A VTA configuration is made up of:

Events

Each VTA event corresponds to one subscriber and contains some attributes. The VTA supports the following types of events:

Event Attributes

Each event carries attributes. Table 30 describes the types of attributes that are available for each type of event.




Table 30: Event Attributes  
Event Type
Available Attributes

Service and subscriber tracking events from the SAE

  • Plug-in attributes, such as PA_SERVICE_NAME or PA_LOGIN_NAME, associated with an SAE plug-in event. For a list of SAE plug-in events, see the SAE CORBA plug-in SPI online documentation on the Juniper Networks Web site at http://www.juniper.net/techpubs/software/management/sdx/api-index.html or in the SDX software distribution SDK/doc/idl/sae/html/index.html.
  • currentTime attribute—Time since January 1, 1970 UTC when the VTA receives the event. The value is the number of milliseconds in the range 0-9223372036854775807.
  • subscriberId—Defines how to calculate the subscriber ID based on attributes of an SAE service or a subscriber-tracking event. The subscriberId event attribute is a result of the calculation. It identifies the subscriber of the corresponding VTA event.

Account update events

  • old_status_<accountname>—Returns the old status of the account.
  • new_status_<accountname>—Returns the new status of the specified account.
  • old_lastUpdateTime_<accountname>—Returns the old last update time of the account.
  • new_lastUpdateTime_<accountname>—Returns the new last update time of the account.
  • old_balance_<accountname>—Returns the old balance of the account.
  • new_balance_<accountname>—Returns the new balance of the specified account
  • The currentTime attribute, which is the time since January 1, 1970 UTC, when the VTA receives the event. The value is the number of milliseconds in the range 0-9223372036854775807.
  • subscriberId—Defines how to calculate the subscriber ID based on attributes of an SAE service or a subscriber-tracking event. The subscriberId event attribute is a result of the calculation. It identifies the subscriber of the corresponding VTA event.

Callback events

  • callId—Includes all parameters provided with the callback.
  • currentTime—Time since January 1, 1970 UTC, when the VTA receives the event. The value is the number of milliseconds in the range 0-9223372036854775807.
  • subscriberId—Defines how to calculate the subscriber ID based on attributes of an SAE service or a subscriber-tracking event. The subscriberId event attribute is a result of the calculation. It identifies the subscriber of the corresponding VTA event.

Event Handlers

An event handler defines how the VTA processes an event. VTA event handlers consist of:

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 25 shows the event handler model. The VTA processes an event as follows:

  1. 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.
  2. If the condition is met, the 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.
  3. When an event handler finishes processing an event, the next applicable event handler according to the priority of the event handler processes the event.

Figure 25: VTA Event Handler Model

Actions

You can specify actions that the VTA takes in response on an event; for example, updating an account balance, starting a service, or stopping a service. The actions are performed if the event is of the specified type and matches the specified condition. An action is modeled as a call to a function.

An action can update event attributes or add new attributes to an event for subsequent processing of the same event by another event handler.

An action configuration includes:

VTA Processors

Processors receive and process events. The VTA has four processors:

Database Engine Processor

The database engine processor is a proxy to a database. You can use the database engine processor to:

Mail Processor

You use the mail processor to set up the VTA to send e-mail notifications to subscribers when certain events occur.

SAE Proxy Processor

You can use the SAE proxy processor to:

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.

There is an exception if the CurrentSubscriberOnly parameter is set to false. In this case, the function finds subscribers in all SAEs with the NIC.

Script Runner Processor

The Script runner processor can invoke external executable scripts or JavaScripts. We recommend using JavaScript, where possible, for better performance.


[Contents] [Prev] [Next] [Index] [Report an Error] [No Frames]