1 Introduction
This book includes the following parts:
Application Adapters are covered in a separate guide. See the Application Adapters Guide for Oracle Data Integrator for more information.
This chapter provides an introduction to the terminology used in the Oracle Data Integrator documentation and describes the basic steps of how to use Knowledge Modules in Oracle Data Integrator.
This chapter contains the following sections:
Terminology
This section defines some common terms that are used in this document and throughout the related documents mentioned in the Preface.
Knowledge Module
Knowledge Modules (KMs) are components of Oracle Data Integrator that are used to generate the code to perform specific actions against certain technologies.
Combined with a connectivity layer such as, for example, JDBC, JMS, or JCA, Knowledge Modules allow running defined tasks against a technology, such as connecting to this technology, extracting data from it, transforming the data, checking it, integrating it, etc.
Application Adapter
Oracle Application Adapters for Data Integration provide specific software components for integrating enterprise applications data. Enterprise applications suported by Oracle Data Integrator include Oracle E-Business Suite, Siebel, SAP, etc.
An adapter is a group of Knowledge Modules. In some cases, this group also contains an attached technology definition for Oracle Data Integrator.
Application Adapters are covered in a separate guide. See the Application Adapters Guide for Oracle Data Integrator for more information.
Using This Guide
This guide provides conceptual information and processes for working with knowledge modules and technologies supported in Oracle Data Integrator.
Each chapter explains how to configure a given technology, set up a project and use the technology-specific knowledge modules to perform integration operations.
Some knowledge modules are not technology-specific and require a technology that support an industry standard. These knowledge modules are referred to as Generic knowledge modules. For example the knowledge modules listed in Generic SQL and in JMS are designed to work respectively with any ANSI SQL-92 compliant database and any JMS compliant message provider.
When these generic knowledge module can be used with a technology, the technology chapter will mention it. However, we recommend using technology-specific knowledge modules for better performances and enhanced technology-specific feature coverage.
Before using a knowledge module, it is recommended to review the knowledge module description in Oracle Data Integrator Studio for usage details, limitations and requirements. In addition, although knowledge modules options are pre-configured with default values to work out of the box, it is also recommended to review these options and their description.
The chapters in this guide will provide you with the important usage, options, limitation and requirement information attached to the technologies and knowledge modules.
Accessing Data in the Relational Structure
DML operations on tables in the relational are executed with standard SQL statements.
Modifications made to the relational data are propagated to the directory depending on the selected storage :
-
In the case where the virtual mapping is used, all insert, update, and delete requests are automatically propagated to the original LDAP server in an autocommit mode. No explicit COMMIT or ROLLBACK statements will have any impact on the Oracle Data Integrator driver for LDAP.
-
In the case where the external database is used to store the relational structure, all types of DML statements may be used with the driver. However, it is important to know that no modifications will be propagated to the original LDAP server.
Accessing Data in the Schemas
Data in the schemas is handled using the SQL language.
It is possible to access tables in a schema that is different from the current schema. To access the tables of a different schema, prefix the table name with the schema name, followed by a period character (.). For example:
SELECT col1, schema2.table2.col2, table1.col3 FROM table1, schema2.table2.
This query returns data from table1 in the current schema, and from table2 from schema2.
Note:
Note that the other schema must be located on the same storage space - built-in engine or external database - as than the current schema.