CDRe

CDRe is an extension of CDRs, responsible for exporting the CDR events processed by CDRs. It is accessed via CGRateS RPC APIs and configured within cdre section inside JSON configuration.

Export types

There are two types of exports with common configuration but different data sources:

Online exports

Are real-time exports, triggered by the CDR event processed by CDRs, and take these events as data source.

The online exports are enabled via online_cdr_exports JSON configuration option within cdrs.

You can control the templates which are to be executed via the filters which are applied for each export template individually.

Offline exports

Are exports which are triggered via CGRateS RPC APIs and they have as data source the CDRs stored within StorDB.

Parameters

CDRe

CDRe it is configured within cdre section from JSON configuration.

One export profile includes the following parameters:

export_format

Specify the type of export which will run. Possible values are:

*file_csv

Exports into a comma separated file format.

*file_fwv

Exports into a fixed width file format.

*http_post

Will post the CDR to a HTTP server. The export content will be a HTTP form encoded representation of the internal CDR object.

*http_json_cdr

Will post the CDR to a HTTP server. The export content will be a JSON serialized representation of the internal CDR object.

*http_json_map

Will post the CDR to a HTTP server. The export content will be a JSON serialized hmap with fields defined within the fields section of the template.

*amqp_json_cdr

Will post the CDR to an AMQP queue. The export content will be a JSON serialized representation of the internal CDR object. Uses AMQP protocol version 0.9.1.

*amqp_json_map

Will post the CDR to an AMQP queue. The export content will be a JSON serialized hmap with fields defined within the fields section of the template. Uses AMQP protocol version 1.0.

*amqpv1_json_map

Will post the CDR to an AMQP queue. The export content will be a JSON serialized hmap with fields defined within the fields section of the template. Uses AMQP protocol version 1.0.

*sqs_json_map

Will post the CDR to an Amazon SQS queue. The export content will be a JSON serialized hmap with fields defined within the fields section of the template.

*s3_json_map

Will post the CDR to Amazon S3 storage. The export content will be a JSON serialized hmap with fields defined within the fields section of the template.

*kafka_json_map

Will post the CDR to an Apache Kafka. The export content will be a JSON serialized hmap with fields defined within the fields section of the template.

export_path

Specify the export path. It has special format depending of the export type.

*file_csv, *file_fwv

Standard unix-like filesystem path.

*http_post, *http_json_cdr, *http_json_map

Full HTTP URL

*amqp_json_map, *amqpv1_json_map

AMQP URL with extra parameters.

Sample: amqp://guest:guest@localhost:5672/?queue_id=cgrates_cdrs&exchange=exchangename&exchange_type=fanout&routing_key=cgr_cdrs

*sqs_json_map

SQS URL with extra parameters.

Sample: http://sqs.eu-west-2.amazonaws.com/?aws_region=eu-west-2&aws_key=testkey&aws_secret=testsecret&queue_id=cgrates-cdrs

*s3_json_map

S3 URL with extra parameters.

Sample: http://s3.us-east-2.amazonaws.com/?aws_region=eu-west-2&aws_key=testkey&aws_secret=testsecret&queue_id=cgrates-cdrs

*kafka_json_map

Kafka URL with extra parameters.

Sample: localhost:9092?topic=cgrates_cdrs

filters

List of filters to pass for the export profile to execute. For the dynamic content (prefixed with ~) following special variables are available:

*req

The CDR event itself.

*ec

The EventCost object with subpaths for all of it’s nested objects.

tenant

Tenant owning the template. It will be used mostly to match inside FilterS.

synchronous

Block further exports until this one finishes. In case of false the control will be given to the next export template as soon as this one was started.

attempts

Number of attempts before giving up on the export and writing the failed request to file. The failed request will be written to failed_posts_dir defined in general section.

field_separator

Field separator to be used in some export types (ie. *file_csv).

attributes_context

The context used when sending the CDR event to AttributeS for modifications. If empty, there will be no event sent to AttributeS.

fields

List of fields for the exported event. Not affecting templates like *http_json_cdr or *amqp_json_cdr with fixed content.

One field template will contain the following parameters:

path

Path for the exported content. Possible prefixes here are:

*exp

Reference to the exported record.

*hdr

Reference to the header content. Available in case of *file_csv and *file_fwv export types.

*trl

Reference to the trailer content. Available in case of *file_csv and *file_fwv export types.

type

The field type will give out the logic for generating the value. Values used depend on the type of prefix used in path.

For *exp, following field types are implemented:

*variable

Writes out the variable value, overwriting previous one set.

*composed

Writes out the variable value, postpending to previous value set

*filler

Fills the values with a fixed lentgh string.

*constant

Writes out a constant

*datetime

Parses the value as datetime and reformats based on the layout attribute.

*combimed

Writes out a combined mediation considering events with the same CGRID.

*masked_destination

Masks the destination using * as suffix. Matches the destination field against the list defined via mask_destinationd_id field.

*http_post

Uses a HTTP server as datasource for the value exported.

For *hdr and *trl, following field types are possible:

*filler

Fills the values with a string.

*constant

Writes out a constant

*handler

Will obtain the content via a handler. This works in tandem with the attribute handler_id.

value

The exported value. Works in tandem with type attribute. Possible prefixes for dynamic values:

*req

Data is taken from the current request coming from the CDRs component.

mandatory

Makes sure that the field cannot have empty value (errors otherwise).

tag

Used for debug purposes in logs.

width

Used to control the formatting, enforcing the final value to a specific number of characters.

strip

Used when the value is higher than width allows it, specifying the strip strategy. Possible values are:

*right

Strip the suffix.

*xright

Strip the suffix, postpending one x character to mark the stripping.

*left

Strip the prefix.

*xleft

Strip the prefix, prepending one x character to mark the stripping.

padding

Used to control the formatting. Applied when the data is smaller than the width. Possible values are:

*right

Suffix with spaces.

*left

Prefix with spaces.

*zeroleft

Prefix with 0 chars.

mask_destinationd_id

The destinations profile where we match the masked_destinations.

hander_id

The identifier of the handler to be executed in case of *handler type.