Escolar Documentos
Profissional Documentos
Cultura Documentos
Agenda
Overview
Architecture
Developing interfaces
Creating packages
Generating scenarios
Variables declaration
User functions
Creating sequences
Knowledge modules
Provisioning security
Migration Techniques
Overview
An integration platform
To move and transform information across
the information system
Based on metadata
Centralized repository
Enables simply faster integration
ELT architecture provides high
performance.
Knowledge modules provide flexibility
and extensibility.
EL-T
Extract: Extracting the data from
various sources
Load: Loading the data into the
destination target
Transform: Transforming the data
according to set of business rules
Architecture
ODI graphical modules:
ODI Designer
ODI Operator
ODI Topology Manager
ODI Security Manager
ODI agents - A run-time
component of ODI that
orchestrates the integration
process.
ODI Console - The
application server links the
ODI repository to any Web
browser such as Firefox or
Internet Explorer.
ODI repositories - All ODI
modules store their
information in the
centralized ODI repository.
ODI Interfaces Key Concepts
An interface is an ODI object that loads one target data store with data
from one or more source data stores.
An interface implements business rules as mappings, joins, filters, and
constraints.
Other ODI Specific Elements like Variables, Sequences and User functions.
Sequence of Execution
Execution Location
In an ODI Interface, each rule may be executed on the:
Source
Target
Staging area
The execution location is specified at design time.
How a rule gets implemented depends on the technology of its
execution location.
Case Studies
Staging Area
Alternate
Target Server Source Server
Server Both
LKM Only IKM Only
LKM and IKM
Configuring Filters, Joins, and Mappings
KM OPTIONS Description
INSERT UPDATE Should data be inserted/updated in the target?
COMMIT Should the interface commit the insert/updates?
If no, a transaction can span several interfaces.
FLOW CONTROL Should data in the flow be checked?
STATIC CONTROL Should data in the target be checked after the interface?
TRUNCATE / DELETE ALL Should the target data be truncated or deleted before
integration?
DELETE TEMPORARY OBJECTS Should temporary tables and views be deleted or kept for
debugging purposes?
Monitoring Interface Executions
Generating Scenarios
A scenario is designed to put a source component (interface, package,
procedure, variable) into production.
A scenario results from the generation of code (SQL, shell, etc.) for this
component.
The scenario code (the language generated) is frozen, and all subsequent
modifications of the components which contributed to creating it will not
change it in any way.
Re-generating Scenarios
An existing scenario can be regenerated with the same name and version
number.
This lets you replace the existing scenario by a scenario generated from the
source object contents.
ODI Procedures
A procedure is a sequence of commands executed by database engines,
the operating system, or using the ODI tools.
A procedure can have options that control its behavior.
Procedures are reusable components that can be inserted into packages.
Examples
Binding:
Works only for SQL clauses by prefixing it with a colon : rather than a hash
# (binding).
The statement is prepared in the DBMS without the value, then the value is
sent for processing.
It may be used for DBMSs that optimize repeated statements with different
parameter values.
User Functions
ODI user functions are macros in ODI that are replaced at run time by code
that is specific to the technology where they are used.
It is used to create an alias for a recurrent piece of code or encapsulate a
customized transformation.
Use of User Functions:
Simple formula:
If <param1> is null then <param2> else <param1> end if
Can be implemented differently in different technologies:
Oracle:
nvl (<param1>, <param2>)
Other technologies:
case when <param1> is null
then <param2>
else <param1>
end
Properties of User functions
To generate a new sequence value for each row, your mapping should meet
the following conditions:
Mapping must be executed on the target.
The column must be set for insert but not update.
Unique keys must be checked in the flow not containing the column.
The Not Null check box must be deselected for the column.
The column must not be part of the update key.
Modify the flow to force the integration phase to pass all data through the
agent
Use a multiple-technology append or control append IKM.
There should be a SELECT / INSERT command, rather than an INSERTSELECT.
ODI Packages
A package is a pre-defined sequence of steps, designed to be executed in
order.
There are many types of steps, such as:
Interfaces
Procedures
Actions/evaluations on variables
Actions on models, sub-models or data stores
OS Commands
Oracle Data Integrator Tools
Actions/Evaluations On Variables
Declare Variable: When a variable is used in a Package (or in elements of the topology
which are used in the Package), it is strongly recommended that you insert a Declare
Variable step in the Package. This step explicitly declares the variable in the Package.
Refresh Variable: This step refreshes the variable by running the query specified in the
variable definition.
Evaluate Variable: This step compares the value of the variable with a given value
according to an operator. If the condition is met, then the evaluation step is true,
otherwise it is false. This step allows for branching in Packages.
Actions on Models
Journalizing
static check
Reverse-engineering
Knowledge Modules
A Knowledge Module is a code template containing the sequence of
commands necessary to implement a data integration task.
There are different predefined Knowledge Modules for loading, integration,
checking, reverse engineering, journalizing, and deploying data services.
All Knowledge Modules work by generating code to be executed at run time.
General Guidelines
Very few KMs are ever created from scratch. They usually are extensions or
modifications of existing KMs.
Duplicate existing steps and modify them. This prevents typos in the syntax of the odiRef
methods.
All interfaces using the KM inherit the new behavior. Remember to make a copy of the
KM if you do not want to alter existing interfaces. Modify the copy, not the original.
Modifying a KM that is already used is a very efficient way to implement modifications
in the data flow and affect all the existing developments.
ODI Security Profiles
Security Cases
Setting up LDAP security
Setting external authentication
Creating users using generic profiles
Creating users using Non-generic profiles
Creating new custom profiles
Migration of objects
Smart Export
Smart Import
Import Modes
Duplication
Synonym mode Insert
Synonym mode Update
Synonym mode Insert/Update
Import Replace