What is a Knowledge Module and Types of Knowledge Modules

Answer:- 



What is a Knowledge Module?



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.

Types of Knowledge Modules:-



 1) Reverse-Engineering Knowledge Modules (RKM)

 2) Check Knowledge Modules (CKM)

 3) Loading Knowledge Modules (LKM)

 4) Integration Knowledge Modules (IKM)

 5) Journalizing Knowledge Modules (JKM)

 6) Service Knowledge Modules (SKM)



  1) Reverse-Engineering Knowledge Modules (RKM):-

  "Retrieves metadata to the Oracle Data Integrator work repository.Used in models to perform a customized reverse-engineering"

  

  The RKM role is to perform customized reverse engineering for a model. The RKM is in charge of connecting to the application or metadata provider then transforming and writing the resulting metadata into Oracle Data Integrator's repository. The metadata is written temporarily into the SNP_REV_xx tables. The RKM then calls the Oracle Data Integrator API to read from these tables and write to Oracle Data Integrator's metadata tables of the work repository in incremental update mode.

  

  2) Check Knowledge Modules (CKM):-

  "Checks consistency of data against constraints.Used in models, sub models and datastores for data integrity audit.Used in mappings for flow control or static control"

  

   The CKM can be used in 2 ways:



To check the consistency of existing data. This can be done on any datastore or within mappings, by setting the STATIC_CONTROL option to "Yes". In the first case, the data checked is the data currently in the datastore. In the second case, data in the target datastore is checked after it is loaded.

To check consistency of the incoming data before loading the records to a target datastore. This is done by using the FLOW_CONTROL option. In this case, the CKM simulates the constraints of the target datastore on the resulting flow prior to writing to the target.

The CKM accepts a set of constraints and the name of the table to check. It creates an "E$" error table which it writes all the rejected records to. The CKM can also remove the erroneous records from the checked result.



 3) Loading Knowledge Modules (LKM):-

 "Loads heterogeneous data to a staging area.Used in mappings with heterogeneous sources"

 An LKM is in charge of loading source data from a remote server to the staging area. It is used by mappings when some of the source datastores are not on the same data server as the staging area. The LKM implements the declarative rules that need to be executed on the source server and retrieves a single result set that it stores in a "C$" table in the staging area



The LKM creates the "C$" temporary table in the staging area. This table will hold records loaded from the source server.



The LKM obtains a set of pre-transformed records from the source server by executing the appropriate transformations on the source. Usually, this is done by a single SQL SELECT query when the source server is an RDBMS. When the source doesn't have SQL capacities (such as flat files or applications), the LKM simply reads the source data with the appropriate method (read file or execute API).



The LKM loads the records into the "C$" table of the staging area.



A mapping may require several LKMs when it uses datastores from different sources. When all source datastores are on the same data server as the staging area, no LKM is required.



4) Integration Knowledge Modules (IKM):-

   "Integrates data from the staging area to a target.Used in mappings"

   

   The IKM is in charge of writing the final, transformed data to the target table. Every mapping uses a single IKM. When the IKM is started, it assumes that all loading phases for the remote servers have already carried out their tasks. This means that all remote source data sets have been loaded by LKMs into "C$" temporary tables in the staging area, or the source datastores are on the same data server as the staging area. Therefore, the IKM simply needs to execute the "Staging and Target" transformations, joins and filters on the "C$" tables, and tables located on the same data server as the staging area. The resulting set is usually processed by the IKM and written into the "I$" temporary table before loading it to the target. These final transformed records can be written in several ways depending on the IKM selected in your mapping. They may be simply appended to the target, or compared for incremental updates or for slowly changing dimensions. 

   

   There are 2 types of IKMs: those that assume that the staging area is on the same server as the target datastore, and those that can be used when it is not

   5) Journalizing Knowledge Modules (JKM):-

"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."

JKMs create the infrastructure for Change Data Capture on a model, a sub model or a datastore. JKMs are not used in mappings, but rather within a model to define how the CDC infrastructure is initialized. This infrastructure is composed of a subscribers table, a table of changes, views on this table and one or more triggers or log capture programs



6) Service Knowledge Modules (SKM):-

"Generates data manipulation web services.Used in models and datastores"  

SKMs are in charge of creating and deploying data manipulation Web Services to your Service Oriented Architecture (SOA) infrastructure. SKMs are set on a Model. They define the different operations to generate for each datastore's web service. Unlike other KMs, SKMs do no generate an executable code but rather the Web Services deployment archive files. SKMs are designed to generate Java code using Oracle Data Integrator's framework for Web Services. The code is then compiled and eventually deployed on the Application Server's containers.