1. Analytical Application Infrastructure User Guide
  2. Object Administration
  3. Object Migration
  4. Online Object Migration

Online Object Migration

Objects refer to the various definitions defined in the Infrastructure and Financial Services applications. Object Migration framework within the Infrastructure facilitates you to define a set of objects to migrate across Information Domains within the same setup or across different setups.

You can select one or more objects within an object type or within multiple object types and migrate same along with the dependencies of the selected object automatically. For example, if you explicitly select a Group Filter, the migration will automatically happen for the Data Element Filters which are the dependents referenced within that Group Filter.

The following object types are available:
  • Infrastructure UAM Objects such as Alias, Business Processor, Essbase Cube, Datasets, Business Measures, Business Hierarchy, Business Dimension, Data Quality Rule and Data Quality Group.
  • Financial Services Applications infrastructure objects such as Dimension, Hierarchy, Filter, and Expression Rule.
  • You can also migrate objects which are specific to applications such as Asset Liability Management, Funds Transfer Pricing, or Profitability Management, if you have installed those applications.

    Note:

    Apart from this method, you can migrate objects through Command Line Utility to Migrate Objects or Offline Object Migration (UI Based) process based on whether the objects you want to migrate are supported in that approach.
Following are the pre-requisites while working with Object Migration:
  • Both the Source and Target should have the same OFSAA version number.
  • Folders (Segments) that are present in the Source should also be present in the Target.
  • The Source and Target environment should have the same installed locales for migration.
  • Users in Source should be the same in Target. (At least for users associated with objects migrated).
  • Users should have access to Folders in Target similar to the access in Source.
  • Tables accessible to users in Source should also exist in Target.

    For example, if you want to migrate a Data Element Filter based on "Table A" and "Table B" in the Source, those two tables should exist in the Target.

  • The key processing Dimensions should be the same in both the Source and Target environments.
  • For member migration, the dimension type should have the same Attributes in both Source and Target environments.
  • Numeric dimension member IDs should be the same in both the Source and Target environments, to ensure the integrity of any member-based assumptions you want to migrate.

    Note:

    If you have used the Master Table approach for loading dimension data and set it up to generate surrogate keys for members, this results in different IDs between the Source and Target. So it may cause error if you try to migrate objects which depend on these IDs.
  • Migration of Infrastructure UAM Objects happens over a secure Java Socket based communication channel. To facilitate effective communication between the Source and Target systems and also to display the UAM objects from the source, you need to import the SSL certificate of Source in to the Target. For information on importing SSL certificate, see How to Import SSL Certificate for Object Migration (Doc ID 1623116.1)How to Import SSL Certificate for Object Migration (Doc ID 1623116.1).
  • For Object migration across setups, migration process should always be triggered from the target setup. You need to login to the target setup and select the required information domain. Object Migration works more like an IMPORT into the Target. Thus, in case of migrating objects within the same setup across Information Domains, you need to have logged into the Target Information Domain in order to migrate the objects.
  • Before migrating a DQ Group, ensure the DQ Rules present in that DQ Group are unmapped from all other groups in the target. That is, if a DQ Rule is mapped to one or more DQ Groups in the target, then it has to be unmapped from all the groups before migration.
  • The following object types will not be migrated with their parent objects even though they are registered as dependencies:
    • Currencies registered as dependents of Interest Rate Codes (IRCs).
    • Dimension Members registered as dependents.

Ensure that these dependencies exist in the target environment prior to the migration of parent object.

You (AAI System Administrator) need to have FU_MIG_HP function role mapped to access the Object Migration framework within Infrastructure.
This illustration shows the Object Migration Summary window, which displays the list of pre-defined object Definitions with their Migration Code and Dump Name. By clicking the Column header names, you can sort the column names in ascending or descending order. The window has the Search and Filter and Summary pane. In the Search and Filter pane, you can specify the details of the migration and search. In the Summary pane, the search results are displayed, you can also Add, View, Edit, Copy, Delete, and Export the definition.

The Object Migration Summary window displays the list of pre-defined Object Migration rules with the other details such as Name, Folder, Source Infodom, Access Type, Modification Date, Last Execution Date, Modified By, and Status. You can use the Search option to search for a required Object Migration rule based on the Name or Folder in which it exists. The pagination option helps you to view the list of existing Object Migration rules within the system.

In the Object Migration Summary window you can do the following: