72 Migrating Accounts with the Pipeline Manager Running

This chapter explains:

• How BRM migrates accounts when Pipeline Manager is running.

• How to configure your Oracle Communications Billing and Revenue Management (BRM) system to migrate accounts when Pipeline Manager is running.

Before you read this chapter, you should be familiar with account migration and its configuration in BRM.

About Migrating Accounts When Pipeline Manager Is Online

By default, AMM does not support migration when your pipelines are running. You specify whether AMM can migrate accounts while the Pipeline Manager is online by using the controller_N_event_generation parameter in the AMM Infranet.properties file.

BRM migrates accounts while the Pipeline Manager is running whether you use the AMM process (with its pin_amt utility) or the pin_amt_tt utility.

When you migrate accounts while Pipeline Manager is online, your pipelines stop processing any EDRs that apply to accounts undergoing migration. Your pipelines continue processing all other EDRs.

Figure 72-1 shows AMM interaction with the Pipeline Manager.

Figure 72-1 AMM Pipeline EDR Management

Description of "Figure 72-1 AMM Pipeline EDR Management"

To coordinate account migration with your pipelines:

• AMM notifies the pipelines about a job's migration status by sending business events. See "About Notifying the Pipelines about Account Migration".

• The pipelines notify AMM about EDR processing status by sending acknowledgment events. See "About Notifying AMM about EDR Processing".

• The account-router Pipeline Manager suspends, recycles, and routes EDRs. See "About the Account Router Instance of the Pipeline Manager".

Do Not Rerate Events during Account Migration

Because the AMM software may suspend some events that you want to rerate, you must not rerate pipeline events during account migration.

How AMM Interacts with Your Pipelines during Account Migration

The following steps outline how AMM interacts with your pipelines when processing account migration jobs:

1. AMM fetches a configurable number of migration jobs. See "About Starting Multiple Jobs Concurrently".

2. AMM notifies the account-router Pipeline Manager to hold EDRs for all accounts in a job.

3. The account-router Pipeline Manager begins holding all EDRs for the specified list of accounts and sends an acknowledgment to AMM. See "About Suspending Call Records".

4. AMM waits a specified amount of time before migrating accounts. See "About Waiting before Migrating Accounts".

5. AMM migrates all accounts in the job.

6. AMM determines whether the job migrated successfully.

   • If migration finished successfully, AMM notifies the account router, source, and destination instances of the Pipeline Manager.

     Note:

     If configured to do so, AMM also notifies any external applications.

   • If migration failed, AMM does not send any notification to your pipelines and job processing stops.

     Note:

     When migration fails, your pipelines continue to suspend all EDRs for the specified accounts. You must fix the problem and remigrate the job before the pipeline can begin reprocessing suspended EDRs.

7. The account router, source, and destination instances of the Pipeline Manager update their account information and send an acknowledgment to AMM.

8. AMM notifies the account router to resume processing EDRs for the specified list of accounts.

9. The account router resumes processing EDRs for the specified accounts and sends an acknowledgment to AMM.

10. AMM calls the PCM_OP_SEARCH_RECYCLE opcode to recycle suspended EDRs through the pipeline. See "About Reprocessing Suspended Call Records".

About Waiting before Migrating Accounts

After the account-router Pipeline Manager begins suspending EDRs, AMM waits a configurable amount of time before migrating a job. This provides time for your pipelines to flush any EDRs targeted for accounts in the migration job.

The default wait time is 120 minutes. You specify how long the AMM Controller waits before migrating accounts by using the Controller_N_hold_period entry in the AMM Infranet.properties file.

About Starting Multiple Jobs Concurrently

You can minimize the amount of time AMM spends in the waiting period by configuring AMM to start multiple migration jobs concurrently. In this configuration, AMM:

1. Fetches a configurable number of jobs.

2. Notifies the account-router Pipeline Manager to hold EDRs for multiple jobs.

3. Starts the timer for each job.

4. Once the waiting period is over, AMM migrates jobs individually.

This increases the number of jobs in the queue that are ready to be migrated.

You specify how many jobs an AMM Controller processes concurrently by using the Controller_N_concurrent_job_number entry in the AMM Infranet.properties file.

About Notifying the Pipelines about Account Migration

AMM notifies your pipelines about account migration by sending a series of business events through the Account Synchronization architecture.

About AMM Business Events

AMM generates the five business events listed in Table 72-1 to notify the account router, source, and destination instances of the Pipeline Manager when account migration occurs:

Table 72-1 AMM Business Events

Event	Recipient	Description
HoldCDRProcessing	Account-Router Pipeline Manager	Notifies the account-router Pipeline Manager to suspend all EDRs for a specified list of accounts.
ResumeCDRProcessing	Account-Router Pipeline Manager	Notifies the account-router Pipeline Manager to resume processing all suspended and new EDRs for the specified list of accounts.
MigrateAcct	Account-Router Pipeline Manager External Applications	Notifies the account-router Pipeline Manager and any external applications to update the account database location for the specified list of accounts.
MigrateSource	Source Pipeline Manager	Notifies the source Pipeline Manager that all accounts in the job migrated successfully.
MigrateDestination	Destination Pipeline Manager	Notifies the destination Pipeline Manager that all accounts in the job migrated successfully. The destination pipeline then reads account information from the database.

About Sending AMM Business Events to the Pipelines

AMM sends business events to the pipelines by using a series of Account Synchronization queues. Each instance of the Pipeline Manager contains its own queue, which is dedicated to receiving business events from BRM and AMM.

Note:

If configured to do so, AMM also sends business events to a queue for external applications.

AMM sends business events to a Pipeline Manager as follows:

1. AMM sends an event to the primary Connection Manager (CM).

2. The primary CM sends the event to the Account Synchronization architecture.

3. The Account Synchronization architecture uses its ifw_sync_queuenames file to publish the business event to the appropriate queue.

4. The Pipeline Manager's DAT_Listener module dequeues the event and then forwards it to the appropriate pipeline data module.

Figure 72-2 Sending AMM Business Events

Description of "Figure 72-2 Sending AMM Business Events"

You configure your system to send AMM business events to your pipelines by:

• Connecting AMM to the primary CM.

• Creating an Oracle database queue for each instance of the Pipeline Manager.

• Configuring Account Synchronization to publish AMM business events to your queues.

• Configuring each instance of the Pipeline Manager to dequeue AMM business events from its associated Account Synchronization queue.

Figure 72-2 shows the AMM business events process described. See "Configuring AMM to Send Business Events to Your Pipelines".

About Notifying AMM about EDR Processing

Your pipelines notify AMM when it begins holding EDRs, reprocessing EDRs, or updating account data by sending acknowledgment events through a dedicated acknowledgment queue.

About Acknowledgment Events

Each instance of the Pipeline Manager generates acknowledgment events when the following actions listed in Table 72-2 occur:

Table 72-2 Pipeline Manager Acknowledgment Events

Pipeline Instance	Sends Acknowledgments When...
Account router Pipeline Manager	It begins suspending EDRs for a specified migration job. It resumes processing EDRs for a specified migration job. It completes an update of account locations in pipeline memory. This occurs after a migration job is successfully completed.
Pipeline Managers connected to the BRM database	It completes an update of account locations in pipeline memory. This occurs when accounts in a job are successfully migrated to its associated database schema. It receives a MigrateSource event from AMM to indicate that accounts were successfully migrated away from its associated database schema.

About Sending Acknowledgments to AMM

Each instance of the Pipeline Manager sends acknowledgment events to AMM by using a dedicated acknowledgment queue as shown in Figure 72-3.

Each Pipeline Manager sends acknowledgments as follows:

1. The DAT_AccountBatch module sends an acknowledgment event to the DAT_Listener module.

2. The DAT_Listener module publishes the event to the acknowledgment queue.

3. The AMM Controller dequeues the event.

Figure 72-3 Sending Pipeline Acknowledgment Events to AMM

Description of "Figure 72-3 Sending Pipeline Acknowledgment Events to AMM"

To configure your pipelines to send acknowledgments to AMM, you must:

• Configure the DAT_Listener module in each instance of the Pipeline Manager to publish acknowledgment events.

• Create a single database queue that is dedicated to acknowledgment events. All instances of the Pipeline Manager use this single queue.

• Configure the AMM Controller to dequeue events from the acknowledgment queue.

For more information, see "Configuring Your Pipelines to Send Acknowledgments to AMM".

About the Account Router Instance of the Pipeline Manager

The account router instance of the Pipeline Manager is used in multischema systems to route EDRs to the correct instance of the Pipeline Manager. For example, EDRs targeted for accounts that reside in database schema 3 are routed to the Pipeline Manager instance associated with schema 3.

When configured for migration, the account-router Pipeline Manager also performs the following tasks:

• Suspends EDRs targeted for accounts that are undergoing migration. See "About Suspending Call Records".

• Recycles previously suspended EDRs. See "About Reprocessing Suspended Call Records".

You configure the account-router Pipeline Manager for migration by creating three separate pipelines:

• A routing pipeline that routes EDRs to the appropriate instance of the Pipeline Manager and suspends any EDRs targeted for accounts undergoing migration. This pipeline must include the FCT_AccountRouter module, set to router mode; the FCT_PreSuspense module; the FCT_Reject module; and the FCT_Suspense module.

• A pre-recycling pipeline that processes previously suspended EDRs, determines whether an EDR is targeted for an account undergoing migration, and then routes the EDR to the appropriate output stream. This pipeline must include the FCT_AccountRouter module, set to recycle mode.

• A resuspending pipeline that automatically suspends all EDRs. This pipeline must include the FCT_PreSuspense module, the ISC_Migration iScript, the FCT_Reject module, and the FCT_Suspense module.

You must also configure the account router data pool to pass migration status information to your pipelines. Figure 72-4 shows the necessary pipelines and account router data pool.

Figure 72-4 Account Router Pipeline Manager

Description of "Figure 72-4 Account Router Pipeline Manager"

For information on how to configure the account-router Pipeline Manager, see "Configuring Your Account-Router Pipeline Manager".

About Suspending Call Records

The account-router Pipeline Manager initially routes and suspends call records in the routing pipeline.

After AMM notifies the account-router Pipeline Manager that a job is being migrated, the routing pipeline performs the following:

1. (Optional) The FCT_CallAssembly module assembles EDRs that were split into multiple records.

   Note:

   Any call assembling must occur in the account router instance of the Pipeline Manager and not in other instances.

2. (Optional) The FCT_DuplicateCheck module checks whether EDRs have been previously rated by the Pipeline Manager.

   Note:

   Any checking for duplicate EDRs must occur in the account router instance of the Pipeline Manager and not in other instances.

3. The FCT_PreSuspense module adds suspense-related data to the EDR.

4. The FCT_AccountRouter module, set to Router mode:

   • Flags the EDR for the target Pipeline Manager.

   • Determines whether an EDR is for an account undergoing migration. If it is, FCT_AccountRouter flags the EDR for suspension.

5. The FCT_Reject module routes EDRs with a specified error status, such as warning or critical, to the suspense output stream.

6. The FCT_Suspense module determines whether an EDR is flagged for suspension. If it is, FCT_Suspense places the EDR in a separate suspense output stream, where it is eventually loaded into the BRM database by the Suspense Event (SE) Loader.

   Note:

   You can use either standard recycling or Suspense Manager with AMM.

About Reprocessing Suspended Call Records

After AMM successfully migrates a job, it calls the PCM_OP_SEARCH_RECYCLE opcode to recycle previously suspended EDRs through the pipeline. Then, the account-router Pipeline Manager recycles suspended EDRs through the pre-recycling pipeline and the resuspending pipeline.

The account-router Pipeline Manager recycles EDRs as follows:

1. In the pre-recycling pipeline, the FCT_AccountRouter module, set to Recycle mode, determines whether an EDR is targeted for an account that is being migrated by a new job.

   • If the account is being migrated by a new job, FCT_AccountRouter flags the EDR for suspension and routes the EDR to a separate suspense output stream, where it is processed by the resuspending pipeline.

   • If the account is not being migrated, FCT_AccountRouter flags the EDR for the appropriate instance of the Pipeline Manager. The EDR is then rated by the target Pipeline Manager.

2. The resuspending pipeline automatically routes EDRs to a separate suspense output stream, which is eventually loaded into the BRM database by Suspense Event (SE) Loader.

   1. The FCT_PreSuspense module adds suspense-related data to the EDR.

   2. The ISC_Migration iScript automatically flags the EDR for suspension.

   3. The FCT_Reject module routes EDRs with a specified error status to the suspense output stream.

   4. The FCT_Suspense module routes the EDR to a suspense output stream, which is eventually loaded into the BRM database by SE Loader.

Configuring Your System to Migrate Accounts When the Pipeline Manager Is Running

You configure your BRM system to migrate accounts when your pipelines are online by:

1. Configuring Your Account-Router Pipeline Manager

2. Configuring BRM to Handle Suspended EDRs

3. Configuring AMM to Send Business Events to Your Pipelines

4. Configuring Your Pipelines to Send Acknowledgments to AMM

Configuring Your Account-Router Pipeline Manager

To configure your account router instance of the Pipeline Manager, perform the following:

• Configuring Your Routing Pipeline

• Configuring Your Pre-recycling Pipeline

• Configuring Your Resuspending Pipeline

• Configuring the Data Pool

Configuring Your Routing Pipeline

You configure your routing pipeline to route and suspend EDRs by using the following pipeline modules:

• FCT_PreSuspense. To make suspense fields queryable in Suspense Management Center, set the following FCT_PreSuspense registry entries:

  • Use the Active entry to enable this module.

  • Use the QueryableFields entry to specify the tables and fields that you can perform queries on in Suspense Management Center.

• FCT_AccountRouter set to Router mode. To flag EDRs for suspension and for the appropriate Pipeline Manager, set the following FCT_AccountRouter registry entries:

  • Use the Active entry to enable this module.

  • Use the Mode entry to specify Router mode.

  • Use the Streams entry to map EDRs to the appropriate output stream.

• FCT_Reject. To route EDRs with a specified error status to the suspense output stream:

  • Use the Active entry to enable this module.

  • Set the UseRejectStream entry to True. This sends EDRs to the reject stream.

  • Use the MinErrorSeverity entry to reject EDRs that have the specified error severity.

  • Use the StreamMap entry to map errors to specific output streams.

    Note:

    You must also configure an instance of the Out_Reject module for rejected EDRs. All rejected EDRs must be set to the suspense output stream.

• FCT_Suspense. To send EDRs to the suspense output stream, set the following FCT_Suspense registry entries:

  • Use the Active entry to enable this module.

  • Use the SuspenseCreateStream entry to specify the output stream for suspended EDRs.

  • Use the SuspenseUpdateStream entry to specify the output stream for recycled EDRs.

  • Use the DataConnection entry to specify how to connect to the BRM database.

If you want your pipelines to assemble EDRs or check for duplicate EDRs, you must also use the FCT_CallAssembly and FCT_DuplicateCheck modules in the routing pipeline.

Configuring Your Pre-recycling Pipeline

You configure your pre-recycling pipeline to recycle or suspend EDRs by using the FCT_AccountRouter module set to Recycle mode. Make sure you also set the following FCT_AccountRouter registry entries:

• Use the Active entry to enable this module.

• Use the Mode entry to specify Recycle mode.

• Use the Streams entry to map EDRs to the appropriate output stream.

Configuring Your Resuspending Pipeline

You configure your resuspending pipeline to automatically suspend all EDRs by using the following pipeline modules:

• FCT_PreSuspense. To make suspense fields queryable in Suspense Management Center, set the following FCT_PreSuspense registry entries:

  • Use the Active entry to enable this module.

  • Use the QueryableFields entry to specify the tables and fields that you can perform queries on in Suspense Management Center.

• ISC_Migration. To automatically flag all EDRs for suspension, set the following ISC_Migration registry entries:

  • Use the Active entry to enable this module.

  • Use the Filename entry to specify the path to the ISC_Migration file.

• FCT_Reject. To route EDRs with a specified error status to the suspense output stream:

  • Use the Active entry to enable this module.

  • Set the UseRejectStream entry to True. This sends EDRs to the reject stream.

  • Use the MinErrorSeverity entry to reject EDRs that have the specified error severity.

  • Use the StreamMap entry to map errors to specific output streams.

    Note:

    You must also configure an instance of the Out_Reject module for rejected EDRs. All rejected EDRs must be set to the suspense output stream.

• FCT_Suspense. To send EDRs to the suspense output stream, set the following FCT_Suspense registry entries:

  • Use the Active entry to enable this module.

  • Use the SuspenseCreateStream entry to specify the output stream for suspended EDRs.

  • Use the SuspenseUpdateStream entry to specify the output stream for recycled EDRs.

  • Use the DataConnection entry to specify how to connect to the BRM database.

Configuring the Data Pool

You configure the account-router Pipeline Manager data pool to pass account migration data to your pipelines by using the following pipeline data modules:

• DAT_AccountBatch stores AMM business events. In addition to setting the standard connection registry entries:

  • Set the UseAsRouter entry to True. This is required.

  • (Optional) Use the PrintAMTData entry to specify whether to print AMM data to a log file. You can use this data for troubleshooting.

  • (Optional) Use the PrintAMTJobData entry to specify whether to print data about one migration job to a log file. You can use this data for troubleshooting.

• DAT_BalanceBatch. To provide accurate account balances during migration, set the following DAT_BalanceBatch registry entries:

  • Use the IntegrateConnection entry to specify how to connect to the pipeline database. This entry points to the Login registry section.

  • Use the InfranetConnection entry to specify how to connect to the BRM database. This entry points to the LoginInfranet registry section.

  • Use the ListenerDataModule entry to specify how to connect to the DAT_Listener module. This entry points to the Listener registry section.

• DAT_Listener. To retrieve business events from BRM and send acknowledgment events directly to the acknowledgment queue, set the following DAT_Listener registry entries:

  • Use the InfranetConnection entry to specify how to connect to the database schema that contains your queues. This entry points to the LoginInfranet registry section.

  • Use the AckQueueNameAMM entry to specify the name of the acknowledgment queue.

  • Use the QueueName entry to specify the name of the Account Synchronization queue that stores the AMM business events.

Configuring BRM to Handle Suspended EDRs

BRM offers both the default standard recycling feature and the optional Suspense Manager feature to recycle EDRs.

AMM works with both standard recycling and Suspense Manager.

Both standard recycling and Suspense Manager enable you to do the following:

• Load suspended EDRs into the BRM database.

• View, edit, write off, or recycle suspended EDRs.

• Retrieve suspended EDRs from the BRM database.

You must configure your pipeline before you can migrate accounts with the pipeline running. If you have purchased Suspense Manager, see the Suspense Manager documentation for further configuration instructions.

Configuring AMM to Send Business Events to Your Pipelines

To configure AMM to send business events to your pipelines, perform the following:

1. Connecting AMM to the Primary CM

2. Configuring Account Synchronization

3. Configuring Your Pipelines to Dequeue AMM Business Events

Connecting AMM to the Primary CM

You connect AMM to the primary Connection Manager (CM) so that AMM can send business events to the Account Synchronization architecture, where they are eventually routed to your pipelines.

You connect AMM to the primary CM by using the infranet.connection and infranet.login.type parameters in the AMM Infranet.properties file.

Configuring Account Synchronization

You configure the Account Synchronization architecture to send AMM business events to the appropriate instance of the Pipeline Manager by performing the following:

1. Configuring Account Synchronization to send BRM events to your pipelines.

2. Creating queues for sending AMM business events to your pipelines. You must create a queue for each Pipeline Manager instance in your system. See "Configuring Your Account Synchronization Queues for AMM Business Events".

3. Mapping the AMM business events to your Oracle database queues. See "Mapping AMM business events to your queues".

Configuring Your Account Synchronization Queues for AMM Business Events

The Account Synchronization framework uses a set of Oracle database queues to send both BRM events and AMM business events to your pipelines.

Each instance of the Pipeline Manager must have its own database queue. For example, if your system contains three BRM database schemas, Account Synchronization requires a total of four queues. That is, one for each of the following instances:

• Account-router Pipeline Manager

• Pipeline Manager for BRM database schema 1

• Pipeline Manager for BRM database schema 2

• Pipeline Manager for BRM database schema 3

  Note:

  You must also create a separate queue for any external applications that require notifications about account migration.

If your system does not already contain a queue for each instance of the Pipeline Manager, you can create additional queues by using the Account Synchronization pin_ifw_sync_oracle utility.

Mapping AMM business events to your queues

You map which types of events Account Synchronization sends to your queues by using the ifw_sync_queuenames file (BRM_home/sys/dm_ifw_sync/ifw_sync_queuenames). This file lists all queues in your system and the events to route to each one.

You configure the ifw_sync_queuenames file to map AMM business events, in addition to your BRM events, to each of your queues by using the following syntax:

QueueName@DatabaseLink
{
    Criteria
} 

Where:

• QueueName specifies the name of the queue.

• DatabaseLink specifies the database link for connecting to queues on other database schemas. Provide a link only for queues that reside on a separate schema from which the Account Synchronization DM connects.

• Criteria specifies which events to send to the queue. You can configure the Account Synchronization DM to send all business events, only events from a specific database schema, or only specific event types.

For example, assume your BRM system contains three database schemas and four queues as shown in Figure 72-5:

Figure 72-5 Sample Pipeline Account Synchronization Architecture

Description of "Figure 72-5 Sample Pipeline Account Synchronization Architecture"

In this system, you must configure the ifw_sync_queuenames file so that the Account Synchronization architecture does the following:

• Sends HoldCDRProcessing, ResumeCDRProcessing, and MigrateAcct events to the queue for the account-router Pipeline Manager

• Sends MigrateSource and MigrateDestination events to each queue connected to a BRM database schema

For more information about AMM business events, see "About Notifying the Pipelines about Account Migration".

In this example, the ifw_sync_queuenames file requires the following additional entries:

ROUTER_Q
{
    HoldCDRProcessing
    ResumeCDRProcessing
    MigrateAcct
}
  
Q_1 # local database schema queue
{    
    MigrateSource
    MigrateDestination
}
Q_2@database_link_1 # remote database schema
{
    MigrateSource
    MigrateDestination
}
Q_3@database_link_2 # remote database schema
{
    MigrateSource
    MigrateDestination
} 

Configuring Your Pipelines to Dequeue AMM Business Events

You must configure each instance of the Pipeline Manager to retrieve AMM business events from the Account Synchronization queue. To do this, connect the DAT_Listener modules to your Account Synchronization queues by setting the following registry entries:

• Use the InfranetConnection entry to specify how to connect to the database schema that contains the Account Synchronization queue. This entry points to the LoginInfranet registry section.

• Use the QueueName entry to specify the name of the Account Synchronization queue that holds the AMM business events.

Configuring Your Pipelines to Send Acknowledgments to AMM

You configure your pipelines to send acknowledgment events to a centralized queue, where they are retrieved by the AMM Controller, by performing the following:

1. Creating the Acknowledgment Queue

2. Connecting AMM Directly to Your Acknowledgment Queue

3. Configuring Your Pipelines to Send Acknowledgment Events

Creating the Acknowledgment Queue

You create a centralized acknowledgment queue for sending events from your pipelines to the AMM Controller.

You create the acknowledgment queue by using the pin_ifw_sync_oracle utility. Enter the following commands at a UNIX prompt:

% su - pin
% cd BRM_home/apps/pin_ifw_sync
% pin_ifw_sync_oracle.pl create [-l /@DatabaseAlias] [-q queue_name -t queue_table]

The utility creates a database queue named IFW_SYNC_QUEUE and a queue table named IFW_SYNC on the specified schema. To use nondefault names, use the -q and -t options to specify names for the queue and queue table.

Note:

In multischema systems, all queues and queue tables must use unique names. You must also make sure the acknowledgment queue is accessible by the pin user.

Connecting AMM Directly to Your Acknowledgment Queue

You connect the AMM Controller to the acknowledgment queue so that it can retrieve acknowledgment events.

You connect the AMM Controller to the acknowledgment queue by using the controller_N_amt_queue_name and controller_N_amt_queue_owner_name entries in the AMM Infranet.properties file.

Configuring Your Pipelines to Send Acknowledgment Events

You configure your pipelines to send acknowledgment events to AMM by configuring the DAT_Listener module in each Pipeline Manager.

Configure the DAT_Listener registry entries in each instance of the Pipeline Manager to specify the following:

• Use the InfranetConnection entry to specify how to connect to the database schema that contains your acknowledgment queue.

• Use the AckQueueNameAMM entry to specify the name of the acknowledgment queue. This is the queue you created in "Creating the Acknowledgment Queue".