8 Migrating Pipeline Manager Data between Test and Production Systems

This chapter explains the Pipeline Manager data migration features of Oracle Communications Billing and Revenue Management (BRM) Pricing Center. It provides conceptual information about Pipeline Manager data migration and operational information about implementing data migration features in your business. For step-by-step instructions about using the data migration features in Pricing Center, see Pricing Center Help.

Before reading this chapter, you should be familiar with pipeline rating concepts and using Pricing Center to create pipeline rating data. See "About Pipeline Rating". You should also be familiar with your business's internal policies for creating, testing, and deploying pipeline rating data.

Note:

This document covers data migration for pipeline pricing data only. Real-time pricing data is exported and imported using different procedures. See "About Price Lists" in BRM Concepts.

About Pipeline Manager Data Migration

You use the Pipeline Manager data migration feature to create, test, and modify pipeline rating data in a development environment, then deploy it to your production environment. This capability provides increased flexibility and security by isolating development and testing activities from production systems.

The data migration features of Pricing Center are optional. You enable them during the Pricing Center installation or by modifying the Pricing Center configuration file. See "Enabling Data Migration in Pricing Center".

This is the basic workflow of the Pipeline Manager data migration process:

Set up identical development and production systems.

To ensure data integrity and testing validity, the pipeline rating data in the development system must be exactly the same as the data in the production system. The two systems diverge as you make changes to the development environment, but they converge again when you export these changes and import them into the production system.

See "Setting Up Development and Production Environments".
Create and modify rate plans and discount models on the development system.

Using standard Pricing Center procedures with some modifications, you create and modify pipeline pricing data such as rate plans, discount models, and price models. You use change sets to organize your work. Change sets are groups of related changes that are managed and exported as a whole. Change sets ensure data integrity by locking objects when necessary.

See "Understanding Change Sets"and "Understanding Locks and Associations".
Test your changes on the development system.

You should test your changes thoroughly to ensure that they work as you expect. The data migration features in Pricing Center guard against major errors such as referring to objects that don't exist, but you must test the business content of your changes to make sure that you achieve the results that you want.

See "Testing Change Sets".
Export change sets from the development system.

After testing, you can export a single change set or a group of change sets to a file. The file contains the information required to recreate the modified objects in the production database. If you export a group of change sets to a single file, you can specify the order in which the change sets are exported.

See "Planning the Export Process".
Import change set files into the production environment.

The import process reads the file created during export from the development system. All changes are validated to ensure data integrity. For example, the import process checks that all objects referred to by objects in the change set exist in the production database. If errors are found, the entire file is rejected and no changes are made.

See "Planning the Import Process".

Understanding Change Sets

Change sets are the basis of the Pipeline Manager data migration features in Pricing Center. Change sets track the changes you make and make it possible to treat those changes as a whole. They also enforce rules about which objects can be added, changed, or deleted. See "Understanding Locks and Associations".

For example, suppose a change in policies at your business makes it necessary to modify several price models. You can make all these modifications as part of single change set that you export from the development system and import into the production system as a whole. Using a change set guarantees that the production system receives exactly the same changes that you made in the development system.

The content of a change set is determined by the changes you make while that change set is active. When data migration is enabled, you must you have an active change set before you make any changes to rating and pricing data. You can have only one active change set at a time and a change set can be active for only one user at a time. Every change you make is part of the active change set.

You can activate, inactivate, and reactivate change sets freely. For example, you can activate one change set to make a change to a screen, then switch to another change set to make a different change. When you exit from Pricing Center, the active change set is automatically inactivated to make it available to other users.

You can create as many change sets as you need. In some cases you may use only a single change set to include all the changes associated with a particular pricing change. In other cases, you may need to set up a number of different change sets for various parts of the project. See "Organizing Work into Change Sets".

You use the Change Set Manager, a screen in the Pricing Center application, to create and manage change sets. See "About the Change Set Manager".

Understanding the Change Set Life Cycle

Change sets follow a life cycle that dictates what you can and can't do. This life cycle is comprised of change set states through which change sets move. By default, the life cycle includes four states. You can add additional states to conform to your business practices.

Important:

Managing the change set life cycle is a sensitive task. It is possible to invalidate testing scenarios and to create discrepancies between the test and production environments if you do not monitor and manage change set states carefully.

Figure 8-1 illustrates the default change set life cycle:

Figure 8-1 Default Change Set Life Cycle

Description of ''Figure 8-1 Default Change Set Life Cycle''

There are four default change set states:

In Progress. When you create a new change set, it is in the In Progress state, the working state for change sets. When an In Progress change set is active, you can make any modifications to the pipeline rating data that you need. From In Progress, you can manually change the state to Ready to Export or to a custom states that you define.
Ready to Export. You change the state to Ready to Export when you confirm that all your data is complete and correct. You should test your data before switching to this state.

In the Ready to Export state, you cannot make any changes to the data in the change set. If you need to make additional changes, you must manually switch back to In Progress.

The normal next step is to export the change set to a file. When you export a change set, its state automatically switches to Exported.
Exported. This state shows that the change set has been exported, but has not yet been imported into the production database. You cannot make any changes to the data in a change set in the Exported state.

You must manually change the state to Closed when the file is imported.

Important:
Changing to Closed state from Exported is a vital step. If you do not close the change set, all locks and associations remain active, potentially blocking the completion of other change sets.

If there is a problem importing the change set, you can manually return the change set to the In Progress state to make necessary changes. This should be a carefully managed task to avoid confusion about which change set file contains the correct data. See "Planning the Export Process".
Closed. This is the end state for change sets. The Closed state indicates that a change set is complete and in production. The change set is no longer available for use and cannot be reactivated. Its locks and associations are released. You can view information about the modifications made in this change set, but can no longer back them out.

For more information, see "Customizing Change Set States".

Understanding Locks and Associations

Locks and associations are used by change sets to ensure data integrity, prevent contradictory changes, and maintain information about what data has changed or been affected.

A lock prevents a data object from being modified or deleted by a change set other than the one that established the lock.
An association indicates that a data object is referred to by a locked object. While an object can have only a single lock, it can have multiple associations. It can also have a lock and associations at the same time. An object with an association cannot be deleted until the association is removed.

When data migration is enabled, locks and associations are automatically implemented by Pricing Center, preventing you from making changes that violate the locking rules. For example, if a change set has locked a price model, you can't modify that price model with any other change set.

Even though locks and associations are enforced automatically, you should understand the rules that are used to enforce them. This knowledge will help you and your colleagues work efficiently and smoothly. For example, if you create a new calendar in a particular change set, locking prevents that calendar from being visible to other change sets until the change set that created the calendar is closed. You need to plan your work accordingly. See "Organizing Work into Change Sets" for more information.

The next section, "Understanding the Pricing Data Model", provides background information about how pipeline rating data is stored in the database. "Locking and Association Rules" provides information about the rules governing locks and associations.

Understanding the Pricing Data Model

When you create a rate plan, a price model, or another element of pipeline rating data, it is stored in a table in the Pipeline Manager database, but for the purposes of clarity, we can think of Pipeline Manager data as independent objects.

These objects have different kinds of relationships with each other. Many objects are reusable. They are elements such as calendars, time models, price models, and zone models that can be referred to by many other objects. For example, a single calendar can be used by many rate plans as shown in Figure 8-2:

Figure 8-2 Calendar A Reuse by Multiple Rate Plans

Description of ''Figure 8-2 Calendar A Reuse by Multiple Rate Plans''

Other objects have a parent-child relationship. One parent object refers to many different occurrences of the same type of child object. For example, a single rate plan can contain an unlimited number of rate plan versions as shown in Figure 8-3:

Figure 8-3 Rate Plan Versions

Description of ''Figure 8-3 Rate Plan Versions''

The same object can have both parent-child relationships and references to reusable objects. For example, a rate plan can refer to its own rate plan versions as well as a calendar that is referred to by other rate plans as shown in Figure 8-4.

Figure 8-4 Parent-Child Relationships and Reusable Objects

Description of ''Figure 8-4 Parent-Child Relationships and Reusable Objects''

Locking and Association Rules

When an object is modified, added, or deleted while a change set is active, that change set has a lock on the object. For example, if you make a change to a rate plan under Change Set 1, that rate plan is locked by Change Set 1 and cannot be modified or deleted by another change set until the lock is released.

These are the three most basic locking rules:

An object can have only one lock. In other words, when an object is locked by one change set, it cannot be locked by another.
An object that is locked by a change set cannot be modified or deleted by another change set.
A newly created object is locked by the change set that created it.

These rules prevent change sets from making contradictory changes.

In addition to these basic locking rules, additional rules govern the objects related to locked objects. These rules work differently depending on whether the object is reusable or part of a parent-child relationship.

Rules for reusable objects

When a change set locks an object that directly refers to a reusable object, the change set creates an association to the reusable object. For example, when you modify a rate plan, the change set creates a lock on the rate plan and an association to the calendar referred to by the rate plan.

Associations are used to keep track of data that is potentially affected by changes made in a change set. They are also used to guard against deletion of objects that might cause data integrity problems.

These are the rules governing locking and associations for reusable objects:

Objects with associations cannot be deleted until all associations have been removed. The deletion of associated objects is prohibited because it would cause data integrity problems; the locked object would have a reference to an object that no longer exists.
Multiple change sets can create associations to the same object. For example, suppose Rate Plan A and Rate B both refer to Calendar Z. Change Set 1 modifies Rate Plan A, thereby creating an association to Calendar Z. Change Set 2 then modifies Rate Plan B, which creates an additional association to Calendar Z.
A change set can create an association to a locked object, except if that object is newly added by another change set. For example, if Change Set 1 has modified Price Model A and therefore locked it, Change Set 2 can still make a change that results in an association to that price model. However, if Change Set 1 has added Price Model B, the new price model is not visible to other change sets. No associations can be created to it by other change sets.
A change set can obtain a lock on an associated object to make modifications. (The object cannot be deleted, however.) For example, suppose Change Set 1 modifies Rate Plan A, which locks the rate plan and creates an association to Calendar Z. Change Set 2 can still lock the calendar for modification. It cannot delete the calendar because that would violate the rule about deleting associated objects.
Associations are created only for objects directly referred to by a particular locked object. When you lock a rate plan, you create an association to the calendar it refers to, but you do not create an association to any objects referred to by the calendar.

Rules for parent-child relationships

There is one main locking rule for parent-child relationships: a child object is locked when its immediate parent object is locked. For example, when you modify a rate plan, the rate plan and all its rate plan versions are locked.

Unlike associations, parent-child locking is recursive. In other words, not only the children of the parent object, but the children's children, are locked. For example, when you lock a rate plan, its versions are locked, which in turn causes the version's rate plan configurations, rate adjustments, and special day links also to be locked.

Because of the recursive nature of parent-child locks, you need to use some special techniques to minimize their impact. For example, to prevent all of a rate plan's children from being locked when you want to modify only a particular version, you can open the rate plan in read-only mode, then open the version you want to edit. Only that version and its children are locked, making it possible for other change sets to change other parts of the rate plan.

Important:

You cannot delete a child object when you open its parent in read-only mode. For example, if you open a rate plan in read-only mode, then try to delete a rate plan version, you see an error dialog box. You must open and lock the parent object to delete a child object.

About the Change Set Manager

You use the Change Set Manager in Pricing Center to create and work with change sets. The Change Set Manager has two main areas:

The navigation panel on the left enables you to open and create change sets. It lists all the available change sets in two sections: Non-Exported and Exported. You also search for closed change sets in the navigation panel.
The Change Set Manager window displays the details of the open change set, including the name, state, description., the data modified by this change set, and the data associated with it. You can also activate a change set in the Change Set Manager window.

To open the Change Set Manager:

Click the Change Set Manager button in the toolbar.

Description of the illustration ''prc_rate_chg_set_icon.gif''

Alternatively, choose View - Change Set Manager.

The Change Set Manager opens. The navigation panel on the left side of the screen shows the available change sets as shown in Figure 8-5.

Figure 8-5 Change Set Manager

Description of ''Figure 8-5 Change Set Manager''

In the Change Set Manager, you can do the following:

Create new change sets
Activate change sets
View change set data
Work with change set states
Back out change sets
Export change sets
Import change sets

Using Pipeline Manager Data Migration Features in Your Business

The Pipeline Manager data migration features in Pricing Center provide a framework that you can use to create and test new pricing data for your business. Because every business is different, you need to develop procedures that meet your needs. This section provides guidance about integrating Pricing Center data migration features into your business.

Important:

The Pricing Center data migration features guard against problems in data integrity, but don't validate content. You must be careful and methodical to ensure that your business content is correct and testable.

Setting Up Development and Production Environments

To ensure accurate testing, your development and production data models must be identical to begin with. Each database must contain exactly the same objects with exactly the same contents.

When you create new pricing data on the development system, the two databases diverge, but due to the data that you have introduced. You can therefore be confident that your testing will reveal only issues introduced by the new data. Later, when all your changes have been exported from your development system to your production system, the data models will again be identical. See "Copying Production Data to the Development System".

You must also enable data migration for the two systems. When you install Pricing Center, you can choose not to enable data migration, to enable only import capability, or to enable the entire feature. You can also enable or disable data migration after Pricing Center has been installed. See "Enabling Data Migration in Pricing Center".

Until you enable data migration, you cannot import or export data to or from either system.

Important:

If you enable data migration for one instance of Pricing Center, you should also enable data migration for all other instances of Pricing Center that have access to the same test and production databases. Instances of Pricing Center without data migration enabled can make changes outside the scope of change sets, thereby causing inconsistencies in the data.

Another configuration step is setting up the change set life cycle that you want to use. The change set life cycle is based on your business process and reflects the stages that a change goes through from development to production. Depending on your business process, you may want to add change set states to the default life cycle. For example, you may want to add states called Testing and Approval. See "Understanding the Change Set Life Cycle" and "Customizing Change Set States".

Planning Your Work

You should plan your pricing data projects offline before using Pricing Center to implement them on the development system. You should know exactly which new pricing objects you need to introduce, which objects need to be changed, and which need to be deleted. You should also make sure to identify all reusable object that will be modified so that you can test all the objects that refer to them.

The exact planning process you use depends on your business needs and the complexity of the data model you are implementing. Whatever process you use, make sure there is a solid connection between your offline process and your work in Pricing Center. Use a consistent naming policy so that you can track a change from its inception in the planning process to its implementation in Pricing Center. For example, if your marketing department initiates a change through a formal change request, you can incorporate information from the change request into the Change Set ID, name, and description in Pricing Center.

Organizing Work into Change Sets

The way you organize change sets on your development system; how many change sets you use for a particular project and how changes are divided among them; can have a large impact on how efficiently you complete your work. Here are two reasons why you need to think carefully about change set organization:

Change sets can be dependent on each other. For example, if you are creating a new reusable object in one change set, other change sets cannot view or reference that object until the first change set is closed. Dependencies can also be based on content. If you make changes to the content of a price model in one change set, for example, any changes you make in other change sets that rely on this new content create a dependency.
Locks created by one change set can prevent other change sets from accessing objects. For example, suppose two people are implementing two separate groups of changes, each in its own change set, and each change set requires the modification of the same price model. When one user modifies the price model, the other user is blocked until the first change set is closed.

You should use the information from the planning process to decide how many change sets to create and what to include in them. From your planning, you should develop a clear picture of the specific changes you need to make.

These are some of the factors to consider when organizing change sets:

The number and complexity of changes. If you need to make only a few, simple changes, you can make them all in single change set. On the other, if you are working on a major overhaul of your pricing data, you should organize your work into multiple change sets.
The types of changes you are making. Reusable objects can be referenced by many different objects, so changes to them can have a broad impact. To prevent one change set's locks from causing problems for other change sets, you can make all your reusable object changes in one change set that you export and import separately before other changes.
How many users are involved. The larger the number of users involved in the implementation of a pricing data project, the more important it is to be very careful about planning and organizing the work. You can use change sets to divide work among users.

Testing Change Sets

Testing is vital to ensure that the pricing data you create is valid. Pricing Center prevents you from making errors that cause data integrity problems such as references to objects that no longer exist. But it is your responsibility to ensure that the content of your pricing data is valid: Pricing Center can ensure that a price model exists, but it can't verify that it contains the correct information for your business.

Pricing Center does provide warnings in situations where your actions might cause problems. For example, when you open a Pricing Center screen for an object that has an association to another change set, you can get information about which change set created the association.

You should test the data as realistically as possible by using the pricing data in your development system to rate CDRs in an environment that closely resembles your production environment.

These are some guidelines for helping you decide what to test:

When you modify a reusable object, test to ensure that the objects that reference it are still valid. For example, if you make a change to a calendar, you should test all the rate plans that refer to that calendar to make sure that the change doesn't cause an unexpected result.
Keep in mind the possible effects of multiple successive change sets modifying the same object. Locking prevents more than one change set from modifying an object at the same time. After a change set is closed and its locks are released, however, another change set can modify previously locked objects.
Coordinate the activities of all users and all change sets to ensure that you are testing exactly what will be exported and imported. For example, another change set can modify a price model to which a rate plan in your change set has an association. Such a change doesn't cause a referential integrity problem; the price model still exists; but may cause unexpected results during rating. Ideally, when you are testing a change set or group of change sets, there is no other development activity that might affect the tests.

You should also make sure to test any real-time pricing data that is associated with your pipeline pricing data. For example, if you have introduced a new rate plan that is used to rate events associated with a new product, you should make sure that your testing includes both real-time and Pipeline Manager components. For information about testing real-time pricing data, see "Testing Your Price List" in BRM Setting Up Pricing and Rating.

Planning the Export Process

When a change set or group of change sets is complete, you export it to a file that can be imported into the target system.

Follow these guidelines for exporting change sets:

Before you export, make sure that you understand any dependencies between change sets.

Some dependencies are determined by locking rules. For example, if a new reusable object is introduced in one change set, that change set must be exported, imported, and closed before another change set can refer to the new object.

Other dependencies are based on content. For example, if you use a change set to modify an existing calendar, you should make sure to export and import that change set before any change sets that rely on the modification.
To ensure that change sets are exported and imported in the proper order, you can include multiple change sets in the same file and specify the sequence in which they are processed.
Export change sets only when you are sure that they are complete and ready to be imported. There is no point in having incomplete export files in your system. They serve no purpose and there is some risk that they might be imported accidentally.

Managing Change Set Files

Change set files contain sensitive data, so you should manage them carefully. Three tasks are particularly vital:

Ensuring file security. Once a file has been exported, it should be tracked carefully to ensure that it is not lost or corrupted. You should make sure there is no confusion about file names, which files are waiting to be imported, and similar matters.
Keeping track of file versions. It's possible to have more than one version of a change set file. For example, if you export a file and then discover a problem with a change set in the file, you may need to make corrections and export the changes again. You should be very careful to keep track of the file versions to ensure that you are importing the correct one.
Keeping track of the file sequence. In some cases, files must be exported and imported in a particular order. For example, if you modify a calendar in one change set, you should export and import that change set before other change sets that rely on the modified calendar.

Depending on the complexity of your data model, a version control system may be useful for managing change set files.

You can specify the default locations to which change set files are exported and from which they are imported. For example, you can choose to export files to a location known to your version control system.

Planning the Import Process

Importing data into your production system is obviously a critical task. The Pricing Center import process checks every change to ensure that it is valid. If there are any errors during importation, the entire file is rejected, no changes are made to the target data, and the file is moved to an error directory.

In addition, you can take these steps to ensure that data is imported successfully:

Import files in the correct order. If there are content dependencies among change set files, make sure to import them in the required order. For example, a change set may include a modification that another change relies on. The locking rules and other safeguards prevent data integrity errors such as references to non-existent objects, but you must keep track of dependencies based on business content.
Ensure that files reflect final data. You should check that you are importing files that contain the final versions of your pricing data. If you accidentally import a file that is incomplete, you have to remove or modify the data manually; importing a file cannot be reversed. Careful planning and file management will prevent these problems.

Coordinating Real-Time Rating Data Migration and Pipeline Data Migration

BRM price plans contain a mixture of real-time and pipeline data. For example, when you define products, you can map some events to real-time rate plans and other events to pipeline rate plans.

Real-time and pipeline pricing data are exported and imported separately using different procedures. This document covers data migration for pipeline pricing data only. See "About Price Lists" in BRM Concepts.

You must manually coordinate the real-time and pipeline migration procedures. For example, if you added new pipeline pricing data associated with rating a new product, you must migrate both the new product (real-time data) and the new pricing data (pipeline data).

Configuring Pipeline Manager Data Migration Features

There are a number of configuration task for Pipeline Manager data migration that you accomplish outside the Pricing Center application, including enabling data migration, copying data to ensure that the development and production systems are identical, and optionally customizing the change set life cycle.

Enabling Data Migration in Pricing Center

The Pipeline Manager data migration features are optional. They are visible only if you enable them. You can enable the ability to import change set files without enabling the full set of data migration features. Import-only data migration is useful for production systems where you want to reduce the risk of accidental data changes.

You normally enable data migration during the Pricing Center installation process. You can also enable data migration after Pricing Center has been installed by making a change to the Pricing Center configuration file.

Important:

To enable data migration after installation:

Exit Pricing Center.
Open the Pricing Center configuration file (custom.properties) in a text editor. This file is located in the \lib subdirectory of the installation directory, normally C:\Program Files\Portal\PricingCenter.
Change the value for the pipeline.datamigration parameter to 2 (for full data migration functionality) or 1 (for import capability only).
Save the file.
Start Pricing Center.

Copying Production Data to the Development System

When you set up your development environment, you start out with an exact duplicate of the production database.

Important:

The test and production databases must be completely identical, including sequence IDs, for data migration to work reliably.

Use the replication tools provided with your database to copy the production database. See your system's documentation for instructions.

Customizing Change Set States

You can customize change set states to define a workflow for your projects. Your need for this customization depends on the complexity of your work. If there are only one or two change sets in progress at any one time and they contain simple changes, it may not be necessary to customize. On the other hand, if you have a team of planners working on multiple change sets in varying states of completion, you should customize the life cycle to reflect your process. See "Understanding the Change Set Life Cycle".

To customize change set states, you modify the state.config file, then load it by using the stateconfigtool utility. The state.config file lists each valid state transition. In other words, it defines all the states that it is valid to move to from any given state. It also lists whether the transition is manual (accomplished by the user in the Change Set State dialog box) or automatic (accomplished by the BRM).

These are the contents of the default state.config file, which defines the standard change set life cycle:

# State Transition for Changeset
# currentState,nextState,Action

inprogress,readytoexport,manual
readytoexport,exported,automatic
readytoexport,inprogress,manual
exported,inprogress,manual
exported,closed,manual

Important:

You can define additional states, but you cannot delete any default states. The custom states you define must come between In Progress and Ready to Export. All customized states must have a manual transition.

For example, the following file defines a new state called Testing. You can switch to Testing from In Progress and can switch from Testing to Ready to Export or back to In Progress. Note that you can't switch from Ready to Export back to Testing.

# State Transition for Changeset
# currentState,nextState,Action

inprogress,readytoexport,manual
inprogress,testing,manual
testing,readytoexport,manual
testing,inprogress,manual
readytoexport,exported,automatic
readytoexport,inprogress,manual
exported,inprogress,manual
exported,closed,manual

You load the change set configuration into the database by using the stateconfigtool utility. When you run this utility, you specify the file name, the database type, the host, the port number, the database instance, a login user name, and a login password.

To customize change set states:

Use a text editor to open the state.config file located in the Pricing Center directory, typically Program Files\Portal Software\Pricing Center.
Add new states, being careful to account for all the transitions necessary.

Important:
Don't make any changes to the default entries in the state.config file. Doing so will cause an error when you load the file.
Save the file under a new name. Saving the file under a different name preserves the original file in case you want to return to the default configuration.
From the Pipeline_Home\tools\StateConfigTool directory, run the stateconfigtool utility to load the file. Pipeline_Home is the directory where you installed Pipeline Manager. Use this syntax:

stateconfigtool -f file_name -d database_type -h host -n port -u user_name -p password -i database_id

For example:

stateconfigtool -f Pipeline_Home/tools/StateConfigTool/state.config -d oracle 
-h sample_host -n 1521 -u sample_user -p sample_pwd -i pindb

Exporting and Importing Change Sets by Using the loadchangesets Utility

Under certain circumstances, importing and exporting change sets by using Pricing Center may be inconvenient or undesirable. For example, you may prefer not to allow Pricing Center access to your production system to prevent unauthorized or accidental changes to your production pricing data.

In these cases, you can use the loadchangesets command-line utility to export change sets from your test environment and import them into your production database.

Note:

Exporting and importing change sets by using the loadchangesets utility changes only the final stages of the entire pipeline pricing data migration process. You still use Pricing Center to create and manage change sets.

The general process for exporting and importing change sets is similar whether you use Pricing Center or loadchangesets. See Exporting change sets and Importing change sets in Pricing Center Help for more information.

The loadchangesets utility has two modes: interactive and non-interactive. They both enable you to import and export change sets, but work somewhat differently. See "Working in Interactive and Non-Interactive Mode".

Unlike Pricing Center, where you can choose which change sets to export, loadchangesets exports all the change sets that are in Ready to Export state. You should therefore be careful to monitor the life cycles of your change sets to ensure that you are exporting all the changes sets you want and none that you don't want. For more information about change set states, see "Understanding the Change Set Life Cycle" and the discussion about working with change set states in Pricing Center Help.

Specifying BRM Servers for the loadchangesets Utility

Before you can use the loadchangesets utility, you must specify the BRM servers to export from and import to. You enter the host names (or IP addresses) and port numbers in a configuration file.

To specify BRM servers for import and export:

Exit Pricing Center if necessary.
Open the Pricing Center configuration file (custom.properties) in a text editor. This file is located in the \lib subdirectory of the installation directory, normally C:\Program Files\Portal\PricingCenter.
To specify the server from which to export pricing data, enter the host name (or IP address) and port number in the pipeline.datamigration.utility.export.environment.host and pipeline.datamigration.utility.export.environment.port entries.

For example, to export from TestPricingServer, port number 11960, enter the following:
```
pipeline.datamigration.utility.export.environment.host=TestPricingServer
pipeline.datamigration.utility.export.environment.port=11960
```
To specify the server to which to import pricing data, enter the host name (or IP address) and port number in the pipeline.datamigration.utility.import.environment.host and pipeline.datamigration.utility.import.environment.port entries.

For example, to import to ProductionPricingServer, port number 56968, enter the following:
```
pipeline.datamigration.utility.import.environment.host=ProductionPricingServer
pipeline.datamigration.utility.import.environment.port=56968
```
Save the file.

Working in Interactive and Non-Interactive Mode

You can use the loadchangesets utility in interactive or non-interactive mode:

In interactive mode, you issue a command for each step in the process of importing or exporting. After you enter interactive mode, the prompt changes to an angle bracket and commands are single words for performing particular actions. You can view a list of the change sets that will be imported and exported
In non-interactive mode, you use commands that batch several related parts of the import or export process. You must enter a full command, including the utility name for each set of actions.

For more information about interactive and non-interactive modes, see "loadchangesets" in BRM Setting Up Pricing and Rating.

Exporting and Importing Change Sets in Interactive Mode

The following procedures describe exporting and importing change sets by using loadchangesets in interactive mode. See "loadchangesets" in BRM Setting Up Pricing and Rating for detailed information about syntax.

To export and import change sets by using loadchangesets in interactive mode:

Make sure the change sets that you want to export are complete and that they, and no others, are in Ready to Export state.
Go the /lib directory in the Pricing Center installation directory.
To switch to interactive mode, enter the following command:
```
loadchangesets -i
```
The prompt changes to ==>.
To load the change set data from the export database into memory, enter the following command:
```
export
```
To write the change set data from memory to a change set file, enter the following command. The file name must include the .exp file name extension.
```
write change_set_file 
```
The change sets are exported to the specified file in the /export/done subdirectory in the Pricing Center installation directory. This directory is created automatically if it doesn't exist when you run the utility.
Move the change set file that you created into the /import subdirectory in the PricingCenter install directory.
To read the change set data from the change set file into memory, enter the following command. The file name must include the .exp extension.
```
read change_set_file
```
(Optional) Enter the following command to view the names of the change sets you loaded into memory:
```
list
```
To load the change set data from memory into the import database, enter the following command:
```
import
```

Exporting and Importing Change Sets in Non-Interactive Mode

The following procedures describe exporting and importing change sets by using loadchangesets in non-interactive mode. See "loadchangesets" in BRM Setting Up Pricing and Rating for detailed information about syntax.

To export change sets by using loadchangesets in non-interactive mode:

Make sure the change sets that you want to export are complete and that they, and no others, are in Ready to Export state.
Go the /lib directory in the Pricing Center installation directory.
Enter the following command, where change_set_file is the name of the file into which you want to export the change sets. The file name must include the .exp file name extension.
```
loadchangesets -fx change_set_file 
```
The change sets are exported to the specified file in the /export/done subdirectory in the Pricing Center installation directory. This directory is created automatically if it doesn't exist when you run the utility.

To import change sets by using loadchangesets in non-interactive mode:

Move the change set file that you want to import into the /import subdirectory in the PricingCenter install directory.
Go the /lib directory in the Pricing Center installation directory.
Enter the following command, where change_set_file is the name of the file that you want to import. The file name must include the .exp file name extension.
```
loadchangesets -fi change_set_file
```