Loading Legacy Data into the BRM Database

Importing Data

You import legacy data into the BRM database one file at a time.

Note:

To specify a database connection, edit the pin_cmt utility Infranet.properties file in BRM_home/apps/cmt. BRM_home is the directory in which the BRM server software is installed.

To import legacy data into the BRM database:

Go to BRM_home/apps/cmt.
Do one of the following:
- To import data that is not stored in a new storable class, run the pin_cmt utility using the following syntax:
```
pin_cmt -import -file XML_input_data_file stage_ID 
```
  For example:
```
pin_cmt -import -file data.xml 100
```
  Note:
  
  If you have a multischema system, make sure the stage IDs are larger than the database schema IDs. For example, if you have a schema with the number 0.0.0.5, use stage IDs larger than 5.
- To import data that is stored in a new storable class, run the pin_cmt utility using the following syntax:
```
pin_cmt -import_custom -file XML_input_data_file stage_ID 
```
  For example:
```
pin_cmt -import_custom -file data.xml 100
```
See "pin_cmt" for more information.

Possible errors:

On all parser errors, Conversion Manager rejects the whole file. Take corrective action based on the errors logged in cmt.pinlog and resubmit the corrected file.
A record is rejected and not imported if its reference object is not found. For example, in case of importing a child account when the parent account is not found, the child record is rejected. The error is noted in the log file.
I/O errors, such as the inability to find or open the specified document. The whole file is rejected and an error is logged.
You run out of database space. Use pin_cmt with the -recover parameter to recover your data. For more information, see "Reloading Data".

Deploying Converted Data

When you deploy the data, the staging accounts are made available for production by updating the database ID number in the object Portal object IDs (POID).

Note:

To specify a database connection, edit the pin_cmt utility Infranet.properties file in BRM_home/apps/cmt.

To deploy your converted data, run pin_cmt using the following syntax:

pin_cmt -deploy DOM stage_ID

where:

DOM is the billing cycle's day of month.
stage_ID is the identity of the staging area.

See "pin_cmt" for more information.

Reloading Data

If pin_cmt runs out of space in your BRM database for data rows, the importing process stops. Data that was not imported can be imported after more space is made available in the database.

Note:

To specify a database connection, edit the pin_cmt utility Infranet.properties file in BRM_home/apps/cmt.

To import data when the utility runs out of database space:

Add space to the database.
Read the log files in BRM_home/apps/cmt to find the following information:
- How many records were processed.
- The batch ID for the import process that did not complete.
Edit the control files:
1. At the beginning of every control file, replace the string LOAD_DATA with CONTINUE_LOAD_DATA.
2. In each table's control file, specify the number of records to skip for that table by using the INTO TABLE clause. For example:
```
INTO TABLE account_t
SKIP 756
```
  where 756 is the number of previously processed records.
Run the pin_cmt utility with the -recovery load parameter:
```
pin_cmt -recovery load batch_ID
 
```
See "pin_cmt" for more information.

Troubleshooting Conversion Manager

When Conversion Manager imports legacy data into the BRM database, it creates a log file (cmt.pinlog) with a list of errors and warnings depending on the reporting level set for message logging. (See "Setting the Reporting Level for Logging Messages" in BRM System Administrator's Guide.)

In addition, the log file lists successfully processed records and failed records.

To find any error messages, read the cmt.pinlog file in the BRM_home/apps/cmt directory.

You can also read the Connection Manager and Data Manager log files.

Common pin_cmt Utility Error Messages

Table 5-1 shows common pin_cmt error messages.

Table 5-1 Common pin_cmt Messages

Error Message	Description
CMD_LINE_ARG_ERR	Error in the pin_cmt utility command line syntax.
MISSING_RESOURCE_ERR	A required configuration entry in the pin_cmt utility Infranet.properties file is missing.
DB_CONNECTION_ERR	The database connection configuration in the pin_cmt utility Infranet.properties file is incorrect. This error occurs when the database is down.
BAD_INFRANET_CONNECTION	One of the following: BRM is not running The CM connection information in the pin_cmt utility Infranet.properties file is incorrect.
FILE_NOT_FOUND_ERR	The input XML file is missing from the location specified in the command line.
PARSING_ERR	The input XML file is either not well-formed or not valid with respect to CMT XSD.
IL_PR_PARENT_NOT_FOUND_ERR	The input XML file includes an incorrect parent (/group/billing) reference.
IL_PR_PAYING_PARENT_NOT_FOUND_ERR	The input XML file includes an incorrect paying parent (/group/billing) reference.
INCORRECT_DEVICE_REF	The input XML file includes an incorrect device reference.
INCORRECT_SUB_OBJ_SERVICE_REF	The input XML file includes an incorrect subscription service reference.
INCORRECT_GSC_PARENT_REF	The input XML file includes an incorrect group sharing charges reference.
INCORRECT_GSD_PARENT_REF	The input XML file includes an incorrect group sharing discounts reference.
INCORRECT_GSP_PARENT_REF	The input XML file includes an incorrect group sharing profiles reference.
PROCESS_IS_RUNNING	The input XML file is either already loaded or currently being loaded by another pin_cmt instance.
SQL_ERROR	Internal pin_cmt error.

Testing the Imported Data

You test the data to verify that the objects have been created correctly and that record pointers are consistent.

Use any of the following tools to validate the data in your BRM database:

The testnap utility and Object Browser. See "Using testnap and Object Browser to Validate the Database".
Billing Care. See "Using Billing Care to Validate Data".
SQL. See "Using SQL to Validate Data".

Note:

Before performing the initial test conversion, prepare a test database by using the pin_setup script, and then create a backup of the database. Then load the current price list and create another backup. This saves time because it is easier to reload a database than to create one.

Using testnap and Object Browser to Validate the Database

Use testnap to verify that the following objects have been created correctly in the BRM database. Use Object Browser to look at the contents of each new object in the BRM database.

/account
/bill
/item
/event
/service
/group
/payinfo
/billinfo
/balance_group
/device
/device/num
/device/sim

Note:

Print the results of the your testnap commands and match the objects in the list. This allows you to make any necessary notes.

For information on how to use testnap, see "Using the testnap Utility to Test BRM" in BRM Developer's Reference.

Validating /account Objects

To validate /account objects:

Use testnap or Object Browser to display the data in the object.
Examine each field to ensure the data in the field matches the input data file.
Verify that all the charge offers and services owned by this account are present.
Verify that all of the balances for this account are correct.

Validating /bill, /item, /event, /service, and /payinfo Objects

To validate these objects:

Find the POIDs of these objects in the /account object.
Use testnap or Object Browser to display the data for each of these objects.
Examine each field in the object to ensure that the data contained in the field matches the data in the input data file.
Ensure that these objects reference the correct /account object.

Using Billing Care to Validate Data

To validate data, verify the following:

You can retrieve account data without any errors.
You can update an account without any errors.
You can change payment methods successfully. For example, change an account payment method from credit card to invoice and back to credit card (use the answer_s and answer_b daemons, if necessary).
If parent-child billing data was converted, verify that the parent-child grouping works correctly. To check this, do the following:
- Change some of the existing child accounts to orphan accounts, and some of the existing orphan accounts to child accounts.
- Add a few arbitrary hierarchies.
- Move accounts to and from the parent accounts and verify that there are no errors.

Using SQL to Validate Data

You can use SQL to check the various record counts in BRM.

Note:

BRM contains the root account, which increases the number of accounts by 1. Remember to consider this at the time of validation.

Verify the following:

The total number of accounts created is equal to the total number of accounts converted from your legacy system. Use the following SQL statement:
```
select count(*) from ACCOUNT_T
```
The total number of account name and address records is equal to the total number of accounts converted from your legacy system. Use the following SQL statement:
```
select count(*) from ACCOUNT_NAMEINFO_T
```
Note:

If your implementation has more than one name and address type, you need to take this into account.
The total number of bill objects is equal to the total number of accounts converted from your legacy system. This number must equal the number of records in the ACCOUNT_T table. Use the following SQL statement:
```
select count(*) from BILL_T
```
The total number of payment objects is equal to the total number of accounts converted from your legacy system. This number should equal the number of records in the ACCOUNT_T table. Use the following SQL statement:
```
select count(*) from PAYINFO_T
```
Also verify that the total records in the PAYINFO_INV_T, PAYINFO_CC_T, and PAYINFO_DD_T tables match the number of records in the ACCOUNT_T table. Use these SQL statements:
```
select count(*) from PAYINFO_INV_T
select count(*) from PAYINFO_CC_T
```
The total number of /profile objects (if created) is equal to the total number of accounts converted from your legacy system: this number should equal the number of records in the ACCOUNT_T table. Use the following SQL statement:
```
select count(*) from PROFILE_custom_table_T 
```
where custom_table is the implementation-unique identifier you choose; for example, company name.
The total number of child accounts whose bill units are nonpaying matches the number of rows in the GROUP_BILLING_MEMBERS_T table. Use the following SQL statement:
```
select count(*) from GROUP_BILLING_MEMBERS_T where 
object_type = '/account'
```
The total number of parent accounts match the number of rows in the GROUP_T table. Use the following SQL statement:
```
select count(*) from GROUP_T where poid_type= '/group/billing'
```
The total number of parent accounts match the number of rows in the GROUP_PERMITTEDS_T table. Use the following SQL statement:
```
select count(*) from GROUP_PERMITTEDS_T where type = '/account'
```