database, nome de usuario ou qualquer informacao referente a um servidor ou schema, pare, respire fundo e considere utilizar um Metodo de Substituicao.Boa Pratica #3 Utilize Procedures Apenas Quando NecessarioAs procedures permitem a execucao de acoes bem complexas, incluindo comandos SQL. Alem disso, elas permitem a utilizacao das conexoes source e target e ainda suportam binding. Isso significa que e possivel mover dados de um lado para o outro usando apenas procedures.Os desenvolvedores que se sentem a vontade com codigo SQL ficam seriamente tentados a escrever codigo para fazer transformacoes e movimentacao de dados ao inves de desenvolver interfaces.Existem alguns problemas quanto a isso:Procedures contem codigo manual que precisa sofrer manutencao manualmente.Procedures nao mantem referencias com os outros artefatos ODI como datastores, modelos, etc., fazendo com que a manutencao seja muito mais complexa comparado as interfaces.Procedures nunca devem ser utilizadas para mover ou transformar dados, essas operacoes devem ser feitas utilizando as interfaces.Resumindo: Quando voce comecar a usar procedures para mover/transformar dados provavelmente voce esta fazendo uso inadequado das procedures e deveria usar interfaces no lugar delas. Boa Pratica #4 Garantir Qualidade de DadosAs vezes o lider de projeto de integracao de dados nao leva em conta a qualidade dos dados. Isso e um erro comum. O processo de integracao pode estar movendo e transformando lixo e propagando esse lixo para outras aplicacoes.O ODI permite que a qualidade dos dados seja garantida na fonte, (source) utilizando static checks ou entao durante o processo de integracao antes de gravar no destino (target) utilizando flow checks. Utilizando esses dois mecanismos de checagem de dados e possivel garantir a qualidade dos dados.Resumindo: Garanta a qualidade dos dados usando os dois metodos: static checks e flow checks. Qualidade de dados nao e uma opcao.Boa Pratica #5 Capturar Erros em PackagesNuma package e possivel sequenciar passos de execucao. Cada passo em uma package e passivel de falha por qualquer razao (source ou target fora do ar, muitos registros rejeitados em uma interface, etc.).E necessario sempre procurar prever os possiveis erros em cada passo da package.Resumindo: As setas de OK (verdes) nas packages precisam existir e as setas KO (vermelhas) sao o que tornam a sua package a prova de balas.Boa Pratica #6 Escolha o KM corretoA escolha do KM e critica ao desenvolver uma interface pois define quais as features estarao disponiveis e afeta tambem a performance de uma package.Alguns erros comuns na escolha do KM:Comecar com KMs complexos: Desenvolvedores iniciantes que ter suas interfaces rodando rapidamente mas as vezes nao levam em conta todos os requisitos para utilizar um KM. Escolhendo, por exemplo, um LKM de uma tecnologia especifica pode nao funcionar por uma configuracao ou instalacao incorreta do loader. Uma ecolha mais segura seria comecar usando KMs mais genericos (como KMs de SQL) que funcionam na maioria dos casos. Depois de desenvolver suas primeiras interfaces com esses KMs e hora de mudar para KMs mais especificos (estude as especificacoes antes!).Interfaces com excesso de engenharia: KMs com features extras causam um custo extra de performance. Por exemplo, executar inserts e mais rapido do que executar updates