6 Tools and Utilities

This chapter provides a description of the operational programs or executables which are used to administer CCS. All of these processes are performed when needed.

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.

Note:

Most processes can be re-started using the UNIX kill command.

Using SLP Trace log files

Processes started by the inittab and cronjobs produce logfiles that are stored in the tmp folder of each service directory, that is /IN/service_packages/CCS/tmp/.

About Voucher Tools

The voucher-related tools are documented in Voucher Manager Technical Guide.

About ccsAccount

ccsAccount enables you to generate large numbers of CCS subscribers and wallets by batch. This is a good way to create thousands of subscribers and wallets with minimal effort.

The ccsAccount tool has two modes of running:

• Generating subscribers and wallets
• Rolling back an unsuccessful or interrupted run

Note:

This program is signal aware:

• Use SIGHUP to reload the configuration (throttling and so on)
• Ctrl+C once will stop new account generation and finish the current ones
• Ctrl+C twice will completely stop the tool

ccsAccount, when run with the -P (privacy) option, enables you to:

• Generate large numbers of CCS card or subscriber accounts (and corresponding wallets if none exist) randomly in a batch
• Ensure a sequential serial number is allocated and stored into the CLI
• Encrypt the print shop output file

Rollback

This tool will usually ensure that the system is not left in an inconsistent state. The rollback will remove any rows that ccsAccount cannot verify were created successfully. It will not rollback the whole batch, or even the CCS_ACCOUNT_BATCH row. Rollbacks are done by re-running the tool with the -R option. See unresolvable-reference.html#GUID-2131CEE9-A33A-44BB-A638-F9103544B6BC for more information.

About ccsAccountStartup.sh

ccsAccountStartup.sh runs ccsAccount to generate subscriber accounts normally or to rollback account generation. ccsAccountStartup.sh is usually started by smsReportsDaemon when a user clicks a button on the CCS UI. However, it can be run directly from the command line by ccs_oper. On a standard installation, it runs from /IN/service_packages/CCS/bin/.

About ccsAccountWithPrivacy.sh

ccsAccountWithPrivacy.sh can be run directly from the command line. It must be run by the user who imported the GPG key that will be used. If the key was imported using the Public Keys tab, it must be run by smf_oper. On a standard installation, it runs from /IN/service_packages/CCS/bin/.

Run the program in privacy mode:

ccsAccountWithPrivacy.sh GPG_key output_filename other_ccsAccount_parameters

Where other_ccsAccount_parameters are defined in the table in <Command line parameters>.

As a result, ccsAccountWithPrivacy.sh will extract the GPG key and direct the encrypted output to the print shop filename. The rest of the parameters are passed through to the ccsAccount binary as follows:

ccsAccount -P -m encryption_module other_ccsAccount_parameters

And as a result, the account batch output file is generated.

About eserv.config Parameters

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

Some of the CCS shared parameters are also used by ccsAccount:

• oracleUserAndPassword. See Parameters for more information.
• accountNumberLength

accountNumberLength

Syntax:	accountNumberLength = int
Description:	The number of digits in card number in a subscriber account. If accountNumberLength is set to zero (0) then the account number can be any length.
Type:	Integer
Optionality:	Optional (default used if not set)
Allowed:
Default:	10
Notes:	Used by ccsAccount when generating subscriber accounts.
Example:	accountNumberLength = 14

batchFullness

Syntax:	batchFullness = percentage
Description:	Sets a limit (expressed as a percentage) to control how full ccsAccount can allow the batch to become during the run.
Type:	Percentage
Optionality:	Required when ccsAccount is run in privacy mode.
Allowed:
Default:	50
Notes:	This parameter is only applicable when the -P option is used.
Example:	batchFullness = 90

Syntax:	cardNumberIncludesServiceProviderPrefix = true|false
Description:	Determines if the service provider prefix should be included or not when writing out card numbers to the print shop file.
Type:	Boolean
Optionality:	Optional
Allowed:	true, false
Default:	true
Notes:
Example:	cardNumberIncludesServiceProviderPrefix = false

ccsAccount section

Syntax:	ccsAccount = { }
Description:	This section contains the parameters defining ccsAccount generation config.
Type:
Optionality:
Allowed:
Default:
Notes:
Example:

checkAccountNumbers

Syntax:	checkAccountNumbers = true|false
Description:	Whether to check that the supplied subscriber numbers (or generated from the CLIs with the -a option) do not already exist.
Type:	boolean
Optionality:
Allowed:	true, false
Default:	true
Notes:
Example:	checkAccountNumbers = true

checkCLIs

Syntax:	checkCLIs = true|false
Description:	Whether to check that the supplied CLIs do not already exist.
Type:	boolean
Optionality:
Allowed:	true, false
Default:	true
Notes:
Example:	checkCLIs = true

doSMFChallenge

Syntax:	doSMFChallenge = true|false
Description:	Determines whether to do the SMF authentication challenge that allows the process to update the SMF database.
Type:	Boolean
Optionality:	Optional
Allowed:	true, false
Default:	true
Notes:
Example:	doSMFChallenge = true

maximumRetries

Syntax:	maximumRetries = int
Description:	Determines the number of times the ccsAccount tool will accept, in succession, a match to an existing account number, while generating random card/account numbers.
Type:	Integer
Optionality:	Required when ccsAccount is run in privacy mode.
Allowed:
Default:	15
Notes:	This parameter is only applicable when the -P option is used. On exhausting this value, the tool will abort the attempt, even if a unique number has not been found, thus avoiding infinite running. This is more likely to occur as the batch approaches 100% of it's capacity.
Example:	maximumRetries = 100

maximumSendAttempts

Syntax:	maximumSendAttempts = int
Description:	This defines the maximum number of attempts to send the wallet create request to the VWS.
Type:	Integer
Optionality:
Allowed:
Default:	3
Notes:
Example:	maximumSendAttempts = 3

noAbortOnException

Syntax:	noAbortOnException = true | false
Description:	Specifies whether ccsAccount continues to generate accounts or fails and creates a core file when an unknown SQL exception occurs during account creation.
Type:	Boolean
Optionality:	Optional (default used if not set)
Allowed:	true – ccsAccount continues to generate accounts after an unknown SQL exception occurs false – ccsAccount fails and creates a core file when an unknown SQL exception occurs
Default:	false
Notes:
Example:	noAbortOnException = true

progressUpdateInterval

Syntax:	progressUpdateInterval = seconds
Description:	The number of seconds ccsAccount should wait between writing syslog messages monitoring progress.
Type:	Integer
Optionality:
Allowed:
Default:	60
Notes:
Example:	progressUpdateInterval = 60

rollbackFilename

Syntax:	rollbackFilename = "dir"
Description:	The location of the persistent store of the wallet creation status to allow rollback of incomplete/inconsistent wallets.
Type:	String
Optionality:
Allowed:
Default:	"/tmp/ccsAccount-rollbackCache"
Notes:
Example:	rollbackFilename = "/tmp/ccsAccount-rollbackCache"

sendRetryDelay

Syntax:	sendRetryDelay = seconds
Description:	The number of seconds ccsAccount should wait between retry attempts.
Type:	Integer
Optionality:
Allowed:
Default:	16
Notes:
Example:	sendRetryDelay = 16

serialNumberLength

Syntax:	serialNumberLength = int
Description:	Determines the length of the generated card serial numbers (CLIs).
Type:	Integer
Optionality:	Optional
Allowed:	Within the range from 5 to 19
Default:	11
Notes:	This includes the 2 digit service provider prefix number in its length, so a value of 11 will include # nn000000000.
Example:	serialNumberLength = 7

suppressCreateWalletMes - Oberth

Syntax:	suppressCreateWalletMes = true | false
Description:	Specifies whether ccsAccount prints out the create wallet message.
Type:	Boolean
Optionality:	Optional (default used if not set)
Allowed:	If the value is true, do not print out the create wallet message. If the value is false, print out the create wallet message.
Default:	false
Notes:
Example:	suppressCreateWalletMes = false

wantReplicationLogging

Syntax:	wantReplicationLogging = true|false
Description:	Determines whether to tell the replication subsystem that there are changes to replicate out.
Type:	Boolean
Optionality:	Optional
Allowed:	true, false
Default:	true
Notes:
Example:	wantReplicationLogging = true

ClientIF section

Syntax:	ClientIF {}
Description:	Section containing the parameters for the libBeClientIF.
Type:	Parameter array
Optionality:	Optional
Allowed:	Any parameter which is supported by the libBeClientIF.
Default:	Empty
Notes:	For more information about the libBeClientIF, see VWS Technical Guide.
Example:

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:	Required
Allowed:	For value 0, disable heartbeat detection. for any positive integer, show heartbeat period.
Default:	3000000
Notes:	1 000 000 microseconds = 1 second. If no heartbeat message is detected during the specified time, client process switches to the other Voucher and Wallet Server in the pair. This parameter is used by libBeClientIF.
Example:	heartbeatPeriod = 10000000

clientName

Syntax:	clientName = "name"
Description:	The unique client name of ccsAccount.
Type:	String
Optionality:	Mandatory
Allowed:
Default:	"ccsAccount"
Notes:	The server generates clientId from a hash of the value. If more than one client attempts to connect with the same name, then some connections will be lost. This parameter is used by libBeClientIF. However, ccsAccount uses a different default.
Example:	clientName = "ccsAccount-uasprod01"

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

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:	If the value is anything between 1-604800, it indicates the number of seconds to wait. If the value is 0, it means there is no 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

notEndActions

Syntax:	Syntax: notEndActions = [ {type="str", action="[ACK|NACK]"} [...] ]
Description:	The notEndActions parameter array is used to define the messages associated with dialogs that should not have their dialog closes, because the dialog is closed by default. This facilitates failover.
Type:	Parameter array.
Optionality:	Required
Allowed:
Default:
Notes:	If the incoming dialog for a call closes and the last response received was of the notEndActions type, the client process sends an ABRT message. The ABRT message allows the VWS to remove the reservation. An example of this situation would be where slee_acs has stopped working. This parameter is used by libBeClientIF. For more information about slee_acs, see ACS Technical Guide.
Example:	notEndActions = [ {type="IR ", action="ACK "} {type="SR ", action="ACK "} {type="SR ", action="NACK"} {type="INER", action="ACK "} {type="SNER", action="ACK "} {type="SNER", action="NACK"} ]

action

Syntax:
Description:	Action to take with a message.
Type:
Optionality:
Allowed:	"NACK" "ACK"
Default:
Notes:
Example:

type

The type of message.

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:	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

throttling section

Syntax:	throttling = { }
Description:	This section contains the parameters used to minimize impact on the SMF databases and the VWSs.
Type:
Optionality:
Allowed:
Default:
Notes:
Example:

maxAccountsPerMinute

Syntax:
Description:	This sets the unit wallet create requests per minute. Maximum rate of requests to VWSs.
Type:	integer
Optionality:
Allowed:
Default:	60
Notes:
Example:

preAllocDebug

Syntax:	preAllocDebug = true | false
Description:	Specifies whether ccsAccount and its stored procedures create additional debug logs.
Type:	Boolean
Optionality:	Optional (default used if not set)
Allowed:	true – ccsAccount and its associated stored procedures create additional debug logs false – ccsAccount and its associated stored procedures do not create additional debug logs
Default:	false
Notes:
Example:	preAllocDebug = true

preVerifyAccountNumber

Syntax:	preVerifyAccountNumber = true | false
Description:	Specifies whether ccsAccount validates that an account number does not already exist in the database before it uses the account number.
Type:	Boolean
Optionality:	Optional (default used if not set)
Allowed:	true – Validates that an account number does not already exist in the database before it uses the account number. When it finds a duplicate account number during validation, ccsAccount uses the next free account number. false – Does not perform account number validation.
Default:	false
Notes:
Example:	preVerifyAccountNumber = true

queueSize

Syntax:
Description:	Unit wallet requests to VWS. Maximum wallet creations in progress at once.
Type:	integer
Optionality:
Allowed:
Default:	10
Notes:
Example:

BE eserv.config Parameters

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

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"

Example of ccsAccount Section Parameters

An example of the parameters of a SLC eserv.config file which configures ccsAccount. Comments have been removed.

CCS = {
...
accountNumberLength = 10
...
ccsAccount = {
maximumSendAttempts = 3
sendRetryDelay = 16
progressUpdateInterval = 60
rollbackFilename = "/tmp/ccsAccount-rollbackCache"
doSMFChallenge = true
wantReplicationLogging = true
serialNumberLength = 7
maximumRetries = 100
batchFullness = 90
cardNumberIncludesServiceProviderPrefix = false
checkAccountNumbers = true
checkCLIs = true
suppressCreateWalletMes = true
noAbortOnException = true
ClientIF = {
clientName = "ccsAccount"
plugins = []
}
throttling = {
queueSize = 10
maxAccountsPerMinute = 60
preAllocDebug = true
preVerifyAccountNumber = true
}
}
}

Note:

ccsAccount also uses the global parameters:

• oracleUserAndPassword. See Parameters for more information.
• accountNumberLength. See Parameters for more information.
• beLocationPlugin. See BE eserv.config Parameters for more information.

Seeing the configuration

You can see the configuration that the tool is running, when not in privacy mode, by setting the debug flag ccsAccount_config:

export DEBUG=ccsAccount_config

The recommended debug flags are:

export DEBUG=ccsAccount,ccsAccount_config

Normal running should not require debug flags set.

Command Line Parameters

Running ccsBeResync from the command line with the -h flag will print out a list of the command line parameters.

Usage:

ccsBeResync -u username/password [-b id] [-m primary|secondary] [-r] [-v] [-s id] [-e id] [-o filename] [-h] [-?]

The available parameters are:

-u

Syntax:	-u username/password
Description:	VWS database username and password.
Type:	String
Optionality:
Allowed:
Default:
Notes:
Example:	-u e2be_admin/manager

-b

Syntax:	-b id
Description:	The ID of the Voucher and Wallet Server pair to synchronize.
Type:
Optionality:
Allowed:
Default:
Notes:	This should be the same as the entry from CCS_BE_LOCATION.BE_ACCT_ ENGINE_ID for logical Voucher and Wallet Server pair.
Example:

-e

Syntax:	-e id
Description:	End of range, using one of the following: CCS_ACCT.BE_ACCT_ID if synchronizing wallets (default) CCS_VOUCHER_REFERENCE.ID when synchronizing vouchers (-v). Defaults to 0.

-h/-?

Display syntax help.

-m

Syntax:	-m primary|secondary
Description:	Master [primary|secondary]. The Voucher and Wallet Server which will be the master data source.
Type:
Optionality:
Allowed:	primary secondary
Default:
Notes:	If specified, will only make changes to the slave Voucher and Wallet Server regardless of the nature of the differences that ccsBeResync identifies. Records that only exist on the slave will not be recreated on the master and all updates resulting from differences will be resolved in favor of the master.
Example:

-o

Syntax:	o filename
Description:	When specified, ccsBeResync will redirect individual difference and overall statistics output to the nominated file.
Type:
Optionality:
Allowed:
Default:	stdout
Notes:
Example:

-r

Syntax:
Description:	Report mode.
Type:
Optionality:
Allowed:
Default:
Notes:	Wallet/voucher information requests are sent and differences reported either as standard output or in the output file (-o parameter). No updates will be made to either Voucher and Wallet Server.
Example:

-s

Syntax:	-s id
Description:	Start of range, using one of the following: CCS_ACCT.BE_ACCT_ID if synchronizing wallets (default) CCS_VOUCHER_REFERENCE.ID when synchronizing vouchers (-v). Defaults to 0.

-v

Syntax:
Description:	Vouchers. Will cause ccsBeResync to perform synchronization updates/reporting to be performed on vouchers instead of wallets.
Type:
Optionality:
Allowed:
Default:
Notes:	If this is not set it will default to performing the synchronization on wallets only. The tool will not attempt doing both.
Example:

Example Usage

ccsAccount -B BE Id -t prod_type [-s start -e end] -n number –b limit_type -C PIN_digits -c currency [-d] –o file [-a] -l CLI_list_filename -m auth_module_name [-u]

Exported Card or Account Batch Files

Subscriber account/calling card batch file format is controlled by the account writer plug-in used to generate the batch. Which libraries are used is defined by the authentication name specified in the New Subscriber Batch screen.

Header fields are in the format "Key_field_name=value". Key field names always start with an alphabetic character. This makes it easy to distinguish them from voucher records (which always start with a number).

The following header fields are used in the voucher batch file header, (although downstream processors should detect any "Key_field_name=value" lines).

Header field	Description
AccountBatchID=int	The ID of the subscriber account batch.
ServiceProviderID=int	The ID number of the service provider the subscriber batch belongs to. When ccsAccount is started by the screens the value of this field is populated by the id of the service provider which is selected in the Service Provider field of the Subscriber Management screen when the New button is clicked.
AccountTypeID=int	The product type the subscriber batch has. When ccsAccount is started by the screens the value of this field is populated by the Product Type field on the New Subscriber Batch screen.
maxConcurrent=int	The maximum number of concurrent connections wallets generated with this subscriber batch can have. When ccsAccount is started by the screens the value of this field is populated by the Maximum Concurrent Accesses field on the New Subscriber Batch screen.
BatchSize=int	The number of subscriber accounts in this batch. When ccsAccount is started by the screens the value of this field is populated by the Batch Size field on the New Subscriber Batch screen.
RangeStart=int	Beginning of the range of subscriber account numbers. When ccsAccount is started by the screens the value of this field is populated by the Card Number Start Range field on the New Subscriber Batch screen.
RangeEnd=int	End of the range of subscriber account numbers. When ccsAccount is started by the screens the value of this field is populated by the Card Number End Range field on the New Subscriber Batch screen.
AuthenticationModuleID=int	The ID of the authentication module used for: Encryption and/or random generation of PINs for this batch (optionally) sends the output file for encryption by gpg. When ccsAccount is started by the screens the value of this field is populated by the PAM Name field on the New Subscriber Batch screen.
BillingEngineID=int	The ID number of the Voucher and Wallet Servers .
CurrencyID=int	The ID of the currency the wallets generated with this subscriber batch will use. When ccsAccount is started by the screens the value of this field is populated by the Wallet Currency field on the New Subscriber Batch screen.
LimitType=str	The type of limit the wallets generated with this subscriber batch will use.
BalanceType=int	The balance type ID of the balance type this wallet will have any initial value stored in.

A line consisting of a single equal sign (=) terminates the header lines. All subsequent lines are voucher detail records.

ccsAccount example

This table gives an example of how to use ccsAccount to generate a batch of subscriber accounts.

Stage	Description
1	User telnets to the SMS on which the CCS application is installed and logs in as ccs_oper.
2	User navigates to the directory in which ccsAccount is located. In a standard installation, this will be /IN/service_packages/CCS/bin.
3	User starts the subscriber account batch generation with the following command: $ ccsAccount -t PTS -s 141000 -e 141100 -n 10 –b debit -C 4 -c EUR -d –o /tmp/AcctGenDemo.txt -l Sample_CLI_file
4	ccsAccount generates 10 subscribers and wallets of "PTS" product type. Subscriber numbers start at 141000 and end at 141100. PIN length limit is 4. The subscribers and wallets are stored in the database, the output file is /tmp/AcctGenDemo.txt, the EUR currency will be used and the wallets will have debit balances. Note: AccountLength must be configured to be “6” for this to succeed. The -l cli_filename parameter specifies the CLI file to which the ccsAccount program will refer. The CLI file you specify contains lines which are either: Comments (start with #) Blank Single CLI (may not start with 0, must be a number) Range of CLIs (neither beginning nor end may start with 0, beginning and end separated by '-') Example: # Sample CLI file# 95551212 95550000-95550050 955500595559999 95053333 The ccsAccount program goes through the lines one at a time. If a range is given, it goes through the range in order. Both the beginning and end of a range are available for use as CLIs for a subscriber.

Tip:

Information may appear on the screen in DEBUG builds of ccsAccount to show the progress of the subscriber/wallet generation. However, if this information is not displayed during the generation process, a summary of it may be viewed by using the output command. A subset of this information will appear when using a non-debug build.

Example of Card or Account Output File

Here is an example ccsAccount command and the resulting account batch output file:

Command

ccsAccount -P -t "World" -m "DES" -s 8815000000 -e 8820990000 -n 10 -b debit -C 7 -c USD -d 2>&1

Card or Account Output File

This example shows an exported subscriber account/calling card output file.

# Account Batch Output File
# Generated Wed Dec 31 01:24:29 2008
#
AccountBatchID=59
ServiceProviderID=1
AccountTypeID=7
maxConcurrent=1
BatchSize=10
RangeStart=8815000000
RangeEnd=8819990000
AuthenticationModuleID=4
BillingEngineID=2
CurrencyID=2
LimitType=DEBT
BalanceType=1
=
Dec 31 01:24:29.861203 ccsAccount(15179) NOTICE: Beginning account generation.
16309877,3415992,7,G8.H3zCjoKzbY,8800127
19052821,0363266,7,G8fRbQy015unk,8800128
18627603,5447142,7,G82efn9Gh2gSY,8800129
16635167,9003194,7,G8nkF67MOzS9g,8800130
19498256,8441931,7,G8tfZtbQvbOIg,8800131
18758105,8744644,7,G8CSYLULMZtww,8800132
17349265,3517347,7,G8GH/BMl4HHzs,8800133
16223817,0064708,7,G8MbgIe4gPO.U,8800134
16089674,7771756,7,G8lXd7ySSzsVw,8800135
16405822,1207166,7,G8JugOSguxjqg,8800136
Dec 31 01:24:35.514685 ccsAccount(15179) NOTICE: Progress 10/10 (100.0%) Complete
Dec 31 01:24:35.515578 ccsAccount(15179) NOTICE: Account generation complete.

Failure

If ccsActions fails, the CCS feature node functionality will fail. This will usually result in call processing becoming unstable or failing.

Output

ccsAccount writes a log of all created subscriber accounts to /IN/service_packages/CCS/account/export/.

ccsAccount inserts data into the following tables in the SMF:

• CCS_ACCT
• CCS_ACCT_REFERENCE
• CCS_ACCT_ACCT_REFERENCES
• CCS_ACCT_HIST_INFO

Other ccsAccount Commands

The $ cat /tmp/AccountDemo.txt file allows the user to view the actual output of the file, whether or not that information was displayed during the Account generation.

This allows the user to take input from a file and insert it into the database.

Note:

When a limited credit account is created, the minimum credit balance is set by default to = 0. The minimum credit balance must then be reset manually to the required amount, using the SMS Java administration screens.

Example

# Account Batch Output File
# Generated Mon Aug 28 01:15:52 2000
#
AccountBatchID=0
ServiceProviderID=22
AccountTypeID=35
BatchSize=10
RangeStart=141500
RangeEnd=141520
AuthenticationModuleID=1
BillingEngineID=1
CurrencyID=1
BalanceType=2
=

141500,0801,4,G8bVdVSGtI.9.
141501,4742,4,G8WI1B6IHdSQI
141502,6891,4,G8ACBmfc.cYGg
141503,9394,4,G8OVlG4MDKtmQ
141504,4904,4,G8iiqCNLGD./k
141505,9709,4,G8JoxdWtgYmkk
141506,0158,4,G8uGhZ4LG5qfE
141507,2641,4,G8o6Lc/./i/uw
141508,1468,4,G8/wyTezMlx9U
141509,9023,4,G8JMbJcWiem1E
$ ccsAccount-d -i filename –c EUR

About ccsBeResync

The ccsBeResync is a tool that will resolve and/or report differences between Voucher and Wallet Servers in a logical pair for wallet and voucher tables that may be caused by a software or hardware fault. It does not replace the beSync, which is used to keep the pair synchronized during normal operation.

The tool has two primary operational modes:

• Resynchronizing wallets
• Resynchronizing vouchers

Without a command line option specifying vouchers it will default to resynchronizing wallets. In addition, the tool can be run to one of the following:

• Use one specified Voucher and Wallet Server in a pair as the model data source (that is, when the data on the other Voucher and Wallet Server has been corrupted or is out of date)
• Use configurable business rules to make updates on both Voucher and Wallet Servers

A range of wallet or voucher IDs can be specified, so as to limit the range of voucher/wallets it processes as described in the configuration section.

The ccsBeResync tool can be configured with both:

• Command line arguments
• Entries in the ccsBeResync section of the eserv.config file

Data Transferred

This table lists the E2BE database columns for which the ccsBeResync tool will resynchronize E2BE data.

Table	Column
BE_WALLET	.NEVER_EXPIRES .EXPIRY .MAX_CONCURRENT .STATE .NEVER_ACTIVATED .ACTIVATION_DATE
BE_BALANCE	.LIMIT_TYPE .MINIMUM_CREDIT
BE_BUCKET	.EXPIRY .NEVER_EXPIRES .VALUE .LAST_USE .NEVER_USED .START_DATE .REFERENCE
BE_VOUCHER	.REDEEMED .REDEEMED_DATE .REDEEMING_WALLET_ID

Startup

It is recommended that ccsBeResync is run from the SMS but it can be run from anywhere so long as it is able to connect to the SMF and E2BE databases.

Command Line Parameters

Running ccsBeResync from the command line with the -h flag will print out a list of the command line parameters.

Usage:

ccsBeResync -u username/password [-b id] [-m primary|secondary] [-r] [-v] [-s id] [-e id] [-o filename] [-h] [-?]

The available parameters are:

-u

Syntax:	-u username/password
Description:	VWS database username and password.
Type:	String
Optionality:
Allowed:
Default:
Notes:
Example:	-u e2be_admin/manager

-b

Syntax:	-b id
Description:	The ID of the Voucher and Wallet Server pair to synchronize.
Type:
Optionality:
Allowed:
Default:
Notes:	This should be the same as the entry from CCS_BE_LOCATION.BE_ACCT_ ENGINE_ID for logical Voucher and Wallet Server pair.
Example:

-e

Syntax:	-e id
Description:	End of range, using one of the following: CCS_ACCT.BE_ACCT_ID if synchronizing wallets (default) CCS_VOUCHER_REFERENCE.ID when synchronizing vouchers (-v). Defaults to 0.

-h/-?

Display syntax help.

-m

Syntax:	-m primary|secondary
Description:	Master [primary|secondary]. The Voucher and Wallet Server which will be the master data source.
Type:
Optionality:
Allowed:	primary secondary
Default:
Notes:	If specified, will only make changes to the slave Voucher and Wallet Server regardless of the nature of the differences that ccsBeResync identifies. Records that only exist on the slave will not be recreated on the master and all updates resulting from differences will be resolved in favor of the master.
Example:

-o

Syntax:	o filename
Description:	When specified, ccsBeResync will redirect individual difference and overall statistics output to the nominated file.
Type:
Optionality:
Allowed:
Default:	stdout
Notes:
Example:

-r

Syntax:
Description:	Report mode.
Type:
Optionality:
Allowed:
Default:
Notes:	Wallet/voucher information requests are sent and differences reported either as standard output or in the output file (-o parameter). No updates will be made to either Voucher and Wallet Server.
Example:

-s

Syntax:	-s id
Description:	Start of range, using one of the following: CCS_ACCT.BE_ACCT_ID if synchronizing wallets (default) CCS_VOUCHER_REFERENCE.ID when synchronizing vouchers (-v). Defaults to 0.

-v

Syntax:
Description:	Vouchers. Will cause ccsBeResync to perform synchronization updates/reporting to be performed on vouchers instead of wallets.
Type:
Optionality:
Allowed:
Default:
Notes:	If this is not set it will default to performing the synchronization on wallets only. The tool will not attempt doing both.
Example:

Configuration - eserv.config

ccsBeResync supports these parameters from the ccsBeResync section of the eserv.config file.

ccsBeResync = {
beID = id
syncSequenceDifference = int
maxQueueSize = int
pollTime = seconds
recheckDelay = seconds
maxInfoRechecks = int
maxUpdatesPerRequest = int
beRequestTimeout = seconds
notificationInterval = seconds

bucketValueHighest = true|false
bucketExpiryLatest = true|false
balanceMinCreditHighest = true|false
balanceLimitTypeHighest = true|false
walletMaxConHighest = true|false
walletExpiryLatest = true|false
walletActivationLatest = true|false
bucketReferencePrimary = true|false
skipLastUseFieldCheckAtWallet = true|false

beLocationPlugin = "lib"
oracleUserPass = "usr/pwd"
clientName = "name"

heartbeatPeriod = microsecs
messageTimeoutSeconds = seconds
maxOutstandingMessages = int
reportPeriodSeconds = seconds
connectionRetryTime = seconds

plugins = [
{
config="confStr",
library="lib",
function="str"
}
[...]
]

confStr = { 
plugin configuration
}

notEndActions = [
{type="str", action="[ACK |NACK]"}
[...]
]
}

Parameters

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

beID

Syntax:	beID = id
Description:	ID of the Voucher and Wallet Server pair to resynchronize.
Type:	Integer
Optionality:	Optional (default used if not set).
Allowed:
Default:	1
Notes:	This value can be found in the database table CCS_DOMAIN.DOMAIN_ID. Only one pair can be re-synchronized at a time.
Example:	beID = 3

beRequestTimeout

Syntax:	beRequestTimeout = seconds
Description:	The number of seconds to wait before timing out a message and giving up on that particular wallet/voucher.
Type:	integer
Optionality:	Optional
Allowed:
Default:	60
Notes:	This will produce syslog messages.
Example:	beRequestTimeout = 60

maxInfoRechecks

Syntax:	maxInfoRechecks = int
Description:	If when the wallet/voucher is rechecked for differences, it has changed; it will wait recheckDelay and try again.
Type:	integer
Optionality:	Optional
Allowed:
Default:	5
Notes:	If it is a heavy use wallet, ccsBeResync will give up after maxInfoRechecks.
Example:	maxInfoRechecks = 5

maxQueueSize

Syntax:	maxQueueSize = int
Description:	Maximum number of wallets/ vouchers being checked simultaneously.
Type:	Integer
Optionality:	Optional
Allowed:
Default:	10
Notes:	Increasing this setting will have an impact on the VWSs, but in turn will make resynchronization faster. The count: Includes all wallets/vouchers with outstanding WI/VI and updates Excludes the wallets/vouchers sleeping/waiting to do another WI/VI in order to confirm the differences before correction
Example:	maxQueueSize = 10

maxUpdatesPerRequest

Syntax:	maxUpdatesPerRequest = int
Description:	Maximum size of updates for VWSs. If an update is larger than this maximum, the message will be split into more than one part.
Type:	integer
Optionality:	Optional
Allowed:
Default:	10
Notes:	Large updates sent to the Voucher and Wallet Server may cause problems with the size of a SLEE event. Instead, send maxUpdatesPerRequest each time, and send more than one request if we have more than that many updates to send. ccsBeResync will log alarms if timeouts are occurring because updates are too large.
Example:	maxUpdatesPerRequest = 10

notificationInterval

Syntax:	notificationInterval = seconds
Description:	How often, in seconds, to print out the progress of the ccsBeResync tool.
Type:	integer
Optionality:
Allowed:
Default:	300
Notes:
Example:	notificationInterval = 300

pollTime

Syntax:	pollTime = seconds
Description:	Maximum number of seconds to poll VWS connections before attempting to start another request or check sleeping requests.
Type:	integer
Optionality:	Optional
Allowed:
Default:	1
Notes:
Example:	pollTime = 1

recheckDelay

Syntax:	recheckDelay = seconds
Description:	Number of seconds wait before rechecking an inconsistent wallet/voucher record.
Type:	integer
Optionality:	Optional
Allowed:
Default:	120
Notes:	Setting this too low will cause transactions to be applied twice; once by this tool, and again by the transaction from the other VWS. This should be at least the time it takes for a transaction to make it from one VWS to the other. Inconsistent records are/can be caused when a record has been updated on one VWS, but not synced with the other by beSync yet.
Example:	recheckDelay = 120

skipLastUseFieldCheckAtWallet

Syntax:	skipLastUseFieldCheckAtWallet = true|false
Description:	If this parameter is set to true, ccsBeResync tool synchronizes the wallets with active reservation where commits are not happening during recheckDelay interval for that reservation.
Type:	Boolean
Optionality:	Optional
Allowed:
Default:	false
Notes:	Only those wallets are synchronized whose LUSE field is changing between two WI_Ack responses received for the requests sent recheckDelay seconds apart to a particular VWS node.
Example:	skipLastUseFieldCheckAtWallet = true

syncSequenceDifference

Syntax:	syncSequenceDifference = int
Description:	The maximum allowable difference between sequence numbers on the Voucher and Wallet Servers. If this amount is exceeded, the tool will terminate the resynchronization. This prevents ccsBeResync from applying transactions twice (once itself, and once by the beSync).
Type:	Integer
Optionality:	Optional (default used if not set)
Allowed:	If the value is a negative integer, ignore any difference between sequence numbers. This is useful if (for example) you are recreating the entire database after hardware failure. If the value is a positive integer, it indicates the maximum allowable difference before terminating the resync.
Default:	10
Example:	syncSequenceDifference = 10

eserv.config Business Rules Parameters

The ccsBeResync tool recreates any rows deemed missing in BE_WALLET, BE_BALANCE, BE_BUCKET on either VWS. Therefore, the following parameters are set to determine the resolution of differences between rows that exist on both Voucher and Wallet Servers.

Note:

If the following parameters are not defined, the defaults will be applied to the row, that is, even if the parameter is not set, the row will be updated with the default behavior.

balanceLimitTypeHighest

Syntax:	balanceLimitTypeHighest = true|false
Description:	Make both balances have the same value by taking the highest (true)/ lowest (false) value. Defined (lowest->highest) order is: SingleUse Debit LimitedCredit Credit
Type:	boolean
Optionality:	Optional, default will be used if not specified.
Allowed:	true, false
Default:	false
Notes:	Alters BE_BALANCE.LIMIT_ TYPE.
Example:	balanceLimitTypeHighest = false

balanceMinCreditHighest

Syntax:	balanceMinCreditHighest = true|false
Description:	Make both balances have the same minimum credit limit by taking the highest (true)/ lowest (false) value.
Type:	boolean
Optionality:	Optional, default will be used if not specified.
Allowed:	true, false
Default:	false
Notes:	Alters BE_BALANCE.MINIMUM_ CREDIT.
Example:	balanceMinCreditHighest = false

bucketExpiryLatest

Syntax:	bucketExpiryLatest = true|false
Description:	Makes both buckets have the same expiry by taking the earliest (true)/ latest (false) expiry.
Type:	boolean
Optionality:	Optional, default will be used if not specified.
Allowed:	true, false
Default:	true
Notes:	The latest possible expiry is 'never expires'. Alters BE_BUCKET.EXPIRY and BE_BUCKET.NEVER_EXPIRES.
Example:	bucketExpiryLatest = true

bucketReferencePrimary

Syntax:	bucketReferencePrimary = true|false
Description:	Which VWS Voucher and Wallet Server to use as the master data when resynchronizing buckets (BE_BUCKET) which have a reference and start date.
Type:	Boolean
Optionality:	Optional (default used if not set).
Allowed:	If the value is true, use the values from the primary VWS Voucher and Wallet Server to set the periodic charges. If the value is false, use the values from the secondary VWS Voucher and Wallet Server to set the periodic charges
Default:	true
Notes:	Applies to periodic charge buckets (that is, periodic charges).
Example:	bucketReferencePrimary = false

bucketValueHighest

Syntax:	bucketValueHighest = true|false
Description:	Makes both buckets have the same value by taking the highest (true)/ lowest (false) value.
Type:	boolean
Optionality:	Optional, default will be used if not specified
Allowed:	true, false
Default:	true
Notes:	Alters BE_BUCKET.VALUE
Example:	bucketValueHighest = true

walletActivationLatest

Syntax:	walletActivationLatest = true|false
Description:	Make both wallet have the same activation date by taking the earliest (true)/ latest (false) expiry.
Type:
Optionality:	Optional, default will be used if not specified.
Allowed:	true, false
Default:	true
Notes:	The latest possible expiry is 'never expires'. Alters BE_WALLET. ACTIVATION_ DATE.
Example:	walletActivationLatest = true

walletExpiryLatest

Syntax:	walletExpiryLatest = true|false
Description:	Make both wallet have the same expiry by taking the earliest (true)/ latest (false) expiry.
Type:	boolean
Optionality:	Optional, default will be used if not specified.
Allowed:	true, false
Default:	true
Notes:	The latest possible expiry is 'never expires'. Alters BE_WALLET.EXPIRY and BE_WALLET.NEVER_EXPIRES.
Example:	walletExpiryLatest = true

walletMaxConHighest

Syntax:	walletMaxConHighest = true|false
Description:	Make both wallets have the same maximum concurrent users by taking the highest (true)/ lowest (false) value.
Type:	boolean
Optionality:	Optional, default will be used if not specified.
Allowed:	true, false
Default:	true
Notes:	Alters BE_WALLET.MAX_ CONCURRENT.
Example:	walletMaxConHighest = true

libBeClientIF Parameters

The ccsBeResync tool may use the libBeClientIF to connect to the Voucher and Wallet Server. The standard configuration is available in the parameters described below.

clientName

Syntax:	clientName = "name"
Description:	The unique client name of the process.
Type:	String
Optionality:	Required
Allowed:	Must be unique.
Default:	The host name of the local machine.
Notes:	The server generates clientId from a hash of str. If more than one client attempts to connect with the same name, then some connections will be lost. This parameter is used by libBeClientIF.
Example:	clientName = "scpClient"

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:	Required
Allowed:	If the value is 0, disable heartbeat detection. If the value is a positive integer, it indicates the heartbeat period.
Default:	3000000
Notes:	1 000 000 microseconds = 1 second. If no heartbeat message is detected during the specified time, client process switches to the other Voucher and Wallet Server in the pair. This parameter is used by libBeClientIF.
Example:	heartbeatPeriod = 10000000

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:	If the value is between 1-604800, it indicates the number of seconds to wait. If the value is 0, it indicates no 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

notEndActions

Syntax:	notEndActions = [ {type="str", action="[ACK|NACK]"} [...] ]
Description:	The notEndActions parameter array is used to define the messages associated with dialogs that should not have their dialog closes, because the dialog is closed by default. This facilitates failover.
Type:	Parameter array.
Optionality:	Required
Allowed:
Default:
Notes:	If the incoming dialog for a call closes and the last response received was of the notEndActions type, the client process sends an ABRT message. The ABRT message allows the VWS to remove the reservation. An example of this situation would be where slee_acs has stopped working. This parameter is used by libBeClientIF. For more information about slee_acs, see ACS Technical Guide.
Example:	notEndActions = [ {type="IR ", action="ACK "} {type="SR ", action="ACK "} {type="SR ", action="NACK"} {type="INER", action="ACK "} {type="SNER", action="ACK "} {type="SNER", action="NACK"} ]

action

Syntax:
Description:	Action to take with a message.
Type:
Optionality:
Allowed:	"NACK" "ACK"
Default:
Notes:
Example:

type

The type of message.

plugins

Syntax:	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 libclientBcast. This parameter is used by libBeClientIF.
Example:	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

Example Configuration

An example of the ccsBeResync parameter group of a SLC eserv.config file is listed below. Comments have been removed.

ccsBeResync = {
beID = 1
syncSequenceDifference = 10
maxQueueSize = 10
pollTime = 1
recheckDelay = 120
maxInfoRechecks = 5
maxUpdatesPerRequest = 10
beRequestTimeout = 60
notificationInterval = 300

bucketValueHighest = true
bucketExpiryLatest = true
balanceMinCreditHighest = false
balanceLimitTypeHighest = false
walletMaxConHighest = true
walletExpiryLatest = true
walletActivationLatest = true
bucketReferencePrimary = true
skipLastUseFieldCheckAtWallet = false
}

Failure

Re-synchronization between the data in the source E2BE database and the data in the destination E2BE database will fail. Any discrepancies between the databases may remain. Rerun the tool.

Output

Rows that do not exist on one VWS will be created on the other (only on the slave if performing a master/slave resynchronization).

The ccsBeResync tool will first establish a connection to the Voucher and Wallet Servers in the specified VWS pair. It will then send wallet/voucher information requests to both Voucher and Wallet Servers.

• If the responses do not match it will wait for a configurable number of seconds and send requests again. This is to determine whether the data it is querying is currently in use and waiting for normal synchronization processing to complete.
• If the responses from the first and second queries do not match (that is, the differences between the wallets have changed since the first information request), it keeps trying until it receives a matching response from subsequent requests.
• If no master has been specified it then creates updates according to the business rules set in the eserv.config file and sends them to the appropriate Voucher and Wallet Servers.
• If a master has been specified ('primary'/'secondary'), it will only create updates that will force the slave Voucher and Wallet Server data to become a duplicate of the master.

Note:

The updates are a special message that will not be subject to the normal synchronization process, that is, after being sent to one or the other Voucher and Wallet Server they will not be duplicated across the pair after they have been applied.

Resynchronizing in Normal Operation

The tool is installed in /IN/service_packages/CCS/bin. To run the ccsBeResync tool you must ensure that the ccsBeResync section is present in the eserv.config file that you are using. The tool should be run by ccs_oper. Output of differences found between the Voucher and Wallet Servers when using business rule definitions will be sent to the system log in the form of a NOTICE entry as well as to the tool's standard output. When performing master/slave resynchronizations the differences will only be sent to standard output or the output file.

Examples of Normal Operation:

$/IN/service_packages/CCS/bin/ccsBeResync

With no command line options selected the ccsBeResync tool will:

• Use the Voucher and Wallet Server pair specified in the eserv.config file
• Use business rules to resynchronize records
• Process wallets only
• Output to stdout (no report file will be created)
• Check and update wallet-related database columns specified below for all records in those tables (no start or end range defined).

Table	Column
BE_WALLET	.NEVER_EXPIRES .EXPIRY
BE_BALANCE	.LIMIT_TYPE .MINIMUM_CREDIT
BE_BUCKET	.MAX_CONCURRENT .STATE .NEVER_EXPIRES .EXPIRY .NEVER_ACTIVATED .ACTIVATION_DATE .VALUE

$/IN/service_packages/CCS/bin/ccsBeResync -r -m secondary -o /tmp/Wallet_Resync_Report.txt

With the above command line options the ccsBeResync tool will:

• Use the Voucher and Wallet Server pair specified in the eserv.config file
• Create a report only. No updates to the databases on either VWS will be performed
• Process wallets only
• Create and write output to /tmp/Resync_Report.txt (note: this file will be overwritten by re-running the ccsBeResync tool unless another filename is specified)
• Check and report on wallet-related database column differences for ALL records in those tables (no start or end range defined)

$/IN/service_packages/CCS/bin/ccsBeResync -v -s 1000 -e 5000 -o /tmp/Voucher_Resync.txt

With the above command line options the ccsBeResync tool will:

• Use the Voucher and Wallet Server pair specified in the eserv.config file
• Process vouchers only
• Check and update the BE_VOUCHER.REDEEMED database column according to business rules in the eserv.config file for records with IDs between BE_VOUCHER.ID 1000 and BE_VOUCHER.ID 5000
• Create and write output to /tmp/Voucher_Resync.txt

Normal Error Conditions

The ccsBeResync tool will exit on certain error conditions before it has been able to process all records. These include:

• ccsBeResync process killed during processing
• Configuration file parsing errors
• Command line parsing errors
• Unable to connect to one or both Voucher and Wallet Servers:
• Database unavailable
• Voucher and Wallet Server not running or disabled
• Connection to database or Voucher and Wallet Server broken
• Voucher and Wallet Servers too far out of sync (configurable with override)

When the ccsBeResync has been interrupted during processing the statistics output will report how far through the selected list of records the tool had reached, for example:

Statistics:

• Completed IDs = 3579
• In sync vouchers = 3579
• Last ID processed = 280525
• Total IDs = 100020
• Voucher info acks = 3579
• Voucher info requests sent to primary VWS = 3589
• Voucher info requests sent to secondary VWS = 3589

Note:

Statistics not listed were equal to zero.

Resynchronization Reports

The standard report will contain configuration information used by the ccsBeResync tool, any differences between the specified E2BE databases that were found and a statistics summary for all actions taken by the tool during processing.

Example:

ccsBeResync starting on Fri Oct 3 11:03:55 2003

ccsBeResync Configuration
-------------------------
 beID                   : 1
 masterBE               : not defined
 syncSequenceDifference : -1
 startRange             : 0
 endRange               : 0
 smfUserPass            : /
 Primary BE IP          : 192.168.0.191
 Primary BE Port        : 1700
 Secondary BE IP        : 192.168.0.190
 Secondary BE Port      : 1700
 BE Oracle SID          : E2BE
 BE Oracle logon        : e2be_admin/e2be_admin
 Max Queue size         : 10
 Poll Time              : 2
 Recheck Delay          : 10
 Max Info Rechecks      : 5
 BE Request Timeout     : 60
 Notification Interval  : 3
 Output filename        : syncWallet.out
 No master defined, using business rules

Config map for first BE beClientIF = {
billingEngines = [
{
id = 1
primary = {
ip = "192.168.0.191"
port = 1700
}

}

]

clientName = "ccsBeResync"
plugins = []
}

Config map for second BE beClientIF = {
billingEngines = [
{
id = 1
primary = {
ip = "192.168.0.190"
port = 1700
}

}

]

clientName = "ccsBeResync"
plugins = []
}

 Process wallets
 Report and fix inconsistencies
 ----------------------------------- 
 Business rules
  Highest Bucket Value             : true
  Highest Bucket Expiry Date       : true
  Highest Min Credit Value         : true
  Highest Limit Type               : true
  Highest Wallet Max Concurrent    : true
  Highest Wallet Expiry Date       : true
  Highest Wallet Activation Date   : true
 ----------------------------------- 

Updating primary BE wallet 144 maxCon:1->1 state:PREU->ACTV neverExpires:1->1 expiryDate:0->0 neverActivated:1->1 activationDate=0->0
Wallet 282 Updating secondary bucket 90080 Value 102442000->105181000 Expiry neverExpires->neverExpires
Wallet 284 Updating secondary bucket 90084 Value 102442000->105181000 Expiry neverExpires->neverExpires
Wallet 286 Updating secondary bucket 90088 Value 102442000->105181000 Expiry neverExpires->neverExpires
Wallet 288 Updating secondary bucket 90092 Value 102442000->105181000 Expiry neverExpires->neverExpires
Wallet 290 Updating secondary bucket 90096 Value 102442000->105181000 Expiry neverExpires->neverExpires
Updating primary BE wallet 281 maxCon:1->3 state:ACTV->ACTV neverExpires:1->1 expiryDate:0->0 neverActivated:0->0 activationDate=1064964017->1064964017
Wallet 281 Updating secondary bucket 90078 Value 102530100->105291100 Expiry neverExpires->neverExpires
Wallet 283 Updating secondary bucket 90082 Value 102420000->105181000 Expiry neverExpires->neverExpires
Wallet 285 Updating secondary bucket 90086 Value 102420000->105181000 Expiry neverExpires->neverExpires
Wallet 287 Updating secondary bucket 90090 Value 102420000->105181000 Expiry neverExpires->neverExpires
Wallet 292 Updating secondary bucket 90100 Value 102442000->105181000 Expiry neverExpires->neverExpires
Wallet 294 Updating secondary bucket 90102 Value 102442000->105181000 Expiry neverExpires->neverExpires
Wallet 296 Updating secondary bucket 90106 Value 102442000->105181000 Expiry neverExpires->neverExpires
Wallet 298 Updating secondary bucket 90112 Value 102442000->105181000 Expiry neverExpires->neverExpires
Wallet 291 Updating secondary bucket 90098 Value 102420000->105181000 Expiry neverExpires->neverExpires
Wallet 293 Updating secondary bucket 90104 Value 102420000->105181000 Expiry neverExpires->neverExpires
Wallet 295 Updating secondary bucket 90108 Value 102420000->105181000 Expiry neverExpires->neverExpires
Wallet 297 Updating secondary bucket 90110 Value 102420000->105181000 Expiry neverExpires->neverExpires
Wallet 299 Updating secondary bucket 90116 Value 102420000->105181000 Expiry neverExpires->neverExpires
Wallet 300 Updating secondary bucket 90114 Value 102442000->105192000 Expiry neverExpires->neverExpires

Statistics:
BE_WALLET rows updated = 2
Completed IDs = 5027
In sync wallets = 5000
Last ID processed = 5280
Secondary BE_BUCKET rows updated = 19
Total IDs = 5027
Update Acks = 21
Update responses received = 21
Updates sent = 21
Updates sent to primary = 2
Updates sent to secondary = 19
Wallet Info Acks = 5027
Wallet Info Requests sent to primary BE = 5060
Wallet Info Requests sent to secondary BE = 5060
Wallet diffs without updates = 7
Wallet that changed, and required checking again = 6
Wallets checked second time = 33

ccsBeResync stopped at Fri Oct  3 11:05:19 2003

About ccsBatchCharge

The ccsBatchCharge tool applies batches of updates to subscriber wallets.

ccsBatchCharge permits the activation, processing and deactivation of rules that are used to allocate additional items to a specified balance type for selected subscribers.

Example

ccsBatchCharge supports the following command line parameters:

ccsBatchCharge [-i file] [-o file] [-c str] [-h] [-?]

Parameters

ccsBatchCharge accepts the following command line parameters.

-b

Syntax:	-b bucket
Description:	Default bucket (if not specified in input).
Type:	integer
Optionality:
Allowed:
Default:	-1
Notes:
Example:

-c

Syntax:	-c str
Description:	The section of the eserv.config file to get configuration for bePlugin.
Type:	String
Optionality:	Optional (default used if not set).
Allowed:
Default:	BE
Notes:
Example:	-c

-d

Syntax:	-d debitstrategy
Description:	Debit strategy rule selection.
Type:	integer
Optionality:
Allowed:	1 = SINGLE_NO_NEG 2 = SINGLE_NEG 3 = MULTIPLE
Default:	1
Notes:
Example:

-e

Syntax:	-e CDRextrainfovalue
Description:	Extra information to put into EDR in cdrExtraInfoTag.
Type:	string
Optionality:
Allowed:
Default:	CCSBC
Notes:
Example:

-h

Displays the help file.

-i

Syntax:	-i file
Description:	File to read batch information from.
Type:	String
Optionality:	Optional (default used if not set).
Allowed:
Default:	stdin
Notes:
Example:	-i ChargeBatch.txt

-m

Syntax:	-m maxpending
Description:	Maximum number of requests pending at any time.
Type:	integer
Optionality:
Allowed:
Default:	10
Notes:
Example:

-o

Syntax:	-o file
Description:	The file to write error output to.
Type:	String
Optionality:	Optional (default used if not set).
Allowed:
Default:	stdout
Notes:
Example:	-o ChargeBatch.log

-p

Syntax:	-p seconds
Description:	Default poll time for beClient.
Type:	integer
Optionality:
Allowed:
Default:	1
Notes:	in seconds.
Example:

-r

Syntax:	-r num
Description:	Number of times to poll a request before timing it out.
Type:	integer
Optionality:
Allowed:
Default:	30
Notes:
Example:

-t

Syntax:	-t balancetype
Description:	Default balance type (if not specified in input).
Type:	string
Optionality:
Allowed:
Default:	'General Cash'
Notes:
Example:

-w

Syntax:	-w wallettype
Description:	Wallet type.
Type:3	string
Optionality:
Allowed:
Default:	'Personal'
Notes:
Example:

bePlugin

Syntax:
Description:	Override the default config section used to get information about bePlugin.
Type:	string
Optionality:
Allowed:
Default:	beLocationPlugin
Notes:
Example:

cdrExtraInfoTag

Syntax:
Description:	Name of the tag added to the EDR which holds extra information configured in cdrExtraInfoValue.
Type:	string
Optionality:
Allowed:
Default:	CCSBC
Notes:
Example:

-?

Displays the help file.

About ccsDomainMigration

ccsDomainMigration takes details from the SMS screens and migrates wallets between VWS Voucher and Wallet Servers. For more information about migrating wallets, see VWS Technical Guide.

Startup

Start ccsDomainMigration from the Service Management System (SMS) by selecting the Services->Prepaid Charging->Subscriber Management screen and clicking Restart on the UBE Account Balancing tab. When you push the Restart button, SMS passes parameters to ccsDomainMigration which is started by the ccsDomainMigrationStartup.sh script.

For more information about the UBE Account Balancing tab, see Charging Control Services User's Guide.

You can also invoke the ccsDomainMigrationStartup.sh script in test mode to test connectivity to the VWS servers that are involved in a migration. In this case, the script does not actually perform a migration.

Note:

Invoke ccsDomainMigrationStartup.sh as a command only if wish to run a connectivity test. Use the Restart button in the UBE Account Balancing tab to perform an actual migration.

To run ccsDomainMigration in test mode, invoke it from the command line with the -t parameter. In test mode, ccsDomainMigration reports to the log file whether it successfully connects to the VWS servers.

You can also specify the -p pollTime option in conjunction with the -t option to set the poll time to use in the connection test. The polltime parameter value overrides the value of the polltime parameter in the eserv.config file. After connecting to a VWS, ccsDomainMigration sends four polls before sending the first wallet migration request. The -p polltime option specifies the number of seconds that ccsDomainMigration waits after sending each poll.

The -p option allows you to test different poll time values to determine which ones are best suited for connecting to the VWS. You then can use those values for the polltime parameter in the eserv.config file.

Configuration

ccsDomainMigration supports parameters from the ccsDomainMigration parameter group in the eserv.config file on a SMS. It contains parameters arranged in the structure shown below.

ccsDomainMigration = {
ClientIF = {

heartbeatPeriod = microsecs
messageTimeoutSeconds = secs
maximumSendAttempts = int
pollTime = secs
progressTimeout = secs
sendRetryDelay = secs
}
lockFile = "dir"
commitInterval = int
commitVolume = int
throttle = int
}

Note:

ccsDomainMigration also uses the global parameters:

• beLocationPlugin. See BE eserv.config Parameters for more information.
• oracleUserAndPassword. See Parameters for more information.

Parameters

ccsDomainMigration supports the following parameters in the ccsDomainMigration section of eserv.config.

ClientIF section

Syntax:	ClientIF {}
Description:	Section containing the parameters for the libBeClientIF.
Type:	Parameter group
Optionality:	Required
Allowed:	Any parameter which is supported by the libBeClientIF.
Default:	Empty
Notes:	For more information about the libBeClientIF, see VWS Technical Guide.
Example:

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:	Required
Allowed:	If the value is 0, disable heartbeat detection. If the value is a positive integer, it indicates the heartbeat period.
Default:	3000000
Notes:	1 000 000 microseconds = 1 second. If no heartbeat message is detected during the specified time, client process switches to the other Voucher and Wallet Server in the pair. This parameter is used by libBeClientIF.
Example:	heartbeatPeriod = 10000000

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:	If the value is between 1-604800, it indicates the umber of seconds to wait. If the value is 0, it indicates no 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 = 2maximumSendAttempts

Syntax:	maximumSendAttempts = num
Description:	The number of times that a particular wallet request will be sent to a VWS. A request is resent if either an unrecoverable error occurs or the request times out. The first request sent is counted as attempt number one.
Type:	Integer
Optionality:	Optional (default used if not set)
Allowed:
Default:	3
Notes:	If you specify a value that is lower than the default, ccsDomainMigration uses the default value instead.
Example:	maximumSendAttempts = 5

pollTime

Syntax:	pollTime = seconds
Description:	The number of seconds between the four Voucher and Wallet Server polls ccsDomainMigration makes after it has made a connection to the Voucher and Wallet Server before sending the first wallet migration request.
Type:	Integer
Optionality:	Optional (default used if not set).
Allowed:
Default:	1
Notes:	The time spent polling enables the beServer and ccsDomainMigration to establish a confirmed connection. If errors appear in the syslog indicating a connection has been established and request sending is failing, this value should be increased.
Example:	pollTime = 2

progressTimeout

Syntax:	progressTimeout = seconds
Description:	The number of seconds between checks to ensure that a migration is making progress, that is, that wallet requests are being processed.
Type:	Integer
Optionality:	Optional (default used if not set)
Allowed:
Default:	120
Notes:	If you specify a value that is lower than the default, ccsDomainMigration uses the default value instead.
Example:	progressTimeout = 180

sendRetryDelay

Syntax:	sendRetryDelay = seconds
Description:	The number of seconds between attempts to send a wallet request. The limit on the number of attempts is specified by the maximumSendAttempts parameter.
Type:	Integer
Optionality:	Optional (default used if not set)
Allowed:
Default:	16
Notes:	If you specify a value that is lower than the default, ccsDomainMigration uses the default value instead.
Example:	sendRetryDelay = 20

commitInterval

Syntax:	commitInterval = seconds
Description:	The maximum number of seconds between wallet update commits to the SMF.
Type:	Integer
Optionality:	Optional (default used if not set).
Allowed:	Positive integers
Default:	15
Notes:	Wallet update commits may also be triggered by the number of commits exceeding commitVolume (on page 2).
Example:	commitInterval = 15

commitVolume

Syntax:	commitVolume = int
Description:	The number of records to commit in one batch.
Type:	Integer
Optionality:	Optional (default used if not set).
Allowed:
Default:	200
Notes:	Wallet update commits may also be triggered by the number of seconds between commits exceeding commitInterval (on page 2).
Example:	commitVolume = 200

lockFile

Syntax:	lockFile = "path"
Description:	The directory path and filename of the lockfile.
Type:	String
Optionality:	Optional (default used if not set).
Allowed:
Default:	"/IN/service_packages/CCS/tmp/ccsDomainMigration.lock"
Notes:	On a clustered SMS this must be on the global file system. On a clustered SMS this should be set to the same value on all nodes.
Example:	lockFile = "/IN/service_packages/CCS/tmp/ccsDomainMigration.lock"

throttle

Syntax:	throttle = int
Description:	The maximum number of wallet migration requests to send to the VWS each second.
Type:	Integer
Optionality:	Optional (default used if not set).
Allowed:	If the value is a positive integer, it indicates the maximum requests. If the value is 0, it indicates no limit (disable throttling)
Default:	0
Notes:	For each migration, the lowest value of this setting and the setting in the Throttle field for the migration is used.
Example:	throttle = 2

walletLockMilliSec

Syntax:	walletLockMilliSec = milliseconds
Description:	The number of milliseconds during which the migrating subscriber's wallets will be locked on the source VWS while being migrated to the destination VWS.
Type:	Integer 32 bit integer value (signed)
Optionality:	Optional
Default:	30000
Example:	walletLockMilliSec = 30000

Example

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

ccsDomainMigration = {
ClientIF = {
heartbeatPeriod = 10000000
messageTimeoutSeconds = 2
maximumSendAttempts = 5
pollTime = 1
progressTimeout = 180
sendRetryDelay = 20
}
lockFile = "/IN/service_packages/CCS/tmp/ccsDM.lock" 
commitInterval = 10
commitVolume = 100
throttle = 2
}

Failure

If ccsDomainMigration fails on startup, the UBE Account Balancing tab will report an error and no changes will be made.

If ccsDomainMigration fails or is stopped while processing a migration, ccsDomainMigration will exit and attempt to commit any pending successful transactions to the SMF database. However, it is likely that some wallets will have been migrated on the Voucher and Wallet Server, but the confirmation has not been returned to the ccsDomainMigration process so the SMF database will not reflect those changes. ccsDomainMigration should not be stopped manually. Instead, the migration should be stopped using the Cancel or Pause buttons on the UBE Account Balancing tab. For more information about the UBE Account Balancing tab, see Charging Control Services User's Guide.

Output

ccsDomainMigration updates wallet location and migration details in the following tables in the SMF database.

Note:

You can use the UBE Account Balancing tab in the Subscriber Management screen to export the migration report to a flat file. For more information, see Charging Control Services User's Guide.

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

ccsMFileDump

ccsMFileDump writes data from a specified binary MFile into formatted text or html.

Startup

ccsMFileDump is started from the command line.

Configuration

ccsMFileDump supports the following command-line switches and parameters.

ccsMFileDump [-h|-H prefix] [-c CLI -d DN [-t timestamp] [-p str]] file

file

Syntax:	file
Description:	The name of the CCS MFile to validate and dump. For named event catalogue MFiles the filename must begin with 'P'.
Type:	String
Optionality:	Mandatory
Allowed:
Default:
Notes:
Example:	001160095644

-c

Syntax:	-c CLI
Description:	Dump a portion of the MFile only for the specified CLI and DN.
Type:	Integer
Optionality:	Optional (default used if not set).
Allowed:
Default:	Dump information for all CLI.
Notes:	If -c is specified, -d should also be specified.
Example:	-c 03

-d

Syntax:	-d DN
Description:	Dump a portion of the MFile only for the specified CLI and DN.
Type:	Integer
Optionality:	Optional (default used if not set).
Allowed:
Default:	Dump information for all destination numbers.
Notes:	If -d is specified, -c should also be specified.
Example:	-d 06

-h

Syntax:	-h
Description:	Output the dump in an HTML file with links.
Type:	Boolean
Optionality:	Optional (default used if not set).
Allowed:
Default:	Dump to raw text.
Notes:
Example:

-H

Syntax:	-H prefix
Description:	Dump output to multiple HTML files.
Type:	String
Optionality:	Optional (default used if not set).
Allowed:
Default:	Dump to raw files.
Notes:	Format of file will start with: prefix-1234.html The numbers correspond to the offsets into the MFile.
Example:	-H MFileDump

-p

Syntax:	-p product|named_event_catalogue
Description:	Dump a portion of the MFile for the specified product or named event catalogue. The internal ID for the product type/named event catalogue must be specified. product is also equal to the Account Type ID in the account type section in the MFile.
Type:	Integer
Optionality:	Optional (default used if not set).
Allowed:
Default:	Dump data for all product types.
Notes:	For rating Mfiles, if -p is specified, -c and -d should also be specified. For named event catalogue Mfiles, -p is the only optional parameter.
Example:	-p 4

-t

Syntax:	-t timestamp
Description:	Dump a portion of the MFile for the given timestamp.
Type:	String
Optionality:	Optional (default used if not set).
Allowed:	The timestamp can be specified in any of the following formats: YYYYMMDDHHMMSS, YYYYMMDDHHMM or YYYYMMDD YYMMDDHHMMSS, YYMMDDHHMM or YYMMDD
Default:	Dump all Dates and Times for the specified CLI and DN.
Notes:	If -t is specified, -c and -d should also be specified.
Example:	-t 20061225132500

Rating Example

These lines show examples of the command line configuration for a rating MFile (where the MFile filename is \001160095644\):

ccsMFileDump 001160095644"
ccsMFileDump -h 001160095644"
ccsMFileDump -H out 001160095644"
ccsMFileDump -c 03 -d 06 001160095644"
ccsMFileDump -c 03 -d 06 -t 20061225132500 001160095644"
ccsMFileDump -c 03 -d 06 -t 20061225132500 -p 4 001160095644"

Named Event Catalog Example

These lines show examples of the command line configuration for a named event catalogue MFile (where the MFile filename is \P001160095644\):

ccsMFileDump P001160095644
ccsMFileDump -h P001160095644
ccsMFileDump -H out 001160095644
ccsMFileDump -p 55 001160095644

Output

The ccsMFileDump writes error messages to the system messages file, and writes the content of the MFile to stdout.

ccsProfileBulkUpdate

The ccsProfileBulkUpdate tool applies bulk updates to CCS subscriber profile field tags. It is used to update tags for integer and date profile fields. Multiple tags may be processed at the same time.

When a profile field tag is updated for a subscriber, the old profile tag is removed from the subscriber's profile and the new tag is added. The value previously associated with the old tag is assigned to the new tag.

Note: If the new tag is already present in the subscriber's profile then no changes are made to the tag.

Startup

Follow these steps to run the Profile Tags Bulk Update tool.

1. Login to the SMS as ccs_oper.
2. Navigate to the directory in which ccsProfileBulkUpdate is located. In a standard installation, this will be /IN/service_packages/CCS/bin.
3. Run the program:

   ccsProfileBulkUpdate parameters

   Where the available parameters are defined in the table in Command line parameters (on page 2).

   Note:

   The profileTags.cfg configuration file is located in /IN/service_packages/CCS/etc.

Example

ccsProfileBulkUpdate [-f "filename"] [-?]

Command Line Parameters

-f

Syntax:	-f "filename"
Description:	The name of the input file containing the profile tag updates.
Type:	String
Optionality:
Allowed:
Default:	profileTags.cfg
Notes:	The profileTags.cfg configuration file is located in /IN/service_packages/CCS/etc.
Example:	-f "profileTags.cfg"

-u <user>/<password>

Syntax:	-u "user/password"
Description:	The Oracle username and password.
Type:	String
Optionality:
Allowed:
Default:	"/"
Notes:
Example:	-u "/"

-?

Displays the help file.

Profile Tags Input File

The profile tags input file (profileTags.cfg) lists the profile tags to be updated. Each line in the file contains two decimal numbers separated by a space. These are the number for the tag to be changed followed by the number for its new tag.

Example profileTags.cfg

This is an example profileTags.cfg file.

3146497 3146498
3146511 3146512
1310724 1310725

About License forccsVoucherStartup.sh

The ccsVoucherStartup.sh script is only available if you have purchased the Voucher Management license. For more information about this tool, see Voucher Manager Technical Guide.

CCS Balance Top Up Suite

CCS Balance Top Up Suite uses rules to increment balances on a regular basis. The additional balances are used in the same way as normal funds when the customer makes calls. Updates are applied to a specified balance type of the nominated subscriber wallets by the ccsBatchCharge tool.

Each promotion has associated with it:

• A rule that defines the balance to update, the frequency, the first processing date
• An MSISDN file that defines which subscriber wallets are impacted by the rule

Possible Uses of ccsBatchCharge

You can use the CCSBT when you want to give a list of subscribers one of the following:

• Five notifications every week for six months and the notifications would expire one week after being added if not used
• A one-off increase of 30 units of currency that would expire one month after being added if not used

Rule Definition

A rule is used to decide:

• What balance type to add to
• When to add to the balance
• How often to add to the balance (for a recurrent rule)
• How long the addition will last

Column Definition

The columns allowed in the definition of a balance topup rule are detailed in the following table.

Column	Definition
Name	Name of the rule.
Item count	Number of items (or amount) to add to the balance for every processing of the rule. Valid values are * and positive and negative integers. Where the value is *, the value will be taken from an MSISDN list file. When the rule relates to non-cash balances, the value to be added is absolute (for example, for a value of 10, the number of items to be added will be 10). When the rule relates to cash balances, the value to be added is expressed as 'littles' (for example, adding a value of 15023 will result in a currency amount of 150.23).
First execution date	Date from which the rule begins processing. Valid values are: * Any valid date in the format DD/MM/YYYY. Where the value is *, the value is defaulted to the current date. In this case, the execution mode must be set to IMM. A rule with this value will fire at the next rules execution cycle.
Cycle period	The frequency that the rule fires. The cycle period value has the format nu, where: n is a positive integer u is the time unit. (This can be either d (days) or m (months).) Examples: 13d (13 days), 1d (1 day), 1m (1 month). A value of zero is allowable when iteration count is equal to 1.
Expiry period	The length of time the newly added bucket lasts. The bucket expiry date will be set, and the bucket will be removed when this date is reached. The expiry period value has the format nu, where: n is a positive integer u is the unit. (This can be either d (days) or m (months).) Examples: 13d (13 days), 1d (1 day), 1m (1 month). The expiry date on the added bucket will be date the rule is run plus the expiry period.
Iteration count	The number of times the rule is run. This value must be 1 or more.
Execution mode	Determines whether the rule is to be run immediately, or is to be scheduled for nightly processing. Valid values are: IMM for immediate execution REC for recurrent execution
Wallet type	This is the type of wallet in which the balance is incremented. This value must match a value from CCS_WALLET_TYPE.NAME Examples: 'Primary', 'Secondary'
Balance type	This is the type of balance that is incremented. The balance type must be a free SMS balance type and must match a value from CCS_BALANCE_TYPE.NAME.

The Four Functions

There are four types of basic function related to balance top-up rules.

• Activate rule
• Deactivate rule
• Deactivation cleanup
• Execute rule

Each of these functions is implemented as a separate Unix shell script on the SMS platform. The shell scripts invoke PL/SQL scripts and the PI (PIbatch) to implement the rule. See CCS Balance Topup Rule Scripts for more information.

CCS Balance Top Up MSISDN Files

MSISDN files contain lists of MSISDN numbers or ranges, and are used in the activation and deactivation of Balance Top Up rules.

The MSISDN file structure for activation and deactivation are the same, except that activation files must have a header record.

Note:

The header record is not required for deactivation files.

Record Types

There are two record types for the MSISDN file:

• Header record
• MSISDN detail record

Example MSISDN Files for Activations

Here are example MSISDN files for activations:

7;fPROM56
32496556500
32496556509
32496550000-32496550020

0;vPROM90
32496556500 5
32496556509 10
32496550000-32496550020 4
32496560000-32496560020 8

Example MSISDN Files for Deactivations

Here are example MSISDN files for deactivations:

32496556500
32496556509
32496550000-32496550020

32496556500
32496556509
32496550000-32496550010
32496560000-32496560010

CCS Balance Topup Rule Scripts

The CCS balance topup rule scripts are used to apply balance topup rules to balances. There are four scripts that are installed into /IN/service_packages/CCS/bin and are used in the following ways:

Use	Script
Activate rule	ccsbt_activate_rule.sh
Deactivate rule	ccsbt_deactivate_rule.sh
Deactivation Cleanup	ccsbt_deactivate_cleanup.sh
Execute rule	ccsbt_execute.sh

Activate Rule

Before a rule can be run, the operator must activate it by initiating the Activate rule script. The activation checks that the rule definition and subscriber list (MSISDN file) are valid. If they are valid, the details are stored. All rules being activated must have an associated MSISDN file.

Activation is required for rules of both immediate execution and recurrent execution modes.

A recurrent (REC) rule can only be activated once. The activation process automatically schedules the execution of the rule.

An immediate (IMM) rule where the first execution date is ‘*’ can be activated multiple times. Reactivation of an Immediate rule replaces all MSISDNs that are currently associated with the rule with those contained in the associated MSISDN file.

ccsbt_activate_rule.sh

Use the ccsbt_activate_rule.sh shell script to activate CCS balance topup rules. Before running the script, log on to the SMS as ccs_oper and change to the shell script's directory.

The script must be run using the following parameters:

Usage: ccsbt_activate_rule.sh RuleParameters MSISDNFile [user/password]

The available parameters are:

Rule Parameters

Syntax:
Description:	The parameter definition of the rule to be activated.
Type:
Optionality:
Allowed:	For more information, see Column definition (on page 2).
Default:
Notes:	Rule parameters must be specified in the order that they appear in the rule definition table. They must be comma separated and enclosed within single quote marks.
Example:

MSISDN file

Syntax:
Description:	The name of the file that holds the subscriber list.
Type:
Optionality:
Allowed:
Default:
Notes:
Example:

user/password

Syntax:	oracleuser/password
Description:	The Oracle user name and password to be used when running the script.
Type:
Optionality:	Optional (default used if not specified).
Allowed:
Default:	"/"
Notes:
Example:

Example ccsbt_activate_rule.sh

ccsbt_activate_rule.sh 'PROMO1,1,20/03/2005,1d,1m,2,REC,Personal,Free SMS' PROMO1MSISDNfile

Note:

It is recommended that you review the log file generated by the rule activation process.

Deactivate Rule

Deactivating a rule lets you remove MSISDNs that are associated with it.

Depending on the MSISDNs specified, the rule can be totally deactivated, or can become non-active for certain MSISDNs to which it previously applied.

To deactivate a rule, the operator initiates the deactivate rule script. This checks that the rule name and a subscriber list (MSISDN file) are valid. If they are valid, the specified MSISDN associations are removed from the rule details.

The deactivation of a rule can only take place where the rule has already been activated.

If the deactivation of a rule removes all associations between a rule and any subscribers, then the rule record is removed from the SMF database.

ccsbt_deactivate_rule.sh

Use the ccsbt_deactivate_rule.sh shell script to deactivate a rule.

Before running the script, log on to the SMS as ccs_oper and change to the shell script's directory.

The script must be run using the following parameters:

Usage: ccsbt_deactivate_rule.sh RuleName MSISDNFile [user/password]

The available parameters are:

Rule Name

The unique name of the rule to be deactivated.

Default:

-

MSISDN file

The name of the file that holds the subscriber list to be deactivated.

Default:	-
Note:	You specify the name only. The system assumes that the file is in the ../input directory.

user/password

Syntax:	oracleuser/password
Description:	The Oracle user name and password to be used when running the script.
Type:
Optionality:	Optional (default used if not specified).
Allowed:
Default:	"/"
Notes:
Example:

ccsbt_deactivate_rule.sh

This text shows an example of the ccsbt_deactivate_rule.sh being used.

ccsbt_deactivate_rule.sh PROMO1 PROMO1deactivate

Note:

It is recommended that you review the log file generated by the rule. activation process.

Execute Rules

The execute rule function adds an amount or value to subscriber balances for active rules. The rules are assessed for processing based on the first execution date, the cycle period and the iteration count.

The execute rule function is initiated automatically by two scheduled tasks:

• The first scheduled task processes recurrent rules. This is initiated once per day, at a configurable time (the default time is 02.00 hrs). The task invokes a process that applies the rules of execution mode ‘REC’ to the relevant balances.
• The second scheduled task processes Immediate rules. This is initiated once per hour, configurable after installation (the default is between 10:00 hrs and 17:00 hrs). The task invokes a process that applies the rules of execution mode ‘IMM’ to the relevant balances.

Immediate Rules

Immediate rules only run once after each activation.

An Immediate rule, where the first execution date is ‘*’, can be re-activated multiple times with different subscriber lists (MSISDN files). Reactivating this sort of rule replaces all MSISDNs that are currently associated with the rule, with the rules contained in the new MSISDN file. Reactivation of this sort of rule more than once per day is not supported. The processing applies to one activation that day only.

Output Files

Each rule processing scheduled task generates several output files. These are:

• Log file - a log file is created for each rule processing scheduled task. You are recommended to review this file
• Daily result file - a separate daily result file is created for each processing of each rule
• Daily error file - a separate daily error file is created for each processing of each rule

Execution Log File

A log file is created for each processing of all the current rules. This usually happens hourly.

The file name has the following format:

execute_rule_rundate_runtime_machine_node.log

where:

• rundate is the run date of the execution in DDMMYY format
• runtime is the run time of the execution in HHMM format
• machine_node is the machine node where the processing took place

The file is written to by the CCSBT software and by the ccsBatchCharge program. All activation output and ccsBatchCharge normal and error output is written to this file. After the CCSBT header information, there will be some ccsBatchCharge header information, and then one line for each MSISDN being recharged.

A successful recharge consists of the line number, the word "SUCCESS" and then the input that was used for ccsBatchCharge.

Example: 1,SUCCESS,1231,-50,Free SMS,-2,,AD

Daily Error File

A separate daily error file is created for each processing of each rule. The file name has the following format:

ccsbt_error_machine_node_rundate_rulename.err

where:

• machine_node is the machine node where the processing took place
• rundate is the run date of the execution in DDMMYY format
• rulename is the name of the rule to which the error file pertains

Deactivation Cleanup

Deactivation cleanup provides the ability to:

• Remove the association with a rule where the subscriber has been terminated.
• Remove rules where the final processing date (last active date) has passed. The final processing date is the last date on which a rule runs.

The deactivation cleanup function is initiated automatically by a scheduled task.

The deactivation of a rule for a subscriber can only take place where the rule has already been activated for the subscriber.

The deactivation determines the subscribers that have been terminated and disassociates all rules from the subscriber.

REC Execution Mode

Rules which have the recurrent (REC) execution mode are run in chronological order based on their first execution date. They are run when they meet the following conditions:

Execution	Test Conditions
First execution	When the first execution date is equal to the current date.
Subsequent executions	When the: Iteration count is greater than 1 Current date is an iteration anniversary The rule runs 'iteration count' times, with the interval between executions determined by the cycle period. This means the rule runs if the current date is one of the dates calculated as: (first execution date + (cycle period * (1.. Iteration count - 1)))
Final execution	When the current date is equal to the following anniversary date: (first execution date + (cycle period * (Iteration count)))

IMM Execution Mode

Rules which have the immediate (IMM) execution mode are executed when they meet the following conditions:

Execution	Test Conditions
First execution	When the first execution date is: Equal to '*', or the current date The rule has not been run since activation
Final execution	When the current date is equal to the following anniversary date: (first execution date + (cycle period * (iteration count))) Note: This only applies where the first execution date is a valid date.

dwsublist.sh

The script dwsublist.sh is a report generating tool used to collate the account balances of each subscriber. To generate report data from your Oracle database the script uses the configurable parameters in the dwsublist.cfg file to connect and extract subscriber balance information. See Parameters for more information about configuring the tool.

The script is located in the /IN/service_packages/SMS/input/Ccs_Service/Summary/dwsublist.Errors from the tool are written to the dwsublist.log.

Process

Here is a description of process that dwsublist.sh performs.

1. Create links to each primary E2BE database
2. Extract and merge SMF and E2BE data for each VWS.
3. Process data extracted into temporary global table.
4. Fix date inconsistencies in extracted data.
5. Update CCS_ACCT_HIST_INFO.LAST_CHANGE_STATE_REASON to simulate state changes if account is dormant for a configurable period.
6. Make CCARD and PCARD temporary files (.tmp).
7. Process Data
8. Change CCARD and PCARD filenames from .tmp to real name for the system to pick up.

Reports

The dwsublist is used to collate data which can be presented in the following reports:

• Account Balance in text format
• Account Balance in CSV format

Refer to Charging Control Services User's Guide for details.

Parameters

The dwsublist.sh supports the following parameters from the dwsublist.cfg configuration file.

pcardOutputDir

Syntax:	balancesOutputDir='path'
Description:	The path for the balance output.
Type:	String
Optionality:	Optional (default used if not set).
Allowed:
Default:	'/IN/service_packages/SMS/output/Ccs_Service/Summary'
Notes:
Example:	balancesOutputDir='/IN/service_packages/SMS/output/Ccs_Service/Summary'

ccardOutputDir

Syntax:	ccardOutputDir='path'
Description:	The path to output the CCARD file.
Type:	String
Optionality:	Optional (default used if not set).
Allowed:
Default:	'/IN/service_packages/SMS/output/Ccs_Service/Summary/ccard'
Notes:
Example:	ccardOutputDir='/IN/service_packages/SMS/output/Ccs_Service/Summary/ccard'

pcardOutputDir

Syntax:	pccardOutputDir='path'
Description:	The path to output the PCARD file.
Type:	String
Optionality:	Optional (default used if not set).
Allowed:
Default:	'/IN/service_packages/SMS/output/Ccs_Service/Summary/pcard'
Notes:
Example:	ccardOutputDir='/IN/service_packages/SMS/output/Ccs_Service/Summary/pcard'

Example Configuration

Here is an example dwsublist.cfg file.

ccardOutputDir='/IN/service_packages/SMS/output/Ccs_Service/Summary/ccard'
pcardOutputDir='/IN/service_packages/SMS/output/Ccs_Service/Summary/pcard'
balancesOutputDir='/IN/service_packages/SMS/output/Ccs_Service/Summary'

Example Balance Top Up Rule Execution

The following topics provide some examples of valid and invalid rule executions.

The comma separated rule consists of these components:

• Rule name
• No of SMS (n)
• First execution date (a)
• Cycle period
• Expiry period (e)
• Iteration count
• Execution mode (IMM or REC)
• Wallet type (w)
• Balance type (b)

In the examples the acceptable values for the following variables are:

• p must be an integer greater than 0
• t must be an integer greater than 0
• n must be an integer greater than 0
• a must be a date in the format DD/MM/YYYY, and it must be equal to or greater than the date of activation

Note:

The parameters for each example rule are specified in the order that they appear in the rule definition table. For details, see Column Definitionfor more information.

Valid IMM Rule Examples

The following table provides examples of valid immediate (IMM) rule executions.

Rule	Description
PROM_01,n,*,0,eM,1,IMM,w,b	Run once after activation. (b) bucket added to (w) wallet with value (n) for each valid MSISDN, and is valid for (e) months.
PROM_02,*,*,0,eM,1,IMM,w,b	Run once after activation. (b) bucket added to (w) wallet with value determined from the MSISDN file for each valid MSISDN, and is valid for (e) months.
PROM_03,n,a,0,eM,1,IMM,w,b	Run once on date (a). (b) bucket added to (w) wallet with value(n) for each valid MSISDN, and is valid for (e) months.
PROM_04,*,a,0,eM,1,IMM,w,b	Run once on date (a). (b) bucket added to (w) wallet with value determined from the MSISDN file for each valid MSISDN, and is valid for (e) months.
PROM_05,n,*,0,eM,1,IMM,w,b	Run once after activation. (b) bucket added to (w) wallet with value(n) for each valid MSISDN, and is valid for (e) days.
PROM_06,*,*,0,eM,1,IMM,w,b	Run once after activation. (b) bucket added to (w) wallet with value determined from the MSISDN file for each valid MSISDN, and is valid for (e) days.
PROM_07,n,a,0,eM,1,IMM,w,b	Run once on date (a). (b) bucket added to (w) wallet with value(n) for each valid MSISDN, and is valid for (e) days.
PROM_08,*,a,0,eM,1,IMM,w,b	Run once on date (a). (b) bucket added to (w) wallet with value determined from the MSISDN file for each valid MSISDN, and is valid for (e) days.
PROM_09,n,*,tD,eM,1,IMM,w,b	Run once after activation. (b) bucket added to (w) wallet with value(n) for each valid MSISDN, and is valid for (e) months. Cycle period is ignored.
PROM_10,*,*,tM,eM,1,IMM,w,b	Run once on date (a). (b) bucket added to (w) wallet with value determined from MSISDN file for each valid MSISDN, and is valid for (e) months. Cycle period is ignored.
PROM_11,n,a,tD,eM,1,IMM,w,b	Run once after date (a). (b) bucket added to (w) wallet with value (n) for each valid MSISDN, and is valid for (e) months. Cycle period is ignored.
PROM_12,*,a,tM,eM,1,IMM,w,b	Run once on date (a). (b) bucket added to (w) wallet with value determined from MSISDN file for each valid MSISDN, and is valid for (e) months. Cycle period is ignored.
PROM_13,n,*,tD,eD,1,IMM,w,b	Run once after activation. (b) bucket added to (w) wallet with value(n) for each valid MSISDN, and is valid for (e) days. Cycle period is ignored.
PROM_14,*,*,tM,eD,1,IMM,w,b	Run once after activation. (b) bucket added to (w) wallet with value determined from MSISDN file for each valid MSISDN, and is valid for (e) days. Cycle period is ignored.
PROM_15,n,a,tD,eD,1,IMM,w,b	Run once on date (a). (b) bucket added to (w) wallet with value (n) for each valid MSISDN, and is valid for (e)days. Cycle period is ignored.
PROM_16,*,a,tM,eD,1,IMM,w,b	Run once on date (a). (b) bucket added to (w) wallet with value determined from MSISDN file for each valid MSISDN, and is valid for (e) days. Cycle period is ignored.

ccs_pmx_mv_schedular.sh

This script is used to create or delete scheduler which runs periodically (based on set frequency) to clear CCS_PMX_MSISDN_WHITE_BLACK_MV materialised view logs.

The following are the flags used during scheduler creation:

-u: User name to connect to the database

-v: Value for the scheduler frequency (in seconds)

-o: Operation to be performed (create/destroy)

-m: Check or change current refresh mode (current/demand/commit)

Example Commands

To show list of valid options:

./ccs_pmx_mv_schedular.sh

To create scheduler:

./ccs_pmx_mv_schedular.sh -u /@smf -v 300 -o create

To delete scheduler:

./ccs_pmx_mv_schedular.sh -u /@smf -o destroy

To check current refresh mode:

./ccs_pmx_mv_schedular.sh -u /@smf -m current

To alter refresh mode:

./ccs_pmx_mv_schedular.sh -u /@smf -m demand