This section provides an overview of the CDR Resource Adaptor and concepts related to its management and operation.
About the CDR Resource Adaptor
The CDR resource adaptor provides an interface for SBBs to write Call Detail Records (CDRs) to a series of CDR files. The resource adaptor supports automatic rollover by number of CDRs written, CDR file size, or elapsed time. CDR files can be automatically post-processed by an external program when they are completed.
CDR streams
A single CDR resource adaptor entity can manage multiple CDR streams. A CDR stream is a series of rolled-over CDR files. From the perspective of an SBB, a CDR stream is a named destination for writing CDRs to. A single SBB can write to multiple CDR streams by providing a stream name as one of the parameters when invoking methods of the CDR Resource Adaptor interface.
Defining multiple CDR streams allows separation for groups of related CDRs, such as a CDR stream per user service or type of CDR. This usually simplifies any post-processing of generated CDR files; for example, CDR files that SBBs use consistently can be generated by a single stream, to contain CDRs in the same format.
CDR streams are configured by creating, modifying, and removing profiles in a CdrStreamConfiguration profile table. Each profile represents a CDR stream. The name of the profile in the profile table is used as the CDR stream name. As the CDR resource adaptor supports active reconfiguration, there is no need to deactivate it for reconfiguration.
Reliability/Latency tradeoff
Each CDR stream can be configured to favour write operation reliability or write operation latency from the perspective of the calling SBB. That is, whether the resource adaptor should wait until the CDR is persisted to disk (meaning it is synchronous) or just queue the CDR write internally before returning control to SBB (in which case it is asynchronous).
The default CDR stream configuration favours write reliability over latency for SBBs making synchronous CDR write requests to a given stream. This behaviour can be changed to make the write requests asynchronous.
|
It is important to understand that this tradeoff is not between the probability of write failure or CDR write operation latency. It is only about whether the SBB should wait for the result of writing the file, for example to customise SBB behaviour if a CDR write operation fails. |
|
See also
the description of WriteTimeout and WriteSync stream configuration attributes in
CDR stream profile-based configuration.
|
CDR files
Each CDR stream can be configured to generate CDR files in either binary or text format. When text format is selected, CDRs are persisted to a human-readable text file with configurable character encoding. In turn, selecting binary format results in creation of binary CDR files. The format of CDR records is controlled by the SBB developer, by either providing the CDR as SBB-controlled text or defining a Google Protocol Buffers message descriptor and generating code that is the SBB uses to represent the CDR.
|
|
Examples for both usage scenarios are part of the CDR Resource Adaptor distribution package. |
