Migration is used to migrate data from one database to another. You can migrate data during installation or during setup.
To migrate data after installation, use the Setup tool described in Reconfiguring After Installation. Briefly:
Launch the Setup tool by issuing the following command from the bin subdirectory of your installation:
See command-line parameters in Setup.
Select the Migration tool on the first panel:
Fill in the following properties:
Previous Registry Version - Oracle Service Registry version from which you are migrating data
Previous Registry Directory - the directory in which the previous Oracle Service Registry is installed. The existing data will be migrated from it.
Previous Registry Administrator Username - name of the user having rights to retrieve data from the previous Registry version.
Current Registry Administrator Username - name of the user having rights to save UDDI structure keys. By default, only the administrator can migrate all data including private data.
JDBC drivers - Set path to the directory in which the .jar (.zip) of JDBC drivers is located.
Enter this path only if the previous Oracle Service Registry installation is configured with a different type of database than the current one.
The following table summarizes what data is migrated by the migration tool in setup.
Table 2. Migration
|Type of data||Data detail||Migrated by migration tool||Location|
|UDDI Data||UDDI v3 (v2) data (business entities and their sub-entities, tModels, subscriptions, publisher assertions, taxonomies).||Yes||Database|
|UDDI security||ACL||Yes (it is a part of UDDI entity)||Database|
|Configuration of Permissions||No||File app/uddi/conf/permission_list.xml|
|Certificate store||No||File conf/pstore.xml, conf/clientconf.xml|
|Accounts||Account (User Profile) and Group data||Yes||Database|
|LDAP configuration||No||File app/uddi/conf/directory.xml|
|Approval configuration||No||File app/uddi/conf/production.xml, app/uddi/conf/staging.xml|
|Temporary UDDI Data||Custody transfer tokens||No||Database|
|Other configuration||Configuration of URLs||No. URLs are already set up in the installation preceding migration in setup. Migrated registries often run in different environments.||Multiple XML files in app/uddi/conf/, work/uddi/bsc.jar/conf/|
|Configuration of BSC, including BSC customizations (accessible in BSC UI: Configuration tab)||No||Files in work/uddi/bsc.jar/conf/|
|Configuration of Registry UI (accessible in Web UI: Manage->Registry control configuration)||No||Files in app/uddi/conf/|
|Configuration of Registry (accessible in Web UI: Manage->Registry configuration)||No||Files in app/uddi/conf/|
|Replication Items||No (manual steps are described below Manual migration of replications from older versions of Oracle Registry)||File in app/uddi/conf/replication.xml, app/uddi/conf/replication_list.xml|
|Configurations which are stored in the database and their history||No||Database|
Replications in this version use a different configuration from previous versions. The main difference is that replications are now transactional. In previous versions it was common to have two replication items, one for business entities (and sub-entities) and another for tModels. In this version the replication item can contain several subscriptions, but they have to be complete, as failure to replicate any entity means failure of the whole replication (failed replication will not leave any incomplete entities). Another difference is that referenced tModels are not fetched automatically, a subscription for them is needed. Time is specified in a more reliable way. Older versions specified a time of replication by an interval measured from the start of the Registry. The new version allows time specification patterns fixed relative to time of day, day of the week, or day of the month. New replications have some new features like color coded reports and an option to preserve owners of replicated entities.
For each group of related replication items in old Registry:
Create a new replication item which will reference all subscriptions from old items.
If the old replication depended on the fact that referenced tModels were replicated, a new subscription for such tModels will be needed. Add a key of this subscription to the replication item.
Convert the old time specification to the new one.
Fill all other fields in the same way they were filled in the older version of Registry.