3 Account Migration Restrictions

Learn about the account migration restrictions for using Oracle Communications Billing and Revenue Management (BRM) Account Migration Manager (AMM).

Topics in this document:

Account Activity Prevented during Account Migration

To prevent applications from accessing or modifying accounts that are being migrated, AMM locks the accounts in Oracle. Only one batch of accounts per thread is locked at a time and only while the accounts are being physically migrated.

Note:

When migrating account groups, AMM locks all accounts in the account group before migration begins.

If an application attempts to access a locked account, the Oracle Data Manager (DM) returns a PIN_ERR_INVALID_OBJECT error.

Do Not Rerate Events during Account Migration

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

Do Not Alter Account Group Members

AMM checks account group relationships only when you first create a job, and does not re-verify relationships during the migration process. Therefore, once an account group is included in a migration job, you:

  • Must not add members to the account group

  • Must not modify relationships between account group members

If you need to alter an account group after it is included in a job but before the job completes migration, you must:

  1. Delete the migration job.

  2. Modify the account group.

  3. Re-create the account migration job.

Migration Prevented during Account Activity

AMM does not migrate accounts while they are being accessed or modified by BRM or another application. For best performance, stop all account activity before you migrate accounts.

If you cannot restrict all access to the accounts in your database schemas, AMM can still process account migration jobs. However, AMM does not migrate any batch that contains active accounts. You can check for failed batches and resubmit them for migration once account activity stops.

Unique POIDs Required across All Database Schemas

The AMM software can migrate only accounts that have a unique POID. Starting with Infranet Release 6.2 ServicePack 1, the multischema software automatically creates unique POIDs across all database schemas in your system.

If your database contains accounts created both prior to and after Release 6.2 ServicePack 1 was installed, AMM migrates only those accounts created after 6.2 ServicePack 1 was installed. For information on how to migrate accounts created prior to 6.2 ServicePack 1, contact your Oracle BRM representative.

Note:

If your BRM system uses a custom POID generation scheme, make sure the sequence number generation algorithm creates unique POIDs across all of your database schemas.

Transient Objects Are Not Migrated

While the pin_amt utility migrates account objects, it does not migrate any transient objects.

Some Client Applications May Fail during Account Migration

BRM client applications may generate error messages and fail to commit changes to the database during account migration. For example, if a CSR opens an account in Billing Care just prior to the account being migrated to another database schema, an error might result.

In that case, the CSR must restart Billing Care and access the account again so it retrieves the account's new location.

Note:

If your system contains custom client applications that connect to the BRM database and search accounts based on POID, you must modify your application. See "Modifying Custom Client Applications for AMM".

AMM Does Not Support LDAP Manager

Currently, you cannot use AMM to migrate accounts if your BRM system includes LDAP Manager.

Using BRM Reports after Migration

To use BRM Reports after you migrate accounts, you must use BRM Reports Release 6.2 ServicePack 1 or later. If you use an earlier version of BRM Reports with AMM, your reports will retrieve and process duplicate data from your source and destination database schemas.

For example, if an account object is migrated from schema 0.0.0.1 to schema 0.0.0.2, earlier versions of BRM Reports retrieve the account object from both schemas while BRM Reports 6.2 ServicePack 1 and later retrieve the account object only from schema 0.0.0.2.

For information on how to modify custom reports to work with AMM, see "Modifying Custom BRM Reports for AMM".