Knowledge Modules (KMs) are code
templates. Each KM is dedicated to an individual task in the overall data
integration process. The code in the KMs appears in nearly the form that it
will be executed except that it includes Oracle Data Integrator (ODI)
substitution methods enabling it to be used generically by many different
integration jobs. The code that is generated and executed is derived from the
declarative rules and metadata defined in the ODI Designer module.
- A KM will be reused across several interfaces or models. To modify the behavior of hundreds of jobs using hand-coded scripts and procedures, developers would need to modify each script or procedure. In contrast, the benefit of Knowledge Modules is that you make a change once and it is instantly propagated to hundreds of transformations. KMs are based on logical tasks that will be performed. They don't contain references to physical objects (datastores, columns, physical paths, etc.)
- KMs can be analyzed for impact analysis.
- KMs can't be executed standalone. They require metadata from interfaces, datastores and models.
KMs fall into 6 different categories
as summarized in the table below:
Knowledge
Module
|
Description
|
Usage
|
Reverse-engineering
KM
|
Retrieves metadata to the Oracle
Data Integrator work repository
|
Used in models to perform a
customized reverse-engineering
|
Check
KM
|
Checks consistency of data against
constraints
|
|
Loading
KM
|
Loads heterogeneous data to a
staging area
|
Used in interfaces with
heterogeneous sources
|
Integration
KM
|
Integrates data from the staging
area to a target
|
Used in interfaces
|
Journalizing
KM
|
Creates the Change Data Capture
framework objects in the source staging area
|
Used in models, sub models and
datastores to create, start and stop journals and to register subscribers.
|
Service
KM
|
Generates data manipulation web
services
|
Used in models and datastores
|
No comments:
Post a Comment