Performing MDM Code migration

Are you looking for information about how to perform MDM code migration? If so, then read this article which provides brief information about code migration for the MDM hub, User Exits, Informatica Data Director, etc.

Click here for the code migration document.

1. MDM Initial Migration

• The development team needs to complete all the development activities and to validate the ORS to ensure that there are no errors.
• Below are the steps to export an ORS (with all the development objects) from the source ORS (Dev/QA).

a)      In the source environment, launch the MDM HUB and connect to the Master Database.

b)      Click on the ‘Repository Manager’ under the Configuration Workbench.

c)       Click on the ‘export’ tab and select the repository to export from the dropdown list and click on the export button (Save the icon at the extreme right).

d)      Save the ORS as the MDM<EnvName><Date>.Change.xml file to the disk.

• Below are the steps to Import an ORS to target ORS (QA/Prod) for the initial migration.

a)      In the target environment, launch the MDM HUB and connect to the Master Database.

b)      Click on the ‘Repository Manager’ under the Configuration Workbench.

c)       Click on the ‘Import’ tab and then click the button beside the Source to select the source repository to be migrated and then click on the ‘File Repository’ tab.

d)      Choose the Target repository (which is blank for the initial migration) to which the code needs to be migrated and then click on the ‘Apply Changes’ icon.

e)      MDM prompts the roll back option in case of any issues encountered during the code migration. Select ‘Full rollback’ so that there won’t be any partial code migrated to the Target ORS.

f)      Once the changes are applied, there will be a prompt for an integrity check. Select ‘Yes’ for the prompt.

g)      It will take a while to implement the changes and gives the below prompt. Select ‘Ok’ for prompt.

2. MDM Incremental Migration

• The development team must complete all the development activities for the selected objects, validate the ORS, and make sure there are no errors.
• Refer to the above steps for exporting (backup) the source ORS and the target ORS to the Change.xml file.
• Below are the steps to import an ORS to the target ORS (QA/Prod) for the incremental migration:

a)      In the target environment, launch the MDM HUB and connect to the Master Database.

b)      Click on the ‘Repository Manager’ under the Configuration Workbench.

c)     Click on the ‘Promote’ tab and then click on the ‘Visual’ tab. Next click the button beside ‘Source’ and click on the ‘File Repository’ tab to select the source Change.xml file generated in the step above. 

d)      It will load the change list and validation will be done automatically. It should show the status as ‘Valid’.

e)      Select the Target ORS from the dropdown into which the changes need to be migrated. It will be shown below the progress bar and will take a few minutes to load the ORS objects. Once loaded, the objects with changes from the source to the target are shown as ‘Refresh’ icons and the new objects are shown with a green dot.

f)   Select the changes to be promoted, right click and select Promote. The popup shows up below. Select the option ‘Use Source values as the final results for conflicts’ and click ‘OK’.

g)      Once the changes are listed, click on ‘Run a simulation of changes’ icon  (white play button). This will simulate the changes and throw out any errors/issues. This way the issues can be identified before actually applying the changes.

h)      Below the prompt will be shown. Select ‘Yes’.

i)      Once the simulation is done, click on the ‘Apply Changes’ icon  (Green Play button).

j)      MDM prompts for the roll back option in case of any issues encountered during the code migration. Select ‘Full rollback’ so that there won’t be any partial code migrated to the Target ORS.

i)      Repeat the above steps (from step f) to promote the changes for each component (like Cleanse function, mappings, BOs, etc.)

3. MDM User Exits Migration

                  The customizations required in the MDM HUB are implemented in the MDM user exit java code. Any changes in the jar file in Dev need to be migrated to QA and further environments.  Below are the steps to migrate the user exit in the MDM HUB.

• Connect to the MDM HUB in the target environment. Click on the ‘User Object Registry’ under the ‘Utilities’ Workbench.
• Click on ‘User Exists’. Only one jar file can be uploaded as the MDM user exit.

a)      If the jar is being added for the first time, click on the plus (+) icon and add the jar file. 

b)    If the existing jar file needs to be updated, click on pencil ico , and the popup appears below. Browse the location of the jar file and click on ‘OK’. It will refresh in a few seconds and the latest jar file should upload to the MDM HUB.

4. IDD Code Migration

Follow the steps below to create a new IDD application for doing the initial code migration:

1)      Take the export from the source IDD application as shown in the screenshot below and save the zip file to the disk.

2)      Launch the target system’s IDD url and login with a user with required privileges.

3)      Click on the ‘Add’ button at the top and fill in the required details as below.

4)      Once the application is created, select the application and hover over the import button to see the dropdown of the options. Select the ‘Import complete IDD application (Zip)’ and browse the zip file from the source. 

5)      Bind the ORS and hover over the ‘Application State’ button and select the ‘Full Deployment’ option. It will take a few minutes to deploy the application. Once done, the application status should be valid (green check mark under the status column). 

5. Code Migration Issues

1)      Package Migration Issues:

a)      Custom queries have to be migrated manually by copying the query from the Source to the Target. However, new custom queries can be migrated from the Repository Manager.

b)      If any columns are removed from the non-custom query, those columns have to be removed manually from the Target system by directly going to the query under the package.

2)      BO Migration:

a)      The column in the target system needs to be deleted if any of the following occurs: any columns are removed from the BO, the data type is changed, the length is decreased, or the display name is changed. Follow the steps below in the Target system before deleting the column.

·         Check the impact analysis and identify the dependent objects such as Packages and Child Tables.

·         Remove the field from all the Packages where the particular field is referred.

·         Remove the column from the child table.

·         Once the field is removed from all the dependent objects, then remove the columns from BO.

·         Migrate the column from the Source to the Target system from the Repository Manager.

3)      SAM Migration:

Once the SAM access for an existing role is migrated from the source to the target system, check the SAM access by querying the database. Below is a sample query:

select 'QA' ENV,sysdate CREATE_DATE, B.ROLE_NAME,C.SIPERIAN_OBJECT_UID,A.PRIVILEGE_CREATE_IND CREATE1,

A.PRIVILEGE_READ_IND READ1, A.PRIVILEGE_UPDATE_IND UPDATE1,

A.PRIVILEGE_DELETE_IND DELETE1,A.PRIVILEGE_EXECUTE_IND EXECUTE1

from cmx_ors_dev2.C_REPOS_SAM_ROLE_PRIVS A,cmx_ors_dev2.c_repos_sam_role B,

cmx_ors_dev2.C_REPOS_SAM_RESOURCE C

where A.rowid_sam_role=B.rowid_sam_role

AND A.rowid_sam_resource=C.rowid_sam_resource

4)      Hierarchy Migration:

If a new hierarchy is created on the existing BO, then the BO needs to be truncated to migrate from the source to the target.

5)      Securing the Resources:

If any new code objects are migrated to the Target system, make sure to verify that these objects are secure from the SAM tool in the MDM HUB by applying the filter below.

The screenshot below shows the secure resources and the checking for any Private resources.