5 Background Processes on the VWS

This chapter provides a description of the programs or executables used by CCS as background processes on the VWSs.

Executables are located in the /IN/service_packages/CCS/bin directory.

Some executables have accompanying scripts that run the executables after performing certain cleanup functions. All scripts should be located in the same directory as the executable.

For more information about the processes and systems that use these programs and executables, see System Overview.

WARNING:

It is a prerequisite for managing these core service functions that the operator is familiar with the basics of Unix process scheduling and management. Specifically, the following Unix commands:

  • init (and inittab)

  • cron (and crontab)

  • ps

  • kill

beVWARS

Purpose

beVWARS is the Vouchers Wallets Accounts Reserve System. It enables CCS to handle actions that interact with the wallet, account, and voucher tables in the E2BE database on the VWS. Most beVWARS functionality is provided by plug-ins and handlers as defined in the plugins and handlers parameters. This section shows beVWARS configuration, which includes CCS plug-ins and handlers.

Note:

If the VWS is not used, the beVWARS handlers and the plug-ins are not relevant.

Example

An example of the beVWARS parameter group of a Voucher and Wallet Server eserv.config file is listed below. comments have been removed.
beVWARS = {
    other beVWARS configuration

    handlers = [
        VWS beVWARS handlers

        "ccsVWARSReservationHandler.so"
        "ccsVWARSNamedEventHandler.so"
        "ccsVWARSRechargeHandler.so"
        "ccsVWARSAmountHandler.so"
        "ccsVWARSWalletHandler.so"
        "ccsVWARSPolicyHandler.so"
    ]
    plugins = [
        VWS beVWARS plug-ins

        "ccsVWARSExpiry.so"
        "ccsRewardsPlugin.so"
        "ccsVWARSActivation.so"
        "ccsPDSMSPlugin.so"
        "ccsNotification.so"
        "ccsWLCPlugin.so"
        "ccsBadPinPlugin.so"
        "ccsPMXPlugin.so"
        "ccsPolicyPlugin.so"
    ]
}

Note:

Other handlers and plug-ins may be provided which extension features (for example the ccsVWARSVoucherHandler is provided by the Voucher Manager feature). For more information about those libraries, see the documentation provided with the feature.

Parameters

beVWARS has two parameters which are relevant to CCS configuration. They are documented below. For more information about other beVWARS parameters, see VWS Technical Guide.

handlers
Syntax:
handlers = [
        "lib"
        [...]
]
Description: Lists the beVWARS message handler plug-ins to load.
Type: Array
Optionality: Required to load handlers which handle messages from CCS processes such as ccsBeOrb.
Allowed: -
Default: -
Notes:

This array will also include the standard handlers provided by VWS.

For more information about the standard handlers provided with CCS including their configuration, see the following:

Example:
handlers = [
        "ccsVWARSReservationHandler.so"
        "ccsVWARSNamedEventHandler.so"
        "ccsVWARSRechargeHandler.so"
        "ccsVWARSAmountHandler.so"
        "ccsVWARSWalletHandler.so"
]

plugins

Syntax:
plugins = [
        "lib"
        [...]
]
Description: Lists the beVWARS event plug-ins to load.
Type: Array
Optionality: Required to load event plug-ins which perform functions needed by CCS.
Allowed: -
Default: -
Notes:

Where plug-ins are triggered by the same event, they will operate in the order they appear in this list.

This array will also include the standard plug-ins provided by VWS, and may also include plug-ins from other applications such as Promotion Manager.

For more information about the standard plug-ins provided with CCS including their configuration, see the following:

Example:
plugins = [
        "ccsVWARSExpiry.so"
        "ccsRewardsPlugin.so"
        "ccsVWARSActivation.so"
        "ccsPDSMSPlugin.so"
        "ccsNotification.so"
        "ccsWLCPlugin.so""ccsBadPinPlugin.so"
        "ccsPMXPlugin.so"
        "ccsPolicyPlugin.so"
]

ccsActivationCharge

Purpose

ccsActivationCharge is a beVWARS plug-in which:

  • Processes wallets as they activate (triggers on a wallet activated event)
  • Applies any periodic charges which apply to the wallet and have Charge on Activation set to true.

For more information about periodic charge configuration, see Charging Control Services User's Guide.

Note:

This process only applies to periodic charges which were configured in CCS 3.1.4 or earlier.

Startup

If ccsActivationCharge is included in the beVWARS plugins array in eserv.config, it is loaded by beVWARS when beVWARS is initialized.

It is included in the following lines:

plugins = [
        "ccsActivationCharge.so"
]

For more information about the beVWARS plugins section, see Table 5-*.

Note:

Other event plug-ins may also be included in the plugins array.

Parameters

The ccsActivationCharge supports the following parameter in the ccsActivationCharge section of eserv.config.

periodicChargeCacheValidityPeriod

Syntax:
periodicChargeCacheValidityPeriod = seconds
Description: Time out value in seconds for the periodic charge cache.
Type: Integer
Optionality: Optional
Allowed: Any positive decimal integer.
Default: 600
Notes: -
Example:
periodicChargeCacheValidityPeriod = 600

Example

An example of the ccsActivationCharge parameter group of a Voucher and Wallet Server eserv.config file is listed below. Comments have been removed.

ccsActivationCharge = {
    periodicChargeCacheValidityPeriod = 600
}

ccsBadPinPlugin

Purpose

ccsBadPinPlugin is a beVWARS event plug-in that checks for bad PIN thresholds. It is triggered by a balance value changed event.

Startup

If ccsBadPinPlugin is included in the beVWARS plugins array in eserv.config, it is loaded by beVWARS when beVWARS is initialized.

It is included in the following lines:

plugins = [
    "ccsBadPinPlugin.so"
]

For more information about the beVWARS plugins section, see Table 5-*.

Note:

Other event plug-ins may also be included in the plugins array.

Configuration

ccsBadPinPlugin supports the parameters from the badPinPlugin section of eserv.config.

Note:

Some of the ccsVWARSVoucherHandler parameters are also used by ccsBadPinPlugin:
  • clearConsecutivePin
  • dailyBadPinExpiryHours
  • weeklyBadPinExpiryHours
  • monthlyBadPinExpiryHours
  • consecutiveBadPinExpiryHours
  • vomsInstalled

cacheFlushPeriod

Syntax:
cacheFlushPeriod = seconds
Description: The number of seconds before refreshing the balance type cache used by ccsBadPinPlugin.
Type: Integer
Optionality: Optional (default used if not set).
Allowed:
Default: 200
Notes: -
Example:
cacheFlushPeriod = 300

cacheValidityTime

Syntax:
cacheValidityTime = seconds
Description: The number of seconds an entry is kept before the entry's record is re-read.
Type: Integer
Optionality: Optional (default used if not set).
Allowed: -
Default: 10
Notes: -
Example:
cacheValidityTime = 30

ccsBeAvd

License

The ccsBeAvd binary is only available if you have purchased the Voucher Management license.

For more information about this library, see Voucher Manager Technical Guide.

ccsCB10HRNAES

License

The ccsCB10HRNAES library is available only if you have purchased the Voucher Management license.

For more information about this library, see Voucher Manager Technical Guide.

ccsCB10HRNSHA

License

The ccsCB10HRNSHA library is available only if you have purchased the Voucher Management license.

For more information about this library, see Voucher Manager Technical Guide.

ccsExpiryMessageGenerator

Purpose

ccsExpiryMessageGenerator generates a list of wallets or balances which will expire shortly. The list of subscribers is generated on the VWSs and transfered to the SMS, where they are actioned by ccsExpiryMessageLoader.

Startup

The CCS install process adds the ccsExpiryMessageGenerator process to the crontab, running at 9 am on each day of month for ccs_oper by default.

It is scheduled as /IN/service_packages/CCS/bin/ccsExpiryMessageGenerator by the following line:

0 2 * * * . /IN/service_packages/CCS/.profile ; . 
/IN/service_packages/CCS/.profile-be ; 
/IN/service_packages/CCS/bin/ccsExpiryMessageGenerator >> 
/IN/service_packages/CCS/tmp/ccsExpiryMessageGenerator.log 2>&1

Parameters

Available parameters are detailed in ccsExpiryMessageLoader.

Example

CCS = {
    ExpiryMessages = {
        walletExpiryPeriod = 15
        balanceExpiryPeriod = 10
        balanceTypes = [ 1 ]
        oracleUsername = ""
        oraclePassword = ""
        generatorFilename = "ccsExpiryMessages"

        generatorFiledir = "/IN/service_packages/CCS/logs/expiryMessageWrite/"
        inputDirectory = "/IN/service_packages/CCS/logs/expiryMessageRead/" 

        cmnPushFiles = [    
        "-d", "/IN/service_packages/CCS/logs/expiryMessageWrite/"
        "-r", "/IN/service_packages/CCS/logs/expiryMessageRead/"
        "-h", "produsms01"
        "-p", "2027"
        "-F"
        ]
    } 
}

This section of the eserv.config must be set up on the SMS and VWS for expiry notification short messages sent from the ccsExpiryMessageGenerator and ccsExpiryMessageLoader processes. If this section is not present, then no expiry notifications will be sent at all.

Note:

Note: ccsExpiryMessageGenerator uses ORACLE_SID to connect to database. It is recommended to set ORACLE_SID to a valid TNS entry. In case ORACLE_SID is not set, then ccsExpiryMessageGenerator process establishes connection to database using the oracleUsername and oraclePassword provided in eserv.config.

Failure

If ccsExpiryMessageGenerator fails, no expiry notifications will be sent at all.

Output

The notification request files produced by ccsExpiryMessageGenerator are in the format:

notif_id lang_id MSISDN num_params param1[|param2|...]

ccsExpiryMessageGenerator writes error messages to the system messages file, and also writes additional output to /IN/service_packages/CCS/tmp/ccsExpiryMessageGenerator.log.

ccsLegacyPIN

Purpose

ccsLegacyPIN plug-in library is used by ccsAccount and the ccsVoucher_CCS3 voucher tool to encrypt the PINs using the DES authentication rule. For more information about authentication rules, see Security libraries.

Note:

The ccs3Encryption plug-in is a symbolic link to the ccsLegacyPIN plug-in, but in the ccs3Encryption mode it uses different parameters.

Startup

ccsLegacyPIN is used by ccsVoucher_CCS3 as necessary. No startup configuration is required for this library to be used.

Configuration

ccsLegacyPIN has no specific configuration. It does accept some parameters from ccsVoucher_CCS3 for voucher encryption which are configured in the CCS Voucher Management and Service Management screens.

ccsMFileCompiler

Purpose

MFiles store data that is not updated very often (for example, tariffing data). ccsMFIleCompiler compiles MFiles on the Voucher and Wallet Server to provide a fast lookup for the stored data.

When a new row is replicated into the CCS_MFILE table on the E2BE database, ccsMFileCompiler processes the tariffing or named event catalogue data in the E2BE database and creates an MFile for the VWS processes to use.

For more information about MFile processing, see the discussion on MFile updates in VWS Technical Guide. For information about MFile configuration, see the section on MFile generation in Charging Control Services User's Guide.

MFile filenames

ccsMFileCompiler generates MFile filenames based on the service provider ID and the date and time that the MFile is created. For rating MFiles, ccsMFileComplier use the following format:

acs_Cust_IDDtimestamp

For named event catalogue MFiles, ccsMFileCompiler uses the following format:

Pacs_Cust_IDDtimestamp

where acs_Cust_ID is the ID of the service provider in the ACS_CUST_ID field of the CCS_MFILE table, and timestamp is the date and time when ccsMFileCompiler created the file. For example, the following rating MFile would be for a service provider with ID 11:

11D20150330110120

Note:

For backward compatibility, if acs_Cust_ID is 0 (zero), then ccsMfileCompiler generates the filename using only the timestamp. For example, the filename format is "timestamp" for rating MFIles or "Ptimestamp. for named event catalogue MFiles. For example, the following rating MFIle would be for a service provider with ID 0:

20150330110120

Startup

ccsMFileCompiler is started by entry ccs9 in the inittab, through the /IN/service_packages/CCS/bin/ccsMFileCompilerStartup.sh shell script.

Configuration

ccsMFileCompiler reads the following configuration from the CCS and BE sections of the eserv.config file:

CCS = {   
    oracleUserAndPassword = "user/pwd"

    MFile = {
        path = "dir"
        numberOfErrors = int
        timeout = int
    }

    BE = {
        serverId = int
        amPrimary = true|false
        beLocationPlugin = "lib"
    }

Parameters

This section describes the ccsMFileCompiler configuration parameters in the CCS section of the eserv.config file.

ccsMFileCompiler uses the oracleUserAndPassword parameter from the CCS section of eserv.config to retrieve Oracle database login details. For more information, see Table 2-*.

MFile Configuration Parameters

ccsMFileCompiler supports the following parameters from the CCS, MFile section of eserv.config:

path

Syntax: path = "dir"
Description: The location of compiled MFiles.
Type: String
Optionality: Optional (default used if not set)
Allowed:
Default: "/IN/service_packages/CCS/MFile"
Notes:
Example: path = "/var/CCS/MFile"

numberOfErrors

Syntax: numberOfErrors = int
Description: The number of compile errors that can occur before the ccsMFileCompiler process will stop.
Type: Integer
Optionality: Optional (default used if not set).
Allowed:
Default: 1
Notes:
Example: numberOfErrors = 1

timeout

Syntax: timeout = microsecs
Description: The number of microseconds to wait to successfully connect to the beServer before timing out.
Type: Integer
Optionality: Optional (default used if not set).
Allowed:
Default: 20000
Notes:
Example: timeout = 5000

Example MFile Configuration

The following shows an example MFile configuration section of a eserv.config file on the Voucher and Wallet Server.

MFile = {
    path = "/IN/service_packages/CCS/MFile"
    numberOfErrors = 1
    timeout = 20000
}

Shared Configuration Parameters

ccsMFileCompiler uses the following shared parameters defined in the BE section of eserv.config to retrieve details of the Voucher and Wallet Server to which it should connect, and to reload the MFile data:

  • amPrimary
  • serverId
  • beLocationPlugin

For information about configuring BE shared parameters, see BE eserv.config parameters (on page 2).

ccsMFileCompiler Command Line Parameters

ccsMFileCompiler supports the following optional command line parameters:

ccsMFileCompiler [-r row_id] [-l be_location_plugin] [-a true|false] [-i be_server_id] [-d debug_flag]
Parameters

-r

Syntax: -r row_id
Description: Runs the ccsMFileCompiler process for a specific row in the CCS_MFILE table, where row_id identifies the row for which the the process should be run.
Type: Integer
Optionality: Optional
Allowed:
Default: None
Notes: Runs ccsMFileCompiler once and then exits.
Example: -r 10

-l

Syntax: -l be_location_plugin
Description: Specifies the location of the BE plug-in. This value overrides the value configured for the beLocationPlugin parameter in the BE section of eserv.config.
Type: String
Optionality: Optional (default used if not set)
Allowed:
Default: libGetccsBeLocation.so
Notes:
Example: -l "libGetccsBeLocation.so"

-a

Syntax: -a true|false
Description: Set to true if this is the primary VWS. Otherwise set to false.
Type: Boolean
Optionality: Optional (default used if not set)
Allowed:

true

false

Default: true
Notes: Overrides the value configured for amPrimary in the BE section of eserv.config.
Example: -a true

-i

Syntax: -i be_server_id
Description: Sets the ID of the VWS pair where be_server_id is the ID of the VWS.
Type: Integer
Optionality: Optional (default used if not set)
Allowed:
Default: 1
Notes: Overrides the value configured in the serverId parameter in the BE section of eserv.config.
Example: -i 1

-d

Syntax: -d debug_flag
Description: Defines which flag you want to use for debugging.
Type: String
Optionality: Optional
Allowed:

all – full debugging

ccsMFileCompiler – component only debugging

none – no debug

Default: None
Notes:
Example: -d all

Failure

If ccsMFileCompiler fails, MFile updates will stop.

MFile entries will still be replicated to the CCS_MFILE table in the E2BE database, but they will not be processed. The corresponding MFile will not be created for the unprocessed entries and therefore beVWARS will not use any rating or named event catalogue changes made since the last MFile was created.

Output

ccsMfileCompiler writes error messages to the system messages file, and also writes additional output to /IN/service_packages/CCS/tmp/ccsMFileCompiler.log.

ccsNotification

Purpose

ccsNotification is a beVWARS event plug-in that generates a list of real-time wallet notifications for delivery. Notifications can be triggered on the following events:

  • Wallet expiry
  • Wallet state change
  • Balance value changed
  • Bucket expiry

Note: Other plug-ins, such as ccsVWARSPeriodicCharge, can write notifications. For more information about notifications and events that trigger notifications, see Notifications.

Real-time Wallet Notifications Delivery Process

The following high-level process describes how the ccsNotification process delivers real-time wallet notifications. For more information, see Real-Time Notifications.

  • When a wallet or bucket is triggered through beVWARS on a primary VWS, ccsNotification checks whether a real-time wallet notification should be sent.
    • The criteria for sending real-time wallet notifications and the templates they are based on are defined in the Prepaid Charging, Wallet Management window in the CCS user interface (UI), and replicated to the VWS. For more information about configuring real-time wallet notifications, see Charging Control Services User's Guide.
  • ccsNotification checks the E2BE database to establish whether the real-time notification uses an ACS template or a DAP template. For information about how real-time wallet notifications which are based on DAP templates are delivered, see DAP Notification Delivery.
  • ccsNotification looks up the text configured for the template in the database and creates the final notification text by substituting values for any variables. For information about configuring ACS notification templates, see Advanced Control Services User's Guide.
  • ccsNotification delivers the notification through the beServiceTrigger process.

Processes Used to Deliver Real-time Wallet Notifications

This table lists the main processes involved in sending real-time wallet notifications for delivery.

Process Role Further information
ccsNotification ccsNotification is a beVWARS event plug-in that generates a list of real-time wallet notifications for delivery. NA
beVWARS beVWARS is the main VWS process that supports the ccsNotification plug-in and handles interaction with the E2BE database. VWS Technical Guide
beServiceTrigger Delivers the notification to the subscriber. VWS Technical Guide

Startup

If ccsNotification is included in the beVWARS plugins array in eserv.config, beVWARS loads it during initialization.

To include ccsNotification in the beVWARS plugins configuration, use the following syntax:

plugins = [
    "ccsNotification.so"
]

For more information about the beVWARS plugins section, see Table 5-*.

Configuration

The ccsNotification beVWARS plug-in is configured by the notificationPlugin parameter group in the eserv.config file on the VWS:

notificationPlugin = {
    xmlInterfaceName = "name"
    cacheFlushPeriod = seconds
    cacheValidityTime = seconds
    useOldestExpiry = true|false
    UTCOffsetHours = hours
}

Parameters

ccsNotification plugin supports these parameters in the notificationPlugin section of eserv.config.

xmlInterfaceName

Syntax: xmlInterfaceName = "name"
Description: The name of the SLEE xml interface.
Type: String
Optionality: Required
Allowed:
Default: xmlIF
Notes:
Example: xmlInterfaceName = "xmlIF"

cacheFlushPeriod

Syntax: cacheFlushPeriod = seconds
Description: Sets the number of seconds between each clearance of the notification caches.
Type: Integer
Units: Seconds
Optionality: Required
Allowed:
Default: 200
Notes:
Example: cacheFlushPeriod = 200

cacheValidityTime

Syntax: cacheValidityTime = seconds
Description: The length of time, in seconds, an entry is kept before the entry's record is re-read.
Type: Integer
Optionality: Required
Allowed:
Default: 10
Notes:
Example: cacheValidityTime = 10

useOldestuseOldestExpiry

Syntax: useOldestExpiry = true|false
Description: When a subscriber's balance contains multiple buckets, this parameter specifies which bucket's expiration date to include in the real-time wallet notification.
Type: Boolean
Optionality: Optional (default used if not set)
Allowed:

true - Uses the bucket with the expiration date set the furthest in the future. For example, if Bucket A expires 1 Jan 2016, and Bucket B expires 1 Sep 2016, the real-time wallet notification includes Bucket B's expiration date.

false - Uses the bucket that expires first. For example, if Bucket A expires 1 Jan 2016, and Bucket B expires 1 Sep 2016, the real-time wallet notification includes Bucket A's expiration date.

Default: true
Notes:
Example: useOldestExpiry = true

UTCOffsetHours

Syntax: UTCOffsetHours = hours
Description:

For use in non-GMT/UTC time zones. The number of hours offset from Universal Coordinated Time (UTC) that are applied to wallet and balance expiry notifications.

The CCSNotification plug-in converts this parameter to seconds and applies the offset to all timestamp variables in wallet and balance expiry notifications.

Type: Integer
Optionality: Optional (default used if not set)
Allowed: + or - the number of hours. For example, +5 or -5.
Default: 0
Notes:
Example: UTCOffsetHours = +4

Example

This text shows an example ccsNotification configuration.

notificationPlugin = {
    xmlInterfaceName = "xmlIF"
    cacheFlushPeriod = 200
    cacheValidityTime = 10
    useOldestExpiry = true
    UTCOffsetHours = +3
}

ccsSLEEChangeDaemon

Purpose

The ccsSLEEChangeDaemon has three main functional areas:

  • Update assignment of periodic charges to wallets. The ccsSLEEChangeDaemon handles periodic charge changes such as a periodic charge being:
    • Added to CCS or being assigned to a product type
    • Removed from a product type or from CCS
  • Update assignment of Wallet Life Cycle Plans to wallets. The ccsSLEEChangeDaemon handles WLC changes such as a WLC plan being:
    • Added to CCS or being assigned to a product type
    • Removed from a product type or from CCS
  • It also handles balance expiry extensions, updating the balance types in the affected wallets by the defined extension configuration.

ccsSLEEChangeDaemon is a SLEE process which runs on the primary VWS node.

The daemon receives its tasks by reading CCS_PC_QUEUE table, which is hosted in the SMF database on the SMS and is replicated to the E2BE database on the VWS.

Startup

On start-up, ccsSLEEChangeDaemon finds the -r flag and will check for a node ID and run in primary VWS mode.

In order to start, ccsSLEEChangeDaemon must be referenced in the SLEE.cfg file. See Editing the SLEE.cfg.

Note:

If the daemon is started on a secondary VWS VWS it will immediately shut down.

Configuration

ccsSLEEChangeDaemon supports parameters from the ccsSLEEChangeDaemon parameter group in the eserv.config file on a Voucher and Wallet Server. It contains parameters arranged in the structure shown in the example below.

ccsSLEEChangeDaemon = { 
    # BE Client section. Mandatory.
    beClient = {
        # pollPeriod = 300
        # throttle = 1000
        # numCursorRows = 1000
        clientName = "be1_ccsSLEEChangeDaemon"
        # heartbeatPeriod = 30000000
        # connectionRetryTime = 5
        # messageTimeoutSeconds = 2
        # billingEngines = [
        # { id = 1, # pair ID
        # primary = { ip="PRIMARY_BE_IP", port=1500 },
        # secondary = { ip="SECONDARY_BE_IP", port=1500 }
        # }
        # ]
        # serviceTriggerTimeout = 5
} # beClient
} # ccsSLEEChangeDaemon

eserv.config parameters

ccsSLEEChangeDaemon supports the following parameters from the CCS section of eserv.config.

beClient

Syntax: beClient = { config }
Description: The configuration for the connection to the beServer on the VWS.
Type: Parameter group
Optionality: Mandatory
Allowed:
Default:
Notes:

This configuration is for the libBeClientIF library which ccsSLEEChangeDaemon uses to manage the connection.

For more information about this library, see VWS Technical Guide.

Example:

billingEngines

Syntax:

billingEngines = [

{ id = id

primary = { ip="ip", port=port },

secondary = { ip="ip", port=port }

}

]

Description:

Overrides connection details that beLocationPlugin obtains from the database.

For more information about the parameters included in the array, see billingEngines configuration for the ccsBeOrb process.

Type: Array.
Optionality: Optional.
Allowed:
Default:
Notes:

Identifies the Voucher and Wallet Servers and assigns their Internet connection details.

Include this section to ensure that ccsSLEEChangeDaemon only connects to the local domain. If omitted, ccsSLEEChangeDaemon will connect to all VWS domains.

Example:
billingEngines = [
    {   id = CHANGE_ME,
        primary = { ip="PRIMARY_BE_IP", port=1500 }, 
        secondary = { ip="SECONDARY_BE_IP", port=1500 } 
    }
]

clientName

Syntax: clientName = "name"
Description: The unique client name of the process.
Type: String
Optionality: Mandatory
Allowed: Must be unique.
Default: ccsSLEEChangeDaemon
Notes: If more than one client connects with the same name the BE server will drop the other, therefore name must be unique.
Example: clientName = "be1_ccsSLEEChangeDaemon"

connectionRetryTime

Syntax: connectionRetryTime = seconds
Description: The maximum number of seconds the client process will wait for a connection to succeed before attempting a new connection.
Type: Integer
Optionality: Required
Allowed:
Default: 5
Notes: This parameter is used by libBeClientIF.
Example: connectionRetryTime = 2

heartbeatPeriod

Syntax: heartbeatPeriod = microsecs
Description: The number of microseconds during which a Voucher and Wallet Server heartbeat message must be detected, or the BeClient process will switch to the other VWS in the pair.
Type: Integer
Optionality: Optional (Default used if not present)
Allowed:

0: Disable heartbeat detection.

positive integer: Heartbeat period.

Default: 30000000
Notes: 1 000 000 microseconds = 1 second.
Example: heartbeatPeriod = 30000000

throttle

Syntax: throttle = num
Description: The maximum number of Voucher and Wallet Server updates per second.
Type: Integer
Optionality: Optional (default used if not set).
Allowed:

0: Disable throttling (no limit).

positive integer: update limit

Default: 1000
Notes:
Example: throttle = 1000

maxOutstandingMessages

Syntax: maxOutstandingMessages = num
Description: The maximum number of messages allowed to be waiting for a response from the Voucher and Wallet Server.
Type: Integer
Optionality: Required
Allowed:
Default: If this parameter is not set, the maximum is unlimited.
Notes:

If more than this number of messages are waiting for a response from the Voucher and Wallet Server, the client process assumes the Voucher and Wallet Server is overloaded. In this event, the client process refuses to start new calls but continues to service existing calls.

The messages are queued until the Voucher and Wallet Server has reduced its outstanding load.

This parameter is used by libBeClientIF.

Example: maxOutstandingMessages = 100

messageTimeoutSeconds

Syntax: messageTimeoutSeconds = seconds
Description: The time that the client process will wait for the server to respond to a request.
Type: Integer
Units: Seconds
Optionality: Required
Allowed:

1-604800: number of seconds to wait.

0: do not time out.

Default: 2
Notes:

After the specified number of seconds, the client process will generate an exception and discard the message associated with the request.

This parameter is used by libBeClientIF.

Example: messageTimeoutSeconds = 2

numCursorRows

Syntax: numCursorRows = num
Description: The maximum number of cursor rows processed on the VWS when doing balance extensions.
Type: Integer
Optionality: Optional (default used if not set).
Allowed: Any number between 100 and 1000000. The closest number divisible by 100 will be used.
Default: 1000
Notes:
Example: numCursorRows = 1000

plugins

Syntax:
plugins = [
    {
        config=""
        library="lib"
        function="str"
    }
    ...
]
Description: Defines any client process plug-ins to run. Also defines the string which maps to their configuration section.
Type: Parameter array
Optionality: Optional (as plug-ins will not be loaded if they are not configured here, this parameter must include any plug-ins which are needed to supply application functions; for more information about which plug-ins to load, see the BeClient section for the application which provides the BeClient plug-ins).
Allowed:
Default: Empty (that is, do not load any plug-ins).
Notes:

The libclientBcast plug-in must be placed last in the plug-ins configuration list.

For more information about the libclientBcast plug-in, see VWS Technical Guide.

This parameter is used by libBeClientIF.

Example:
plugins = [
    {
        config="broadcastOptions"
        library="libclientBcast.so"
        function="makeBroadcastPlugin"
    }
]

config

Syntax: config="name"
Description: The name of the configuration section for this plug-in. This corresponds to a configuration section within the plugins section in the eserv.config file.
Type: String
Optionality: Required (must be present to load the plug-in)
Allowed:
Default: No default
Notes:
Example: config="voucherRechargeOptions"

function

Syntax: function="str"
Description: The function the plug-in should perform.
Type: String
Optionality: Required (must be present to load the plug-in)
Allowed:
Default: No default
Notes:
Example: function="makeVoucherRechargePlugin"

library

Syntax: library="lib"
Description: The filename of the plug-in library.
Type: String
Optionality: Required (must be present to load the plug-in)
Allowed:
Default: No default
Notes:
Example: library="libccsClientPlugins.so"

reportPeriodSeconds

Syntax: reportPeriodSeconds = seconds
Description: The number of seconds separating reports of failed messages.
Type: Integer
Units: Seconds
Optionality: Required
Allowed: -
Default: 10
Notes:

BeClient issues a failed message report:

  • For timed-out messages
  • For unrequested responses
  • For new calls rejected because of congestion
  • For messages with invalid Voucher and Wallet Server identifiers
  • If new and subsequent requests fail because both Voucher and Wallet Servers have stopped working

VWS heartbeat detection must be enabled for the parameter to work. Set reportPeriodSeconds to more than heartbeatPeriod.

This parameter is used by libBeClientIF.

Example: reportPeriodSeconds = 10

serviceTriggerTimeout

Syntax: serviceTriggerTimeout = seconds
Description: The maximum duration, in seconds, the change daemon waits for beServiceTrigger response when control plans are triggered through the OSD interface
Type: Integer
Optionality: Optional (default used if not set).
Allowed:
Default: 5
Notes:
Example: serviceTriggerTimeout = 5

BE eserv.config parameters

The following parameters are available in the BE section of the eserv.config.

amPrimary

Syntax: amPrimary = true|false
Description: True if this is the primary VWS in the pair.
Type: Boolean
Optionality: Optional, default used if not set
Allowed:
Default: true
Notes:
Example: amPrimary = false

beLocationPlugin

Syntax: beLocationPlugin = "lib"
Description: The plug-in library that finds the Voucher and Wallet Server details of the Voucher and Wallet Servers to connect to.
Type: String
Optionality: Optional (default used if not set)
Allowed:
Default: libGetccsBeLocation.so
Notes: This library must be in the LD_LIBRARY_PATH.
Example: beLocationPlugin = "libGetccsBeLocation.so"

serverId

Syntax: serverId = id
Description: The ID of the VWS pair.
Type: Integer
Optionality:
Allowed:
Default: 1
Notes: Set to 1 if this is not a VWS
Example: serverId = 11

Command line parameter

ccsSLEEChangeDaemon supports the following command-line switch.

ccsSLEEChangeDaemon -r id

-r

Syntax: -r id
Description: The node ID of the VWS node on which the ccsSLEEChangeDaemon is running.
Type: Integer
Optionality: Optional (default used if not set).
Allowed:
Default: If not set, will not start.
Notes: Node number must be between 512 and 1023.
Example: -r 531

Failure

While ccsSLEEChangeDaemon is down, periodic charge assignment updates will not be run on the local machine. In addition, wallet updates for balance expiry extensions will not be processed.

This table describes the recovery and failure files used by ccsSLEEChangeDaemon to attempt to recover after a failure.

File Details
.recovery

These files are only written on the VWS VWS. They have the following naming convention:

.recovery.ACSCustomerID.CCS_PC_QUEUE.ID

These files are written for a every 100th row processed and also on VWS "No Connection" error.

The file should contain one line. For periodic charge updates it will contain:

SubscriberId|WalletId

For balance expiry extensions it will contain:

WalletId

Each time ccsSLEEChangeDaemon writes one of these files, it will also raise a Warning level alarm.

If ccsSLEEChangeDaemon fails while processing a batch, it will reprocess CCS_PC_QUEUE from the point recorded in the .recovery file.

These files are automatically deleted by ccsSLEEChangeDaemon.

.failed

These files are written on both the SMS and the VWS. They have the following naming convention:

.failed.<ACS Customer ID>.<CCS_PC_QUEUE.ID>

An entry is written to this file for each wallet update which initially fails. They contain a line for each failure:

  • For periodic charge and WLC updates:

    SubscriberId|WalletId|PeriodicChargeBalanceTypeId|ProductId|ChangeAction

  • For balance expiry extensions:

    SubscriberId|WalletId|PeriodicChargeBalanceTypeId|PCQProductId|PCQNumMonths|PCQNumDays

Each time ccsSLEEChangeDaemon adds an entry to this file, it will also raise an Error level alarm. ccsSLEEChangeDaemon reads the entries in this file and attempts to reprocess them. Once all the entries in the file have been reprocessed, the ccsSLEEChangeDaemon deletes them.

failed

These files are written on both the SMS and the VWS. They have the following naming convention:

failed.<ACS Customer ID>.<CCS_PC_QUEUE.ID>

An entry is written to this file every time an entry in the .failed file is resent, and fails a second time. This file's first two lines are:

# Periodic Charge Change Daemon: failed updates # SubscriberId|WalletId|PeriodicChargeBalanceTypeId|ChangeType|ChangeAction|DomainId|NumberofBalanceTypes[|BalanceTypeId|BucketId|BucketValue[|...]]

Then there is an entry for each wallet update which fails a second time:

SubscriberId|WalletId|PeriodicChargeBalanceTypeId|ChangeType|ChangeAction|DomainId|NumberofBalanceTypes[|BalanceTypeId|BucketId|BucketValue[|...]]

For balance expiry extensions on the VWS VWS the entry is:

SubscriberId|WalletId|PeriodicChargeBalanceTypeId|PCQProductId|PCQNumMonths|PCQNumDays

Each time ccsSLEEChangeDaemon writes an entry to this file, it will raise an Error level alarm.

failure files are left for manual recovery.

Note:

If an operation fails due to a "No Connection" error, ccsSLEEChangeDaemon will raise a LOGGED_WARNING and stop processing the row.

Output

ccsSLEEChangeDaemon writes recovery and failure logs for period charge updates to /IN/service_packages/CCS/logs/ccsSLEEChangeDaemon/ccsPCChange/.

ccsSLEEChangeDaemon writes recovery and failure logs for balance expiry extensions to /IN/service_packages/CCS/logs/ccsSLEEChangeDaemon/ccsBalExtension/.

If one of these files cannot be written to, the ccsSLEEChangeDaemon will exit with a critical error (for alarm details, see CCS Alarms Reference Guide).

ccsSLEEChangeDaemon writes error messages to the system messages file, and also writes additional output to /IN/service_packages/CCS/tmp/ccsSLEEChangeDaemon.log.

ccsPDSMSPlugin

Purpose

ccsPDSMSPlugin handles the promotional destination of notifications. The configuration identifies the balance type that holds the number of promotional notifications sent by the customer.

It is triggered by wallet activated and bucket expiry events.

Startup

If ccsPDSMSPlugin is included in the beVWARS plugins array in eserv.config, it is loaded by beVWARS when beVWARS is initialized.

It is included in the following lines:

plugins = [
    "ccsPDSMSPlugin.so"
]

For more information about the beVWARS plugins section, see background-processes-vws1.html#GUID-6896447A-C166-4545-985B-725C0C34878B__GUID-F2172538-04BC-4EEF-8824-BC98DEB70292.

Note: Other event plug-ins may also be included in the plugins array.

Parameters

Parameters for ccsPDSMSPlugin are contained in the ccsPromotionalDestinationSMS section of the eserv.config file. The following parameters are supported.

balanceTypes

Syntax: balanceTypes = [config ]
Description: A list parameter containing identifiers for service providers. For each service provider (ACS customer) configure parameters for the PDSMS balance type.
Type: Array
Optionality: Mandatory
Allowed:
Default:
Notes:
Example:

ServiceProviderID

Syntax: ServiceProviderID = id
Description: The identification number of an ACS customer.
Type: Integer
Optionality: Mandatory. At least one ID must be mapped.
Allowed:
Default: 1
Notes:
Example: ServiceProviderID = 1

ThresholdCacheValidityPeriod

Syntax: ThresholdCacheValidityPeriod = minutes
Description: The number of minutes between threshold table refreshes from DB.
Type: Integer
Optionality: Mandatory
Allowed:
Default: 10
Notes: Each threshold table is cached for performance reasons. This period indicates how long each cached table remains valid before being flushed and repopulated from the database.
Example: ThresholdCacheValidityPeriod = 10

TypeID

Syntax: TypeID = id
Description: The PDSMS balance type number for the ACS customer.
Type: Integer
Optionality: Mandatory
Allowed:
Default:
Notes:
Example: TypeID = 7

Example

An example of the ccsPromotionalDestinationSMS parameter group of a Voucher and Wallet Server eserv.config file is listed below. Comments have been removed.

ccsPromotionalDestinationSMS = {
    balanceTypes = [
        {
            ServiceProviderID = 1
            TypeID = 7
        }
        {
            ServiceProviderID = 2
            TypeID = 8
        } 
        {
            ServiceProviderID = 3
            TypeID = 5
        }
    ]
    ThresholdCacheValidityPeriod = 10
}

ccsRewardsPlugin

Purpose

ccsRewardsPlugin handles the balance changes due to heavy use rewards. For more information about heavy user rewards, see Recharges.

This plug-in triggers on wallet activated, bucket value changed and bucket expiry events.

Startup

If ccsRewardsPlugin is included in the beVWARS plugins array in eserv.config,it is loaded by beVWARS when beVWARS is initialized.

It is included in the following lines:

plugins = [
    "ccsRewardsPlugin.so"
]

For more information about the beVWARS plugins section, see background-processes-vws1.html#GUID-6896447A-C166-4545-985B-725C0C34878B__GUID-F2172538-04BC-4EEF-8824-BC98DEB70292.

Note:

Other event plug-ins may also be included in the plugins array.

Parameters

The ccsRewardsPlugin supports the following parameters from the CCS.ccsRewards section of eserv.config.

balanceTypes

Syntax: balanceTypes = [config]
Description: This section configures which the balance types can be used for rewards for each service provider.
Type: Parameter array
Optionality: Mandatory for ccsRewardsPlugin.
Allowed:
Default: None
Notes: You need to add a new service provider in this config file each time one is added in the database.
Example:
balanceTypes = [{
    id = 1
    allowed = [ 1 ]
    expenditure = 4
    notification = [ 1 
}
{
    id = 2
    allowed = [ 5,6 ]
    expenditure = 7
}
]

allowed

Syntax: allowed = [ <id>,...]
Description: Lists the balance types that can contribute towards monthly expenditure.
Type: Array
Optionality: Mandatory if expenditure rewards are used.
Allowed:
Default: None
Notes:

Must match balance type ids in E2BE database.

This is part of the Table 3-* parameter array.

Example: allowed = [ 1,2,8 ]

expenditure

Syntax: expenditure = [ id,... ]
Description: The balance type for the monthly expenditure.
Type: Array
Optionality: Mandatory if monthly expenditure is used.
Allowed:
Default:
Notes:

Must match balance type IDs in E2BE database.

This parameter is part of the Table 3-* array.

Example: expenditure = [ 4 ]

id

Syntax: id = id
Description: The service provider ID for the balance types.
Type: Integer
Optionality: Required
Allowed:
Default:
Notes:

Must match service provider ID in E2BE database.

This parameter is part of the Table 3-* array.

Example: id = 1

notification

Syntax: notification = [ id,... ]
Description: Lists the balance types to go in notification short message.
Type: Array
Optionality: Mandatory if notifications are to report any balance types.
Allowed:
Default: None
Notes:

Must match balance type ids in E2BE database.

This parameter is part of the Table 3-* array.

Example: notification = [ 1,8 ]

cacheFlushPeriod

Syntax: cacheFlushPeriod = seconds
Description: The number of seconds before the reward definition caches are cleared and reloaded.
Type: Integer
Optionality: Optional (default used if not set).
Allowed: 600
Default:
Notes:
Example: cacheFlushPeriod = 600

cacheValidityTime

Syntax: cacheValidityTime = seconds
Description: The number of seconds entries are valid for, before a re-read for that reward definition record is required.
Type: Integer
Optionality: Optional (default used if not set).
Allowed:
Default: 30
Notes: When ccsRewardsPlugin needs to look up a reward definition, it will check whether the reward definition in the cache is older than this number of seconds. If it is, ccsRewardsPlugin will refresh the cache entry for that reward definition.
Example: cacheValidityTime = 30

cmnPushFiles = [ ]

For the eserv.config on the VWS, use the cmnPushFiles configuration to transfer files to the SMS ready for processing by ccsRewardsBatch. Include the -F option to detect the file in use.

Note:

These directories must match the respective directories set in Table 5-* and readDirectoryName.

For more information about configuring cmnPushFiles, see cmnPushFiles.

fileIdleTime

Syntax: fileIdleTime = seconds
Description: The maximum number of seconds an output file from the ccsRewardsPlugin can be idle before the plug-in will close it.
Type: Integer
Optionality: Optional (default used if not set).
Allowed:
Default: 10
Notes:
Example: fileIdleTime = 30

filePrefix

Syntax: filePrefix = "prefix"
Description:

The prefix for files:

  • Written by ccsRewardsPlugin to Table 5-*
  • Read by ccsRewardsBatch from readDirectoryName
Type: String
Optionality: Optional (default used if not set).
Allowed:
Default: "ccsRewards"
Notes:
Example: filePrefix = "ubeprod01-rewards-"

fileSuffix

Syntax: fileSuffix = "suffix"
Description:

The suffix for files:

  • Written by ccsRewardsPlugin to Table 5-*
  • Read from ccsRewardsBatch from readDirectoryName
Type: String
Optionality: Optional (default used if not set).
Allowed:
Default: ".txt"
Notes:
Example: filesuffix = ".txt"

maxLinesInFile

Syntax: maxLinesInFile = num
Description: The maximum number of lines in an output file before it is closed.
Type: Integer
Optionality: Optional (default used if not set).
Allowed:
Default: 100
Notes:
Example: maxLinesInFile = 500

oracleUserPass

Syntax:
Description: User name and password for connecting to local database (SMF).
Type:
Optionality: This parameter is optional.
Allowed:
Default: "/"
Notes:
Example:

writeDirectoryName

Syntax: writeDirectoryName = "dir"
Description: Name of the directory where ccsRewardsPlugin writes its output files.
Type: String
Optionality: Optional (default used if not set).
Allowed:
Default: "/IN/service_packages/CCS/logs/ccsRewardsWrite/"
Notes:
Example: writeDirectoryName = "/var/logs/Rewards/"

Example

This text shows an example of the ccsRewards section of eserv.config.

ccsRewards = {
    oracleUserPass = "/"
    fileIdleTime = 10
    maxLinesInFile = 100
    
    writeDirectoryName = "/IN/service_packages/CCS/logs/ccsRewards/"
    readDirectoryName = "/IN/service_packages/CCS/logs/ccsRewards/"
    filePrefix = "ccsRewards"
    fileSuffix = ".txt"

    cmnPushFiles = [
        "-d", "/IN/service_packages/CCS/logs/ccsRewards/"
        "-r", "/IN/service_packages/CCS/logs/ccsRewards/"
        "-h", "ctelsmp"
        "-p", "2027"
        "-F"
    ]
    balanceTypes = [
        {
            id = 1
            allowed = [ 1 ]
            expenditure = 4
            notification = [ 1 ]
        }
        {
            id = 2
            allowed = [ 5,6 ]
            expenditure = 7
        }
    ]

    cacheFlushPeriod = 600
    cacheValidityPeriod = 30
}

Note:

This section is also used by ccsRewardsBatch on the SMS and ccsMacroNodes on the SLC.

ccsPMXPlugin

Purpose

ccsPMXPlugin handles the balance changes due to promotions. This plug-in triggers on wallet and balance events, for example:

  • Wallet activation
  • Wallet expiry
  • Balance expiry
  • Balance charge
  • Balance recharge
  • Tracker threshold
  • Tracker expiry

This plug-in receives an event and attempts to apply the promotion definitions that match the event type. Matching promotions will be applied providing the conditions configured in the promotion definition are met.

Note: Promotions are configured in the Promotion Manager screen.

Licence

ccsPMXPlugin is only available if the Promotion Manager license has been purchased.

Startup

If ccsPMXPlugin is included in the beVWARS plugins array in eserv.config, it is loaded by beVWARS when beVWARS is initialized.

It is included in the following lines:

plugins = [
    "ccsPMXPlugin.so"
]

For more information about the beVWARS plugins section, see background-processes-vws1.html#GUID-6896447A-C166-4545-985B-725C0C34878B__GUID-F2172538-04BC-4EEF-8824-BC98DEB70292.

Note:

Other event plug-ins may also be included in the plugins array.

Parameters

The ccsPMXPlugin supports the following parameters from the CCS.ccsPMXPlugin section of eserv.config.

cacheValidityTime

Syntax: cacheValidityTime = seconds
Description: The length of time in seconds that an entry will be valid for, before the promotion definition record must be reloaded.
Type: Integer
Optionality: Optional (default used if not set).
Allowed: Numerical value
Default: 30
Notes: When ccsPMXPlugin needs to look up a promotion definition, it will check whether the promotion definition in the cache is older than this number of seconds. If it is, ccsPMXPlugin will refresh the cache entry for that promotion definition.
Example: cacheValidityTime = 30

ccsBplServiceHandle

Syntax: ccsBplServiceHandle = "service_name"
Description: The service name to use when triggering a control plan to recharge third-party balance types.
Type: String
Optionality: Optional (default used if not set).
Allowed:
Default: "CCS_BPL"
Notes: For the control plan to trigger ACS and the SLEE must be configured with this service name mapped to the CCS service loader.
Example: ccsBplServiceHandle = "CCS_BPL"

dapInterfaceName

Syntax: dapInterfaceName = "name"
Description: The name of the DAP interface running on the VWS
Type: String
Optionality: Optional (default used if not set).
Allowed: A valid DAP interface name
Default: dapIF
Notes:
Example: dapInterfaceName = "dapIF"

rechargeControlPlan

Syntax: rechargeControlPlan = "name"
Description: The name of the control plan to use for recharging third-party balance types.
Type: String
Optionality: Optional (default used if not set).
Allowed: Either a predefined Promotion Manager control plan or an Open Notifications eRetail control plan.
Default: "CCS_WebService_Recharge"
Notes: The Promotion Manager control plan must contain a Voucher Type Recharge node to recharge the third party balance type.
Example: rechargeControlPlan = "CCS_WebService_Recharge"

rechargeOperationName

Syntax: rechargeOperationName = "name"
Description: The name of the OSD operation to use when triggering a control plan to recharge a third-party.
Type: String
Optionality: Optional (default used if not set).
Allowed: A valid OSD operation name.
Default: "applyReward"
Notes:
Example: rechargeOperationName = "applyReward"

Example

This text shows an example of the ccsPMXPlugin section of eserv.config.

ccsPMXPlugin = {
    cacheValidityTime = 30
    rechargeControlPlan = "CCS_WebService_Recharge"
    ccsBplServiceHandler = "CCS_BPL"
    rechargeOperationName = "applyReward"
    dapInterfaceName = "dapIF"
}

ccsVWARSActivation

Purpose

This beVWARS plug-in activates wallets, and optionally credits them with the appropriate balances (from the product type).

Note:

If the VWS is defined as a tracking domain only, then only tracking domain balances (fraud and expense balance types) will be updated.

On activation of a wallet (wallet activation event, state change from PreUse to Active), from:

  • The product type (CCS_ACCT_TYPE): set the wallet expiry date to the current time + INIT_ACCT_EXPIRY_PERIOD
  • CCS_PROMOTION: give the Wallet the promotional amount for the selected balance type and set the expiry date
  • The product type (CCS_ACCT_TYPE): set the bucket expiry dates to the current time + EXPIRATION

Note:

This can include free SMS buckets.

For more information about wallet states, see VWS Technical Guide.

Startup

If ccsVWARSActivation is included in the beVWARS plugins array in eserv.config, it is loaded by beVWARS when beVWARS is initialized.

It is included in the following lines:

plugins = [
    "ccsVWARSActivation.so"
]

For more information about the beVWARS plugins section, see background-processes-vws1.html#GUID-6896447A-C166-4545-985B-725C0C34878B__GUID-F2172538-04BC-4EEF-8824-BC98DEB70292.

Note:

Other event plug-ins may also be included in the plugins array.

Parameters

The ccsVWARSActivation handler supports the following parameters in the CCS section of eserv.config.

accountBatchCacheValidityPeriod

Syntax: accountBatchCacheValidityPeriod = seconds
Description: Time to leave entries in the CCS_ACCT_BATCH cache.
Type: Integer
Optionality: Optional.
Allowed:
Default: 60
Notes:
Example: accountBatchCacheValidityPeriod = 60

alwaysOverwriteBucketExpiry

Syntax: alwaysOverwriteBucketExpiry = true|false
Description: If true, always set the wallet's buckets' expiry dates, even if these are earlier than the existing bucket's expiry dates.
Type: Boolean
Optionality: Optional.
Allowed: true, false
Default: false
Notes:
Example: alwaysOverwriteBucketExpiry = false

alwaysOverwriteNonExpiringBucketExpiry

Syntax: alwaysOverwriteNonExpiringBucketExpiry = true|false
Description: If the existing bucket never expires, overwrite the expiry date.
Type: Boolean
Optionality: This parameter is optional.
Allowed: true, false
Default: true
Notes:
Example: alwaysOverwriteNonExpiringBucketExpiry = true

alwaysOverwriteNonExpiringWalletExpiry

Syntax: alwaysOverwriteNonExpiringWalletExpiry = true|false
Description: If the existing wallet never expires, overwrite the expiry date.
Type: Boolean
Optionality: Optional.
Allowed: true, false
Default: true
Notes:
Example: alwaysOverwriteNonExpiringWalletExpiry = true

alwaysOverwriteWalletExpiry

Syntax: alwaysOverwriteWalletExpiry = true|false
Description: If true, always set the wallet expiry date, even if this is earlier than the existing wallet expiry date.
Type: Boolean
Optionality: Optional.
Allowed: true, false
Default: false
Notes:
Example: alwaysOverwriteWalletExpiry = false

Example

An example of the ccsVWARSActivation parameter group of a Voucher and Wallet Server eserv.config file is listed below. Comments have been removed.

ccsVWARSActivation = {
    accountBatchCacheValidityPeriod = 60
    alwaysOverwriteWalletExpiry = false
    alwaysOverwriteNonExpiringWalletExpiry = true
    alwaysOverwriteBucketExpiry = false
    alwaysOverwriteNonExpiringBucketExpiry = true
}

ccsVWARSAmountHandler

Purpose

beVWARS handler for handling messages relating to rate requests (seconds and named events) and OSA CHAM amounts.

Startup

If ccsVWARSAmountHandler is included in the beVWARS handlers array in eserv.config, it is loaded by beVWARS when beVWARS is initialized.

handlers = [
    "ccsVWARSAmountHandler.so"
]

For more information about the beVWARS handlers section, see handlers.

Note:

Other handlers may also be included in the handlers array.

Configuration

ccsVWARSAmountHandler is configured by the amountHandler section of eserv.config. This text shows an example of the section.

amountHandler = {
    syslogErrors = true|false
}

ccsVWARSAmountHandler must also have the appropriate not end actions configured in the beServer section.

{type="IARR", action="ACK "}
{type="SARR", action="ACK "}
{type="SARR", action="NACK"}

syslogErrors

Syntax: syslogErrors = true|false
Description: Whether or not to log unspecified wallet errors for IARR and DA messages.
Type: Boolean
Optionality: Optional (default used if not set).
Allowed:

true: Log the errors to the syslog

false: Do not log the errors to the syslog

Default: false
Notes: The logging of specific wallet errors is not be affected by this parameter.
Example: syslogErrors = false

ccsVWARSExpiry

Purpose

ccsVWARSExpiry is a beVWARS event plug-in which maintains wallet states. This includes:

  • Triggering on wallet queries to:
    • Expire PreUse wallets if their subscriber account batch has expired (it also stops actions being taken on PreUse wallets with inactive subscriber account batches)
    • Move wallets from Dormant to Active if they have been used
    • Move wallets from Active to Dormant or Dormant to Terminated if they have not been used for a configurable period of time
    • Remove wallets which have been in a Terminated state for a configurable period of time
    • If expiryAtMidnightTZ is set to true, expire periodic charge buckets
  • Triggering on wallet expiry to remove wallets
  • Logging wallet removals (this can also be sent to the HLR to update HLR MSISDN records)
  • Writing EDRs for most changes (including state changes and removals and bucket removals).

For more information about how ccsVWARSExpiry works with ccsWalletExpiry to manage wallet expiry and removal, see Subscriber Accounts and Wallet Management.

For more information about subscriber account batches, see Charging Control Services User's Guide.

Note: Wallets and buckets can also be expired by the VWS beVWARS plug-in beVWARSExpiry. For more information about beVWARSExpiry, see VWS Technical Guide.

Startup

If ccsVWARSExpiry is included in the beVWARS plugins array in eserv.config, it is loaded by beVWARS when beVWARS is initialized.

It is included in the following lines:

plugins = [
    "ccsVWARSExpiry.so"
]

For more information about the beVWARS plugins section, see Table 5-*.

Note:

Other event plug-ins may also be included in the plugins array.

Configuration

The ccsVWARSExpiry beVWARS plug-in supports parameters from the notificationPlugin parameter group in the eserv.config file on a VWS. It contains parameters arranged in the structure shown below.

Note:

This configuration is also used by ccsWalletExpiry on the SMS.

ccsVWARSExpiry = {
        expiredPrefix = "prefix"
        expiredDirectory = "dir"
        expiredSuffix = "suffix"
        expiredMaxAge = seconds
        expiryWalletStates = "str[...]"
        produceCDRForWalletExpiredBucket = true|false
        removedDirectory = "dir"
        removedPrefix = "prefix"
        removedSuffix = "suffix"
        removedMaxAge = seconds

        accountBatchCacheValidityPeriod = seconds
        logNotRemoveWallet = true|false
        
        removeAtMidnightTZ = "tz"
        cmnPushFiles = [
            "-d", "dir"
            "-r", "dir"
            "-h", "host"
            "-p", "host"
            "-F"
        ]
        deleteEmptyBalances = true|false
}

Note:

ccsVWARSExpiry also uses the expireAtMidnightTZ parameter which is set in the BE.beVWARSExpiry section.

Parameters - CCS section

ccsVWARSExpiry supports the following parameters from the CCS section of eserv.config.

accountBatchCacheValidityPeriod

Syntax: accountBatchCacheValidityPeriod = seconds
Description: The number of seconds an item may stay in the subscriber account batch (CCS_ACCT_BATCH) cache before being re-read from the E2BE database.
Type: Integer
Optionality: Optional (default used if not set).
Allowed:
Default: 60
Notes:
Example: accountBatchCacheValidityPeriod = 120

cmnPushFiles = [ ]

Syntax: cmnPushFiles = []
Description: For the eserv.config on the VWS, use the cmnPushFiles configuration to transfer files to the SMS ready for processing by ccsExpiryMessageLoader.
Type: Parameter array
Optionality: Mandatory
Allowed:
Default:
Notes:

Include the -F option to detect the file in use. See cmnPushFiles for all parameters.

These directories must match the respective directories set in generatorFiledir.

Example:

createEdrForExpiredValue

Syntax: createEdrForExpiredValue = "nonzero"|"all"
Description:

Sets whether or not to create an EDR for expired balances with 0 (zero) value. When createEdrForExpiredValue is set to:

  • "all", ccsVWARSExpiry creates an EDR for all expired balances including those with 0 value
  • "nonzero", ccsVWARSExpiry creates an EDR only for expired balances that are greater than 0
Type: String
Optionality: Optional (default used if not set)
Allowed: all, nonzero
Default: nonzero
Notes:
Example: createEdrForExpiredValue = "all"

deleteEmptyBalances

Syntax: deleteEmptyBalances = true|false
Description: If set, ccsVWARSExpiry will delete balances that have both no buckets remaining and the "delete" flag set.
Type: Boolean
Optionality: Optional (default used if not set).
Allowed: true, false
Default: false
Notes:
Example: deleteEmptyBalances = false

expiredDirectory

Syntax: expiredDirectory = "dir"
Description: Defines the location of files listing wallets moving to terminated state.
Type: String
Optionality: Optional (default used if not set).
Allowed:
Default: "/IN/service_packages/CCS/logs/wallet"
Notes: The file is generated by ccsVWARSExpiry on the VWS and read by ccsWalletExpiry on the SMS.
Example: expiredDirectory = "/var/CCS/expiredWallets"

expiredMaxAge

Syntax: expiredMaxAge = seconds
Description: The number of seconds before closing file listing wallets moving to terminated state and creating a new one.
Type: Integer
Optionality: Optional (default used if not set).
Allowed:
Default: 60
Notes: The file is generated by ccsVWARSExpiry on the VWS and read by ccsWalletExpiry on the SMS.
Example: expiredMaxAge = 120

expiredPrefix

Syntax: expiredPrefix = "prefix"
Description: The prefix of files listing wallets moving to terminated state.
Type: String
Optionality: Optional (default used if not set).
Allowed:
Default: "expiredWallet"
Notes:

The file is generated by ccsVWARSExpiry on the VWS and read by ccsWalletExpiry on the SMS.

The filename format is: expiredPrefix_YYYYMMDDHHMMSSexpiredSuffix

Example: expiredPrefix = "prodube01_termWallets"

expiredSuffix

Syntax: expiredSuffix = "suffix"
Description: The suffix of files listing wallets moving to Terminated state.
Type: String
Optionality: Optional (default used if not set).
Allowed:
Default: .log
Notes:

The file is generated by ccsVWARSExpiry on the VWS and read by ccsWalletExpiry on the SMS.

The filename format is: expiredPrefix_YYYYMMDDHHMMSSexpiredSuffix

Example: expiredSuffix = ".log"

expireNegativeExpenditureBuckets

Syntax: expireNegativeExpenditureBuckets = true|false
Description: If set, ccsVWARSExpiry will expire negative expenditure buckets.
Type: Boolean
Optionality: Optional (default used if not set).
Allowed: true, false
Default: false
Notes:
Example: expireNegativeExpenditureBuckets = false

expiryWalletStates

Syntax: expiryWalletStates = "str[...]"
Description: Specifies the valid wallet states when ccsVWARSExpiry processes bucket expirations.
Type: String
Optionality: Optional (default used if not set)
Allowed:
  • A – Active
  • D – Dormant
  • F – Frozen
  • P – Pre-use
  • S – Suspended
  • T – Terminated
Default: Active and Dormant
Notes:
Example: expiryWalletStates = "AD"

includeExpiredBalanceNames

Syntax: includeExpiredBalanceNames = true|false
Description: Whether or not to output the expired balance names in the BALANCE_TYPE_NAMES field in EDRs.
Type: Boolean
Optionality: Optional (default used if not set).
Allowed: true, false
Default: false
Notes:
Example: includeExpiredBalanceNames = false

logNotRemoveWallet

Syntax: logNotRemoveWallet = true|false
Description: ccsVWARSExpiry plugin will log, and not remove the wallet, so that screen queries will still succeed (they will fail if they have CCS rows but no wallet).
Type: Boolean
Optionality: Optional (default used if not set).
Allowed:

true: If ccsVWARSExpiry is processing a wallet which has been queried and is in the Terminated state, it will log the wallet's ID to the remove List. If ccsVWARSExpiry is processing a wallet which has been removed, no action will be taken.

false: If ccsVWARSExpiry is processing a wallet which has been queried and is in the Terminated state, it will:

  • Log an EDR detailing the wallet removal
  • Remove all the buckets associated with the wallet
  • Log EDRs for each bucket which is being removed
  • Remove the wallet

If ccsVWARSExpiry is processing a wallet which has been removed, it will log the wallet's ID to the remove List.

Default: true
Notes: If ccsVWARSExpiry does not remove the wallet, ccsWalletExpiry will remove the wallet when it processes the list of wallets to be removed from ccsVWARSExpiry.
Example: logNotRemoveWallet = false

produceCDRForWalletExpiredBucket

Syntax: produceCDRForWalletExpiredBucket = true|false
Description: Whether or not to produce an EDR for buckets which are expired because they are attached to a wallet which has expired.
Type: Boolean
Optionality: Optional (default used if not set).
Allowed:

false: The plug-in will not produce an EDR for a bucket which has been expired and has an expiry date in the future or no expire date (as can happen when it is expired as part of a wallet expiry). An EDR will still be produced if the bucket does have an expiry date in the past (so both the bucket and the wallet were due to expire)

true: A bucket expiry EDR will always be produced if the bucket is expired, whether the expiry date is past, present, or future, or it has no expiry date at all.

Default: false
Notes: For more information about when buckets are expired due to their wallet expiring, see VWS Technical Guide.
Example: produceCDRForWalletExpiredBucket = true

removeAtMidnightTZ

Syntax: removeAtMidnightTZ = "tz"
Description:

Sets wallets and buckets to be removed at midnight for the time zone specified:

  • Midnight GMT (UTC) following the expiry trigger from beVWARSExpiry
  • Midnight in the specified timezone after the expiry trigger from beVWARSExpiry
  • The time specified by the expiry date
Type: String
Optionality: Optional (default used if not set).
Allowed:

The time zone part of the parameter must be typed in a form that the operating system recognizes.

Alternatively you can select a time zone from the operating system's list. To view top-level time zone names, enter ls /usr/share/lib/zoneinfo from a shell. To see second-level time zone names, enter ls /usr/share/lib/zoneinfo TopLevelName/. For example, to verify that the operating system recognizes a time zone name for DeNoranha, in Brazil, you would enter ls /usr/share/lib/zoneinfo/Brazil/. DeNoranha is listed, so the time zone name would be "Brazil/DeNoranha".

Default: Use time specified by the expiry date.
Notes:

The wallet is expired by beVWARSExpiry depending on its configuration. However, will be expired when the wallet is next processed by beVWARSExpiry. The timing of the beVWARSExpiry processing depends on the activity on the VWS. Generally, beGroveller will process the wallet To remove the wallets during the night, the groveller must be set to start after midnight, but before any other access is likely to happen.

A list of time zones can be found in the Time Zones appendix of ACS Technical Guide.

Example 1: removeAtMidnightTZ = "GMT0"
Example 2: removeAtMidnightTZ = "Brazil/DeNoranha"

removedDirectory

Syntax: removedDirectory = "dir"
Description: Defines the location of files listing wallets being removed.
Type: String
Optionality: Optional (default used if not set).
Allowed:
Default: "/IN/service_packages/CCS/logs/wallet"
Notes: The file is generated by ccsVWARSExpiry on the VWS and read by ccsWalletExpiry on the SMS.
Example: removedDirectory = "/var/CCS/removedWallets"

removedMaxAge

Syntax: removedMaxAge = seconds
Description: The number of seconds before closing file listing wallets being removed and creating a new one.
Type: Integer
Optionality: Optional (default used if not set).
Allowed:
Default: 60
Notes:

The file is generated by ccsVWARSExpiry on the VWS and read by ccsWalletExpiry on the SMS.

Whether ccsVWARSExpiry or ccsWalletExpiry removes the wallet depends on Table 5-*.

Example: removedMaxAge = 120

removedPrefix

Syntax: removedPrefix = "prefix"
Description: The prefix of files listing wallets being removed from the system.
Type: String
Optionality: Optional (default used if not set).
Allowed:
Default: "removedWallet"
Notes:

The file is generated by ccsVWARSExpiry on the VWS and read by ccsWalletExpiry on the SMS.

Whether ccsVWARSExpiry or ccsWalletExpiry removes the wallet depends on Table 5-*.

The filename format is: removedPrefix_YYYYMMDDHHMMSSremovedSuffix

Example: removedPrefix = "prodube01_removeWallets"

removedSuffix

Syntax: removedSuffix = "suffix"
Description: The suffix of files listing wallets being removed from the system.
Type: String
Optionality: Optional (default used if not set).
Allowed:
Default: .log
Notes:

The file is generated by ccsVWARSExpiry on the VWS and read by ccsWalletExpiry on the SMS.

Whether ccsVWARSExpiry or ccsWalletExpiry removes the wallet depends on Table 5-*.

The filename format is: removedPrefix_YYYYMMDDHHMMSSremovedSuffix

Example: removedSuffix = ".log"

renewPCAtMidnightTZ

Syntax: renewPCAtMidnightTZ = "tz"
Description: If specified, sets periodic charge balances to expired from midnight (00:00 hrs; the beginning of the day) on the expiry date for the time zone specified.
Type: String
Optionality: Optional (default used if not set)
Allowed: A valid time zone. For more information, see the Time Zones appendix of ACS Technical Guide.
Default: Not set
Notes:
Example: renewPCAtMidnightTZ = "NZ"

Parameters - BE section

ccsVWARSExpiry supports the following parameters from the BE section of eserv.config.

expireAtMidnightTZ

Syntax: expireAtMidnightTZ = "tz"
Description: Sets wallets and buckets to expire at midnight for the time zone specified.
Type: String
Optionality: Optional (default used if not set).
Allowed:

The time zone part of the parameter must be typed in a form that the operating system recognizes.

Alternatively you can select a time zone from the operating system's list. To view top-level time zone names, enter ls /usr/share/lib/zoneinfo from a shell. To see second-level time zone names enter ls /usr/share/lib/zoneinfo TopLevelName/. For example, to verify that the operating system recognizes a time zone name for DeNoranha, in Brazil, you would enter ls /usr/share/lib/zoneinfo/Brazil/. DeNoranha is listed, so the time zone name would be "Brazil/DeNoranha".

Default: false (do not modify expiry calculation).
Notes: A list of time zones can be found in the Time Zones appendix of ACS Technical Guide.
Example:

An account is created at 2 p.m. on 5 September 2006 and is set to have a life span of 24 days.

If the parameter expireAtMidnightTZ = "Asia/Vladivostok" is included, the account will expire on 29 September 2006 at midnight, Vladivostok time.

If this parameter is omitted, the account will expire on 29 September 2006 at 2 p.m.

ccsVWARSNamedEventHandler

Purpose

This beVWARS message handler performs the VWS-side processing of messages relating to named events. This includes:

  • Returning the desired cost for an event class and event name combination (discounts will be applied to the rates returned)
  • Generating named event EDRs

Tariffs are based on the information replicated to the CCS part of the E2BE database.

Named events include GSM notifications, product type swaps, and other discrete billing events. Named events can be performed as either a single-shot or a reserve/commit pair. The type of transaction used will depend on the service's requirement to reverse the charge from the customer based on other events.

Startup

If ccsVWARSNamedEventHandler is included in the beVWARS handlers array in eserv.config, it is loaded by beVWARS when beVWARS is initialized.

handlers = [
    "ccsVWARSNamedEventHandler.so"
]

For more information about the beVWARS handlers section, see handlers.

Note: Other handlers may also be included in the handlers array.

Configuration

The ccsVWARSNamedEventHandler beVWARS handler supports parameters from the namedEventHandler parameter group in the eserv.config file on a Voucher and Wallet Server. It contains parameters arranged in the structure shown below.
namedEventHandler = {
      maxWalletLockLength = millisecs
      # cascade to use for non promotional Named Events  CascadeNamesByAcsId = [ 
        { 
    
      acsCustomerId =
            ID1
      cascade = "name"
      }
      { 
    
      acsCustomerId =
            ID2
      cascade = "name" 
    
      } 
    
      ] 
    
      # cascade to use
          for promotional Named Events 
    
      PromoCascadeNamesByAcsId = [ 
    
      { 
    
      acsCustomerId =
            ID1
      promo_cascade =
            "promo_name" 
    
      } 
    
      {
      acsCustomerId =
            ID2
      promo_cascade =
            "promo_name" 
    
      } 
    
      ]
      reservationPeriod =
            millisecs
      reservationPeriodTolerance = seconds
      eventCacheAgeSeconds = seconds
      activatePreuseAccount = true|false
      roundingRuleType = "type"
}

Parameters

The ccsVWARSNamedEventHandler supports the following parameters in the namedEventHandler section of eserv.config.

activatePreuseAccount

Syntax: activatePreuseAccount = true|false
Description: When true, activate pre-use wallets for NE and INER requests.
Type: Boolean
Optionality:
Allowed: true, false
Default: true
Notes:
Example: activatePreuseAccount = true

acsCustomerId

Syntax: acsCustomerID = ID
Description: The ID of the ACS customer.
Type: Integer
Optionality: Required
Allowed: A valid ID for an existing ACS customer.
Default:
Notes:
Example: acsCustomerID = 12

CascadeNamesByAcsId

Syntax:
CascadeNamesByAcsId = [
{ 
acsCustomerId = ID1
cascade = "name"
}
[{ 
acsCustomerId = ID2
cascade = "name"
}]
]
Description: Defines the default balance type cascades for non-promotional named events on a per ACS customer basis.
Type: Array
Optionality:
Allowed:
Default:
Notes:
Example: See Example configuration.

cascade

Syntax: cascade = "name"
Description: The name of the default balance type cascade for non-promotional named events for the ACS customer specified in acsCustomerId (on page 2).
Type: String
Optionality:
Allowed:
Default: "EventCascade"
Notes:
Example: cascade = "NE Test Cascade""

eventCacheAgeSeconds

Syntax: eventCacheAgeSeconds = seconds
Description: How long to keep named events CCS_EVENT_CLASS, CCS_EVENT_CHARGE, CCS_ACCT_EVENT_CHANGE entries in the cache.
Type: Integer
Optionality:
Allowed:
Default: 600
Notes:
Example: eventCacheAgeSeconds = 600

maxWalletLockLength

Syntax: maxWalletLockLength = millisecs
Description: How long to lock the wallet for.
Type: Integer
Optionality:
Allowed:
Default: 10000
Notes:
Example: maxWalletLockLength = 10000

PromoCascadeNamesByAcsId

Syntax:

PromoCascadeNamesByAcsId = [

{

acsCustomerId = ID1

promo_cascade = "name"

}

[{

acsCustomerId = ID2

promo_cascade = "name"

}]]

Description: Defines the default balance type cascades for promotional named events on a per ACS customer basis.
Type: Array
Optionality:
Allowed:
Default:
Notes:
Example: See Example configuration.

promo_cascade

Syntax: promo_cascade = "name"
Description: The name of the default balance type cascade for promotional named events for the ACS customer specified in acsCustomerId.
Type: String
Optionality:
Allowed:
Default: "EventPromoCascade"
Notes:
Example: promo_cascade = "NE Test Promo Cascade""

reservationPeriod

Syntax: reservationPeriod = millisecs
Description: How long to reserve monies for named events in milliseconds.
Type: Integer
Optionality: Optional (default used if not set)
Allowed:
Default: 3600
Notes:
Example: reservationPeriod = 3600

reservationPeriodTolerance

Syntax: reservationPeriodTolerance = seconds
Description: The number of seconds to tolerate a delay for named events reservations before reporting timeout.
Type: Integer
Optionality: Optional (default used if not set).
Allowed:
Default:
Notes:
Example: reservationPeriodTolerance = 30

roundingRuleType

Syntax: roundingRuleType = "type"
Description: How to round charging list.
Type: String
Optionality: Optional (default used if not set).
Allowed:

bankers – Apply banker's rounding

(0.000x to 0.499x rounded down to whole integer 0.5 -> 0.999x - round up to whole integer)

ceiling – Apply ceiling rounding

(0.000x to 0.999x - round up to whole integer)

floor – Apply floor rounding

(0.000x to 0.999x - round down to whole integer)

Default:
Notes:
Example: roundingRuleType = "floor"

Example

An example of the ccsVWARSExpiry parameter group of a Voucher and Wallet Server eserv.config file is listed below. Comments have been removed.

namedEventHandler = {
    maxWalletLockLength = 10000
    CascadeNamesByAcsId = [ 
        { 
        acsCustomerId = 12
        cascade = "Cascade1"
        }
        { 
        acsCustomerId = 32 
        cascade = "Cascade2" 
        } 
    ] 

    PromoCascadeNamesByAcsId = [ 
        { 
        acsCustomerId = 12 
        promo_cascade = "Promo Cascade 1" 
        } 
        {
        acsCustomerId = 32
        promo_cascade = "Promo Cascade 2" 
        } 
    ]

    reservationPeriod = 3600
    reservationPeriodTolerance = 30
    eventCacheAgeSeconds = 600
    activatePreuseAccount = true
    roundingRuleType = "floor"
}

Failure

If ccsVWARSNamedEventHandler fails, interaction with the wallets from the SLC involving updates to named events will fail.

Output

The ccsVWARSNamedEventHandler writes error messages to the system messages file, and also writes additional output to the beVWARS log. For more information about the beVWARS log, see VWS Technical Guide.

ccsVWARSPeriodicCharge

Purpose

This beVWARS plug-in handles periodic charge-specific tasks associated with periodic charge bucket changes.

ccsVWARSPeriodicCharge performs these tasks:

  • Triggers on bucket expiry event and handles periodic charge logic when the periodic charge expires (that is, when it triggers the next stage in the periodic charge cycle). For more information about the periodic charge life cycle, see Charging Control Services User's Guide.
  • Triggers on bucket value changed event (set by ccsVWARSWalletHandler when it processes a WU_Req) and handles updating the periodic charge bucket for a new periodic charge state. For subscriptions, creates new balance type and bucket.
  • Triggers on wallet state change event or a balance value change event and checks for periodic charges which are in the grace state. For each one it finds it attempts the charge (NE_Req).
    • If successful, all backlogged charges will be applied for the current periodic charge.
    • If one charge fails, the periodic charge will be moved back to the current grace state.
    • If all backlogged charges are successful, move to an active state.

Notes:

  • ccsVWARSPeriodicCharge only acts on periodic charge balances and buckets.
  • ccsVWARSWalletHandler handles the initial WU_Req messages and bucket updates (except new subscriptions). These updates trigger extra tasks performed by ccsVWARSPeriodicCharge.

For more information about how these tasks fit into the overall periodic charging functionality, see Periodic Charges.

Startup

If ccsVWARSPeriodicCharge is included in the beVWARS plugins array in eserv.config, it is loaded by beVWARS when beVWARS is initialized.

It is included in the following lines:

plugins = [
    "ccsVWARSPeriodicCharge.so"
]

For more information about the beVWARS plugins section, see Table 5-*.

Note:

Other event plug-ins may also be included in the plugins array.

Configuration

The ccsVWARSPeriodicCharge beVWARS event plug-in supports parameters from the ccsVWARSPeriodicCharge parameter group in the eserv.config file on a Voucher and Wallet Server. It contains parameters arranged in the structure shown below.

ccsVWARSPeriodicCharge = {
    retryTimeoutMinutes = mins
    chargeTimeGMTHours = HH
    cacheTimeoutSeconds = seconds
    notificationMidnightTZ = "tz"
    noNotifsInvalidWallet = true|false
    useNonGMTTimezoneOfTriggeringSource = true|false
    alwaysWrite52EDR = true|false
    subscribeExtendsPCExpiryDate = true|false    
    keepGraceExpiryInFuture = true|false
    adjustPcVtrBucketExpiry = true
}

Parameters

The ccsVWARSPeriodicCharge supports the following parameters in the ccsVWARSPeriodicCharge section of eserv.config.

adjustPcVtrBucketExpiry

Syntax: adjustPcVtrBucketExpiry = true|false
Description: When set to true, it sets the PC expiry date to bucket expiry date of the PC balance types in case of Voucher Type Recharges.
Type: Boolean
Optionality: Optional
Allowed: true, false
Default: false
Notes: Scenario: When the monthly PC subscribe date is 31st Jan (month end), and later when you perform monthly PC renewal, it works fine and calculates PC bucket expiry date as 29th Feb. However when you perform the PC renewal again, it calculates PC bucket expiry as 29th March instead of 31st March. This flag allows you to calculate the PC bucket expiry to 31st March.
Example: adjustPcVtrBucketExpiry = true

alwaysWrite52EDR

Syntax: alwaysWrte52EDR = true|false
Description: Whether or not to write a type 52 EDR record for every state change and every expiry date change. When set to false, a type 52 EDR will not be generated if the state remains the same but the expiry date changes.
Type: Boolean
Optionality: Optional (default used if not set).
Allowed:

true: Write type 52 EDR for every state change including expiry date changes

false: Do not write type 52 EDR when the state remains the same but the expiry date changes

Default: true
Notes:
Example: alwaysWrite52EDR = true

cacheTimeoutSeconds

Syntax: cacheTimeoutSeconds = seconds
Description: The number of seconds to store entries in the beVWARS periodic charge cache.
Type: Integer
Optionality: Optional (default used if not set).
Allowed: Integer, 1-3600.
Default: 300
Notes:
Example: cacheTimeoutSeconds = 450

chargeTimeGMTHours

Syntax: chargeTimeGMTHours = HH
Description: The time of day (in GMT) that a charge attempt will be made for fixed-date charges.
Type: Integer
Optionality: Optional (default used if not set).
Allowed: Integer, 0-23
Default: 0
Notes:

The hours correspond to the hours in a 24 hour clock. For example, specify 10 pm (2200 hours) as 22. Midnight is 0.

This parameter has no affect on the first charge date other than to set the hour. For example, if there is a fixed periodic charge on the 14th day of each month and this parameter specifies an offset for the charge of 12 hours, the first charge will be in the next month, even if the subscriber subscribes in the time lapse between 0:00 and the offset specified by this parameter, or between 0:00 and 12:00 in this case.

For more information about fixed-date configuration, see Charging Control Services User's Guide.

Example: chargeTimeGMTHours = 22

keepGraceExpiryInFuture

Syntax: keepGraceExpiryInFuture = true|false
Description:

This parameter dictates how expiry dates will be calculated when there is a forcible movement of Periodic Charges (PCs) from ‘Active’ to ‘Grace’ before actual PC expiry.

During the forcible ‘Active’ to ‘Grace’ transition, if this parameter is set to true and new calculated PC expiry is in the past, then the PC expiry will be changed to ‘current expiry + grace days’.

Type: Boolean
Optionality: Optional (default used if not set).
Allowed: true, false
Default: false
Notes:
Example: keepGraceExpiryInFuture = true

notificationMidnightTZ

Syntax: notificationMidnightTZ = "tz"
Description: The timezone to use when calculating when a notification should be sent.
Type: String
Optionality: Optional (default used if not set).
Allowed:
Default: "UTC"
Notes: This parameter controls the timezone the notification send time is calculated in. The time is 00:00 by default, but can be specified in the periodic charge configuration on the Wallet Management screen. For more information, see Charging Control Services User's Guide.
Example: notificationMidnightTZ = "GMT"

noNotifsInvalidWallet

Syntax: noNotifsInvalidWallet = true | false
Description: For wallets in an invalid state, specifies whether ccsVWARSPeriodicCharge suppresses all Periodic Charge (PC) notifications or just the Pre-Charge notifications.
Type: Boolean
Optionality: Optional (default used if not set)
Allowed:
  • true – Suppresses all PC notifications
  • false – Suppresses only the PreCharge notifications
Default: false
Notes:
Example: noNotifsInvalidWallet = true

useNonGMTTimezoneOfTriggeringSource

Syntax: useNonGMTTimezoneOfTriggeringSource = true|false
Description:

Sets whether to use the timezone defined in the Timezone field in the Periodic Charge, When configuration screen in the SMS UI. Set to:

  • true – To use the timezone supplied by the source triggering the periodic charge if the supplied timezone is not GMT or UTC.
  • false – To use the timezone defined in the periodic charge Timezone field or UTC if the periodic charge definition does not specify a time zone.

Regardless of the value of this parameter, the time zone supplied by the triggering source is always used when there are no periodic charge definitions for the balance type being processed.

Type: Boolean
Optionality: Optional (default used if not set)
Allowed: true, false
Default: false
Notes: When set to true, this parameter provides support for periodic charges based on the subscriber's actual timezone. Because there is limited support for, or lack of capability of the various triggering sources, setting this parameter to true can lead to inaccurate or erroneous calculations, and inconsistencies in time when notifications are sent, and when periodic charges are applied. Therefore, you are recommended to always set this parameter to false.
Example: useNonGMTTimezoneOfTriggeringSource = false

retryTimeoutMinutes

Syntax: retryTimeoutMinutes = mins
Description: The number of minutes before reattempting a charge after a VWS error.
Type: Integer
Optionality: Optional (default used if not set).
Allowed: 1-1440
Default: 10
Notes:
Example: retryTimeoutMinutes = 30

subscribeExtendsPCExpiryDate

Syntax: subscribeExtendsPCExpiryDate = true|false
Description: Controls whether a SUBSCRIBE event changes the expiry date of a periodic charge in pre-charge and grace states.
Type: Boolean
Optionality: Optional (default used if not set)
Allowed:

true|false

true - extend the periodic change expiry date

false - do not extend the expiry date

Default: True
Notes:
Example: subscribeExtendsPCExpiryDate = true

Example

An example of the ccsVWARSPeriodicCharge parameter group of a Voucher and Wallet Server eserv.config file is listed below. Comments have been removed.

ccsVWARSPeriodicCharge = {
    cacheTimeoutSeconds = 300
    notificationMidnightTZ = "UTC"
    chargeTimeGMTHours = 0
    useNonGMTTimezoneOfTriggeringSource = false
    retryTimeoutSeconds = 10
}

Failure

If ccsVWARSPeriodicCharge fails, periodic charges will not be processed. When ccsVWARSPeriodicCharge recovers, it will process the failed periodic charges the next time they are queried.

Output

ccsVWARSPeriodicCharge writes:

  • Notifications to notification batch file
  • Error messages to the system messages file
  • Additional output to the beVWARS log

For more information about the beVWARS log, see VWS Technical Guide.

ccsVWARSQuota

About the ccsCWARSQuota Plugin

The ccsVWARSQuota plugin sends a notification to the subscriber each time that updates to the subscriber's quota balance type cause a threshold configured for the subscriber's quota balance type to be breached. You configure the quota thresholds for quota balance types by determining the quota value in a profile field, and then by specifying the threshold as a percentage of the quota value.

For more information about configuring quota balance types and thresholds, see the discussion on configuring balance types in Convergent Charging Controller Charging Control Services User's Guide.

Startup

To enable ccsVWARSQuota to send quota notifications to the subscriber you must include the ccsVWARSQuota plugin in the beVWARS plugins array in eserv.config. The ccsVWARSQuota plugin is loaded by beVWARS when beVWARS is initialized.

You include the ccsVWARSQuota plugin by using the following syntax:

beVWARS = [
    plugins = [
        "ccsVWARSQuota.so"
        ]
]

There are no additional configuration parameters for ccsVWARSQuota in the eserv.config file, and ccsVWARSQuota does not accept any command line parameters.

Note:

Other event plug-ins may also be included in the plugins array. For more information about the beVWARS plugins section, see Table 5-*.

Failure

If ccsVWARSQuota fails, then the quota notifications configured in the Wallet Management screens in the Prepaid Charging UI will not be sent.

ccsVWARSResearchHandler

Purpose

ccsVWARSRechargeHandler is a beVWARS message handler which handles general wallet recharges (WGR).

Startup

If ccsVWARSRechargeHandler is included in the beVWARS handlers array in eserv.config, it is loaded by beVWARS when beVWARS is initialized.

It is included in the following lines:

handlers = [
    "ccsVWARSRechargeHandler.so"
]

For more information about the beVWARS handlers section, see handlers.

Note:

Other handlers may also be included in the handlers array.

Parameters

The ccsVWARSRechargeHandler supports parameters from the ccsVWARSUtils section of eserv.config. For more information, see Parameters.

ccsVWARSReservationHandler

Parameters

This beVWARS message handler performs the VWS-side processing of all messages relating to chargeable call processing including calculating tariffs for CLI-DN combinations. Discounts are applied after the rate is returned. These messages are the reservation messages, and include:

  • Initial Reservation (IR)
  • Subsequent Reservation (SR)
  • Commit Reservation (CR)
  • Revoke Reservation (RR)

Startup

If ccsVWARSReservationHandler is included in the beVWARS handler array in eserv.config, it is loaded by beVWARS when beVWARS is initialized.

It is included in the following lines:

handlers = [
    "ccsVWARSReservationHandler.so"
]

For more information about the beVWARS handlers section, see handlers.

Note:

Other handlers may also be included in the handlers array.

Parameters

The ccsVWARSReservationHandler supports the following parameters in the reservationHandler section of eserv.config.

addDisplaySpendRatio

Syntax: addDisplaySpendRatio = true|false
Description: Enable if display spend ratio is required in the EDR.
Type: Boolean
Optionality: Optional (default used if not set)
Allowed:
  • true - Add spend ratio in the EDR.
  • false - Do not add spend ratio in the EDR.
Default: false
Notes: Setting this parameter to true adds a comma delimited (per balance) spend ratio in the EDR. e.g. DISPLAY_SPEND_RATIO=1.0,2.0,1.0 etc
Example: addDisplaySpendRatio = false

addGeoSetID

Syntax: addGeoSetID = true|false
Description: Log the geo set entry IDs for CLI and DN into EDR.
Type: Boolean
Optionality: Optional (default used if not set).
Allowed:
Default: false
Notes:
Example: addGeoSetID = true

alwaysContributeToXBTDTimeBalance

Syntax: alwaysContributeToXBTDTimeBalance = <true|false>
Description: Indicates how to do handle cross balance duration.
Type: Boolean
Optionality: Optional
Allowed:

true: Always debit the duration of the current rate from the Cross balance type Time balance (if applicable in the current Cross balance type cascade) regardless of whether a wallet discount is being applied to the resulting cost of this rate.

false:

Default: false
Notes:
Example: alwaysContributeToXBTDTimeBalance = false

createEDRForMidSessionCommit

Syntax: createEDRForMidSessionCommit = <true|false>
Description: Flag to generate a partial EDR for each mid-session commit.
Type: Boolean
Optionality: Optional (default used if not set).
Allowed:
  • true - generate partial EDR, or
  • false - do not generate any partial EDRs
Default: false
Notes:
Example: createEDRForMidSessionCommit = false

discountData

Syntax: discountData = true|false
Description: Whether or not to discount charges on data balances.
Type: Boolean
Optionality: Optional (default used if not set).
Allowed:

true: Apply discounts

false: Do not apply discounts

Default: true
Notes:

For example, if discountData is set to true and you have 40 free data units and a discount of 50%, you will actually get 80 data units of call time.

If discountData is set to false, you will get 40 free data units regardless of applicable discounts.

Example: discountData = true

discountRuleType

Syntax: discountRuleType = "<rule>"
Description: How to factor service discounts from the IR_Req, SR_Req or CR_Req into the discounts to be applied from the rating and the wallet.
Type: String
Optionality: Optional (default used if not set).
Allowed:

ServiceOverride: override service discounts

s*r*w: compound service, rating and wallet discounts

s+r+w: cumulate service, rating and wallet discounts

s+r*w: cumulate service and rating discounts then compound the result to the wallet discount

s*r+w: compound service and rating discounts then cumulate the result to the wallet discount

s+w*r: cumulate service and wallet discounts then compound the result to the rating discount

s*w+r: compound service and wallet discounts then cumulate the result to the rating discount

r+w*s: cumulate rating and wallet discounts then compound the result to the service discount

r*w+s: compound rating and wallet discounts then cumulate the result to the service discount

Default: s*w*r
Notes:

s = service. The incoming discounts from the SLC as specified in the IR_Req, SR_Req and CR_Req messages.

r = rating. Holiday or weekly discounts that may be applicable during the call.

w = wallet. The discounts that are based on specific 'Cross Balance Type Discount' wallet balances being present when the call charge is being calculated.

Example: discountRuleType = "s*r*w"

discountTime

Syntax: discountTime = <true|false>
Description: Whether or not to discount charges on time balances.
Type: Boolean
Optionality: Optional (default used if not set).
Allowed:

true: Apply discounts

false: Don't apply discounts

Default: false
Notes:

For example, if discountTime is set to true and you have 40 free minutes and a discount of 50%, you will actually get 80 minutes of call time.

If discountTime is set to false, you will get 40 free minutes regardless of applicable discounts.

Example: discountTime = true

greedyReservationLengthLimit

Syntax: greedyReservationLengthLimit = <secs>
Description: The number of seconds reservation of funds should aim to be.
Type: Integer
Optionality: Optional (default used if not set).
Allowed:
Default: 60
Notes:

If this number of seconds cannot be reserved, the wallet is treated as if it has a Maximum Concurrent Accesses of 1. For more information about Maximum Concurrent Accesses settings, see Charging Control Services User's Guide.

This parameter does not affect charging for named events.

Example:

maxReservationLength

Syntax: maxReservationLength = <secs>
Description: The number of seconds to attempt to reserve for an IR or SR.
Type: Integer64
Optionality: Optional (default used if not set).
Allowed:
Default: 3600
Notes: This is what will be reserved if the wallet has infinite funds.
Example:

reservationLengthTolerance

Syntax: reservationLengthTolerance = <secs>
Description: The number of seconds the reservation length should exceed the length of time which can be paid for out of the funds available to the wallet.
Type: Integer
Optionality: Optional (default used if not set).
Allowed:
Default: 350
Notes: This does not give free call time but allows the application of a CR or SR to be delayed slightly.
Example: reservationLengthTolerance = 350

showCostsEDRScaledByDisplaySpendRatio

Syntax: showCostsEDRScaledByDisplaySpendRatio = true|false
Description: Whether to show COSTS scaled by the display spend ratio in EDR.
Type: Boolean
Optionality:
Allowed:

true - Show COSTS scaled by the display spend ratio.

false - Do not show COSTS scaled by the display spend ratio.

Default: false
Notes: COSTS added to the EDR remove the scaling due to the display spend ratio by default. In order to see the COSTS scaled by the display spend ratio, set showCostsEDRScaledByDisplaySpendRatio to true.
Example: showCostsEDRScaledByDisplaySpendRatio = false

skipZeroBalances

Syntax: skipZeroBalances = true|false
Description: If set to true, skip the balances with zero reservations while charging and continue to charge with other non-zero balances.
Type: Boolean
Optionality: Optional (default used if not set)
Allowed:

true - Skip balances with zero reservations while charging and continue to charge with other non-zero balances in other balance cascades.

false - It will not go to the next balance cascade in a multi-tariff CLI-DN as soon as first balance with zero reservation is found while charging.

Default: true
Notes: Usually because of rounding mechanism, smaller reservations are stored as zero. While charging, it stops charging as soon as the first zero reservation is found. This flag is used to overcome that scenario, if rounding mechanism cannot be changed.
Example: skipZeroBalances = true

suppressEDRRatingDetails

Syntax: suppressEDRRatingDetails = <true|false>
Description:

Whether to suppress some rating fields in the EDRs written for midcall rating change (FMC) and/or multi tariff rating calls.

Single tariff calls are not affected by this parameter.

Type: Boolean
Optionality: Optional (default used if not set).
Allowed:

true: Suppressing the fields listed above for FMC and/or MTR calls.

false: Use normal approach to writing fields.

Default: true
Notes:

The suppressed fields are:

  • RATES
  • LENGTHS
  • MAX_CHARGE
  • DISCOUNTS
  • CASCADE_ID
  • CBTD_DISCOUNTS, and
  • CBTD_CASCADE_ID.

For more information about these EDR fields, see EDR Reference Guide.

Example:

syslogErrors

Syntax: syslogErrors = <true|false>
Description: Whether or not to log some NACKs to the syslog.
Type: Boolean
Optionality: Optional (default used if not set).
Allowed:

true: Log all NACKs except MaxConcurrentExceeded, InsufficientFunds, and WalletDisabled to the syslog.

false: Do not log any NACKs to the syslog.

Default: false
Notes: These errors include some detail about why the action failed.
Example:

useWorstCaseBalances

Syntax: useWorstCaseBalances = <true|false>
Description: For new calls during initial reservations, whether to use worst case balances only or all available balances.
Type: Boolean
Optionality: Optional (default used if not set).
Allowed:

true: Use worst case balances only.

false: Use all available balances.

Default: true
Notes: Worst case balances are those which are having a start date and an expiry date. Balances having expiry date, without any start date are considered as worst case balance, only if it is not going to expire within the call start time and a calculated expected call finish time.
Example: useWorstCaseBalances = false

zeroLengthFreeCalls

Syntax: zeroLengthFreeCalls = {}
Description: How successful, free, zero-length calls should be handled. For example, where the caller hangs up before the call is answered.
Type: Array
Optionality: Optional (not used if not set).
Allowed:
Default:
Notes: These settings can be used to reduce the amount of resources used for successfully placed free calls, which are unanswered.
Example:

updateLastUseDate

Syntax: updateLastUseDate = <true|false>
Description: Whether successful, free, zero-length calls should change the wallet's last use date in the database. For example, where the caller hangs up before the call is answered.
Type: Boolean
Optionality: Optional (default used if not set).
Allowed:

true: Update the wallet's last use date in the database

false: Do not update the wallet last use date.

Default: true
Notes:

This settings can be used to reduce the amount of resources used for successfully placed free calls, which are unanswered.

For more information about Last Use Date, see Charging Control Services User's Guide.

Example:

writeCDR

Syntax: updateLastUseDate = <true|false>
Description: Whether successful, free, zero-length calls should generate an EDR. For example, where the caller hangs up before the call is answered.
Type: Boolean
Optionality: Optional (default used if not set).
Allowed:

true: Write an EDR for the call.

false: Do not write an EDR for the call.

Default: true
Notes:

This settings can be used to reduce the amount of resources used for successfully placed free calls, which are unanswered.

For more information about EDRs, see EDR Reference Guide.

Example:

Example

An example of the reservationHandler parameter group of a Voucher and Wallet Server eserv.config file is listed below. Comments have been removed.

reservationHandler = {
    syslogErrors = false
    maxReservationLength = 3600
    reservationLengthTolerance = 30
    greedyReservationLengthLimit = 60
    discountRuleType = "s*w*r"
    alwaysContributeToXBTDTimeBalance = false
    suppressEDRRatingDetails = true
    skipZeroBalances = true
    discountTime = false
    discountData = true
    addGeoSetID = true    
    createEDRForMidSessionCommit = false
    addDisplaySpendRatio = false
    showCostsEDRScaledByDisplaySpendRatio = false
    useWorstCaseBalances = false
    zeroLengthFreeCalls = {
    updateLastUseDate = true
    writeCDR = true
    }
}

Failure

If ccsVWARSReservationHandler fails, interaction with the subscriber accounts from the SLC involving call charging will fail.

Output

The ccsVWARSReservationHandler writes error messages to the system messages file, and also writes additional output to:

/IN/service_packages/E2BE/tmp/beVWARS.log

ccsVWARSVoucherHandler

Purpose

This beVWARS message handler performs the Voucher and Wallet Server side processing of messages directly relating to vouchers. This includes voucher reservation/commit, alteration and deletion. It does not perform the wallet recharge; this is done by the ccsVWARSWalletHandler . The message handler only controls the Voucher and Wallet Server side of the CCS voucher tables, not the main body of data about vouchers that is replicated from the SMS.

This handler validates incoming voucher reserve (for example, scratch or redeem) requests, and refers to the replicated CCS voucher tables for all information except the current redeemed/unredeemed state of the voucher.

It is important to remember that the BE_VOUCHER record will in all probability not exist unless the voucher has had a previous successful (or almost successful) redeem performed upon it. This state is hidden from the client process, a non-existent BE_VOUCHER record is proof that the voucher has not been redeemed.

Startup

If ccsVWARSVoucherHandler is included in the beVWARS handlers array in eserv.config, it is loaded by beVWARS when beVWARS is initialized.

It is included in the following lines:

handlers = [

"ccsVWARSVoucherHandler.so"

]

For more information about the beVWARS handlers section, see handlers.

Note: Other handlers may also be included in the handlers array.

Parameters

The ccsVWARSVoucherHandler supports the following parameters in the beVWARS section of eserv.config .

Note: It also required the BE.serverId parameter. For more information about setting serverId, see VWS Technical Guide.

badPinExpiryHours

Syntax: badPinExpiryHours = hours
Description: The number of hours before the bucket storing the bad PIN expires.
Type: Integer
Optionality: Optional (default used if not set)
Allowed:

negative integer: Does not expire

positive integer: Number of hours before expiry

Default: 24
Notes:
Example: badPinExpiryHours = 48

clearConsecutivePin

Syntax: clearConsecutivePin = Boolean
Description: If true, then a successful voucher recharge will set the number of consecutive bad pin attempts for an account to zero.
Type: Boolean
Optionality: Optional (default used if not set)
Allowed:
Default: false
Notes:
Example: clearConsecutivePin = true

consecutiveBadPinExpiryHours

Syntax: consecutiveBadPinExpiryHours = hours
Description: The number of hours before the bucket storing the consecutive bad PIN expires.
Type: Integer
Optionality: Optional (default used if not set)
Allowed:

negative integer: Does not expire

positive integer: Number of hours before expiry

Default: 24
Notes:
Example: consecutiveBadPinExpiryHours = 48

createRechargeCDRInactiveAccount

Syntax: createRechargeCDRInactiveAccount = true|false
Description: When true, failed voucher recharges generate an EDR.
Type: Boolean
Optionality: Optional (default used if not set)
Allowed: true, false
Default: true
Notes:
Example: createRechargeCDRInactiveAccount = true

dailyBadPinExpiryHours

Syntax: dailyBadPinExpiryHours = hours
Description: The number of hours before the bucket storing the daily bad PIN expires.
Type: Integer
Optionality: Optional (default used if not set)
Allowed:

negative integer: Does not expire

positive integer: Number of hours before expiry

Default: 24
Notes:
Example: dailyBadPinExpiryHours = 48

monthlyBadPinExpiryHours

Syntax: monthlyBadPinExpiryHours = hours
Description: The number of hours before the bucket storing the monthly bad PIN expires.
Type: Integer
Optionality: Optional (default used if not set)
Allowed:

negative integer: Does not expire

positive integer: Number of hours before expiry.

Default: 744
Notes:
Example: monthlyBadPinExpiryHours = 744

weeklyBadPinExpiryHours

Syntax: weeklyBadPinExpiryHours = hours
Description: The number of hours before the bucket storing the weekly bad PIN expires.
Type: Integer
Optionality: Optional (default used if not set)
Allowed:

negative integer: Does not expire

positive integer: Number of hours before expiry

Default: 744
Notes:
Example: weeklyBadPinExpiryHours = 744

replicationInterface

Syntax: replicationInterface = "if"
Description: The handle of the SLEE replication interface.
Type: String
Optionality: Optional (default used if not set)
Allowed: Must match the Interface name in SLEE.cfg.
Default: "replicationIF"
Notes: For more information about SLEE.cfg, see SLEE Technical Guide.
Example: replicationInterface = "replicationIF"

requireBonusRow

Syntax: requireBonusRow = true|false
Description: When true, vouchers will fail if there is no entry in CCS_BONUS_VALUES.
Type: Boolean
Optionality: Optional (default used if not set)
Allowed: true, false
Default: true
Notes:
Example: requireBonusRow = true

updateLastUseVoucherRecharge

Syntax: updateLastUseVoucherRecharge = true|false
Description: When true, voucher recharges update the 'last use date' field.
Type: Boolean
Optionality: Optional (default used if not set)
Allowed: true, false
Default: true
Notes:
Example: updateLastUseVoucherRecharge = true

vomsInstalled

Syntax: vomsInstalled = true|false
Description:

Define if you are using:

  • Voucher Manager-type bad PIN balances (true)
  • Just a single, VWS bad PIN (false)
Type: Boolean
Optionality: Optional (default used if not set)
Allowed: true, false
Default: false
Notes:
Example: vomsInstalled = true

Example

An example of the voucherHandler parameter group of a Voucher and Wallet Server eserv.config file is listed below. Comments have been removed.

voucherHandler = {

requireBonusRow = true

updateLastUseVoucherRecharge = true

createRechargeCDRInactiveAccount = true

badPinExpiryHours = 24

dailyBadPinExpiryHours = 24

monthlyBadPinExpiryHours = 744

consecutiveBadPinExpiryHours = -1

vomsInstalled = true

replicationInterface = "replicationIF"

}

Failure

If ccsVWARSVoucherHandler fails, interaction with the wallets from the SLC involving vouchers will fail.

Output

The ccsVWARSVoucherHandler writes error messages to the system messages file, and also writes additional output to /IN/service_packages/E2BE/tmp/beVWARS.log.

ccsVWARSWalletHandler

Purpose

This beVWARS message handler performs the VWS side processing of all messages relating directly to wallets. This includes:

  • Wallet information (WI) - responds with wallet information
  • Wallet create (WC) - creates new wallets
  • Wallet update (WU) - updates wallets and possibly adds reload bonuses and writes an EDR.
  • Wallet delete (WD) - deletes existing wallets and corresponding buckets
  • Bad PIN updates (BPIN) - updates bad PIN balance if the wallet has one.

EDRs are produced for all Wallet updates (create/modify/delete/recharge) with the details of the change.

Note: ccsVWARSWalletHandler only performs some updates for periodic charge balances and buckets. For more information about how ccsVWARSWalletHandler handles WU_Req messages which relate to periodic charges, see Processing periodic charge subscription changes.

For more information about wallet messages, see VWS Technical Guide.

Startup

If ccsVWARSWalletHandler is included in the beVWARS handlers array in eserv.config, it is loaded by beVWARS when beVWARS is initialized.

It is included in the following lines:

handlers = [

"ccsVWARSWalletHandler.so"

]

For more information about the beVWARS handlers section, see handlers.

Note: Other handlers may also be included in the handlers array.

Configuration

The ccsVWARSWalletHandler library accepts the following configuration parameter for the ccsWalletUpdateHandler plug-in:

walletUpdateHandler = {

createEmptyBuckets = true|false

deleteEmptyBuckets = true|false

maxReservationsPerSLEEMessage = 5

}

createEmptyBuckets

Syntax: createEmptyBuckets = true | false
Description: Specifies whether ccsVWARSWalletHandler creates empty buckets for subscribers that are added through PI commands or the User Interface (UI).
Type: Boolean
Optionality: Optional (default used if not set)
Allowed:
  • true – Empty buckets are created
  • false – No empty buckets are created
Default: true
Notes:
Example: createEmptyBuckets = false

deleteEmptyBuckets

Syntax: deleteEmptyBuckets = true|false
Description: Controls whether beServer deletes empty buckets or whether it is done by beVWARSExpiry (and controlled by its configuration).
Type: Boolean
Optionality: Optional (default used if not set).
Allowed:

true: Empty buckets will be removed by the beServer.

false: Empty buckets will be removed by the beVWARSExpiry plug-in.

Default: true
Notes: This flag will be functional only when clearEmptyBuckets flag is set to true. For more information about beServer, beVWARSExpiry, and clearEmptyBuckets flag, see VWS Technical Guide.
Example: deleteEmptyBuckets = false

maxReservationsPerSLEEMessage

Syntax: maxReservationsPerSLEEMessage = Int
Description: Specifies the maximum number of reservations returned by the VWS when querying for wallet reservation details.
Type: Integer
Optionality: Optional (default used if not set)
Allowed:
Default: 5
Notes: Do not set this parameter higher than the maximum SLEE event size (MAXEVENTS). See About Configuring MAXEVENTS. Otherwise, the CCSRM1=QRY PI command time outs, and the VWS generates a no free events error.
Example: maxReservationsPerSLEEMessage = 3

Failure

If ccsVWARSWalletHandler fails, interaction with the wallets from the SLC will fail.

Output

The ccsVWARSWalletHandler writes error messages to the system messages file.

ccsWLCPlugin

Purpose

ccsWLCPlugin is a beVWARS plug-in that handles wallet life cycle periods. It is triggered by a wallet query event and provides the following services:

  • Processes wallet life cycle plan and periods transitions
  • Triggers on entry and on backout control plans
  • Triggers on entry and on backout notifications

Startup

If ccsWLCPlugin is included in the beVWARS plugin array in eserv.config, it is loaded by beVWARS when beVWARS is initialized.

It is included in the following lines:

plugins = [

"ccsWLCPlugin.so"

]

For more information about the beVWARS plugins section, see plugins (on page 2).

Note: Other plug-ins may also be included in the plugins array.

cmnPushFiles

cmnPushFiles

Purpose

cmnPushFiles is responsible for pushing files to other machines including, but not limited to, log files to the SMS.

Warning: You must install the xinetd daemon as a prerequisite to running cmnPushFiles. You install the daemon by entering the following command:

yum install xinetd

Startup

Each instance of the cmnPushFiles daemon should be started with a separate entry in the inittab of the machine where it will run. It runs under the control of inetd.

Before adding an entry to the inittab, you must decide the following:

  • User you wish to have cmnReceiveFiles write incoming files as (for example, ccs_oper)
  • File names you wish to transfer (for example, file names starting with "ccsCDR")
  • Directories on each host you want to transfer files between (for example,BE/logs/CDR and CCS/logs/CDR)
  • Host name of the receiving side of the connection (for example, hp3)
  • Port number the two programs will use to communicate (for example, 2027)

Receiving machine

You must also ensure a matching cmnReceiveFiles is available on the destination machine.

On the receiving machine, add an entry to /etc/services like this:

ccsoperFiles 2027/tcp

and to /etc/inetd.conf, add an entry like this:

ccsoperFiles stream tcp nowait root /IN/service_packages/CCS/bin/cmnReceiveFiles cmnReceiveFiles -u ccs_oper.

Parameters

cmnPushFiles supports the following parameters.

-a

Syntax:
Description: How old transferred files must be before they are removed.
Type:
Optionality:
Allowed:
Default: Never clean
Notes: This parameter is only relevant if the -o parameter is specified.
Example:

-C

Syntax:
Description: Clean up period.
Type:
Optionality: Optional
Allowed:
Default: 1800
Notes: In seconds
Example:

-d

Syntax:
Description: Scan Directory. The directory to search for files to transfer to the receiving side. cmnPushFiles will only transfer those files matching a pattern. See -P.
Type:
Optionality:
Allowed:
Default:
Notes:
Example:

-f

Syntax:
Description: Retry directory.
Type:
Optionality: Optional.
Allowed:
Default: none
Notes:
Example:

-F

Syntax:
Description: Use fuser to not move files in use.
Type:
Optionality: Optional.
Allowed:
Default: Do not use
Notes:
Example:

-h

The host name of the cmnReceiveFiles listener.

-M

Syntax:
Description: Maximum retry period.
Type:
Optionality: Optional.
Allowed:
Default: 900
Notes:
Example:

-o

Syntax:
Description: Transferred directory. What to do with files that have been transferred.
Type:
Optionality: Optional.
Allowed:
Default: File deleted
Notes:
Example:

-p

Syntax:
Description: The port number of the cmnReceiveFiles listener.
Type:
Optionality: This parameter is optional.
Allowed:
Default: 2027
Notes:
Example:

-P

Syntax:
Description: Match Pattern. Specify a filename prefix that must be matched in order to qualify a file for transfer to the remote side.
Type:
Optionality: This parameter is optional.
Allowed:
Default:
Notes:
Example: -P ccsCDR will cause all files matching ccsCDR* in the source directory to be transferred.

-R

Syntax:
Description: Initial retry period.
Type:
Optionality: Optional
Allowed:
Default: 15
Notes: In seconds.
Example:

-r

Remote directory prefix.

  • If the -r parameter is omitted, files will be written to the target machine using the path used by the source machine.
  • If the -r parameter is included, the remote directory prefix is added to the front of all matching file names in the source directory.
  • If the -d parameter is used and if it specifies a relative directory (one that starts with a /), the -r parameter must be specified. Otherwise, this parameter is optional.

-s

Syntax:
Description: The re-scan interval. After cmnPushFiles has scanned its input directory and found no files to transfer, it goes to sleep for a configurable interval. To change this interval, specify the number of seconds to sleep after the -s.
Type:
Optionality: Optional
Allowed:
Default: 15
Notes: In seconds
Example:

-S

Syntax:
Description: File suffix.
Type:
Optionality: Optional
Allowed:
Default:
Notes:
Example:

-t

Syntax: -t int
Description: Throttle. Controls the maximum transmission speed the application will use when transferring data.
Type: Integer
Optionality: Optional.
Allowed:
Default:
Notes: Specify the number of bits per second to use after the option.
Example:

-T

Syntax:
Description: Tree move. Recursively moves the directory tree.
Type:
Optionality: Optional
Allowed:
Default: off
Notes:
Example:

-x

No host name prefix. By default, cmnPushFiles adds the sending host name to file names sent to the receiving side using the convention: hostName_fileName. To prevent the host name being added, use the –x switch. This parameter is optional.

Failure

If cmnPushFiles fails, files will collect in the input directory. When the process starts up again, the unprocessed files will be processed.

If cmnPushFiles fails to copy a file to the remote location, it will move the files into a failed directory.

Output

cmnPushFiles will transfer files to the configured target machine and will move the local files to a completed transfer directory.

The cmnPushFiles writes error messages to the system messages file.

libccsCommon

Purpose

libccsCommon provides common functions to various CCS processes.

Startup

libccsCommon is used by a number of CCS processes. No startup configuration is required for this library to be used.

Configuration

The libccsCommon library supports parameters from the common parameter group in the eserv.config file on all machines. It contains parameters arranged in the structure shown below. The value types for each parameter are displayed as placeholders.
common = {
      # how long entries should remain in the various
          caches
      balanceTypeCascadeIdCacheAgeSeconds = seconds
      balanceTypeCascadeCacheAgeSeconds = seconds
      balanceTypeUnitCacheAgeSeconds = seconds
      balanceTypeIdCacheAgeSeconds = seconds
      defaultBalanceTypeCacheAgeSeconds = seconds
      systemCurrencyBalanceUnitCacheAgeSeconds = seconds
      accountCacheAgeSeconds = seconds
      accountTypeBestPeriodsCacheAgeSeconds = seconds
      tariffPlanIdCacheAgeSeconds = seconds
      walletTypeCacheAgeSeconds = seconds
      profileDetailsSubtagsCacheAgeSeconds = seconds
      domainsCacheAgeSeconds = seconds
      lowCreditDapDisableCacheAgeSeconds = seconds
      ccsAcctReferenceCacheAgeSeconds = seconds
      productTypeIdCacheAgeSeconds = seconds
      creditCardCacheAgeSeconds = seconds
      creditCardCacheRepIntervalSeconds = seconds
      #the following should go into
        eserv.config.be
      acsCustIdAgeSeconds = seconds
      ccsBalanceExpiryRoundUp = boolean
      # If set, the timezone in which to set the expiry date of an
            expenditure
      # balance to the next midnight.
      # default: GMT
      # expenditureBalanceMidnightExpiryTZ = "timezone"
      # mode for CB10 HRN validation.
      # true = force HRN to be validated against
        seed
      # false = no validation of HRN against
        seed
      # default: true
      authCB10ValidateSeed = boolean
      # Name of xmlIF used when sending low credit DAP notifications
            (default xmlIF)
      xmlInterfaceName = "interface name"
      # The length of time in seconds between syslog messages
            about
      # not being able to send to a SLEE Interface. (BE
          only)
      # Default 60 (seconds)
      rateLimitIFSendErrors = seconds
      }

Parameters

libccsCommon library supports these parameters in the common section of eserv.config.

accountCacheAgeSeconds

Syntax: accountCacheAgeSeconds = seconds
Description: The maximum number of seconds that account data remains cached.
Type: Integer
Optionality:
Allowed:
Default: 600
Notes:
Example: accountCacheAgeSeconds = 600

accountNumberLength

Syntax: accountNumberLength = len
Description: The number of digits in a card account number generated by ccsAccount tool.
Type: Integer
Optionality: Optional
Allowed:
Default: 10
Notes: If you set accountNumberLength to 0 (zero), the account numbers that the ccsAccount tool generates can be any length.
Example: accountNumberLength = 10

accountTypeBestPeriodsCacheAgeSeconds

Syntax: accountTypeBestPeriodsCacheAgeSeconds = seconds
Description:

The value specified in the accountTypeBestPeriodsCacheAgeSeconds parameter indicate the maximum validity time for data stored in the accountTypeBestPeriodcache.

The accountTypeBestPeriodcache caches the best (that is longest) value of each of the four items listed below from the CCS_ACCT_TYPE table, for each wallet. That is, for each item, it caches the longest value across all account types using the wallet.

  • ACTIVE_DORMANT - Number of days an account in the active state can be inactive before it is deemed dormant.
  • DORMANT_TERMINATED - Number of days an account in the dormant state can be inactive before it is deemed terminated.
  • PRE_USE_EXPIRY - Number of days an account in the pre-use state can be inactive before it is deemed terminated.
  • TERMINATED_REMOVED - Number of days an account in the terminated state can be inactive before it is removed from the database.

Each row in the CCS_ACCT_TYPE table represents a product type. It is possible to have a wallet which is shared by more than one account, each of which has a different product type.

Type: Integer
Optionality:
Allowed:
Default: 600
Notes:
Example: accountTypeBestPeriodsCacheAgeSeconds = 600

authCB10ValidateSeed

Syntax: authCB10ValidateSeed = true|false
Description: The mode for CB10 HRN validation.
Type: Boolean
Optionality: Optional (default used if not set).
Allowed:

true: Force incoming HRN to be validated against originating seed (voucher number).

false: Do not validate of HRN against originating seed.

Default: true
Notes:

This parameter is only needed if the system is using ccsCB10HRNSHA or ccsCB10HRNAES.

This setting may be useful where:

  • Vouchers have been imported from another system and the original voucher number seeds are not available
  • Validation performance gains are needed.
Example: authCB10ValidateSeed = false

balanceTypeCascadeCacheAgeSeconds

Syntax: balanceTypeCascadeCacheAgeSeconds = seconds
Description: The maximum number of seconds that data of the cascade balance type remains cached.
Type: Integer
Optionality: Optional (default used if not set)
Allowed:
Default: 600
Notes:
Example: balanceTypeCascadeCacheAgeSeconds = 600

balanceTypeCascadeIdCacheAgeSeconds

Syntax: balanceTypeCascadeIdCacheAgeSeconds = seconds
Description: The maximum number of seconds that data of the cascade identifier balance type remains cached.
Type: Integer
Optionality: Optional (default used if not set)
Allowed:
Default: 600
Notes:
Example: balanceTypeCascadeIdCacheAgeSeconds = 600

detailedCascadeCacheAgeSeconds

Syntax: detailedCascadeCacheAgeSeconds = seconds
Description: The maximum number of seconds that data of the cascade detailed balance type remains cached.
Type: Integer
Optionality:
Allowed:
Default: 600
Notes:
Example: detailedCascadeCacheAgeSeconds = 600

balanceTypeIdCacheAgeSeconds

Syntax: balanceTypeIdCacheAgeSeconds = seconds
Description: The maximum number of seconds that data of the identifier balance type remains cached.
Type: Integer
Optionality: Optional (default used if not set).
Allowed:
Default: 600
Notes:
Example: balanceTypeIdCacheAgeSeconds = 600

balanceTypeUnitCacheAgeSeconds

Syntax: balanceTypeUnitCacheAgeSeconds = seconds
Description: The maximum number of seconds that data of the unit balance type remains cached.
Type: Integer
Optionality:
Allowed:
Default: 600
Notes:
Example: balanceTypeUnitCacheAgeSeconds = 600

balanceUnitTypeCacheAgeSeconds

Syntax: balanceUnitTypeCacheAgeSeconds = seconds
Description: The number of seconds before the balance unit cache is refreshed from the database.
Type: Integer
Optionality: Optional (default used if not set).
Allowed:
Default: 600
Notes: The balance unit type configuration is used by the rating engine for determining how a balance type should be treated, (that is, is is cash, time or other). This configuration is based on the name of the unit.
Example: balanceUnitTypeCacheAgeSeconds = 600

ccsAcctReferenceCacheAgeSeconds

Syntax: ccsAcctReferenceCacheAgeSeconds = seconds
Description: The maximum number of seconds data from the CCS_ACCT_REEFERENCE table is cached.
Type: Integer
Optionality: Optional (default used if not set)
Allowed:
Default: 600
Notes:
Example: ccsAcctReferenceCacheAgeSeconds = 600

ccsBalanceExpiryRoundUp

Syntax: ccsBalanceExpiryRoundUp = boolean
Description: Used when calculating the expiry time of the balance in days, to present to the customer.
Type: Boolean
Optionality: Optional (default used if not set).
Allowed:

true: Round up when calculating expiry time.

false: Do not round up when caluclating expiry time.

Default: false
Notes:

Sample scenarios:

  • If the balance expires 3.25 days from now, the expiry time will always be given as 3 days.
  • If the balance expires 3.75 days from now, and this parameter is true, it will be given as 4 days.
  • If the balance expires 3.25 days from now, and this parameter is true, it will be given as 3 days.
Example ccsBalanceExpiryRoundUp = true

ccsBonusTypeAgeSeconds

Syntax: ccsBonusTypeAgeSeconds = seconds
Description: The number of seconds before refreshing the bonus type cache from the E2BE database.
Type: Integer
Optionality: Optional (default used if not set).
Allowed:
Default: 600
Notes: This cache holds the balance type ID to apply the bonus to for a given bonus.
Example: ccsBonusTypeAgeSeconds = 600

ccsBonusValuesAgeSeconds

Syntax: ccsBonusValuesAgeSeconds = seconds
Description: The number of seconds before refreshing the bonus value cache from the E2BE database.
Type: Integer
Optionality: Optional (default used if not set).
Allowed:
Default: 600
Notes: This cache holds the range of valid values and the bonus percentage to give for a given bonus.
Example: ccsBonusValuesAgeSeconds = 600

ccsWlcAgeSeconds

Syntax: ccsWlcAgeSeconds = seconds
Description: The maximum number of seconds that wallet life cycle data remains in the CCS common cache.
Type: Integer
Optionality:
Allowed:
Default: 600
Notes:
Example: ccsWlcAgeSeconds = 600

ccsRewardTranslationAgeSeconds

Syntax: ccsRewardTranslationAgeSeconds = seconds
Description: The maximum number of seconds that CCS reward translation data remains cached.
Type: Integer
Optionality:
Allowed:
Default:
Notes:
Example: ccsRewardTranslationAgeSeconds = 600

ccsWalletNameTranslationAgeSeconds

Syntax: ccsWalletNameTranslationAgeSeconds = seconds
Description: The maximum number of seconds that CCS wallet name translation data remains cached.
Type: Integer
Optionality:
Allowed:
Default:
Notes:
Example: ccsWalletNameTranslationAgeSeconds = 600

ccsLanguageDetailsAgeSeconds

Syntax: ccsLanguageDetailsAgeSeconds = seconds
Description: The maximum number of seconds that CCS language details data remains cached.
Type: Integer
Optionality:
Allowed:
Default:
Notes:
Example: ccsLanguageDetailsAgeSeconds = 600

ccsBalanceTypeTranslationAgeSeconds

Syntax: ccsBalanceTypeTranslationAgeSeconds = seconds
Description: The maximum number of seconds that CCS balance translation data remains cached.
Type: Integer
Optionality:
Allowed:
Default:
Notes:
Example: ccsBalanceTypeTranslationAgeSeconds = 600

creditCardCacheAgeSeconds

Syntax: creditCardCacheAgeSeconds = seconds
Description: The maximum number of seconds data from the CCS_CREDIT_CARD_DETAILS table is cached.
Type: Integer
Optionality: Optional (default used if not set)
Allowed:
Default: 600
Notes:
Example: creditCardCacheAgeSeconds = 600

creditCardCacheRepIntervalSeconds

Syntax: creditCardCacheRepIntervalSeconds = seconds
Description: The refresh interval (in seconds) of cached credit card data.
Type: Integer
Optionality: Optional (default used if not set)
Allowed:
Default: 6
Notes:
Example: creditCardCacheRepIntervalSeconds = 6

defaultBalanceTypeCacheAgeSeconds

Syntax: defaultBalanceTypeCacheAgeSeconds = seconds
Description: The maximum number of seconds that data of the default balance type remains cached.
Type: Integer
Optionality:
Allowed:
Default: 600
Notes:
Example: defaultBalanceTypeCacheAgeSeconds = 600

domainsCacheAgeSeconds

Syntax: domainsCacheAgeSeconds = seconds
Description: The maximum number of seconds data from the CCS_DOMAIN table is cached.
Type: Integer
Optionality: Optional (default used if not set)
Allowed:
Default: 600
Notes:
Example: domainsCacheAgeSeconds = 600

expenditureBalanceMidnightExpiryTZ

Syntax: expenditureBalanceMidnightExpiryTZ = "timezone"
Description: Daily, monthly, and yearly expenditure balances have an expiry time of midnight in the specified time zone.
Type: String
Optionality: Optional (default used if not set).
Allowed:

To view a list of accepted time zone values, see Appendix A Time Zones in the Advanced Control Services Technical Guide.

If this parameter is not set, expenditure balances have an expiry time of GMT midnight.

Default: GMT
Notes:
Example: expenditureBalanceMidnightExpiryTZ = "timezone"

ignoreBTs

Syntax: ignoreBTs = [ type, ...]
Description: The balance types which are not required in wallet request messages.
Type: Array
Optionality: Optional
Allowed:
Default:
Notes:
Example: ignoreBTs = [ 201 ]

lowCreditDapDisableCacheAgeSecondss

Syntax: lowCreditDapDisableCacheAgeSeconds = seconds
Description: The maximum number of seconds boolean profile tags within the CCS_ACCT_REFERENCE.PROFILE table are cached.
Type: Integer
Optionality: Optional (default used if not set)
Allowed:
Default: 600
Notes:
Example: lowCreditDapDisableCacheAgeSeconds = 600

maxConcurrentChargingSessions

Syntax: maxConcurrentChargingSessions = num
Description: Overrides the maximum number of concurrent transactions configured for all wallets.
Type: Integer
Optionality: Optional (default used if not set).
Allowed: Values greater than or equal to 1 are valid.
Default: The value specified for the wallet is used.
Notes:
Example: maxConcurrentChargingSessions = 50

productTypeIdCacheAgeSeconds

Syntax: productTypeIdCacheAgeSeconds = seconds
Description: The maximum number of seconds product type id data from the CCS_ACCT_TYPE table is cached.
Type: Integer
Optionality: Optional (default used if not set)
Allowed:
Default: 600
Notes:
Example: productTypeIdCacheAgeSeconds = 600

profileDetailsSubtagsCacheAgeSeconds

Syntax: profileDetailsSubtagsCacheAgeSeconds = seconds
Description: The maximum number of seconds product type data from the CCS_ACCT_TYPE table is cached.
Type: Integer
Optionality: Optional (default used if not set)
Allowed:
Default: 600
Notes:
Example: profileDetailsSubtagsCacheAgeSeconds = 600

rateLimitIFSendErrors

Syntax: rateLimitIFSendErrors = seconds
Description: The length of time in seconds between syslog messages about not being able to send to a SLEE Interface. (BE only)
Type: Integer
Optionality: Optional (default used if not set).
Allowed:
Default: 60
Notes:
Example: rateLimitIFSendErrors = 600

systemCurrencyBalanceUnitCacheAgeSeconds

Syntax: systemCurrencyBalanceUnitCacheAgeSeconds = seconds
Description: The maximum number of seconds that data of the system currency balance unit remains cached.
Type: Integer
Optionality:
Allowed:
Default: 600
Notes:
Example: systemCurrencyBalanceUnitCacheAgeSeconds = 600

systemCurrencyIdAgeSeconds

Syntax: systemCurrencyIdAgeSeconds = seconds
Description: The number of seconds the system currency ID will stay in the cache before being refreshed.
Type: Integer
Optionality: Optional (default used if not set).
Allowed:
Default: 600
Notes:
Example: systemCurrencyIdAgeSeconds = 300

tariffPlanIdCacheAgeSeconds

Syntax: tariffPlanIdCacheAgeSeconds = seconds
Description: The maximum number of seconds tariff plan Id data from the CCS_TARIFF_PLAN table is cached.
Type: Integer
Optionality: Optional (default used if not set).
Allowed:
Default: 600
Notes:
Example: tariffPlanIdCacheAgeSeconds = 600

walletTypeCacheAgeSeconds

Syntax: walletTypeCacheAgeSeconds = seconds
Description: The maximum number of seconds data from the CCS_WALLET_TYPE table is cached.
Type: Integer
Optionality: Optional (default used if not set)
Allowed:
Default: 600
Notes:
Example: walletTypeCacheAgeSeconds = 600

xmlInterfaceName

Syntax: xmlInterfaceName = "name"
Description: The name of xml interface used when sending low credit DAP notifications.
Type: String
Optionality: Optional (default used if not set).
Allowed:

Default: "xmlIF"
Notes:

Example: xmlInterfaceName = "xmlIF"

Example

An example of the common parameter group of an eserv.config file that is used by the libccsCommon library is listed below. Comments have been removed.

common =
        {
      balanceTypeCascadeIdCacheAgeSeconds = 600
      balanceTypeCascadeCacheAgeSeconds = 600
      detailedCascadeCacheAgeSeconds = 600
      balanceTypeUnitCacheAgeSeconds = 600
      balanceTypeIdCacheAgeSeconds = 600
      defaultBalanceTypeCacheAgeSeconds = 600
      systemCurrencyBalanceUnitCacheAgeSeconds = 600
      accountCacheAgeSeconds = 600
      accountTypeBestPeriodsCacheAgeSeconds = 600
      ccsWlcAgeSeconds =
          600
      ccsRewardTranslationAgeSeconds = 600
      ccsWalletNameTranslationAgeSeconds = 600
      ccsLanguageDetailsAgeSeconds = 600
      ccsBalanceTypeTranslationAgeSeconds = 600
      acsCustIdAgeSeconds
          = 600
      ignoreBTs = [ 201
          ]
      authCB10ValidateSeed = false
      xmlInterfaceName =
          "xmlIF"
      }

libccsVWARSUtils

Purpose

libccsVWARSUtils is used by beVWARS handlers and plug-ins to perform common tasks such as charges and recharges.

Example

The following example configuration shows the ccsVWARSUtils parameter group in the eserv.config file on the Voucher and Wallet Server node. Comments have been removed.
ccsVWARSUtils = {
createAdditionalExpiryEdr = true
createNonExpiringBuckets = false
rechargePreUseAccounts = true
rechargeTerminatedAccounts = false
perBalanceEDRs = true
raiseAlarmForMissingTemplates = false
setNonExpiringBucketExpiryFromToday = false
canReduceBucketExpiryFromToday = true
earliestBucketExpiryPolicyFromToday = false
useCallDurationInTimeExpenditure = true
addBucketLevelCostsInEdr = true
bucketLevelCostsLimit = 10
}

Parameters

libccsVWARSUtils accepts the following parameters from the ccsVWARSUtils section in eserv.config.

Note:

These parameters affect the common functions used by beVWARS handlers and plug-ins.

createAdditionalExpiryEdr

Syntax: createAdditionalExpiryEdr = true|false
Description: How to log EDRs when 'replace balance' is specified for any balance type defined for a voucher or voucher type recharge and is used in a WGR operation.
Type: Boolean
Optionality: Optional (default used if not set).
Allowed:
  • true:

    Two EDRs are generated:

    • An expiry EDR (type 3) for the balance which is being replaced, and
    • A recharge EDR (type 4) for the new bucket which is being created with the new value.
  • false: One recharge EDR is logged which records the old and new bucket values.
Default: false
Notes:

The recharge EDR type may be overridden depending on calling mechanism.

For more information about WGR operations, see VWS Technical Guide.

Example: createAdditionalExpiryEdr = true

createNonExpiringBuckets

Syntax: createNonExpiringBuckets = true|false
Description: What to do if a wallet recharge includes setting up a new bucket, but doesn't provide details of how to set the bucket's expiry date.
Type: Boolean
Optionality: Optional (default used if not set).
Allowed:
  • true: If the recharge does not provide bucket expiry details, create the bucket without an expiry date.
  • false: If the recharge does not provide bucket expiry details, do not create the bucket.
Default: true
Notes:
Example: createNonExpiringBuckets = false

perBalanceEDRs

Syntax: perBalanceEDRs = true|false
Description: Split multiple balance voucher recharge EDRs into several single balance voucher recharge EDRs.
Type: Boolean
Optionality: Optional (default used if not set).
Allowed:
Default:
Notes:
Example: perBalanceEDRs = true

raiseAlarmForMissingTemplates

Syntax: raiseAlarmForMissingTemplates = true|false
Description: Specifies whether beVWARS raises an alarm when a recharge notification template is not found.
Type: Boolean
Optionality: Optional (default used if not set)
Allowed: true, false
Default: false
Notes:
Example: raiseAlarmForMissingTemplates = false

rechargePreUseAccounts

Syntax: rechargePreUseAccounts = true|false
Description: Whether to allow wallets with a PreUse to be recharged.
Type: Boolean
Optionality: Optional (default used if not set).
Allowed: true, false
Default: true
Notes: Recharging a PreUse wallet will also activate it.
Example: rechargePreUseAccounts = false

rechargeTerminatedAccounts

Syntax: rechargeTerminatedAccounts = true|false
Description: Whether or not to allow wallets with a terminated state to be recharged.
Type: Boolean
Optionality: Optional (default used if not set).
Allowed:
  • true: Allow recharges of wallets with a terminated state to be recharged.
  • false: Do no allow recharges of wallets with a terminated state to be recharged.
Default: false
Notes:

If this parameter is set to true, the recharge must set a wallet expiry extension value, or the wallet will expire immediately after the recharge is performed.

For more information about setting wallet expiry extension periods, see Charging Control Services User's Guide.

Example: rechargeTerminatedAccounts = true

setNonExpiringBucketExpiryFromToday

Syntax: setNonExpiringBucketExpiryFromToday = true|false
Description:

Allows the bucket expiry date to be set for non-expiring buckets following a recharge that sets an expiry date and has an expiry extension policy of "From Today".

The expiry date is set if setNonExpiringBucketExpiryFromToday is set to true. If setNonExpiringBucketExpiryFromToday is set to false, then the expiry date is not set.

Type: Boolean
Optionality: Optional (default used if not set)
Allowed: true or false
Default: false
Notes:
Example: setNonExpiringBucketExpiryFromToday = true

canReduceBucketExpiryFromToday

Syntax: BucketExpiryFromToday = true | false
Description: Whether or not libccsVWARutils overwrites a bucket's expiration date when the bucket is recharged and uses the "From Today" policy. This can be used to shorten expirations.
Type: Boolean
Optionality: Optional (default used if not set)
Allowed:
  • true – Overwrites the bucket's expiration date
  • false – Does not overwrite the bucket's expiration date
Default: false
Notes:
Example: canReduceBucketExpiryFromToday = true

earliestBucketExpiryPolicyFromToday

Syntax: earliestBucketExpiryPolicyFromToday = true | false
Description:

Whether or not libccsVWARSutils updates all buckets in the balance when applying logic from either of these parameters:

  • setNonExpiringBucketExpiryFromToday
  • canReduceBucketExpiryFromToday
Type: Boolean
Optionality: Optional (default used if not set)
Allowed: true, false
Default: false
Notes:
Example: earliestBucketExpiryPolicyFromToday = True

useCallDurationInTimeExpenditure

Syntax: useCallDurationInTimeExpenditure = true | false
Description: For time expenditure balance type, whether to use total call duration or actual time balance expenses while incrementing.
Type: Boolean
Optionality: Optional (default used if not set)
Allowed:
  • true – Use total call duration expenses while incrementing time expenditure balance.
  • false – Use actual time balance expenses while incrementing time expenditure balance.
Default: false
Notes:
Example: useCallDurationInTimeExpenditure = true

addBucketLevelCostsInEdr

Syntax: addBucketLevelCostsInEdr = true | false
Description: Specifies whether to populate and add BUCKET_LEVEL_COSTS tag in EDR.
Type: Boolean
Optionality: Optional (default used if not set)
Allowed:
  • true – Add Bucket Level Costs in EDR.
  • false – Do not add Bucket Level Costs in EDR.
Default: false
Notes:

The BUCKET_LEVEL_COSTS tag is added only in case of charging.

For mid-session EDR enabled scenarios, BUCKET_LEVEL_COSTS tag will be present only in the mid-session EDRs and not in the final EDR.

Example: addBucketLevelCostsInEdr = true

bucketLevelCostsLimit

Syntax: bucketLevelCostsLimit = int
Description: Specifies the maximum number of entries to populate in the BUCKET_LEVEL_COSTS tag in the EDR. This parameter caps the output to prevent EDR/CDR truncation when the system is configured with many buckets.
Type: Integer
Optionality: Optional (default used if not set)
Allowed:
  • 0: BUCKET_LEVEL_COSTS entries are unlimited, matching previous behaviour.
  • N (> 0): Limits the BUCKET_LEVEL_COSTS output to a maximum of N entries.
Default: 0
Notes:
  • This configuration applies only when BUCKET_LEVEL_COSTS population is enabled.
  • When unset or set to 0, system behaviour remains unchanged and all bucket-level cost entries are included.
  • When set to a positive value, the system dynamically enforces the cap during BUCKET_LEVEL_COSTS generation in EDRs.
  • This enhancement helps prevent EDR/CDR truncation in production environments with a large number of configured buckets.
Example: bucketLevelCostsLimit = 10

dcaResPlugin

Purpose

dcaResPlugin is used by beVWARS handlers and plug-ins to send ReAutorizationRequest (RAR) notifications to SLC.

When a wallet with active diameter session is recharged, it triggers a RAR request to diameterControlAgent at SLC via dapIF at VWS.

Example

CCS {
    dcaResPlugin{
        dapOperationSet = "RAR"
        sendNotifications = false
    }
}

Parameters

dcaResPlugin accepts the following parameters from the dcaResPlugin section in eserv.config.

Note:

These parameters affect the common functions used by beVWARS handlers and plug-ins.

dapOperationSet

Syntax: dapOperationSet = "RAR"
Description: Name of the operation set used by DAP to send the notification.
Type: String
Optionality: This configuration must be set to send the notifications. Notifications will not be sent if it is left empty or not configured.
Allowed:
Default:
Notes: eserv.config shipped with product has it set to "RAR".
Example: dapOperationSet = "RAR"

sendNotifications

Syntax: sendNotifications = true|false
Description: Determines whether to send RAR notification.
Type: Boolean
Optionality: Optional (default used if not set).
Allowed: true, false
Default: true
Notes:
Example: sendNotifications = false