A partir de hoje, durante as próximas semanas, colocarei post relacionados ao trabalho com javascripts
Para começar a brincadeira vai o primeiro código:
var fW = typeof getFormWarpRequest == "function" ? getFormWarpRequest() : document.forms["formWarpRequest"];
Esse script retorna o formulário utilizado pelo Cognos, é possível obter praticamente qualquer informação por ele. Serve tanto para a versão 8 quanto a 10.
Abs
sábado, 30 de julho de 2011
terça-feira, 26 de julho de 2011
Dica da Semana
Esses dias peguei um erro meio estranho no Cognos 10, rodei um relatório e apareceu uma mensagem de erro de javascript.
O pior é que era um javascript do Cognos que deu erro, um tal GUtil.js.
bom, procurando na internet achei esse link da IBM aqui, ele explica a solução para o problema com o bubble chart.
Eu tive esse problema com drills em listas mas a resolução é a mesma.
Então no Internet Explorer, vá em Ferramentas, opções e avançadas. Na parte de segurança procure por Habilitar suporte para XMLHTTP nativo e pronto.
Espero que ajude.
O pior é que era um javascript do Cognos que deu erro, um tal GUtil.js.
bom, procurando na internet achei esse link da IBM aqui, ele explica a solução para o problema com o bubble chart.
Eu tive esse problema com drills em listas mas a resolução é a mesma.
Então no Internet Explorer, vá em Ferramentas, opções e avançadas. Na parte de segurança procure por Habilitar suporte para XMLHTTP nativo e pronto.
Espero que ajude.
quarta-feira, 20 de julho de 2011
Dica da semana
Essa dica vai para quem está acostumado a utilizar a versão 8 mas por alguma conspiração do universo precisa usar a versão 10.
Como muitos, ou todos, devem saber, a versão 10 possui um novo motor gráfico e obviamente mudou tudo.
Dica 1
Você ainda pode utilizar o motor antigo, se quiser por retro-compatibilidade. Relatórios vindos de upgrades não migram o motor gráfico, é necessário marretar o trem.
Então se você precisa, ou não, utlizar o motor novo, dentro do Report Studio vá em Ferramentas, Opções e Avançado.
Check a opção Usar criação de gráficos anterior para...hum... usar a versão 8.
Uncheck a opção Usar criação de gráficos anterior para...vejamos... usar a versão 10.
Dica 2
Na versão 8, quando você queria associar uma série ao eixo secundário, você simplesmente escolhia o eixo nas propriedades daquela série, certo?
Na versão 10... advinha, mudou... você precsia selecionar o gráfico. Existe uma propriedade no gráfico chamada Combinações, nela você pode especificar o que (linhas, barras ou áreas), como (empilhado, empilhado 100% ou cluster) e onde (eixo primário, eixo secundário, etc).
Depois de definido o que, como e onde, você pode continuar normalmente a construção de seu gráfico.
Espero que ajude.
Abs.
Como muitos, ou todos, devem saber, a versão 10 possui um novo motor gráfico e obviamente mudou tudo.
Dica 1
Você ainda pode utilizar o motor antigo, se quiser por retro-compatibilidade. Relatórios vindos de upgrades não migram o motor gráfico, é necessário marretar o trem.
Então se você precisa, ou não, utlizar o motor novo, dentro do Report Studio vá em Ferramentas, Opções e Avançado.
Check a opção Usar criação de gráficos anterior para...hum... usar a versão 8.
Uncheck a opção Usar criação de gráficos anterior para...vejamos... usar a versão 10.
Dica 2
Na versão 8, quando você queria associar uma série ao eixo secundário, você simplesmente escolhia o eixo nas propriedades daquela série, certo?
Na versão 10... advinha, mudou... você precsia selecionar o gráfico. Existe uma propriedade no gráfico chamada Combinações, nela você pode especificar o que (linhas, barras ou áreas), como (empilhado, empilhado 100% ou cluster) e onde (eixo primário, eixo secundário, etc).
Depois de definido o que, como e onde, você pode continuar normalmente a construção de seu gráfico.
Espero que ajude.
Abs.
terça-feira, 19 de julho de 2011
Configurações avançadas - Burst to file system
Como configurar o Cognos para gerar relatórios em arquivos.
Relatórios em busrt(distribuição) são uma opção interessante quando se precisa criar sub-relatórios seguindo um padrão, o Cognos possibilita a geração de busrt de 3(três) formas:
1 - Geração e envio por e-mail.
2 - Geração e salvar no portal.
3 - Geração e salvar em sistema de arquivos.
Todas opções são interessantes, depende do cenário.
Nesse caso:
Archive Location File System Root, esse é o nome bicho. Essa opção está disponível no Cognos Configuration do App Tier, pode-se configurar um endereço local ou UNC com file:// na frente.
Ex.:
file:///C:/Cognos/files - Local
file://\\server1\files - UNC
file://../files - relativo a instalação do Cognos
No Cognos Configuration faça duas coias, primeiro em Action -> Edit Global Configuratios -> Aba General, coloque o caminho em "Archive Location File System Root".
Depois em Content Manager habilite a opção "Save report outputs to a file system".
Uma vez definido o diretório, é possivel acessar IBM Cognos Administration, Configurações e configurar as entradas de diretórios relativo ao definido acima.
Acesse o icone "Definir Locais de Sistema de Arquivos" e defina um nome(será exibido nas opções do busrt) novo local para a geração de arquivos e defina a segurança de quem pode gerar arquivos nessa entrada.
Tudo configurado? Faça o teste:
Rode um relatório com opções, clique em salvar, opções avançadas, e salvar no sistema de arquivos.
Obs.: Essa opção não precisa ser usada necessariamente com busrt.
Relatórios em busrt(distribuição) são uma opção interessante quando se precisa criar sub-relatórios seguindo um padrão, o Cognos possibilita a geração de busrt de 3(três) formas:
1 - Geração e envio por e-mail.
2 - Geração e salvar no portal.
3 - Geração e salvar em sistema de arquivos.
Todas opções são interessantes, depende do cenário.
Nesse caso:
Archive Location File System Root, esse é o nome bicho. Essa opção está disponível no Cognos Configuration do App Tier, pode-se configurar um endereço local ou UNC com file:// na frente.
Ex.:
file:///C:/Cognos/files - Local
file://\\server1\files - UNC
file://../files - relativo a instalação do Cognos
No Cognos Configuration faça duas coias, primeiro em Action -> Edit Global Configuratios -> Aba General, coloque o caminho em "Archive Location File System Root".
Depois em Content Manager habilite a opção "Save report outputs to a file system".
Uma vez definido o diretório, é possivel acessar IBM Cognos Administration, Configurações e configurar as entradas de diretórios relativo ao definido acima.
Acesse o icone "Definir Locais de Sistema de Arquivos" e defina um nome(será exibido nas opções do busrt) novo local para a geração de arquivos e defina a segurança de quem pode gerar arquivos nessa entrada.
Tudo configurado? Faça o teste:
Rode um relatório com opções, clique em salvar, opções avançadas, e salvar no sistema de arquivos.
Obs.: Essa opção não precisa ser usada necessariamente com busrt.
sexta-feira, 15 de julho de 2011
Javascript Freeze Panes - Congelar Paineis
Quem nunca ouviu aquela frase "Mas no excel dá!"?
Então, no Cognos Também dá.
Segue abaixo a função, encontrei essa função para isso, mas não funcionava direito, mexi um pouco nela e ficou assim.
Modo de usar:
Bom proveito!
------>>>> Código da função
Então, no Cognos Também dá.
Segue abaixo a função, encontrei essa função para isso, mas não funcionava direito, mexi um pouco nela e ficou assim.
Modo de usar:
- Crie um html itém com a função abaixo dentro da tag <script language="javascript" type="text/javascript"> FUNÇÃO </script>.
- Crie um html itém como o conteúdo <span id="t1"> imediatamente antes da lista ou crosstab.
- Crie um html itém como o conteúdo </span> imediatamente depois da lista ou crosstab.
- No final do relatório crie um html itém com o conteúdo <script language="javascript" type="text/javascript"> ScrollableTable( 't1', 600,800, 1, 2)</script>
Bom proveito!
------>>>> Código da função
quarta-feira, 13 de julho de 2011
Configurações avançadas - Roteamento de execução
Como configurar regras de roteamento de pacotes e usuários, para dispatcher específicos.
As vezes, quando o ambiente é muito grande ou existem servidores específicos para certas áreas, regras de roteamento se tornam muito, muito, úteis.
Vou dar dois cenários onde fica visível a utilização de roteamentos.
1º Cenário:
Ambiente: 2 Dispatchers (server01 e server02), 1 Gateway (server01) e um Content Manager(server01).
Obs.: Server01 e Server02 configurados em load balance.
É muito comum empresas que possuem Cognos também possuirem alguma espécie de cubo plugado ao Cognos, nesse caso também é normal que existe um compartilhamento de rede que permitar que ambos os dispatchers acessem o mesmo cubo.
Mais comum ainda é o cubo estar em um dos dispatchers e ser acessado por um compartilhamento pelo outro dispatcher.
O que acontece nesse caso?
O Server01 tem um compartilhamento file://server01/cubos que é o caminho no datasource do cubo(Cognos Connection), ou seja ambos servidores acessam o cubo pela rede.
Por experiência posso dizer que quando o dispatcher no server01 acessa o cubo cria-se uma conexão local, sem tráfego de rede, mas quando o dispatcher no server02 acessa o cubo, bom... ai o drama começa.
Lentidão e travamento são problemas que podem acontecer em função desse tráfego de rede, ainda mais se o cubo for grande.
Para solucionar esse caso existem duas possibilidades a meu ver:
1 - Duplicar os cubos em ambos servidores e criar um apontamento local para o datasource, como C:\cubos.
2 - Criar uma regra de roteamento para pacotes de cubo serem processados somente pelo server01.
A primeira opção não tem nada a ver com esse post então não vem ao caso, logo vamos a segunda.
Antes de dizer como criar uma regra de roteamento, existem algumas informações muito úteis que podem causar confusão senão explicadas.
Regras de roteamento podem ser beseadas em 3 itens, pacote(packages), funções(roles) e grupos(groups), e são direciodadas para um GRUPO de SERVIDORES.
Load balance só acontece em servidores dentro do mesmo grupo, portanto cuidado com essas configurações.
Voltando a vaca fria...
Agora que esses pontos estão claro, né? Vamos criar um regra de roteamento, depois de criar o conjunto de regras e o grupo de servidores, na tela de configuração em Administração do Portal existem um icone Especificar Regras de Roteamento, é o quarto da direita para a esquerda.
Muito simples, escolha o cojunto, grupo de servidores e voila... feito.
Voltando para o cenário:
Server01 no Grupo de Servidores Cubos
Server02 no Grupo de Servidores Relatórios
Todos pacotes de cubos definidos nos conjunto de roteamento CUBOS
Regras criadas:
Repare que foi criada uma segunda regra para o resto dos pacotes.
Mas... se você foi atento e leu o post todo, viu que isso promove a perda de load balance, pois cada servidores estará num grupo diferente.
Para resolver isso, sugiro a instalação de um novo dispatcher no server01, só o dispatcher hein!!
Dessa forma o ambiente ficaria assim:
Ambiente: 3 Dispatchers (server01:9300, server01:10300 e server02), 1 Gateway (server01) e um Content Manager(server01).
Obs.: Server01:9300 e Server02 configurados em load balance e Server01:10300 para cubos.
Assim se resolve o load balance e o problema de acesso de cubos pela rede.
No 2º cenário o caso é que temos um servidor para cada area.
Nesse caso configuramos os grupos de usuários ou funções para cada área e colocamos as pessoas dentro dele, depois criamos uma regra para cada conjunto.
Ambiente:3 Dispatchers (server01-FATURAMENTO, server02-FINANCAS e server03-ESTOQUE), 1 Gateway (server01) e um Content Manager(server01).
Então teremos:
Server01-FATURAMENTO no Grupo de Servidores Faturamento
Server02-FINANCAS no Grupo de Servidores Finanças
Server03-ESTOQUE no Grupo de Servidores Estoque
E os usuários definidos nas funções (roles) Faturamento, Finanças e Estoque, e as funções com seus conjuntos de reteamento também definidos.
Regras criadas:
Como sempre, dúvidas? Comente, email-me.
Já escrevi mais do que o planejado, fui.
As vezes, quando o ambiente é muito grande ou existem servidores específicos para certas áreas, regras de roteamento se tornam muito, muito, úteis.
Vou dar dois cenários onde fica visível a utilização de roteamentos.
1º Cenário:
Ambiente: 2 Dispatchers (server01 e server02), 1 Gateway (server01) e um Content Manager(server01).
Obs.: Server01 e Server02 configurados em load balance.
É muito comum empresas que possuem Cognos também possuirem alguma espécie de cubo plugado ao Cognos, nesse caso também é normal que existe um compartilhamento de rede que permitar que ambos os dispatchers acessem o mesmo cubo.
Mais comum ainda é o cubo estar em um dos dispatchers e ser acessado por um compartilhamento pelo outro dispatcher.
O que acontece nesse caso?
O Server01 tem um compartilhamento file://server01/cubos que é o caminho no datasource do cubo(Cognos Connection), ou seja ambos servidores acessam o cubo pela rede.
Por experiência posso dizer que quando o dispatcher no server01 acessa o cubo cria-se uma conexão local, sem tráfego de rede, mas quando o dispatcher no server02 acessa o cubo, bom... ai o drama começa.
Lentidão e travamento são problemas que podem acontecer em função desse tráfego de rede, ainda mais se o cubo for grande.
Para solucionar esse caso existem duas possibilidades a meu ver:
1 - Duplicar os cubos em ambos servidores e criar um apontamento local para o datasource, como C:\cubos.
2 - Criar uma regra de roteamento para pacotes de cubo serem processados somente pelo server01.
A primeira opção não tem nada a ver com esse post então não vem ao caso, logo vamos a segunda.
Antes de dizer como criar uma regra de roteamento, existem algumas informações muito úteis que podem causar confusão senão explicadas.
Regras de roteamento podem ser beseadas em 3 itens, pacote(packages), funções(roles) e grupos(groups), e são direciodadas para um GRUPO de SERVIDORES.
- Para configurar um grupo de servidores acesse as propriedades de um Dispatcher em Administração do Portal -> Configuração.
Load balance só acontece em servidores dentro do mesmo grupo, portanto cuidado com essas configurações.
- Para configurar pacotes, funções ou grupos, acesse as propriedades do objeto, e na parte inferior da tela defina um conjuto de roteamento.
Voltando a vaca fria...
Agora que esses pontos estão claro, né? Vamos criar um regra de roteamento, depois de criar o conjunto de regras e o grupo de servidores, na tela de configuração em Administração do Portal existem um icone Especificar Regras de Roteamento, é o quarto da direita para a esquerda.
Muito simples, escolha o cojunto, grupo de servidores e voila... feito.
Voltando para o cenário:
Server01 no Grupo de Servidores Cubos
Server02 no Grupo de Servidores Relatórios
Todos pacotes de cubos definidos nos conjunto de roteamento CUBOS
Regras criadas:
| Sequencia | Conjunto de Reteamento Pacote | Conjunto de Reteamento Grupo | Conjunto de Reteamento Função | Grupo de Servidores |
| 1 | CUBOS | Qualquer | Qualquer | Cubos |
| 2 | Qualquer | Qualquer | Qualquer | Relatórios |
Repare que foi criada uma segunda regra para o resto dos pacotes.
Mas... se você foi atento e leu o post todo, viu que isso promove a perda de load balance, pois cada servidores estará num grupo diferente.
Para resolver isso, sugiro a instalação de um novo dispatcher no server01, só o dispatcher hein!!
Dessa forma o ambiente ficaria assim:
Ambiente: 3 Dispatchers (server01:9300, server01:10300 e server02), 1 Gateway (server01) e um Content Manager(server01).
Obs.: Server01:9300 e Server02 configurados em load balance e Server01:10300 para cubos.
Assim se resolve o load balance e o problema de acesso de cubos pela rede.
No 2º cenário o caso é que temos um servidor para cada area.
Nesse caso configuramos os grupos de usuários ou funções para cada área e colocamos as pessoas dentro dele, depois criamos uma regra para cada conjunto.
Ambiente:3 Dispatchers (server01-FATURAMENTO, server02-FINANCAS e server03-ESTOQUE), 1 Gateway (server01) e um Content Manager(server01).
Então teremos:
Server01-FATURAMENTO no Grupo de Servidores Faturamento
Server02-FINANCAS no Grupo de Servidores Finanças
Server03-ESTOQUE no Grupo de Servidores Estoque
E os usuários definidos nas funções (roles) Faturamento, Finanças e Estoque, e as funções com seus conjuntos de reteamento também definidos.
Regras criadas:
| Sequencia | Conjunto de Reteamento Pacote | Conjunto de Reteamento Grupo | Conjunto de Reteamento Função | Grupo de Servidores |
| 1 | Qualquer | Qualquer | Faturamento | Faturamento |
| 2 | Qualquer | Qualquer | Finanças | Financas |
| 3 | Qualquer | Qualquer | Estoque | Estoque |
Como sempre, dúvidas? Comente, email-me.
Já escrevi mais do que o planejado, fui.
terça-feira, 12 de julho de 2011
Customizing - Custom Chart Palette
Alterando a paleta de cores pré-definda dos gráficos.
As vezes, quase nunca, uma empresa decide que os relatórios e o portal do Cognos devem coincidir com identidade da empresa e para tal, é necessário alterar o esquema de cores de tudo (relatório, gráficos, crosstabs, etc).
Eis que para facilitar nossa vida, existe um arquivo chamado ChartPalettes.xml que contém as informações das paletas para versão 8 e um reportPresents.xml complementar para versão 10.
Quem já viu a versão 10 provavelmente agradeceu muito a IBM, pois os gráficos melhoraram muito todavia o XML mudou um pouco...ficou mais difícil mas ainda dá.
Na versão 8 o arquivo ChartPalettes.xml fica localizado em webcontent/pat/res, alterou, está pronto.
Na versão 10 existem tres arquivos, procure os arquivos ChartPalettes.xml e reportPresents.xml no caminho acima, o outro em webcontent\flex.
Importante, alguns arquivos as cores estão definidas em hexadecimal (#FF0000 = vermelho), em outros estão em decimal (255,0,0 = vermelho).
Fora isso, ainda deve-se alterar os arquivos reportstudio_xx.xml, eles contêm as traduções dos IDs, faça um trabalho bem feito e crie IDs e imagens com o padrão e não reutilize nada.
Importante faça o BACKUP dos arquivos.
Veja o PDF oficial para versão 8 aqui.
Logo menos outras informações de customizing...
Abs.
As vezes, quase nunca, uma empresa decide que os relatórios e o portal do Cognos devem coincidir com identidade da empresa e para tal, é necessário alterar o esquema de cores de tudo (relatório, gráficos, crosstabs, etc).
Eis que para facilitar nossa vida, existe um arquivo chamado ChartPalettes.xml que contém as informações das paletas para versão 8 e um reportPresents.xml complementar para versão 10.
Quem já viu a versão 10 provavelmente agradeceu muito a IBM, pois os gráficos melhoraram muito todavia o XML mudou um pouco...ficou mais difícil mas ainda dá.
Na versão 8 o arquivo ChartPalettes.xml fica localizado em webcontent/pat/res, alterou, está pronto.
Na versão 10 existem tres arquivos, procure os arquivos ChartPalettes.xml e reportPresents.xml no caminho acima, o outro em webcontent\flex.
Importante, alguns arquivos as cores estão definidas em hexadecimal (#FF0000 = vermelho), em outros estão em decimal (255,0,0 = vermelho).
Fora isso, ainda deve-se alterar os arquivos reportstudio_xx.xml, eles contêm as traduções dos IDs, faça um trabalho bem feito e crie IDs e imagens com o padrão e não reutilize nada.
Importante faça o BACKUP dos arquivos.
Veja o PDF oficial para versão 8 aqui.
Logo menos outras informações de customizing...
Abs.
sexta-feira, 8 de julho de 2011
Dica da semana
Relatório lento? DMR, Relacional ou OLAP?
- DMR
Coisa feia.. mas funciona basicamente como um cubo, tanto que MDX funciona.
Se seu relatório é em DMR e está lento, procure verificar o tamanho das tabelas envolvidas, esse modo foi desenvolvido para tratar de tabelas pequenas, agregadas, em tabelas muito grandes considere a abordagem normal.
- Relacional
Ai o bixo pega, pois podem ser muitos fatores, creio que os mais comuns são falta de índices e utilização de funções de aplicação logo de cara.
Sempre que for fazer um relatório, leve para a query somente o que for estar visível ou necessário para agregações, tenha certeza de que os relacionamentos estão bem feitos e analise a query para conferir.
Faça uma consulta paralela ao banco e compare os tempos do relatório e do banco, não pode ser muito diferente.
Funções como total( ... for) dificilmente são aplicadas no banco, e são geralmente tratadas na aplicação(servidor cognos), se forem utilizadas na primeira query farão um belo estrago, trazendo muito mais informação do que o necessário para só depois agregar, nesse caso, faça subqueries e só utilize essas funções depois que o nível de agregação do banco já foi feito.
- OLAP(Cubos)
Isso serve para todos os cubos MSAS, PowerCube, etc
Não faça detail filters, pois funciona como funções de aplicação, que antes de filtrar trazem todos os dados do cubo, e isso pesa pacas!!
Utilize slicers(filtros de contexto) e a função filter, que são muito mais performáticas.
Dúvidas? E-mail me!
- DMR
Coisa feia.. mas funciona basicamente como um cubo, tanto que MDX funciona.
Se seu relatório é em DMR e está lento, procure verificar o tamanho das tabelas envolvidas, esse modo foi desenvolvido para tratar de tabelas pequenas, agregadas, em tabelas muito grandes considere a abordagem normal.
- Relacional
Ai o bixo pega, pois podem ser muitos fatores, creio que os mais comuns são falta de índices e utilização de funções de aplicação logo de cara.
Sempre que for fazer um relatório, leve para a query somente o que for estar visível ou necessário para agregações, tenha certeza de que os relacionamentos estão bem feitos e analise a query para conferir.
Faça uma consulta paralela ao banco e compare os tempos do relatório e do banco, não pode ser muito diferente.
Funções como total( ... for) dificilmente são aplicadas no banco, e são geralmente tratadas na aplicação(servidor cognos), se forem utilizadas na primeira query farão um belo estrago, trazendo muito mais informação do que o necessário para só depois agregar, nesse caso, faça subqueries e só utilize essas funções depois que o nível de agregação do banco já foi feito.
- OLAP(Cubos)
Isso serve para todos os cubos MSAS, PowerCube, etc
Não faça detail filters, pois funciona como funções de aplicação, que antes de filtrar trazem todos os dados do cubo, e isso pesa pacas!!
Utilize slicers(filtros de contexto) e a função filter, que são muito mais performáticas.
Dúvidas? E-mail me!
Tudo tem um início.
Eis o primeiro post do blog, sem nada para ninguem ver...
Logo estarei postando coisas, é.. coisas sobre esse tal de Cognos que hoje é IBM.
Versões 8.2, 8.4.1 e 10, que são as que estão na moda.
E uns pitacos de banco...
Aguardem.
Logo estarei postando coisas, é.. coisas sobre esse tal de Cognos que hoje é IBM.
Versões 8.2, 8.4.1 e 10, que são as que estão na moda.
E uns pitacos de banco...
Aguardem.
Assinar:
Postagens (Atom)