Nesta semana, daremos uma olhada nos fundamentos do Cognos Mashup Service. Vamos dividi-lo em suas partes componentes para ver como ele agrega valor à combinação de ofertas do IBM Cognos.
Para utilizar o Cognos Mashup Service, é necessário atender aos seguintes requisitos mínimos:
1. IBM Cognos BI Server 8.4.1
2. Um cliente capaz de interagir com serviços baseados em SOAP ou URL sobre HTTP
Cognos Connection e o Cognos Mashup Service podem ser acessados por meio do gateway Cognos
Nota do autor: Use a voz do ator R. Lee Ermey (Gunny de Full Metal Jacket)
Nos próximos artigos, serei seu instrutor. Você pode me chamar de “Drill Sergeant”. Vou quebrar vocês recrutas nos grãos de areia de onde vieram e reconstruí-los em pedaços de silício gravados a laser. Você sairá daqui com as ferramentas de que precisa para sobreviver no campo de batalha conhecido como Cognos Mashup Service. Você será capaz de codificar seu caminho através de terrenos de visualização personalizados perigosos. Você será capaz de distinguir amigos de inimigos quando se trata de noções de design. Você pode ter pensado que seria mimado pela promessa de serviços REST fáceis. Mas este não é o DESCANSO de sua mãe. Posso obter um “SIM SARGENTO DE BROCA!”? Agora caia e me dê vinte!
Ok, deixe-me fazer uma pausa no personagem para ser sincero. Nesta semana, daremos uma olhada nos fundamentos do Cognos Mashup Service. Vamos dividi-lo em suas partes componentes para ver como ele agrega valor à combinação de ofertas do IBM Cognos.
Para utilizar o Cognos Mashup Service, é necessário atender aos seguintes requisitos mínimos:
1. IBM Cognos BI Server 8.4.1
2. Um cliente capaz de interagir com serviços baseados em SOAP ou URL sobre HTTP
Cognos Connection e o Cognos Mashup Service podem ser acessados por meio do gateway Cognos
O Cognos Mashup Service é composto de duas partes distintas que funcionam em conjunto para permitir que os consumidores quebrem os dados do relatório fora do visualizador de relatório e em visualizações customizadas. Uma parte do serviço é a interface de transporte e a outra é a carga útil. No diagrama abaixo, podemos considerar a solicitação como o transporte e a resposta como a carga útil.
A interface de transporte é o meio pelo qual podemos invocar relatórios. Existem duas opções para os consumidores usarem. Um é baseado em SOAP e o outro utiliza URLs de estilo REST. Ambas as interfaces são executadas em HTTP e são semelhantes em estrutura. Ou seja, para cada operação lógica na interface de estilo SOAP, há uma correspondente no estilo REST. As especificações exatas do método observam as idiossincrasias para o estilo de invocação escolhido. Mas o ponto principal é ... a capacidade de fazer logon, invocar um relatório, obter a saída e fazer logoff está disponível para ambos os campos.
Então, você pode se perguntar "eu, por que escolheria um em vez do outro?" Freqüentemente, a resposta a essa pergunta se apresenta quando se olha para a tecnologia ou convenções de projetos. Veja o exemplo de um consumidor que é desenvolvido inteiramente no lado do cliente. Ele usa HTML e JavaScript para interagir com o Cognos Mashup Service. Em um vácuo, a interface baseada em URL REST tornaria uma integração mais fácil. Em contraste, outro projeto pode ter ativos Cognos SDK existentes em um servlet Java. Eles estão acostumados com os stubs SOAP expostos pelo SDK. Parece mais natural para essa situação tender a ser um consumidor de serviços de mashup baseado em SOAP. Na prática, essa não foi realmente uma escolha difícil de avaliar. Ao olhar para as duas opções, uma sempre parece se encaixar melhor quando se considera a solução geral. As tentativas de usar o outro parecem forçadas.
As operações lógicas oferecidas pela interface de transporte permitem que um consumidor execute tarefas centradas na execução de relatórios e análises do Cognos. O conjunto de opções permite que um consumidor percorra todo o ciclo de vida de execução de um relatório. Isso inclui:
• Autenticação
• Atribuição de parâmetros
• Execução de relatório (síncrono e assíncrono)
• Comportamento de treino
• Recuperação de saída
O serviço de mashup ainda oferece alguns recursos que não estão disponíveis por meio do SDK. No entanto, vamos guardar essa discussão para um próximo artigo comparando e contrastando o serviço de mashup com o SDK.
Agora temos um meio de invocar relatórios por meio de um conjunto de serviços baseado em HTTP. O que sai do outro lado? Isso nos leva ao segundo componente do serviço de mashup. Digite… ”The Payload”.
Uma das opções que podemos especificar ao invocar um relatório por meio do serviço de mashup é o formato de saída. Existem várias opções disponíveis, incluindo HTML Layout Data XML (LDX) e JSON. Existem alguns outros, mas isso cobre o espectro em abroad senso. HTML é praticamente o que você esperaria. Eles são muito semelhantes ao que se obteria de um relatório visualizado por meio do visualizador de relatório dentro do Cognos Connection. Os formatos mais promissores são LDX e JSON. Na verdade, se há um sucesso claro no Cognos Mashup Service, é a introdução desses dois formatos.
Ambos os formatos geram a saída do relatório em um formato neutro de apresentação. Isso permite que o consumidor da saída do relatório renderize as informações em qualquer visualização que possa compreender JSON ou XML. Reserve um momento para ler isso novamente.
Os dados do relatório agora estão livres das algemas colocadas nele pelo Cognos Viewer. Os dados agora podem se mover para lugares que antes eram impraticáveis. Por exemplo, os Rich Internet Applications podem usar estruturas como a API de visualização do Google ou Ext-JS para incrementar a apresentação dos dados. A integração móvel torna-se muito mais acessível à medida que a saída pode ser adaptada a esses dispositivos. Os dados do Cognos podem ser verdadeiramente combinados com dados de fontes externas. Na verdade, os dados do Cognos BI foram vistos recentemente, à solta, misturando-se com dados de um sistema de gerenciamento de conteúdo popular na mesma grade Ext-JS, nada menos! Escandaloso! O que isto significa? Nesse caso, permitiu que ambos os conjuntos de dados fossem gerenciados por meio de suas ferramentas nativas sem um processo complexo planejado para uni-los no navegador.
Abaixo está um mock up simples de baixa fidelidade ilustrando fontes de dados heterogêneas que compartilham a mesma página.
Essa flexibilidade vem com algumas desvantagens. Como estamos adiando a renderização dos dados para outra parte do aplicativo, estamos essencialmente transferindo parte do desenvolvimento que é tradicionalmente feito pelo autor do relatório para uma pessoa que é especialista na tecnologia de visualização. O esforço para entrelaçar os dados do relatório na visualização irá variar em comparação com a criação de um relatório de pixel perfeito nos estúdios Cognos tradicionais. Os planejadores de projeto precisam entender o efeito que isso tem nos cronogramas de desenvolvimento. Descobriremos que as estimativas são mais precisas quando essa nova divisão de trabalho é adotada.
Para resumir esta peça, o Cognos Mashup Service é uma adição empolgante ao arsenal de ferramentas disponíveis para o mix. Ele permite que os dados de BI vão além de apenas carimbar um , contendo um visualizador de relatório, em uma página HTML. No entanto, o tempo nos ensinou que nada é de graça. A flexibilidade de apresentação de dados prejudica a inclusão de novos conjuntos de habilidades no conjunto de soluções. Deixe essa informação ser absorvida por um tempo. Nas entradas subsequentes desta série, entraremos em maiores detalhes sobre o uso de mashup e também como ele se compara a outros candidatos à solução.
