Charging Data Records (CDRs)

You can configure dsTest to collect, and optionally validate, or to generate CDRs when testing an interface application that involves CDRs - Ga, Gx, Ro, or Rf, for example.

If you will be either generating CDRs or validating the CDRs collected by dsTest you'll need to define CDR templates in the subscriber database's PCC Profile for the services and the types of records applicable to your test. These templates define the structures for the various types of records. When dsTest will be generating CDRs it will provision the record templates with actual subscriber data and then transmit the records to the designated peer. If dsTest will be validating the records collected you can provision your templates with criteria that incoming records must satisfy to be considered valid. Instances of CDR templates are named, which enables you to define more than one template for the same type of record and dsTest will consider all of those templates when validating incoming records - only records that don't match any of your templates will be marked as invalid.

You'll need to configure the applicable interface application for either CDR generation or collection and you'll find those elements as part of the node emulator definition. See, for example, an OFCS node's Ga configuration.

On the server side, if you plan to collect CDRs you must configure Record Storage Mode and should configure Records File Name with a meaningful file name. You can use the other "Records File" parameters to fine tune the record buffer to suit your platform if needed, and you can also specify record storage file size and number of files if desired. If record storage is enabled and no other elements are set, dsTest will create ten files in the directory from which dsTest was launched. The files will be named cdr_<node_name>, cdr_<node_name>.0 through cdr_<node_name>.8. The presence of CDR templates determines whether dsTest will validate incoming records, and the application's measurements will report the validation statistics.

CDR collection will stop and the current file will be closed when the collecting node is deleted. If you find it necessary to copy or move an active records file while the test is running, use the Records File Close command to gracefully close the file and ensure that it ends on a record boundary.

On the client side no further configuration is needed apart from the CDR templates but you can specify how many records will be transferred in each message. CDRs will be generated and transmitted naturally as transactions are processed.

With dsClient Desktop, you can use the CDR Search feature to stream the CDRs contained in a records file while the test is running or after it is complete. You can also filter the stream by record type or record field values.

dsTest provides a utility, cdr2csv, to convert the CDR files to csv formatted files. It must be executed from the directory that contains the records file(s) to be processed.

cdr2csv {-f <records_file_name> | -a <application>} [-o <csv_file_name>] [-x <cdr_filter_file_name>] [-c <column_filter_file_name>]

The element name of the application that received the CDRs (if your test configuration did not specify a file name)