There are two types of exports with common configuration but different data sources:
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.
Are exports which are triggered via CGRateS RPC APIs and they have as data source the CDRs stored within StorDB.
CDRe it is configured within cdre section from JSON configuration.
One export profile includes the following parameters:
Specify the type of export which will run. Possible values are:
Exports into a comma separated file format.
Exports into a fixed width file format.
Will post the CDR to a HTTP server. The export content will be a HTTP form encoded representation of the internal CDR object.
Will post the CDR to a HTTP server. The export content will be a JSON serialized representation of the internal CDR object.
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.
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.
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.
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.
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.
SQS URL with extra parameters.
S3 URL with extra parameters.
Kafka URL with extra parameters.
List of filters to pass for the export profile to execute. For the dynamic content (prefixed with ~) following special variables are available:
The CDR event itself.
The EventCost object with subpaths for all of it’s nested objects.
Tenant owning the template. It will be used mostly to match inside FilterS.
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.
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 to be used in some export types (ie. *file_csv).
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 for the exported content. Possible prefixes here are:
Reference to the exported record.
Reference to the header content. Available in case of *file_csv and *file_fwv export types.
Reference to the trailer content. Available in case of *file_csv and *file_fwv export types.
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:
Writes out the variable value, overwriting previous one set.
Writes out the variable value, postpending to previous value set
Fills the values with a fixed lentgh string.
Writes out a constant
Parses the value as datetime and reformats based on the layout attribute.
Writes out a combined mediation considering events with the same CGRID.
Masks the destination using * as suffix. Matches the destination field against the list defined via mask_destinationd_id field.
Uses a HTTP server as datasource for the value exported.
For *hdr and *trl, following field types are possible:
Fills the values with a string.
Writes out a constant
Will obtain the content via a handler. This works in tandem with the attribute handler_id.
The exported value. Works in tandem with type attribute. Possible prefixes for dynamic values:
Data is taken from the current request coming from the CDRs component.
Makes sure that the field cannot have empty value (errors otherwise).
Used for debug purposes in logs.
Used to control the formatting, enforcing the final value to a specific number of characters.
Used when the value is higher than width allows it, specifying the strip strategy. Possible values are:
Strip the suffix.
Strip the suffix, postpending one x character to mark the stripping.
Strip the prefix.
Strip the prefix, prepending one x character to mark the stripping.
Used to control the formatting. Applied when the data is smaller than the width. Possible values are:
Suffix with spaces.
Prefix with spaces.
Prefix with 0 chars.
The destinations profile where we match the masked_destinations.
The identifier of the handler to be executed in case of *handler type.