Oracle Data Integrator Enterprise Edition is built on several components all working together around a centralized metadata repository. These components - graphical modules, runtime components, and a Web interface - in conjunction with other advanced features, make ODI-EE a lightweight, legacy-free, state-of-the-art integration platform. Read this technical brief to learn more about the Oracle Data Integrator Enterprise Edition architecture in detail.
The following is intended to outline our general product direction. It is intended for information purposes only, and may not be incorporated into any contract. It is not a commitment to deliver any material, code, or functionality, and should not be relied upon in making purchasing decisions. The development, release, and timing of any features or functionality described for Oracle's products remains at the sole discretion of Oracle. The ODI-EE architecture is organized around a modular repository, which is accessed in client-server mode by components-graphical modules and execution agents-that are written entirely in Java. The architecture also includes a Web application, Metadata Navigator, which enables users to access information through a Web interface.
The four graphical modules are Designer, Operator, Topology Manager, and Security Manager. These modules can be installed on any graphical platform that supports Java Virtual Machine 1.5 (J2SE), including Windows, Linux, HP-UX, Solaris, AIX, and Mac OS, among others.
2 The graphical modules are as follows: ? Designer defines declarative rules for data transformation and data integrity. All project development takes place in this module; this is where database and application metadata are imported and defined. The Designer module uses metadata and rules to generate scenarios for production. This is the core module for developers and metadata administrators. ? Operator manages and monitors production. It is designed for production operators and shows execution logs with error counts, the number of rows processed, execution statistics, the actual code that is executed, and so on. At design time, developers can also use the Operator module for debugging purposes. ? Topology Manager defines the physical and logical architecture of the infrastructure. The administrators of the infrastructure or project register servers, schemas, and agents in the master repository through this module. ? Security Manager manages user profiles and their access privileges. Security Manager can also assign access privileges to objects and features. Security administrators generally use this module. All modules store their information in the centralized repository.
At runtime, the Scheduler Agent coordinates the execution of the scenarios. The Scheduler Agent can be installed on any platform that supports a Java Virtual Machine (J2SE), including Windows, Linux, HP-UX, Solaris, and IBM AIX, iSeries/AS400, zSeries/OS/390. Execution can be launched from one of the graphical modules, or the built-in scheduler or a thirdparty scheduler can trigger it.
With the Extract-Load Transform (E-LT) architecture, the Scheduler Agent rarely performs any transformation. It simply retrieves code from the execution repository and then requests database
3 servers, operating systems, or scripting engines to execute that code. When the execution is completed, the Scheduler Agent updates the execution logs in the repository and then reports error messages and execution statistics. Users can view the execution logs from the Operator module or the Metadata Navigator Web interface.
It is important to understand that although the Scheduler Agent can act as a transformation engine, it is rarely used for that purpose. Agents are installed at tactical locations in the information system to coordinate the integration processes and leverage existing systems. They are multithreaded, load-balanced, lightweight components in this distributed integration architecture.
4 The repository consists of a master repository and several work repositories. These repositories are databases stored in relational database management systems. All objects that the modules configure, develop, or use are stored in one of these repositories, and are accessed in client-server mode by the various components of the architecture.
There is usually only one master repository, which contains the security information (user profiles and privileges), the topology information (definitions of technologies and servers), and the versions of the objects. The information contained in the master repository is maintained with Topology Manager and Security Manager. All modules have access to the master repository, because they all store topology and security information there.
Project objects are stored on the work repository. Several work repositories can... [download for more]