Standard recycling is the default recycling mechanism for Pipeline Manager event data records (EDRs). You use it to recycle, test recycle, or delete failed EDRs in your BRM system.

Standard recycling mainly relies on these BRM tools:

• 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 the pin_recycle utility to recycle, test recycle, or delete suspended call records. EDRs are often suspended because of a pipeline configuration problem. You fix the problem and test recycle a CDR file of suspended call records. If they pass the recycle test, you can recycle all of the CDR files of suspended calls. The utility also has a delete option to remove call records that have been successfully processed or cannot be rated. For information, see "pin_recycle" in BRM Pipeline Manager Reference.

The standard recycling workflow consists of the following steps:

1. You start the pipeline with active FCT_PreSuspense, FCT_Suspense, and FCT_Reject modules.

2. FCT_PreSuspense appends suspense-related information to all EDRs that come through the pipeline.

3. As an EDR is processed, a module finds an error in the EDR. The module appends the error to the EDR and sets a flag to indicate that the EDR has an error.

4. The EDR is sent to the next module. Each module adds an error if any more are found.

5. The FCT_Reject module analyzes an EDR's errors to determine whether it has failed. It 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 cause EDRs to fail. Call records also "fail" if the pipeline cannot otherwise process them. 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.

6. During recycling operations, FCT_Suspense routes EDRs from SuspenseCreateOutput to SuspenseUpdateOutput.

7. You examine the errors and determine how to reconfigure Pipeline Manager to prevent the errors.

8. Run the pin_recycle utility with the -f filename option to start the recycling process. The utility 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 it.

     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" in BRM Setting Up Pipeline Rating and Discounting.

9. Run pin_recycle again with the delete option to remove any remaining EDRs. For details on the pin_recycle utility, see "pin_recycle" in BRM Pipeline Manager Reference.

For details about configuring Pipeline Manager to use standard recycling, see "Configuring Standard Recycling".

For details about using standard recycling to recycle and delete EDRs, see "Using Standard Recycling to Recycle Suspended EDRs".

The standard recycling process assigns suspended EDRs to 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 2-1 shows how standard recycling fits into your BRM system.

Figure 2-1 Standard Recycling in BRM

Description of "Figure 2-1 Standard Recycling in BRM"

The BRM and standard recycling processes consist of the following:

1. Call records first enter standard recycling through the preprocessing pipeline.

2. 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, such as FCT_DuplicateCheck and FCT_CallAssemblings.

3. 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).

4. SE Loader converts the failed calls to /suspended_usage objects in the BRM database.

5. You check your Pipeline Manager log files to see what caused the calls to fail.

6. You fix any errors, such as by reconfiguring the pipeline.

7. You run the pin_recycle utility to send the rejected EDRs through the pipeline again for another attempt to rate them.

8. The pre-recycle pipeline recycles or test recycles the suspended calls. 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.