1 person found this helpful
- Since complete ODI repositories get installed, can we use this ODI setup for our custom development for metadata load for Planning/Essbase ?
You would need to refer to the ODI Licensing. ODI with FDMEE is licensed as a limited install specifically for use with FDMEE.
- The internal ids of ODI repositories is 500 & 501 for Master and Work repo respectively. Since FDMEE installation does not ask for repo ids at the time of installation, how can we migrate objects created in one environment to another ? This question is based on the fact that ODI repository ids should be unique.
It does not ask for ID's as it requires them to be 500 and 501 respectively for the master and work reps to be imported into them.
But as you must be knowing, migration of ODI objects is possible when repository ids are unique. But with FDMEE installation, the internal ids will be 500 and 501 across my all environments. This will not allow migration of any custom developed object.
For Migrating the FDMEE Artifacts you would need to use LCM to migrate the components.
1 person found this helpful
Adding to what Jeff has already said, the LCM option should work in most use case scenarios. The only time that I would expect collisions (or even the need to export ODI objects from one FDMEE ODI work repository and into another one) would be if you have developed your own data load interfaces to be used in conjunction with FDMEE.
The only time that I would expect to see this with FDMEE would be if you are using open interface table data loads and you have edited a copy of the open interface data load package in ODI to add your own custom interface to load the FDMEE interface table. That option does require a full use ODI license though rather than the limited use license that you get with FDMEE.
If you have developed your own data load interfaces to load the FDMEE data load interface table (as per the 'Customizing ODI to Load Data from a Custom Source' section of http://docs.oracle.com/cd/E40248_01/epm.1112/erpi_admin_11123200.pdf) then you may need to find a way to migrate the custom interface and model for the source system from one ODI work repository to another. One way to do this would be to renumber the target work repository (see ODI note 424680.1) but this is not without risk and a backup of the work repository should be taken before attempting anything like this as the note mentions.
If you have /*not*/ developed your own custom data load interfaces for FDMEE open interface data loads though then the LCM approach is what should be used as Jeff mentions. You should then be able to regenerate any required ODI scenarios for open interface loads from within the FDMEE UI.
If at all possible, the LCM approach for migrating FDMEE artifacts is the one that should be taken. I would personally advise keeping only the FDMEE scenarios etc in the ODI work repository that is created for FDMEE and creating your own custom ODI data load interfaces in a completely ODI separate work repository unless they are required for FDMEE open interface loads. This approach would avoid the need to do anything drastic like renumber your FDMEE ODI work repository and would allow migrations from test to dev to prod to be done using the EPM default of LCM.
To add a bit of context, we did have some problems in the past with importing the ERPI scenarios into the work repositories that had been manually created for ERPI because some customers had used the same IDs for the work repositories that had been used by development. I think that this is why the work repository IDs have been set so high now and are set automatically when configuring FDMEE to try and avoid these collisions when importing the work repository.
I hope this clarifies this a bit
I've got a correction for this (thanks for pointing it out Francisco ), you are now able to use ODI to load the open interface table of FDMEE using the restricted use license of ERPI / FDMEE.
=> From what I understand, It is not recommended to merge our non-FDMEE ODI work repository with the one included in FDMEE (in order to perform synergies) ?
=> But having the same master repository that manage ODI FDMEE work repo + non FDMEE ODI work repo is ok ?
In the same way, since FDMEE is automatically deploying ODI on PROD environment, how to deploy only the "execution" work repository (secure ODI work repository made for PROD env, where you can only import scenario and cannot import / modify packages)?
At the moment, I don't think that there is a way to only "deploy" the ODI work repository. Due to some problems that were repeatedly seen in the past when customers had to manually configure ODI most of the ODI configuration steps (including creation of the master & work repositories and import of the required scenarios) are now done automatically when configuring or applying patches to FDMEE. The ODI master and work repositories are also created as an integral part of the FDMEE schema now (this was not the case in ERPI).
By far the safest option in my opinion is to try to stick with the self contained FDMEE approach of having separate FDMEE work repository and master repository where this is at all possible (in my opinion). This may mean some manual steps are required when configuring the data servers in the master repository (e.g. JDBC connection strings, users, passwords, server names etc) but that would be minimal in most cases I would think and then LCM can deal with most of the rest (but you do need to manually create source system registrations yourselves in FDMEE).
If you need to import custom packages / interfaces that are used in conjunction with open interface loads with FDMEE then you may need to renumber the ODI work repository after it has been created in order to be able to import these ODI objects (but renumbering is not to be taken lightly). Unless anything like this is required though then I would advise sticking with the LCM approach.
If you think that there is a valid business case from your end though for allowing end users of FDMEE to define work repository IDs and master repository IDs when configuring FDMEE to then enable migration of ODI objects that are not handled by LCM then by all means feel free to request an enhancement request in a service request