Thursday 29 June 2017

FDMEE Universal Data Access: Importing Adapters and Universal Data Access Models – Understanding the secrets of OPATCH

In this blog, I would be talking about Importing adapters and the UDA data models. Now, this step is an interesting one because it kind of gives a sneak peek into how the OPATCH utility works. Now, in one of my previous blogs, I had shown how to apply OPATCH for configuring the Universal data access in FDMEE. The log file of the OPATCH has some very specific entries which is going to be of special interest to us.

Now, although we applied and OPATCH to configure Universal Data Access, we still need to import the adapters in ODI since in layman terms, FDMEE and internally ODI does not register itself for these updates. (As a side, it is also that one piece of code, should not have unintended consequence on any other module)

The first step that we need to do is import the Adapter project into the list of registered projects in the system.

The Designer tab in ODI is as shown in the below snapshot.

 Observe the list of projects that are available by default.
  • AIF File Project represents the file based loads.
  • JDE Project will have the logic for processing loads from JD Edwards based systems.
  • Open Interface Adapter Project deals with the steps and logic of moving data after interface tables have been populated.
  • SAP BW project will have the logic of moving data from SAP based systems.
To import a project, click on the Icon next to projects and choose Import project option.

Now, all the new projects for Universal Data Access, would be under the following path:
<MIDDLEWARE_HOME>/EPMSystem11R1/products/FinancialDataQuality/odi/11.1.2.4.00/workrep

After clicking on Open in the above snapshot, the list of projects show up. This is shown in the next snapshot.

I have chosen the Oracle Adapter Project and the import type is kept as INSERT_UPDATE.
Click on OK to import the Project.
A warning pops up saying I may be about to delete or replace some artifacts. Click on the Yes button to accept this. 

 
A status report, as shown in the next snapshot, opens up to show the list of artifacts that were inserted/updated during the process.  

Verify that the Oracle Adapter Project has now come through in the designer tab.

The next step is to import the Universal Data Adapter Project. In order to import the model, in the Designer tab, go to the Models tab, and click on the Import model as shown in the next snapshot. 


The Universal Data Adapter Model is present at the same path where the Adapter projects are updated. This is shown in the next snapshot.



The above snapshot shows the status after importing the Universal Data Adapter model in ODI.

In one of my previous blogs about patching FDMEE for enabling Universal Data Access (http://exploitsinhyperion.blogspot.in/2017/05/applying-opatch-for-enabling-universal.html) , I had attached a snapshot of the log file. The adapter projects and the models in the log file are as shown in the below entries from the log file. 

OPATCH works by updating the nuts and bolts that make up the internals of Hyperion EPM. If you are a Cloud user and you wonder the logic of monthly updates that happen in Cloud, it is part of the same thing happening on a regular basis. (A cycle/iteration in the language of Agile).

In the next blog, we will be talking about defining the source system and source adapters.

Link to previous blogs:

Installing Oracle Data Integrator for enabling Universal Data Access in FDMEE  - http://exploitsinhyperion.blogspot.in/2017/04/installing-oracle-data-integrator-for.html

Connecting to FDMEE Work Repository using Oracle Data Integrator  - http://exploitsinhyperion.blogspot.in/2017/04/connecting-to-fdmee-work-repository.html

Applying OPATCH for enabling Universal Data Access in FDMEE - http://exploitsinhyperion.blogspot.in/2017/05/applying-opatch-for-enabling-universal.html

Defining the Physical and Logical schema for Oracle data source  - http://exploitsinhyperion.blogspot.in/2017/06/universal-data-access-defining-physical.html 

Universal Data Access – Defining the Physical and Logical schema for Oracle data source

In this blog, we will be talking about defining the Physical and Logical schema for the Oracle data source so that we can access Oracle database tables in FDMEE. For this blog, we will be connecting to a schema called FINRPT on the local machine. Before accessing the schemas and associated tables in FDMEE, we will configure the schemas in ODI.

Configuring the Oracle Physical schema is shown in the following snapshots:




 
The above snapshot shows me connecting to Oracle database successfully.

The next snapshot shows me configuring the physical schema for the Oracle DB.


The next step would be to configure Context in ODI. ODI by default comes with one Context called as “Global”. We just need to right click and duplicate it to create a new context. The concept of context is similar to the concept of namespace from programming.

The following snapshots show me configuring the context for Oracle database. Please note that the name of the Context and the code has to be UDA_ORCL in case of Oracle database.




I click Yes in the above snapshot to confirm my choices.

The following couple of snapshots show me configuring the Logical schema details for my Oracle table.
Observe that the new added context is now visible in the Logical schemas.



In the next blog, I would be talking about how to import the adapters for configuring Universal Data Access.

Link to previous blogs:

Installing Oracle Data Integrator for enabling Universal Data Access in FDMEE  - http://exploitsinhyperion.blogspot.in/2017/04/installing-oracle-data-integrator-for.html

Connecting to FDMEE Work Repository using Oracle Data Integrator  - http://exploitsinhyperion.blogspot.in/2017/04/connecting-to-fdmee-work-repository.html

Applying OPATCH for enabling Universal Data Access in FDMEE - http://exploitsinhyperion.blogspot.in/2017/05/applying-opatch-for-enabling-universal.html