April 4

ODI
Series

2012

Uso da ferramenta Oracle Data Integrator (ODI) para a

construo de processos ETL (Extract, Transform and
Load). Nesta srie de tutoriais, utilizaremos o ODI para
integrar dados de diferentes origens (banco de dados
diferentes e arquivos texto) para uma base de destino
Oracle.

Melhores
Prticas

Melhores Prticas
O Oracle Data Integrator (ODI) um produto muito poderoso quando utilizado
corretamente. Infelizmente, alguns erros podem levar a resultados desastrosos
em projetos de integrao de dados. Para tentar mitigar esses problemas segue
abaixo um resumo de 10 prticas que podem ajudar nessa tarefa:

#1 Entenda e Use Corretamente os Contextos e a Topologia

Os Contextos e a Topologia so algumas das caractersticas mais poderosas do
ODI em tempo de Design e em tempo de Execuo de artefatos e vrios
ambientes diferentes.
No ODI, todos os desenvolvimentos bem como as execues so feitos sobre
uma Arquitetura Lgica (schemas lgicos, agentes lgicos), que se resolvem em
um dado Contexto para uma Arquitetura Fsica (fonte de dados fsica/servidores
de dados de destino/schemas e agentes de run-time do ODI). Os Contextos nos
permitem chavear a execuo dos artefatos de um ambiente (Contexto) para
outro.
Dois erros comuns que so cometidas em relao aos Contextos:
Esquecer de mapear as arquiteturas fsica e lgica para um determinado
Contexto. Isso um erro de administrao de Topologia que leva a
falhas de execuo em um dado Contexto. Para evitar isso, garanta que
todos os recursos lgicos esto mapeados para recursos fsicos nesse
Contexto.
Um grande erro forar o Contexto quando no necessrio. Nas
interfaces ou nas procedures, existem caixas de seleo com a lista de
Contextos, defina como default ou execution context. A no ser que
seja realmente necessrio forar o contexto por uma razo funcional,
deixe as caixas de seleo como estiverem. So raros os casos onde
realmente necessrio forar o Contexto.
Resumo
Garanta que o seu entendimento sobre Contextos e Topologia esteja slido.
Defina cuidadosamente a Topologia e o mapeamento dos Contextos. Evite
forar Contextos.

#2 Design Independente de Contexto

Em vrios tipos de artefatos do ODI (procedures, variveis, interfaces, etc.)
possvel adicionar cdigo SQL. Um erro muito comum inserir nomes de
objetos qualificados, como no exemplo abaixo que faz um DROP na tabela
TEMPO_001 num schema de staging:
DROP TABLE STAGING.TEMP_001
Isso um cdigo dependente de contexto. Se voc executa esse cdigo em
ambiente de produo onde a rea de staging se chama PRD_STG, seu cdigo
no funciona. Perceba que os nomes dos schemas so definidos na Topologia,
e os contextos acessam o schema correto dependendo do contexto de
execuo. Nesse caso a pergunta : Como usar isso no seu cdigo?
Os Mtodos de Substituio (OdiRef API) existem para disponibilizar no seu
cdigo os metadados armazenados no ODI tornando o cdigo independente de
contexto. Sendo assim, eles garantem que o nome qualificado da tabela em
questo ser gerado de acordo com o contexto onde o cdigo est sendo
executado.
Utilizando os Mtodos de Substituio, o cdigo genrico ficaria assim:
DROP TABLE <%odiRef.getObjectName("L", "TEMP_001","W")%>.
Consulte o Substitution Methods Reference Guide para mais informaes sobre
como utilizar essa API. O expression editor tambm ajuda muito.
Resumo
To logo voc comece a digitar um nome de schema, nome de database, nome
de usurio ou qualquer informao referente um servidor ou schema, pare,
respire fundo e considere utilizar um Mtodo de Substituio.

#3 Utilize Procedures Apenas Quando Necessrio

As procedures permitem a execuo de aes bem complexas, incluindo
comandos SQL. Alm disso, elas permitem a utilizao das conexes source e
target e ainda suportam binding. Isso significa que possvel mover dados de
um lado para o outro usando apenas procedures.
Os desenvolvedores que se sentem vontade com cdigo SQL ficam
sriamente tentados a escrever cdigo para fazer transformaes e
movimentao de dados ao invs de desenvolver interfaces.
Existem alguns problemas quanto isso:

Procedures contm cdigo manual que precisa sofrer manuteno

manualmente.
Procedures no mantm referncias com os outros artefatos ODI como
datastores, modelos, etc., fazendo com que a manuteno seja muito
mais complexa comparado s interfaces.
Procedures nunca devem ser utilizadas para mover ou transformar
dados, essas operaes devem ser feitas utilizando as intefaces.

Resumo
Quando voc comear a usar procedures para mover/transformar dados
provavelmente voc est fazendo uso inadequado das procedures e deveria
usar interfaces no lugar delas.

#4 Garantir Qualidade de Dados

s vezes o lder de projeto de integrao de dados no leva em conta a
qualidade dos dados. Isso um erro comum. O processo de integrao pode
estar movendo e transformando lixo e propagando esse lixo para outras
aplicaes.
O ODI permite que a qualidade dos dados seja garantida na fonte, (source)
utilizando static checks ou ento durante o processo de integrao antes de
gravar no destino (target) utilizando flow checks. Utilizando esses dois
mecanismos de checagem de dados possvel garantir a qualidade dos dados.
Resumo
Garanta a qualidade dos dados usando os dois mtodos: static checks e flow
checks. Qualidade de dados no uma opo.

#5 Capturar Erros em Packages

Numa package possvel sequenciar passos de execuo. Cada passo em uma
package passvel de falha por qualquer razo (source ou target fora do ar,
muitos registros rejeitados em uma interface, etc.).
necessrio sempre procurar prever os possveis erros em cada passo da
package.
Resumo
As setas de OK (verdes) nas packages precisam existir e as setas KO
(vermelhas) so o que tornam a sua package prova de balas.

#6 Escolha o KM correto
A escolha do KM crtica ao desenvolver uma interface pois define quais as
features estaro disponveis e afeta tambm a performance de uma package.
Alguns erros comuns na escolha do KM:

Comear com KMs complexos: Desenvolvedores iniciantes que ter suas

interfaces rodando rapidamente mas s vezes no levam em conta todos
os requisitos para utilizar um KM. Escolhendo, por exemplo, um LKM de
uma tecnologia especfica pode no funcionar por uma configurao ou
instalao incorreta do loader. Uma ecolha mais segura seria comear
usando KMs mais genricos (como KMs de SQL) que funcionam na
maioria dos casos. Depois de desenvolver suas primeiras interfaces com
esses KMs hora de mudar para KMs mais especficos (estude as
especificaes antes!).
Interfaces com excesso de engenharia: KMs com features extras causam
um custo extra de performance. Por exemplo, executar inserts mais
rpido do que executar updates incrementais. Se sua interface deleta os
dados no destino antes da integrao, utilizar update incremental
excesso de engenharia e causar perda de performance. Utilize o KM
que se encaixa adequadamente sua necessidade.
De maneira similar, ativar ou desativar algumas fatures do KM pode
adicionar passos extras degradando a performance. As opes default do
KM so suficientes para executar o KM da forma como ele foi fornecido.
Aps executar o KM com as opes default sempre bom revisar e
checar se alguma opo pode ser alterada de acordo com a sua
necessidade. A descrio do KM sempre uma boa opo de
documentao para entender e otimizar a utilizao do KM.

Resumo
Comece com os KMs mais simples, no se utilize de excesso de engenharia
com KMs complexos ou ativando opes complexas e preste ateno s opes
dos KMs.

#7 - Customize Seus KMs

Knowledge Modules (KMs) um poderoso framework utilizado em cada ponto
de integrao no ODI. Um grande nmero de KMs est disponvel para
utilizao. Eles suportam uma grande variedade de bancos de dados. Mesmo
no sendo necessrio na maiorias dos casos, alguns projetos podem ter casos
de uso ou requerimentos que solicitem uma customizao de KM.
Ento, qual deve ser o momento de customizar um KM? A resposta : To logo
seja detectada uma operao que precisa ser executada em vrias interfaces,
por exemplo, rodar um comando no target para otimizao da execuo.
No recomendado comear um KM partir de uma folha em branco. O
caminho recomendado encontrar um KM que esteja o mais prximo possvel
do comportamento desejado e partir dele, customizar de acordo com a
necessidade.
Resumo
Quando uma operao necessria em muitas interfaces, no tenha medo de
customizar um KM e criar o seu prprio KM baseado em algum j existente.

#8 Organize o Seu Projeto no Incio

Gerenciamento e organizao podem no parecer pontos crticos quando o
assunto integrao de dados, mas so.
O ODI oferece muitas ferramentas que ajudam a organizar o desenvolvimento
e o ciclo de vida do projeto: perfis de segurana, projetos de desenvolvimento,
pastas, marcadores, versionamento, importao/exportao, impresso da
documentao em PDF, etc.
Revise e utilize todas essas ferramentas e features para gerenciar o projeto.
Defina a organizao do projeto, a padronizao de nomes e tudo o que pode
evitar o caos depois que o projetos tiver iniciado. Faa isso desde o incio do
projeto.
Resumo
Mantenha alta produtividade com o ODI, melhor ter regras de organizao
baseadas nas features do ODI para evitar o desenvolvimento do caos.

#9 Controle os Repositrios
No ODI, um repositrio master pode ter vrios repositrios work. Tambm
possvel ter vrios repositrios master, cada um com seu grupo de repositrios
work. Cada repositrio tem um ID definido na hora da criao do repositrio.
Bem, um repositrio no um documento. a fonte da verdade, a
referncia central entre os artefatos do ODI.
Alm disso, todo objeto identificado por um ID interno que depende do ID do
repositrio. Esse ID interno identifica unicamente um objeto e utilizado pelo
sistema de importao do ODI. Dois repositrios com o mesmo ID
possivemente contm objetos com o mesmo ID interno, o que significa o
mesmo objeto para o ODI.
Transferir objetos entre esses repositrios como copiar arquivos com o
mesmo nome entre diretrios e pode fazer com que o objeto seja substitudo.
Garanta que todos os repositorios sejam criados com IDs diferentes (mesmo
em sites diferentes), e defina uma documentao para o processo de mover
objetos entre repositrios utilizando import/export ou versionamento.
Resumo
A multiplicao de repositorios deve ser feita sob estrito controle e
planejamento (especialmente quanto escolha do ID do repositrio), e o
gerenciamento de transferncias de objetos utilizando import/export ou
versionamento deve ser feito por vias formais.

#10 Cuidado Com o Contedo dos Repositrios

O ODI armazena todas as informaes num repositrio de metadados em um
banco de dados relacional. Sabendo disso muito tentador comear a explorar
as tabelas do repositrio para conseguir informaes mais rpido.
O repositrio no implementa toda a lgica que existe na interface grfica e
tambm no implementa toda a lgica de negcios que existe no cdigo Java.
Construir, por exemplo, dashboards ou relatrios sobre o repositrio aceitvel
mas escrever dados ou alterar as informaes do repositrio perigoso e deve
ser deixado para operaes do suporte tcnico da Oracle.
Resumo
Voc faria isso no banco de dados do ERP da sua empresa? Tambm no faa
com o repositrio de metadados do ODI.