ODI Series

April 4

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