This chapter provides an overview of the Oracle Communications Billing and Revenue Management (BRM) standard recycling features.
For information on the other BRM recycling features, see "About the EDR Recycling Features".
Before using standard recycling, you should be familiar with Pipeline Manager. For details, see "About Pipeline Rating".
You use standard recycling to recycle, test recycle, or delete failed event data records (EDRs).
Standard recycling mainly relies on these BRM tools to suspend and recycle EDRs:
The "FCT_Reject" pipeline module
The "FCT_PreSuspense" pipeline module
The "FCT_Suspense" pipeline module
The Suspended Event (SE) Loader application
The "pin_recycle" utility
You use "pin_recycle" to recycle, test recycle, or delete suspended call records. EDRs are often suspended because of a pipeline configuration problem. You then fix the problem, and test recycle a CDR file of suspended call records. If they pass the recycle test, then you recycle all of the CDR files of suspended calls. pin_recycle also has a delete option to remove call records that have been successfully processed, or call records that cannot be rated.
Overview of the standard recycling process:
You start the pipeline with the FCT_PreSuspense, FCT_Suspense, and FCT_Reject modules active.
FCT_PreSuspense appends suspense-related information to all EDRs that come through the pipeline.
As an EDR is processed, a module finds an error in the EDR. The error is appended to the EDR, and a flag is set to indicate that the EDR has an error.
The EDR is sent to the next module. Each module adds errors, if any more are found.
The FCT_Reject module analyzes an EDR's errors to determine whether it has failed. FCT_Reject also routes EDRs to the appropriate output stream to be stored in the database by Suspended Event (SE) Loader. SE Loader stores suspended EDRs in /suspended_usage objects
By default, FCT_Reject fails call records with an error level of Warning or Error. However, you configure the error level or other conditions that causes EDRs to fail. Call records also "fail" if they cannot otherwise be processed by the pipeline. These failures can be intentional or inadvertent. For example:
A call record may arrive with invalid data and fail a Pipeline Manager validity rule.
The call record may fail custom validity checking set up in a custom iScript.
The Pipeline Manager database tables may be set up incorrectly.
During recycling operations, FCT_Suspense routes EDRs from SuspenseCreateOutput to SuspenseUpdateOutput.
You examine the errors and determine how to reconfigure Pipeline Manager to prevent the errors.
Run the pin_recycle utility with the -f filename option to start the recycling process. This sends the rejected EDRs through the pipeline again for another attempt to rate them.
pin_recycle can recycle EDRs in test mode or real mode. Typically, you run the recycling processes in test mode first, to see if the problems causing the EDR errors have been fixed. When there are no longer any errors, you recycle in real mode.
You usually run pin_recycle (as part of a cron job) periodically.
In test mode, this utility creates a report about the processing, but does not make any state changes.
In recycle mode, this utility sends the results to an output file, and attaches a sequence number to the output file.
Note:This utility sends an entire CDR file to the error directory. You can configure the threshold for the number of errors allowed per file. See "Specifying the Maximum Errors Allowed in an Input File".
Run pin_recycle again with the delete option to remove any remaining unratable EDRs.
For details on the pin_recycle utility, see "pin_recycle".
For details on configuring Pipeline Manager to use standard recycling, see "Configuring Standard Recycling".
For details on using standard recycling to recycle, and delete EDRs, see "Using Standard Recycling to Recycle Suspended EDRs".
As suspended EDRs are processed by standard recycling, they are assigned one of the following states:
Suspended. The call record could not be processed by the pipeline and has been stored in the BRM database as a suspended call record.
Recycling. The call record is being sent through the rating pipeline again to be rated
Succeeded. The call record has been successfully recycled and rated.
Written off. The EDR is set to this state automatically just before being deleted to generate revenue assurance data.
Figure 17-1 shows how standard recycling fits into your BRM system.
Call records first enter standard recycling through the preprocessing pipeline. The preprocessing pipeline converts call records (CDRs) to EDRs used by BRM. Calls only go through this pipeline once, so only a few modules are appropriate for it. FCT_DuplicateCheck and FCT_CallAssembling are candidates.
The rating pipeline is a normal rating pipeline. Most of your pipeline function modules are included in this pipeline. It is in this pipeline where you configure call "success" and "failure" policies. If calls "fail" in this pipeline, they are sent to a Suspended Event Loader (SE Loader).
SE Loader converts the failed calls to /suspended_usage objects in the BRM database.
After these objects are stored in the BRM database, you check your Pipeline Manager log files to see what caused the calls to fail. The problem can frequently be fixed by reconfiguring the pipeline.
Suspended calls that you recycle or test recycle are processed by the pre-recycle pipeline before they go through the rating pipeline again. The pre-recycle pipeline converts the suspended call objects back into files that the pipeline can process, and routes the suspended call records back through their original pipeline for recycling.
If you are test recycling calls, the pipeline tries to rate the calls, but does not make any changes to the database.
The next step is to configure standard recycling. For details, see "Configuring Standard Recycling".