Willy Scalioni

A TI do novo Brasil e CPM Braxis

wscalioni@yahoo.com.br (Willy Scalioni) — Fri, 27 Aug 2010 11:57:53 PDT

Para os que não sabem, atualmente trabalho como consultor de Business Intelligence e Enterprise Performance Management na CPM Braxis, a maior empresa de serviços de TI do Brasil e recentemente contribuí na produção de um artigo chamado A TI do novo Brasil que pode ser lido no site da CPM Braxis.

Juntamente com Nicola Mazzi (do blog BI & Cia) e Gustavo Monteiro, ambos executivos de serviços da CPM Braxis, falamos sobre vários aspectos do Business Intelligence e Enterprise Performance Management, mais especificamente sobre "Tecnologia e Conhecimento de Negócios para a Excelência na Tomada de Decisão".

O artigo está aqui em PDF.

Otimização de Aplicações Planning Pré-existentes – Parte 1

wscalioni@yahoo.com.br (Willy Scalioni) — Fri, 12 Feb 2010 04:05:04 PST

Uma pergunta comum dos clientes que já tem aplicações Planning pré-existentes é "como posso otimizar a performance das minhas aplicações?". Duas iniciativas simples que eventualmente podem ajudar na melhora da performance para ambientes Planning já estabelecidos são:

Remover dados históricos desnecessários
Reorganizar os outlines

Remover dados históricos desnecessários

É comum que se mantenha todo o histórico de dados em aplicações Planning para facilitar a análise ano a ano. Manter uma quantidade excessiva de dados históricos no Planning significa ter uma quantidade enorme de blocos desnecessários e quanto maior a quantidade de blocos, maior o tempo de processamento dos cálculos. É claro que geralmente é necessário manter os dados históricos disponíveis de alguma forma para análise ao longo dos anos e para isso recomendo a prática de criar aplicações Essbase para reporting de dados históricos facilitando assim a otimização das aplicações Planning. Cubos Essbase para reporting podem ser desenvolvidos para manter dados históricos. Esses novos cubos Essbase devem ser desenvolvidos baseados nas aplicações Planning mantendo a mesma estrutura. Todos os dados que não sejam para novos planejamentos orçamentários ou forecasts devem ser movidos para esses cubos de reporting que são "puramente" Essbase. Essa integração entre as aplicações Planning e os cubos Essbase de reporting podem ser feitas usando técnicas como Partitioning, @XREF, ou mesmo exportação e importaçao de dados (export/import, report scripts). Os dados de planejamento como Orçado, Forecast, etc, permanecem nas aplicações Planning e através de processos de automação, ao longo dos anos os dados que se tornam históricos são migrados para as aplicações Essbase de reporting. Sugestão de passo a passo para migrar os dados históricos do Planning:

Crie aplicações Essbase nativas para receber os dados históricos.
Os novos cubos devem ser baseados na estrutura das aplicações Planning existentes.
Remova das aplicações Planning todos os dados que não tem relação com o processo de geração de novos budgets e forecasts.
Carregue os dados históricos nas aplicações nativas Essbase para reporting.
Remova os membros das dimensões do Planning que dizem respeito apenas aos dados históricos.
Escolha uma das técnicas disponíveis e integre os dados do ano corrente do Planning com os cubos Essbase de reporting.

Reorganizar Outlines

Pela "cartilha" ou se preferir "by the book" é sabido que a organização de outlines deve ser feita de cima para baixo:

Dimensões densas com a maior quantidade de membros stored até as dimensões densas com a menor quantidade de membros stored
Dimensões esparsas com a menor quantidade de membros stored até as dimensões esparsas com a maior quantidade de membros stored.

É claro que essa regra não se aplica a todos os modelos mas é recomendado que se comece dessa forma executando várias fases de testes com múltiplas configurações executandos os cálculos em cada uma delas até chegar na organização ótima do outline.

É possível também simular cálculos usando SET MSG ONLY no calc script. Um cálculo simulado oferece resultados que ajudam na análise da performance de um cálculo real baseado nos mesmos dados e no mesmo outline

Executando um cálculo simulado com um comando como o SET NOTICE HIGH, é possível verificar o tempo de cálculo de cada dimensão esparsa. Depois, executando o cálculo real em uma ou mais dimensões é possível estimar quanto tempo o cálculo vai demorar pois deve ser alguma coisa bem próxima do tempo do cálculo simulado.

Obviamente não considere esses passos como sendo o ciclo completo de otimização das aplicações Planning, considere como um bom começo.

Utilitários para produtos Oracle/Hyperion

wscalioni@yahoo.com.br (Willy Scalioni) — Wed, 18 Nov 2009 08:32:26 PST

Precisando executar algumas tarefas relacionadas ao gerenciamento de filtros de segurança no Essbase, pesquisei bastante e encontrei um utilitário chamado Hyperion Essbase Filter Mania Utility (ou Filter Mania para os íntimos) que atualmente está disponível no prórpio site da Oracle para download mas ela afirma não garantir o funcionamento correto dos utilitários listados, sendo que o uso deles fica por nossa conta e risco.

Nada que um bom teste em ambiente de desenvolvimento não resolva. Alguns utilitários são bem interessantes e vou descrever aqui os que gostei mais. Para ver os outros, basta acessar essa página com todos os utilitários para produtos Hyperion no site da Oracle (em inglês).

Hyperion Essbase Filter Mania Utility: Pode ser usado para exportar, importar ou alterar filtros de segurança do Hyperion Essbase com cliques, sem precisar programar ESSCMD ou MaxL. Para alterações recorrentes em filtros de segurança, esse utilitário pode te economizar horas de trabalho.Clique aqui para fazer o download do Hyperion Essbase Filter Mania Utility

Hyperion Essbase Log Reconciler: Esse utilitário é um script PERL compilado que reformata os logs do Essbase deixando os logs visualmente mais fáceis de ler. Clique aqui para fazer o download do Hyperion Essbase Log Reconciler

Hyperion SetCache Utility: Essa é interessante para o pessoal de infraestrutura que administra muitas aplicações. Esse utilitário monitora e ajusta o tamanho do Index Cache para todas as aplicações em um determinado servidor. É um conjunto de scripts que checam o tamanho dos Index Caches e dinamicamente cria outros scripts MaxL que alteram o valor do Index Cache de cada aplicação para o valor apropriado (90% do tamanho do arquivo de índice). Clique aqui para fazer o download do Hyperion SetCache Utility

Como eu disse, existem muitos outros utilitários, code snippets e aplicações de exemplo, não deixe de conferir a lista completa.

O que é ser um bom consultor?

wscalioni@yahoo.com.br (Willy Scalioni) — Wed, 18 Nov 2009 09:04:59 PST

Por Nicola Mazzi em seu blog BI & CIA

Me lembro do meu primeiro (e único) processo de seleção em uma empresa de consultoria. Tivemos que fazer uma prova de conhecimentos gerais, uma prova de inglês, uma dinâmica de grupo, uma entrevista com um gerente e entrevistas com dois sócios. A cada etapa o número de candidatos ia diminuindo. Se para entrar no processo o meu currículo (engenharia em uma boa universidade do RJ) foi importante, na medida em que as etapas iam sendo superadas, percebia que cada vez mais ele deixava de ser relevante. As entrevistas buscavam avaliar sobretudo as habilidades não técnicas, como capacidade de argumentação, eloquência e relacionamento inter-pessoal, entre outras. Ao final do processo, o grupo selecionado era formado pelos candidatos com maior potencial para se tornarem bons consultores. E afinal de contas, o que é ser um bom consultor?

Continue lendo no blog BI & CIA

Essbase com Perl e também Python

wscalioni@yahoo.com.br (Willy Scalioni) — Wed, 18 Nov 2009 08:35:47 PST

Fazendo algumas buscas sobre como implementar algumas rotinas de integração de dados em Perl para processos batch de cargas Essbase descobri essa pérola no Google Code.

Semelhante ao módulo Essbase.pm, está disponível também o módulo Essbase.py que permite enviar comandos para dll primária do MaxL (essmaxl.dll ou essmaxlu.dll) usando scripts em Python. No Google Code tem também scripts de exemplo de utilização do módulo Python para Essbase.

É óbvio que será necessário ter um interpretador Python na máquina onde o script será executado. Para testes de desenvolvimento sugiro baixar aqui o ActivePython.

O módulo CTYPES do Python, utlizado nesse módulo para Essbase é padrão nas versões 2.5 ou superior do Python. O módulo Essbase.py está disponível para Essbase versão 6.5 e 7.1 mas a versão 7.1 também é funcional no Essbase 9.3.1

Certificações Oracle para BI e EPM

wscalioni@yahoo.com.br (Willy Scalioni) — Mon, 09 Nov 2009 14:58:20 PST

Muitos profissionais me perguntam sobre as provas de certificações de BI e EPM da Oracle. Para o pessoal de consultoria que já está no mercado há 8 ou 10 anos isso é uma "onda" relativamente nova pois há pouco tempo atrás havia um número muito pequeno de consultores "Hyperion" e as certificações não tinham o peso que têm atualmente, bastava que o profissional tivesse alguma experiência na ferramenta para ser considerado um especialista.

As coisas mudaram um pouco, as tecnologias envolvidas começaram a ser absorvidas por uma massa muito maior de profissionais e o conhecimento está sendo pulverizado, naturalmente. Na minha opnião, as certificações são um verdadeiro caçaníqueis não medem muita coisa, medem, só um pouco, o profissional técnico, mas não todos os outros skills necessários para construir um profissional completo, especialmente o consultor pois o perfil de consultoria envolve muito mais do que o mero conhecimento técnico. Mesmo assim, já que o "Sr. Mercado" quer as certificações, cabe a nós estudar para tê-las.

Se você ainda está pensando se vale à pena investir muitas horas de estudo para fazer uma prova dessas ou se já decidiu fazer mas não sabe muito bem por onde começar, aí vão algumas dicas:

Avalie as provas de certificação existentes. Não existe certificação para todo e qualquer produto vendido pela Oracle. Lembre-se que a Oracle compra uma empresa a cada 40 minutos, mais ou menos, então não há certificação pra tudo, apenas para as tecnologias mais importantes.
Tenha prioridades. Não adianta fazer uma lista enorme de certificações que você gostaria de ter pensando que vai fazer tudo em uma semana. Escolha uma, vá ate o fim e só depois parta para a próxima.
Tenha foco. Escolha provas imediatamente relevantes para a sua carreira. Se daqui a algum tempo você mudar um pouco de área, faça outra que se encaixe à sua realidade atual. O investimento de tempo de estudo é grande o suficiente para você não precisar fazer provas "à toa" mas também é pequeno o suficiente para você poder fazer uma nova certificação sempre que sua carreira demandar.
Busque orientação. Conversar com quem já fez a prova que você vai fazer ajuda bastante. Pequenas dicas, detalhes, "pegadinhas" podem te salvar.

Existem dois tipos de prova de certificação Oracle:

Non-proctored

São as provas que você pode fazer a qualquer momento online sem supervisão pagando com seu cartão de crédito. É um bom caminho para começar se você nunca fez uma prova de certificação pois a tensão é menor e serve como preparação para a prova supervisionada. Claro que na hora de buscar uma contratação ou uma promoção, o peso dessas certificações é menor, mas ainda assim são válidas. Atualmente a Oracle disponibiliza apenas as provas abaixo nesse modelo:
- 1Z0-007 Introduction to Oracle9i SQL®
- 1Z0-011-JPN SQL (Japanese Only)
- 1Z0-051 Oracle Database 11g: SQL Fundamentals I
- 1Z0-200 11i E-Business Suite Essentials for Implementers
- 1Z0-204 Oracle E-Business Suite R12: E-Business Essentials

Como você pode perceber, não há nenhuma prova Non-proctored para Fusion Middleware.

Proctored

São as provas supervisionadas que devem ser feitas num local autorizado pela Oracle a aplicar a prova. Atualmente a empresa autorizada a aplicar os testes da Oracle é a PEARSON VUE. Para o pessoal de BI e EPM, destaque para as provas de Essbase, Planning, Financial Management (HFM) e BI+. Veja no site da Oracle a lista de todas as certificações.

Agora que você já se considera preparado para fazer a sua prova, você deve se cadastrar no site da PEARSON VUE para agendar a sua prova.

Boa sorte.

10 Cuidados Para Transformar a Implantação de BI em um Caso de Sucesso

wscalioni@yahoo.com.br (Willy Scalioni) — Thu, 15 Oct 2009 13:33:23 PDT

Em seu blog, Nicola Mazzi oferece 10 importantes cuidados para transformar a Implantação de BI em um caso de sucesso. Veja o post e visite o blog BI & Cia.

1. Patrocínio

Antes de iniciar um projeto de BI, certifique-se de que este projeto está "comprado" por um dos gestores da Empresa. Geralmente os projetos de BI são gerenciados pela área de TI, mas esta iniciativa deve ser patrocinada por alguém que tenha força para fazer com que todos da empresa envolvidos no projeto tenham a dedicação e o envolvimento necessários. Sem este apoio, muitas vezes TI não consegue que os usuários participem ativamente do projeto, seja nas etapas de desenho, construção e/ou validação, e ainda pior, não conseguem fazer os usuários trocarem as planilhas em uso pelo novo sistema de informações.

O ideal é que o próprio CEO esteja envolvido no projeto, pois somente ele poderá garantir uma abrangência corporativa à iniciativa, mesmo que iniciado em um departamento específico.

A prática mostra que sem este apoio, na grande maioria dos casos de conflito, os usuários acabam sempre priorizando as atividades do dia-a-dia em detrimento àquelas do novo projeto.

2. Escolha do Software

Atualmente a quantidade de softwares/soluções de BI existentes no mercado é muito grande e especializada. Ferramentas de dashboards, query, reports, simulações, input de dados e etl, são apenas alguns exemplos que compõe este vasto universo. Esta diversidade faz com que exista uma grande disparidade de preços e funcionalidades entres os produtos, que pode gerar percepções equivocadas se comparadas indiscriminadamente pelo comprador.

Antes de escolher o pacote, é importante entender claramente quais são os requisitos técnicos e de negócio da Empresa, e verificar dentro das ofertas, aquelas que se adequam melhor ao desejado.

Exemplificando, se a empresa possui uma base de dados operacional (fontes de dados do BI) fragmentada, é importante adquirir uma ferramenta de etl que seja capaz de fazer esta integração. Se existem disparidades de conceitos entre os departamentos da Empresa, talvez seja importante adquirir uma ferramenta de gestão de meta-dados.

Uma outra boa questão é a escolha entre uma solução completa de um único fabricante (Oracle, SAP e IBM por exemplo), e a aquisição soluções específicas chamadas "best-of-breed" (Panorama, Informatica, etc). Além disso, já existem no mercado aplicações de BI "prontas", que trazem indicadores, modelos de dados e mapas de extração de dados já desenvolvidos, e prometem uma redução significativa no tempo de desenvolvimento do projeto.

3. Parceiro Experiente

A escolha de um bom parceiro (fornecedor) para a implantação do projeto traz vantagens, não apenas pelo aporte de conhecimento técnico e funcional aplicáveis ao projeto, mas também por mitigar riscos comuns, cujo pré-conhecimento garantirá uma significativa redução de custos e horas gastas no projeto.

Geralmente no mercado as empresas de consultoria especializadas estão vinculadas à uma bandeira, ou seja, representam, revendem ou distribuem softwares de uma determinada Empresa. Nestes casos, a escolha do parceiro estará diretamente ligada à escolha do pacote de software.

A utilização do parceiro em projetos de BI vai desde a terceirização total dos serviços para o parceiro (outsourcing), até a contratação tipo "turn-key" com a capacitação da equipe interna. Dessa forma, é muito importante que a Empresa defina a estratégia de utilização do parceiro desde o início do projeto.

4. Definição do Piloto

O ditado diz: "Pensar grande, começar pequeno". Escolha uma área da Empresa como piloto para o projeto. Para a escolha vários fatores podem ser levados em conta: Aquela que detém os indicadores mais importantes (vendas, por ex.), aquela cujos usuários são mais integrados a TI, aquela cuja extração dos dados é mais simples, etc.

O piloto tem dois principais objetivos: Ajudar a conhecer, em proporções controláveis, quais são os pontos de risco do projeto e ajudar a vender o projeto internamente para os usuários.

5. Aderência ao Modelo de Gestão

Um sistema de informações gerenciais será utilizado na medida em que reflita o modelo de gestão da Empresa. É muito comum chegar ao final de um projeto de BI e para a surpresa de todos, o conjunto de informações apresentadas não atender às demandas dos principais gestores. Neste caso, o sentimento de frustração é muito grande por parte de todos os envolvidos.

Para evitar este tipo desagradável de surpresa, é fundamental iniciar o projeto com um desenho conceitual que enderece com clareza o detalhamento dos Fatores Críticos de Sucesso (FCS) e seus respectivos Indicadores-Chave de Desempenho (ICD). Dimensões, atributos e fontes de dados, entre outros, devem ser documentadas e apresentadas aos usuários finais para validação.

Uma dica para esta etapa é solicitar os relatórios atualmente utilizados pelos gestores para a tomada de decisão. Embora na maioria das vezes estejam em formato desestruturado, um olho treinado poderá extrair deles informações valiosas para o desenho.

6. Arquitetura Técnica Adequada

Antes de iniciar o projeto é importante ter uma visão das necessidades de hardware e software envolvidos. Esta visão deve contemplar o projeto completo, e deve-se levar em conta que o crescimento do modelos de dados gerenciais é geralmente exponencial, ou seja, embora em um primeiro momento (piloto) possamos ter uma boa performance, na medida em que o modelo de dados cresce e/ou dados históricos são acrescentados, este quadro pode mudar rapidamente para um cenário de (sobretudo nos modelos diários) gargalo.

É muito importante criar ambientes similares de desenvolvimento e produção (e eventualmente homologação), pois geralmente um dos fatores mais críticos dos projetos de BI é o tempo de carga e cálculo dos modelos de dados.

É comum encontrar nas empresas um ambiente de desenvolvimento significativamente menor do que o de produção. Neste caso, jamais teremos como avaliar o desempenho dos modelos antes de migrá-los para produção, o que representa um grande risco para o projeto.

7. Fonte de Dados Confiável e Acessível

A fase de extração dos dados operacionais para o BI é aquela que concentra a maior parte dos riscos para o projeto, pois normalmente o esforço e complexidade são subdimensionados. O risco desta etapa aumenta proporcionalmente à quantidade de fontes de dados diferentes.
O BI é uma grande janela que mostra os dados da Empresa, desde o valor consolidado chegando em alguns casos a informações bem detalhadas (ex: sku de produtos, nota fiscal). Por isso é muito comum que o processo de validação dos dados no BI acabe mostrando várias inconsistências existentes nas bases operacionais. Em alguns casos são tantos os problemas de qualidade dos dados que inviabilizam a continuação do projeto.

8. Envolvimento dos Usuários

Um sistema de informações jamais pode ser imposto, ou pelo menos, jamais pode parecer ter sido imposto. Por isso, o usuário final, ou seja, o principal beneficiário, deve ser envolvido no projeto desde a sua concepção, tornando-o co-responsável pelo produto final a ser gerado.

Nos casos onde não há uma co-participação do usuário, é muito comum haver uma maior resistência em abrir mão das ferramentas de gestão atuais, pois o mesmo não se sentirá nem comprometido com o que foi gerado, nem suficientemente seguro para confiar nos números do novo sistema.

A participação do usuário é crítica durante todo o projeto, mas é sobretudo nas etapas de desenho conceitual e de validação dos dados que se torna indispensável.

9. Plano de Implantação Detalhado

O momento de colocar a aplicação em produção é muito crítico. Há muita ansiedade dos usuários pelo novo sistema, e qualquer atraso na implantação gerará frustração. Por isso, é muito importante detalhar um plano de implantação que contemple aspectos como "fall-back" (em caso de problemas), produção assistida e treinamento dos usuários, entre outros.

É importante que a área da empresa responsável pelo gerenciamento de mudança seja envolvida no processo, para preparar o plano de mudança junto aos usuários. Um bom plano de marketing interno focando nos benefícios do novo projeto também é recomendado.

10. Melhoria Contínua

Como dito anteriormente, uma aplicação de BI deve refletir o modelo de gestão da empresa. Como as empresas estão em constante transformação, o modelo de gestão está sempre mudando. A chegada de novos gestores, mudanças no cenário mundial, alterações na legislação, são todos exemplos de mudanças que certamente terão reflexos no BI.

O projeto de BI não termina após a sua implantação. Esta é apenas o marco inicial de um processo contínuo de geração de informações para a tomada de decisão. Na medida em que houver o amadurecimento do sistema, com a adesão de mais e novos usuários, a inclusão de novos indicadores, e a construção de novos módulos (planejamento, consolidação, scorecard) a Empresa caminhará para um cenário onde poderá efetivamente utilizar a informação como diferencial competitivo.

Por Nicola Mazzi em BI & Cia.

Top 10 Melhores Práticas em Projetos com Oracle Data Integrator

wscalioni@yahoo.com.br (Willy Scalioni) — Thu, 11 Feb 2010 07:55:43 PST

Esse post assume que o leitor tem alguma familiaridade com o Oracle Data Integrator.

O Oracle Data Integrator (ODI) é um produto muito poderoso quando utilizado corretamente. Infelizmente, alguns erros podem levar a resultados desastrosos em projetos de integração de dados. Nesse post abordo 10 melhores práticas para evitar os erros mais comuns em projetos com Oracle Data Integrator.

Boa Prática #1 – Entenda e Use Corretamente os Contextos e a Topologia

Os Contextos e a Topologia são algumas das características mais poderosas do ODI em tempo de design e em tempo de execução de artefatos e vários ambientes diferentes.

No ODI, todos os desenvolvimentos bem como as execuções são feitos sobre uma Arquitetura Lógica (schemas lógicos, agentes logicos), que se resolvem em um dado Contexto para uma Arquitetura Física (fonte de dados física/servidores de dados de destino/schemas e agentes de run-time do ODI). Os Contextos nos permitem chavear a execução dos artefatos de um ambiente (Contexto) para outro.

Agora, leia o parágrafo anterior novamente. Tenha certeza de que você compreendeu o conceito de Contexto, Arquitetuta Lógica e Arquitetura Física.

Dois erros comuns que são cometidos em relação aos Contextos:

Esquecer de mapear as arquiteturas física e lógica para um determinado Contexto. Isso é um erro de administração de Topologia que leva a falhas de execução em um dado Contexto. Para evitar isso, garanta que todos os recursos lógicos estão mapeados para recursos físicos nesse Contexto.
Um grande erro é forçar o Contexto quando não é necessário. Nas interfaces ou nas procedures, existem caixas de seleção com a lista de Contextos, defina como “default” ou “execution context”. A não ser que seja realmente necessário forçar o contexto por uma razão funcional, deixe as caixas de seleção como estiverem. São raros os casos onde é realmente necessário forçar o Contexto.

Resumindo: Garanta que o seu entendimento sobre Contextos e Topologia esteja sólido. Defina cuidadosamente a Topologia e o mapeamento dos Contextos. Evite forçar Contextos.

Boa Prática #2 – Design Independente de Contexto

Em vários tipos de artefatos do ODI (procedures, variáveis, interfaces, etc.) é possível adicionar código 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 “código dependente de contexto”. Se você executa esse código em ambiente de produção onde a área de staging se chama PRD_STG, seu código não funciona. Perceba que os nomes dos schemas são definidos na Topologia, e os contextos acessam o schema correto dependendo do contexto de execução. Nesse caso a pergunta é: Como usar isso no seu código?

Os Métodos de Substituição (OdiRef API) existem para disponibilizar no seu código os metadados armazenados no ODI tornando o código independente de contexto. Sendo assim, eles garantem que o nome qualificado da tabela em questão será gerado de acordo com o contexto onde o código está sendo executado.

Utilizando os Métodos de Substituição, o código genérico ficaria assim:

DROP TABLE <%odiRef.getObjectName("L", "TEMP_001","W")%>.

Consulte o Substitution Methods Reference Guide para mais informações sobre como utilizar essa API. O “expression editor” também ajuda muito.

Resumindo: Tão logo você comece a digitar um nome de schema, nome de database, nome de usuário ou qualquer informação referente à um servidor ou schema, pare, respire fundo e considere utilizar um Método de Substituição.

Boa Prática #3 – Utilize Procedures Apenas Quando Necessário

As procedures permitem a execução de ações bem complexas, incluindo comandos SQL. Além disso, elas permitem a utilização das conexões source e target e ainda suportam binding. Isso significa que é possível mover dados de um lado para o outro usando apenas procedures.

Os desenvolvedores que se sentem à vontade com código SQL ficam sériamente tentados a escrever código para fazer transformações e movimentação de dados ao invés de desenvolver interfaces.

Existem alguns problemas quanto à isso:

Procedures contém código manual que precisa sofrer manutenção manualmente.
Procedures não mantém referências com os outros artefatos ODI como datastores, modelos, etc., fazendo com que a manutenção seja muito mais complexa comparado às interfaces.

Procedures nunca devem ser utilizadas para mover ou transformar dados, essas operações devem ser feitas utilizando as interfaces.

Resumindo: Quando você começar a usar procedures para mover/transformar dados provavelmente você está fazendo uso inadequado das procedures e deveria usar interfaces no lugar delas.

Boa Prática #4 – Garantir Qualidade de Dados

Às vezes o líder de projeto de integração de dados não leva em conta a qualidade dos dados. Isso é um erro comum. O processo de integração pode estar movendo e transformando lixo e propagando esse lixo para outras aplicações.

O ODI permite que a qualidade dos dados seja garantida na fonte, (source) utilizando static checks ou então durante o processo de integração antes de gravar no destino (target) utilizando flow checks. Utilizando esses dois mecanismos de checagem de dados é possível garantir a qualidade dos dados.

Resumindo: Garanta a qualidade dos dados usando os dois métodos: static checks e flow checks. Qualidade de dados não é uma opção.

Boa Prática #5 – Capturar Erros em Packages

Numa package é possível sequenciar passos de execução. Cada passo em uma package é passível de falha por qualquer razão (source ou target fora do ar, muitos registros rejeitados em uma interface, etc.).

É necessário sempre procurar prever os possíveis erros em cada passo da package.

Resumindo: As setas de “OK” (verdes) nas packages precisam existir e as setas “KO” (vermelhas) são o que tornam a sua package à prova de balas.

Boa Prática #6 – Escolha o KM correto

A escolha do KM é crítica ao desenvolver uma interface pois define quais as features estarão disponíveis e afeta também a performance de uma package.

Alguns erros comuns na escolha do KM:

Começar com KM’s complexos: Desenvolvedores iniciantes que ter suas interfaces rodando rapidamente mas às vezes não levam em conta todos os requisitos para utilizar um KM. Escolhendo, por exemplo, um LKM de uma tecnologia específica pode não funcionar por uma configuração ou instalação incorreta do loader. Uma ecolha mais segura seria começar usando KM’s mais genéricos (como KM’s de SQL) que funcionam na maioria dos casos. Depois de desenvolver suas primeiras interfaces com esses KM’s é hora de mudar para KM’s mais específicos (estude as especificações antes!).
Interfaces com excesso de engenharia: KM’s com features extras causam um custo extra de performance. Por exemplo, executar inserts é mais rápido do que executar updates incrementais. Se sua interface deleta os dados no destino antes da integração, 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 opções default do KM são suficientes para executar o KM da forma como ele foi fornecido. Após executar o KM com as opções default é sempre bom revisar e checar se alguma opção pode ser alterada de acordo com a sua necessidade. A descrição do KM é sempre uma boa opção de documentação para entender e otimizar a utilização do KM.

Resumindo: Comece com os KM’s mais simples, não se utilize de “excesso de engenharia” com KM’s complexos ou ativando opções complexas e preste atenção às opções dos KM’s.

Boa Prática #7 - Customize Seus KMs

Knowledge Modules (KMs) é um poderoso framework utilizado em cada ponto de integração no ODI. Um grande número de KM’s está disponível para utilização. Eles suportam uma grande variedade de bancos de dados. Mesmo não sendo necessário na maiorias dos casos, alguns projetos podem ter casos de uso ou requerimentos que solicitem uma customização de KM.

Então, qual deve ser o momento de customizar um KM? A resposta é: Tão logo seja detectada uma operação que precisa ser executada em várias interfaces, por exemplo, rodar um comando no target para otimização da execução.

Não é recomendado começar um KM à partir de uma folha em branco. O caminho recomendado é encontrar um KM que esteja o mais próximo possível do comportamento desejado e à partir dele, customizar de acordo com a necessidade.

Resumindo: Quando uma operação é necessária em muitas interfaces, não tenha medo de customizar um KM e criar o seu próprio KM baseado em algum já existente.

Boa Prática #8 – Organize o Seu Projeto no Início

Gerenciamento e organização podem não parecer pontos críticos quando o assunto é integração de dados, mas são.

O ODI oferece muitas ferramentas que ajudam a organizar o desenvolvimento e o ciclo de vida do projeto: perfis de segurança, projetos de desenvolvimento, pastas, marcadores, versionamento, importação/exportação, impressão da documentação em PDF, etc.

Revise e utilize todas essas ferramentas e features para gerenciar o projeto. Defina a organização do projeto, a padronização de nomes e tudo o que pode evitar o caos depois que o projetos tiver iniciado. Faça isso desde o início do projeto.

Resumindo: Mantenha alta produtividade com o ODI, é melhor ter regras de organização baseadas nas features do ODI para evitar o desenvolvimento do caos.

Boa Prática #9 – Controle os Repositórios

No ODI, um repositório master pode ter vários repositórios work. Também é possível ter vários repositórios master, cada um com seu grupo de repositórios work. Cada repositório tem um ID definido na hora da criação do repositório.

Bem, um repositório não é um documento. É “a fonte da verdade”, é a referência central entre os artefatos do ODI.

Além disso, todo objeto é identificado por um ID interno que depende do ID do repositório. Esse ID interno identifica unicamente um objeto e é utilizado pelo sistema de importação do ODI. Dois repositórios com o mesmo ID possivemente contém objetos com o mesmo ID interno, o que significa o mesmo objeto para o ODI. Transferir objetos entre esses repositórios é como copiar arquivos com o mesmo nome entre diretórios e pode fazer com que o objeto seja substituído.

Garanta que todos os repositorios sejam criados com ID’s diferentes (mesmo em sites diferentes), e defina uma documentação para o processo de mover objetos entre repositórios utilizando import/export ou versionamento.

Resumindo: A multiplicação de repositorios deve ser feita sob estrito controle e planejamento (especialmente quanto à escolha do ID do repositório), e o gerenciamento de transferências de objetos utilizando import/export ou versionamento deve ser feito por vias formais.

Boa Prática #10 – Cuidado Com o Conteúdo dos Repositórios

O ODI armazena todas as informações num repositório de metadados em um banco de dados relacional. Sabendo disso é muito tentador começar a explorar as tabelas do repositório para conseguir informações “mais rápido”.

O repositório não implementa toda a lógica que existe na interface gráfica e também não implementa toda a lógica de negócios que existe no código Java. Construir, por exemplo, dashboards ou relatórios sobre o repositório é aceitável mas escrever dados ou alterar as informações do repositório é perigoso e deve ser deixado para operações do suporte técnico da Oracle.

Resumindo: Você faria isso no banco de dados do ERP da sua empresa? Também não faça com o repositório de metadados do ODI.

Via Data Integration and Management

Twitter API via Oracle PL/SQL

wscalioni@yahoo.com.br (Willy Scalioni) — Wed, 18 Nov 2009 09:06:30 PST

Há alguns dias tive a idéia de usar algumas API's de redes sociais como Twitter e Facebook para gerar algum tipo de relatório estatístico e me parece que as API's não fornecem dados suficientes para isso. Ainda não desisti, mantenho vocês informados.

Continuei estudando um pouco mais sobre o assunto e achei um artigo interessante onde um cara que usa a API do Twitter via Oracle PL/SQL para recuperar o timeline dos seus amigos.

Uso PL/SQL há muito tempo e sempre que isso acontece, acabamos criando uma certa relação afetiva com a linguagem :-p Você que já programou sabe como é isso.

O arquivo XML recuperado contém os 20 updates mais recentes nas últimas 24 horas para o usuário autenticado e seus contatos no Twitter:

create or replace
FUNCTION get_twitter_timeline(t_user IN VARCHAR2,   t_pass IN VARCHAR2)
RETURN XMLTYPE
IS
http_req utl_http.req;
http_resp utl_http.resp;
t_update_send VARCHAR2(200);
res_value VARCHAR2(4000);
XML_RETURN CLOB;
BEGIN
t_update_send := '--head';
--utl_http.set_proxy('http://www-yourproxy.com:80'); --If you need to specify a proxy use this.
http_req := utl_http.begin_request('http://twitter.com/statuses/friends_timeline.xml',   'POST',   utl_http.http_version_1_1);
utl_http.set_response_error_check(TRUE);
utl_http.set_detailed_excp_support(TRUE);
utl_http.set_body_charset(http_req,   'UTF-8');
utl_http.set_header(http_req,   'User-Agent',   'Mozilla/4.0');
utl_http.set_header(http_req,   'Content-Type',   'application/x-www-form-urlencoded');
utl_http.set_header(http_req,   'Content-Length',   to_char(LENGTH(t_update_send)));
utl_http.set_transfer_timeout(to_char('60'));
utl_http.set_authentication(http_req,   t_user,   t_pass,   'Basic');
utl_http.write_text(http_req,   t_update_send);
http_resp := utl_http.get_response(http_req);
BEGIN
WHILE 1 = 1
LOOP
utl_http.read_line(http_resp,   res_value,   TRUE);
XML_RETURN := XML_RETURN || res_value;
END LOOP;
EXCEPTION
WHEN utl_http.end_of_body THEN
NULL;
END;
utl_http.end_response(http_resp);
return XMLTYPE(XML_RETURN);
EXCEPTION
WHEN others THEN
XML_RETURN := sqlerrm;
RAISE;
END get_twitter_timeline;

Via [ApexToday]

Do you speak Hyperion?

wscalioni@yahoo.com.br (Willy Scalioni) — Thu, 14 May 2009 12:36:09 PDT

Coisa rara é encontrar material de boa qualidade, em português, sobre ferramentas específicas de BI. Pelo menos sobre as ferramentas que eu estou acostumado a trabalhar.

Hyperion nunca foi um nome pop entre os profissionais de TI, pelo menos não antes da Oracle adquirir a empresa, mas sempre foi um nome de muito peso na sua área de atuação. Os profissionais qualificados nas ferramentas Hyperion são escassos no Brasil e pelo jeito, no mundo todo, pois nos países emergentes e nos países desenvolvidos, profissionais desse tipo tem sido contratados a peso de ouro. Só não sei por quanto tempo.

Trabalho com Hyperion Essbase desde 2003 e percebo que todos os profissionais que acabam caindo nessa área tem dificuldade de encontrar recursos e informações claras à respeito de Essbase além do Database Administrator Guide. Sim, o DBAG é um ótimo recurso técnico, mas não documenta muitas boas práticas importantíssimas para o desenvolvimento de um bom projeto de aplicações OLAP em Essbase. É bem verdade que é preciso "comer muito feijão" para compreender profundamente uma modelagem multidimensional e propor mudanças conceituais ou, mais complexo ainda, compreender do negócio do cliente e propor um modelo multidimensional eficiente, coisa que está muito antes da escolha da ferramenta.

A verdade é que eu percebo um certo receio dos profissionais Hyperion quanto à expor informações técnicas relevantes. Isso não é uma crítica, é uma constatação. Parece que alguns pensam que seu emprego está em risco se mais pessoas conhecerem a tecnologia.

Eu, particularmente, não penso assim. Toda tecnologia de qualidade tende a ser absorvida pelo mercado como aconteceu com Java, Oracle, PHP, etc, portanto, é questão de tempo até que o conhecimento sobre Hyperion, BI, OLAP, etc, esteja completamente pulverizado e mão de obra de baixa qualidade comece a pipocar por aí. Como acontece com qualquer tecnologia, existirão dois grandes grupos de profissionais:

1. Profissionais de alto nível, competentes, bem posicionados e bem remunerados.
2. E existirá uma nuvem de gente que talvez compre um livro "aprenda seiláoquê em 24 horas" porque acha que isso dá dinheiro.

Eu não me preocupo com nenhum desses grupos. Os primeiros são grandes ajudadores, são pessoas em quem os profissionais devem se espelhar quando tiverem a oportunidade de trabalhar com eles. O segundo grupo nunca incomodou os profissionais competentes que sempre vão ter espaço no mercado. Com isso quero dizer que o que motiva esse blog é a minha vontade de melhorar o meu próprio trabalho. Quero dizer que o blog ajuda a mim mesmo, a reler como realizo algumas coisas no meu trabalho. Ajuda a perceber que "faz sentido" se uma outra pessoa lê e entende o que eu procurei fazer. E espero que acabe ajudando alguém que passe por aqui procurando alguma coisa útil.

Se for útil para você também, ótimo. Qualquer dia desses tomamos um café em algum projeto por aí...