Posts com Tag ‘Camada Semântica’

Sabe aquele relatório que cisma em NÃO executar com uma performance compatível com o seu banco de dados? Seus dashoboards demoram um “zilhão” de anos para abrirem e a navegação entre as páginas é péssima? O OBIEE está inutilizável mesmo com um servidor “parrudo”? Saibam quais os principais erros ao se implementar o Oracle Business Intelligence EE 11g (OBIEE 11g) e como corrigi-los a tempo para salvar seu projeto.

Eu, Felipe Idalgo juntamente com o INBA, convidamos você a participar desta super palestra com muitas dicas, truques e macetes.

LOCAL: SALA ONLINE (Se inscreva, é gratuito) DATA: 20/Agosto Horário: das 16h as 17h

CONABI

Anúncios

Olá Pessoal, hoje venho aqui passar um procedimento bastante simples mas que todo mundo um dia já teve dúvidas a respeito, o de implantação de repositórios de metadados do OBIEE.

O repositório de metadados do OBIEE, também conhecido como RPD pela sua extensão (.rpd), nada mais é do que um arquivo que armazena metadados do Oracle Business Intelligence. Estes metadados armazenados definem as estruturas que iremos consumir através da ferramenta de apresentação como esquemas físicos de banco, arquivos, esquemas lógicos, mapeamentos físico-lógico e outras estruturas mais.

A implantação deste arquivo é necessária para que as fontes de dados possam ser consumidas através dos serviços de apresentação (Ex.: criando uma análise, painél e etc).

Para realizar a implantação de um RPD, siga os passos abaixo:

Com os serviços do OBIEE iniciados, abra o navegador e digite http://obiee:7001/em para acessar o EM (Enterprise Manager);

1

Coloque o usuário e senha de administração do ambiente;

Após carregar a página do EM, expanda no canto esquerdo da tela a seção “business intelligence” e depois clique em “coreapplication”;

2

Agora já na guia “Visão Geral”, clique em “Interromper” para interromper os serviços dos componentes do OBIEE;

3

Clique em “sim”;

4

5

6

Agora vá na guia “Implantação” e clique na sub-aba “Repositório”;

7

Clique em “Bloquear e Editar configuração”.

8

9

10

Clique em “selecionar arquivo”, selecione o seu repositório, coloque a senha do repositório;

11

Clique em “aplicar” e depois em “ativar alterações”;

12

14

16

Vá na guia “Visão Geral”;

17

Agora clique em “Iniciar”.

 

 

18

19

20

Abraços Pessoal

Felipe Idalgo

 

banner_treinamento

Fala Galera, tudo bom???

Gostaria primeiramente de desejar um ótimo 2013 a todos!!!!

Hoje estou aqui para falar sobre hierarquias do tipo pai-filho.

Este tipo de hierarquia se difere da baseada em nível pelo fato dos níveis não estarem dispostos em colunas separadas (níveis fixos), todos os níveis tem o mesmo tipo e estão dispostos em uma mesma coluna e seus níveis são definidos em tempo de execução.

Para a realização deste “LAB”, utilizaremos o modelo físico a seguir:

No modelo acima, minha dimensão de Classe possui uma hierarquia do tipo pai-filho definida pelas colunas SK_CLASSE (membros da hierarquia) e SK_CLASSE_PAI (definição nos níveis), utilizaremos estas 2 colunas para gerar a hierarquia.

Após todo o mapeamento pronto, clique sob a tabela lógica “DM Classe 1g” com o direito do mouse e crie uma dimensão lógica do tipo pai-fiho como exibido na imagem abaixo:

Passo-a-passo para configuração da hierarquia

1 – Defina o nome da sua hierarquia , qual coluna contém os membros (Member key) dessa hierarquia e qual coluna contém os níveis (Parent Column);

Obs.: por default o OBI preenche o seu member key com a chave primária da tabela de dimensão.

Caso queira alterá-lo, basta clica r em procurar a direita do campo “Member Key”.

E nessa nova tela, selecionar a chave desejada.

2 – Definir a coluna com a informação dos níveis

No nosso caso, a coluna que contém a informação dos níveis é a SK_CLASSE_PAI, para defini-la, clique em procurar a direita de Parent Column e selecione a coluna SK_CLASSE_PAI.

.

3 – Definição da Tabela de relacionamento pai-filho

A tabela de relacionamento pai-filho serve para resolver dinamicamente os níveis de sua hierarquia

Clique em configuração pai-filho.

Clique em criar uma nova tabela de relacionamento pai-filho.

Neste primeiro passo de definição da tabela de relacionamento pai-filho, vamos informar o nome e local para os scripts de criação e população desta tabela e após isso clique em “próximo”.

Informe o nome que terá a sua tabela de relacionamento, tanto no banco de dados como em seu repositório e clique em “próximo”.

Após essa definição, o OBI gera os scripts que deverão ser executados no banco de dados. Você pode visualiza-los no diretório de destino que informou acima ou clicando em “Exibir Script” como demonstrado abaixo.

Clique em “finalizar”.

Após a definição da tabela de relacionamento pai-filho, verifique se as colunas desta tabela foram referenciadas de forma correta.

Por padrão estas colunas são definidas da seguinte forma

MEMBER KEY – Chave do membro da hierarquia

ANCESTOR_KEY – Nível pai do membro da hierarquia

DISTANCE – Distância entre o membro da hierarquia e o membro pai

IS_LEAF – Flag que identifica se o membro é o ultimo nível da hierarquia

Clique em OK para concluir a criação da hierarquia.

Após a criação da hierarquia do tipo pai-filho, você poderá visualiza-la na camada lógica do seu repositório.

Confira também se sua tabela de relacionamento pai-filho foi criada na camada física como mostrado abaixo.

4 – Após a criação de sua hierarquia precisamos alterar o modelo para fazer a inclusão da tabela de relacionamento pai-filho

Selecione na camada física a dimensão de classe já existente, a tabela de relacionamento pai-filho que acabamos de criar, a tabela de fatos utilizada e exiba os relacionamento entre estas 3 tabelas.

Note que a tabela que acabamos de criar não está ligada a nenhuma outra tabela.

Precisamos então deletar a junção direta entre a dimensão de classe e a tabela de fatos e posicionar a tabela de relacionamento pai-filho entre as 2 outras

.

Crie agora um relacionamento entre a tabela de relacionamento pai-filho e a tabela de fatos utilizando a chave do membro da hierarquia e um relacionamento entre a tabela de dimensão e a tabela de relacionamento pai-filho utilizando a chave do pai do membro (ANCESTOR_KEY) de sua hierarquia como nas imagens abaixo:

.

Após realizado os joins, o relacionamento entre estas 3 tabelas deverá ficar como apresentado abaixo:

.

Após a conclusão das alterações na camada física, precisamos adicionar na LTS (Logical Table Source) de nossa tabela de dimensões a nossa tabela de relacionamento pai-filho.

Para isso, na camada lógica, expanda o source da tabela de dimensão DM Classe 1g e clique 2 vezes sobre a origem dela para editá-la.

Clique em adicionar uma tabela física a origem lógica

E, em seguida, selecione a tabela de relacionamento pai-filho que acabamos de criar

Clique em OK para finalizarmos os ajustes de modelo.

5 – Criação e carga da tabela de relacionamento pai-filho no banco de dados

Após os ajustes no modelo, temos que criar e popular nossa tabela de relacionamento pai-filho no banco de dados.

Execute primeiramente o script de criação da tabela, como segue abaixo.

Após a criação da tabela, execute o script de carga como segue abaixo

Obs.: a tabela deve ser criada no mesmo schema de banco usando no connection pool do seu modelo.

6 – Validação do Procedimento

Após disponibilizar nossa dimensão (hierarquia pai-filho) na camada de apresentação para que possamos utilizar o objeto em reports, prompts e etc, entre no OBI e renove os metadados

Se o procedimento foi executado com sucesso, poderemos então visualizar a hierarquia criada

Abraços

Felipe Idalgo

 

banner_treinamento

Pessoal, uma ótima tarde a todos!!!!

Depois de algum tempo sem postar, devido a grande demanda de trabalho… estou aqui novamente para compartilhar com vocês um trabalho realizado recentemente em parceria com nosso grande colaborador Tiago Dib.

O trabalho se consiste na migração do OBI 11.1.1.3 para a release 11.1.1.6.2 BP1

*** os passos para realizar a migração estão condicionados ao tipo de desenvolvimento que você tem em seu ambiente

Esta migração pode ser realizada de 2 formas, são elas:

1) In-Place

– Esta modalidade é realizada diretamente no host onde a aplicação antiga está alocada;

– Enquanto o procedimento de upgrade de release estiver sendo realizado, o servidor do OBI ficará inativo;

– Existem utilitários que automatizam grande parte do procedimento.

2) Out-of-Place

– Esta modalidade é realizada em um novo host;

– Enquanto o procedimento de upgrade de release estiver sendo realizado, o servidor do OBI permanecerá ativo;

– O procedimento quase em sua totalidade é executado manualmente.

Como em nosso cliente o servidor de HML é compartilhado com o DSV, optamos por utilizar a migração Out-of-Place, dessa maneira não impactaríamos nos desenvolvimentos que estavam ocorrendo paralelamente.

Step-by-Step

A saber, precisamos realizar os seguintes passos para executar esse tipo de migração:

1) Instalação do ambiente OBI na versão 11.1.1.6.0;

2) Aplicação dos patchs disponíveis para essa versão (hoje já temos o patch que atualiza a release para a 11.1.1.6.2 BP1);

3) Migração dos usuários, grupos e roles para o weblogic 10.3.6;

4) Migração do RPD para a versão 11.1.1.6.X;

5) Migração e upgrade do webcat para a versão 11.1.1.6.X;

6) Atualização dos GUID’s dos usuários e roles.

Após a instalação e aplicação dos patchs, vamos para a migração dos usuários, grupos e roles para o weblogic 10.3.6.

"passos 1 e 2 já concluídos"

3) Migração dos usuários, grupos e roles para o weblogic 10.3.6

Para realizar a migração dos usuários e grupos basta acessar o weblogic, entrar no menu de segurança e exportar as definições para a location informada.

Após isso, você deve entrar no ambiente de destino e realizar a importação das definições

Quando a importação estiver concluída, você poderá ver os usuários e grupos na aba “Usuários e Grupos”.

Após realizar a migração das definições dos usuários e grupos da aplicação, você precisará realizar a migração das roles de policys de ambiente. Isso deve ser executado no ambiente de destino

– Realize o backup do arquivo system-jazn-data.xml localizado em {Middleware_Home}/user_projects/domains/bifoundation_domain/config/fmwconfig;

– Crie 2 diretórios temporários que deverão conter o system-jazn-data.xml de origem e destino. Para a nossa migração assumimos os diretórios 11.3 (origem) e 11.6 (destino);

– Copie o system-jazn-data.xml de origem para o diretório 11.3 e o do destino para o diretório 11.6;

– Crie o arquivo jps-config-policy.xml com o seguinte conteúdo lembrando que o caminho do srcpolicystore e do policystore devem estar de acordo com a location dos seus arquivos

– Execute o WLST.sh (weblogic scripting tool) localizado em {Middleware_Home}/Oracle_BI1/common/bin

Após iniciado, execute o comando abaixo para realizar o merge dos system-jazn-data.xml

migrateSecurityStore(type=”appPolicies”, srcApp=”obi”, configFile=”/home/weblogic/migracao/jps-config-policy.xml”, src=”sourceFileStore”, dst=”targetFileStore”, overWrite=”false”)

*** não se esqueça de informar o caminho correto do jps-config-policy.xml

– Substitua o system-jazn-data.xml original pelo atualizado e reinicie todos os serviços.

4) Migração do RPD para a versão 11.1.1.6.X

O RPD da versão 11.1.1.3 é compatível com a nova release, porém sugiro antes de realizar o procedimento de deploy abri-lo no AdminTool 11.1.1.6, executar o “check consistency” e salvar um cópia, e então faça o deploy dessa cópia no EM

5) Migração e upgrade do webcat para a versão 11.1.1.6.X

Para realizar a migração do webcat, basta fazer a cópia física dos objetos para o novo servidor e executar o upgrade.

Para executar o upgrade, após o novo webcat já estar configurado no instanceconfig.xml, baixe o presentation server, altere a tag <UpgradeAndExit>false</UpgradeAndExit>

para <UpgradeAndExit>true</UpgradeAndExit> e inicie novamente o presentation sever.

Você pode acompanhar o upgrade do webcat pelo log webcatupgradeX.log localizado em /$Instance_Home$/diagnostics/logs/OracleBIPresentationServicesComponent/coreapplication_obipsX/

Após a conclusão do webcat upgrade, o serviço do presentation server irá cair sozinho, então volte a alteração feita no instanceconfig.xml e inicie novamente o presentation server.

6) Atualização dos GUID’s dos usuários e roles

Após realizado o upgrade do webcat, precisamos atualizar o identificador global único dos usuários e roles. Os passos necessários para a execução dessa tarefa são:

– com todos os serviços no ar, edite o arquivo NQSCONFIG.INI e altere a parametrização da tag FMW_UPDATE_ROLE_AND_USER_REF_GUIDS para YES

– edite o arquivo instanceconfig.xml e inclua a tag <UpdateAccountGUIDs>UpdateAndExit</UpdateAccountGUIDs> abaixo de<UpgradeAndExit>false</UpgradeAndExit>

– execute o restart do OPMN, desfaça as alterações feitas anteriormente e execute o restart do OPMN novamente

Espero que tenham gostado!!!!

Abraços a todos, não se esqueçam de nos seguir e se cadastrar em nosso FORUM

Felipe Idalgo

O dicionário de metadado é um conjunto estático de documentos XML que descrevem objetos de metadados, tais como uma coluna ou uma pasta, incluindo suas propriedades e relacionamentos com outros objetos. Um dicionário de metadados pode ajudar os usuários a obter mais informações sobre os objetos e seus atributos mapeados na camada semântica.

Para disponibilizar o acesso ao dicionário é necessário fazer a seguinte alteração no arquivo instanceconfig.xml do BI Presentation services.

Abra o arquivo

“%OBIEE_HOME%/instances/instance1/config/OracleBIPresentationServicesComponent/coreapplication_obips1/

instanceconfig.xml”

E adicione a seguinte entrada entre as tags <WebConfig> e reinicie o OBIEE.

<WebConfig>
<ServerInstance>
<SubjectAreaMetadata>
<DictionaryURLPrefix> /analyticsRes/metadado/</DictionaryURLPrefix>
</SubjectAreaMetadata>
</ServerInstance>
</WebConfig>

Fisicamente, no servidor este diretório esta localizado no seguinte caminho:

“%OBIEE_HOME%/instances/instance1/bifoundation/OracleBIPresentationServicesComponent/coreapplication_obips1/

analyticsRes”

Para gerar o dicionário de metadado realize os seguintes passos:

  1. Abra o repositório em modo off-line usando o BI Administration Tools, click em “Ferramentas -> Utilitários” e selecione “Gerar Dicionário de Metadado” e click em Executar.

Selecione a pasta para salvar o dicionário de metadados e clique em OK. Após a criação bem sucedida, a mensagem mostra a localização dos metadados.

  1. Copiar a pasta do dicionário de metadado gerada para o servidor no seguinte diretório:

“/%OBIEE_HOME/instances/instance1/bifoundation/OracleBIPresentationServicesComponent/coreapplication_obips1/

analyticsRes/metadado/BI_LAB1”

  1. Testando o acesso ao Dicionário deMetadados.

Logar no BI Analytics (http:/hostname:9704/analytics) e selecione Novo > Analise > selecione área de assunto. O ícone marcado com circulo abaixo deve aparecer.

Uma página semelhante abaixo é mostrada:

Pronto, a configuração esta realizada.

Abs.
Alan Viegas

Galera, uma ótima tarde a todos, aposto que todo mundo já está querendo ir embora pra curtir o final de semana, mas… não poderia deixar que vocês fossem sem aprender uma nova técnica de migração de objetos do catalogo web.

O procedimento é bem simples, ele se consiste resumidamente em salvar um objeto do catalogo de origem na sua máquina local e fazer upload dele no catalogo de destino.

Para isso, siga os passo abaixo:

1 – Abra o OBIEE no ambiente de origem (de onde quer fazer o exports) e acesse o catalogo web

2 – Utilize a área superior esquerda (“Pastas”) para navegar até o diretório onde se encontra a análise que você irá exportar;

3 – Após navegar até a análise, selecione-a e clique em compactar (ARCHIVE) na área “Tarefas”;

4 – Marque as opções para exportar as permissões aplicadas e a data/horário de criação da consulta;

5 – Salve a consulta em seu computador;

Obs.: por padrão a consulta será salva na pasta DOWNLOADS

6 – Entre no ambiente que deseja implementar as análises, navegue pelo catalogo web até o diretório que deseja fazer o deploy na área de “Tarefas” e clique em descompactar (UNARCHIVE);

7 – Selecione o arquivo que você exportou do ambiente de origem e marque as opções de não substituir e criar uma nova análise como demonstrado na figura abaixo;

8 – Por fim, como podem ver a análise foi criado com sucesso no ambiente de destino.

Espero que tenham gostado e não se esqueçam de de seguir nosso blog e deixar seus comentários e dúvidas

Abraços,
Felipe Idalgo

Fala Galerinha do Mal..rsss, uma amiga hoje me acionou com uma dúvida sobre a possibilidade de se alterar o formato (orientação) de exportação PDF de um relatório de retrato para paisagem.

Montei um passo-a-passo bem simplificado de como fazer isso.

*** essa configuração é válida para toda página (aba).

1 – Edite o dashboard e navegue até a página que quer fazer a configuração;

2 – Clique em ferramentas na parte superior direita da página e após em “PDF e propriedade de impressão”;

3 – Nesta tela você tem as configurações disponíveis para impressão e exportação de relatórios PDF como descrito abaixo da imagem

Configurações da Página

– Tamanho do Papel (define o tamanho do papel utilizado na impressora)

– Orientação (define o formato da impressão)

– Imprimir linhas (define se serão impressas somente linhas exibidas no relatório ou se serão impressas todas as linhas)

– Ocultar Margens (oculta as margens da impressão)

Cabeçalho e Rodapé

– Incluir Cabeçalho (exibe informações definidas no cabeçalho com possíveis customiação)

– Incluir Rodapé (exibe informações definidas no rodapé com possíveis customiação)

4 – Para definir o tipo de impressão/exportação PDF como paisagem, basta definir o campo “orientação” como paisagem;

E… Bom Proveito…

Abraços,

Felipe Idalgo