This post is all about explaining how the internal Id in ODI plays and acts and what is the best practice and what actually happens when most of the error occurs.
Internal Id is an important element in ODI when its comes to Import Export of Object and so a good understanding of it can help us save time and above all errors related to Export Import . Internal ID apart being an incrementing code also have relationship to Work and Master Repository.
If you are keen on knowing how the internal Id objects have relation to Work (WR)and Master Repository. Here is the key , when you define your 2 or 3 digit number as the Internal ID to Repository, this number(WR Internal ID ) acts like a base in all the object.
Lets say my internal id for Work Repository is 200 .
My project will have the Internal Id – 1200
My Folder will have Internal Id of -2200
Interface1 – 2200
Interface2- 3200
Interface3- 1200
Variable1- 2200.
If you have notice all the different objects have suffix 200( WR Internal ID) to their incrementing number.
Note : ODI can have same internal Id for different objects but never for the same object , since while storing into the SNP work repository tables it increments accordingly by 1000 or other number as defined in its code.
Similarly its go for the Master Repository.
Lets say my Master Repository internal id 50 .
Data Server 1- 2050
Data Server 2 – 3050
Physical Schema1 – 1050
Physical Schema2 – 2050
Agent1-1050
[Please note some of the Default Data server created while Initial ODI installation( Ex - XML_GEO_DIM , File Generic etc ) will have different Internal ID not matching to your Master Repository IDs. ]
We hope till now , you would have got an good understanding of ODI objects , Repository Internal ID and their relationship .
Now let us cover the importance and the simple reason why Repositories needs to have different Internal ID and which is the highly suggested and the best practise to do with few simple scenarios.
Scenario 1. Two DWR having the same internal ID.
Let us call them DWR1 and DWR2. They both have the same Internal Id of 200 connected to different Master Repository.
Let say the development is being carried on both the repository or even the Development and Testing environment are both DWR .
Let say we have reveresed engineered datastore
Source Data Store – ABC (121200)
Target Data Store – TRG (321200)
and created the interface
Interface – XMT_Interface (143200)
The interface is ready and some body in the DWR2 needs the same Interface for their development build, but unfortunately some one have already reverse engineered the same in the DWR and their internal id as follows .
Source Data Store – ABC (122200)
Target Data Store – TRG (322200)
When the Developer brings in the Interface XMT_Interface thinking that already the Data store exists in the DWR2 , it will fail because of improper links , since Interface will look for Datastore ABC (121200) and TRG (321200) and KM and when they are different it error out.
To solve this either the developer have to bring in Duplicate mode and also change the Source Data stores. In short he pretty much needs to rebuild the whole interface again.
The other sub scenario can be Interface with the same ID can exists with different name and code. Again the Developer need to import in duplicate and assign the required datastore , in short rework .
Scenario 2. Two DWR having different internal ID.
Let me call them DWR1 and DWR2. They both have the different internal id of 200 and 201 respectively.
Now let say the developer is moving the Interface from the DWR1 to DWR 2. Well even now the interface will fail , not becuase of Interface id but becuase of the datastore can be different in the DWR2.
To solve this we need to import the data store too but that’s like having two different data stores for single purpose.
Well here the steps to handle in such a scenarios.
Step1. Sync Global Variable and other Global ODI objects , Model and Datastore when imported in One DWR to another DWR immediately or at the End of the Day.
Step2. Import the Codes in this order Project, KM, Local Variable, Procedure ,Interface and Packages for sync [ if required ]
Well with these above conditions in place, the Developer can easily migrate the code since
Source Data Store – ABC (121200)
Target Data Store – TRG (321200)
Will be present and also being a different internal id we can use Insert_Update and import the codes.
Above all, what ever is the case, have different internal Id for Work Repository.
Scenario -3 Importing from DWR to EWR having the same internal ID. (100)
Lets take an Example where a Developer in the EWR makes a duplicate of the present scenario ( 12100) and ODI starts to define a new Internal ID but here comes the issue , that
scenario internal id can be already present or in future when trying to import makes an Error ,since we have created a duplicate interface with that ID.
Scenario -4 Importing from DWR to EWR having the different internal ID. (200 and 201 )
If in case the EWR would have had a different internal id DWR (200) and EWR (201) , so when the Developer make a duplicate the new id will be with some thing like this (12201) and so its does not updates or modify or error out because of an existing object or even when importing scenarios in the future ,since the base ODI have scenarios with numbers ending in 200 .
Similarly the Internal ID can impact for different ODI objects in Topology and Security Manager, so use different Internal ID.
I hope this post have given you an understanding and the relationship of Internal Id , its generation method and why the objects gets error out.
Moral of the Post – Create Different internal Id for both Work Repository and Master Repository always .
Look for odiexperts.com for more tips, tricks and best practices.
