Oracle Data Integrator – Architecture
There are other similar document or web page about this topic. I would like to write my own version with my own observation.
This is from BI Apps development’s perspectives.
I think that the key is that ODI provide a a metadata repository and a pluggable framework.
To best understand ODI, you may start considering what you will do if you are writing a ETL jobs using simple SQL statements.
First, data are in different database and how do you bring the data from different database. Using SQL Loader. OK. Then how can you make the code you wrote reusable? You started to make some part of your script become variables. The starting point may be a script and it is now called KM in the ODI. Each KM is pretty much a script which can take inputs or a script that running under a given environment. That environment has the metadata that can capture inputs.
Each KM is basically a script that can take the inputs.
The clever design of the ODI is that these inputs are not passed from the calling program. Instead, it provides the call back functions, which are called as substitution API. When a KM is being called, the interface is being passed. What happened inside the KM is that the interface can be used to retrieve other information, such as what the connection I should connect to for populating the target table, and what target table I am writing into, etc. The substitution API is pretty much the API can be called by the ODI engine during the compilation time to get the variables replaced based on metadata entered.
I think that this is core of the ODI architecture.