Esse post assume que o leitor tem alguma familiaridade com o Oracle Data Integrator. O Oracle Data Integrator (ODI) e um produto muito poderoso quando utilizado corretamente. Infelizmente, alguns erros podem levar a resultados desastrosos em projetos de integracao de dados. Nesse post abordo 10 melhores praticas para evitar os erros mais comuns em projetos com Oracle Data Integrator.Boa Pratica #1 Entenda e Use Corretamente os Contextos e a TopologiaOs Contextos e a Topologia sao algumas das caracteristicas mais poderosas do ODI em tempo de design e em tempo de execucao de artefatos e varios ambientes diferentes.No ODI, todos os desenvolvimentos bem como as execucoes sao feitos sobre uma Arquitetura Logica (schemas logicos, agentes logicos), que se resolvem em um dado Contexto para uma Arquitetura Fisica (fonte de dados fisica/servidores de dados de destino/schemas e agentes de run-time do ODI). Os Contextos nos permitem chavear a execucao dos artefatos de um ambiente (Contexto) para outro.Agora, leia o paragrafo anterior novamente. Tenha certeza de que voce compreendeu o conceito de Contexto, Arquitetuta Logica e Arquitetura Fisica.Dois erros comuns que sao cometidos em relacao aos Contextos:Esquecer de mapear as arquiteturas fisica e logica para um determinado Contexto. Isso e um erro de administracao de Topologia que leva a falhas de execucao em um dado Contexto. Para evitar isso, garanta que todos os recursos logicos estao mapeados para recursos fisicos nesse Contexto.Um grande erro e forcar o Contexto quando nao e necessario. Nas interfaces ou nas procedures, existem caixas de selecao com a lista de Contextos, defina como default ou execution context. A nao ser que seja realmente necessario forcar o contexto por uma razao funcional, deixe as caixas de selecao como estiverem. Sao raros os casos onde e realmente necessario forcar o Contexto.Resumindo: Garanta que o seu entendimento sobre Contextos e Topologia esteja solido. Defina cuidadosamente a Topologia e o mapeamento dos Contextos. Evite forcar Contextos.Boa Pratica #2 Design Independente de ContextoEm varios tipos de artefatos do ODI (procedures, variaveis, interfaces, etc.) e possivel adicionar codigo SQL. Um erro muito comum e 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_001Isso e um codigo dependente de contexto. Se voce executa esse codigo em ambiente de producao onde a area de staging se chama PRD_STG, seu codigo nao funciona. Perceba que os nomes dos schemas sao definidos na Topologia, e os contextos acessam o schema correto dependendo do contexto de execucao. Nesse caso a pergunta e: Como usar isso no seu codigo?Os Metodos de Substituicao (OdiRef API) existem para disponibilizar no seu codigo os metadados armazenados no ODI tornando o codigo independente de contexto. Sendo assim, eles garantem que o nome qualificado da tabela em questao sera gerado de acordo com o contexto onde o codigo esta sendo executado.Utilizando os Metodos de Substituicao, o codigo generico ficaria assim:DROP TABLE <%odiRef.getObjectName("L", "TEMP_001","W")%>.Consulte o Substitution Methods Reference Guide para mais informacoes sobre como utilizar essa API. O expression editor tambem ajuda muito.Resumindo: Tao logo voce comece a digitar um nome de schema, nome de