Criando Soluções PentahoVersão 1.1 Milestone 5

18 de Maio de 2006

Copyright © 2006 Pentaho Corporation. Redistribuição permitida. Todas as marcas registradas são de propriedade de seus respectivos donos. Para as últimas informações, visite nosso web site www.pentaho.org

Sumário Introdução ................................................................................................................................................. 1 Workflow no Centro ................................................................................................................................. 1 Arquitetura O ientada a Serviços (Serviço-Orien ed Arquitetura, SOA)r t ........................................... 2 Integração de Processos ......................................................................................................................... 2 Regras, Regras, Regras ........................................................................................................................... 2 Fronteira entre Business intelligence e Processos de Negócio .......................................................... 2 Estudo de Caso ......................................................................................................................................... 2 Solução 1: Entregue o que eles pedem ................................................................................................ 3 Solução 2: Entregue o que eles precisam............................................................................................. 3 Conclusão................................................................................................................................................... 3 Audiência ................................................................................................................................................... 5 Introdução ao Mecanismo de Solução................................................................................................... 5 Sequência de Ação ................................................................................................................................... 8 Um Exemplo Mais Complicado.............................................................................................................. 10 Recapitulando a Sequência de Ação .................................................................................................... 11 URL ........................................................................................................................................................... 12

Chamada de Web Serviço.................................................................................................................. 12 Chamada Java......................................................................................................................................... 12 Visão Geral............................................................................................................................................... 16

Introdução............................................................................................................................................ 16 Convenções e Pressupostos Gerais ................................................... Error! Bookmark not defined.

Integrando Relatórios JFreeReport ......................................................... Error! Bookmark not defined. Definições do JFreeReport .................................................................. Error! Bookmark not defined. Criando a Sequência de Ação............................................................. Error! Bookmark not defined. Setup do Driver JDBC .......................................................................... Error! Bookmark not defined. Verificando a Integração do JFreeReport no Pentaho .................... Error! Bookmark not defined.

Integrando Relatórios BIRT...................................................................... Error! Bookmark not defined. Definições de Relatório Eclipse BIRT ................................................ Error! Bookmark not defined. Criando a Sequência de Ação............................................................. Error! Bookmark not defined. Setup do JDBC...................................................................................... Error! Bookmark not defined. Verificando a Intagração do BIRT Integration ao Pentaho............ Error! Bookmark not defined.

Integrando o JasperReports..................................................................... Error! Bookmark not defined. Definições de Relatório JasperReports.............................................. Error! Bookmark not defined. Criando a Sequência de Ação............................................................. Error! Bookmark not defined. Setup do JDBC...................................................................................... Error! Bookmark not defined. Verificando a Integração do JasperReports ao Pentaho ................ Error! Bookmark not defined. ChartComponent ................................................................................................................................. 30 CategoryDatasetComponent.............................................................................................................. 33

Ações ........................................................................................................................................................ 35

Gatilhos (Triggers).................................................................................................................................. 39 Exceções (Misfires)............................................................................................................................ 41

MDXLookupRule .................................................................................................................................. 44 SQLLookupRule ................................................................................................................................... 46

Tipos de Dados das Sequências de Ação ............................................................................................ 52 Tipos de Recursos das Sequências de Ação ....................................................................................... 54 Definições de Componentes.................................................................................................................. 55

HelloWorldComponent........................................................................................................................ 55 componente-name: HelloWorldComponent .................................................................................... 55 EmailComponent ................................................................................................................................. 56 componente-name: EmailComponent.............................................................................................. 56 JavascriptRule...................................................................................................................................... 57 componente-name: JavascriptRule .................................................................................................. 57 SQLLookupRule ................................................................................................................................... 58 componente-name:.SQLLookupRule ................................................................................................ 58 PrintComponent................................................................................................................................... 59 componente-name: PrintComponent ............................................................................................... 59 JobSchedulerComponent ................................................................................................................... 60 SchedulerAdminComponent .............................................................................................................. 60 BIRTReportComponent ...................................................................................................................... 60 JasperReportsComponent ................................................................... Error! Bookmark not defined. ContentRepositoryCleaner ................................................................................................................. 60 componente-name: ContentRepositoryCleaner .............................................................................. 60 SubActionComponent ......................................................................................................................... 61 componente-name: ContentRepositoryCleaner .............................................................................. 61

Pág 1

Abordagem Orientada a Solução Introdução Em nossa experiência ajudando clientes a criar sistemas analíticos, encontramos situações similares muitas vezes. O cenário sempre é diferente, mas a necessidade é sempre a mesma: um relatório é entregue ou uma situação particular é encontrada nos dados e algo específico precisa acontecer – uma decisão precisa ser tomada, causas devem ser descobertas ou processos iniciados. Nestes casos, a apresentação da informação, análise e entrega (BI) é parte de um processo maior. Este processo existe para resolver um problema de negócio. Esclarecendo: • Em geral, a solução para um problema de negócio é um processo que inclui Business intelligence. • Então: o Business intelligence, por si só, não é a solução para o problema. • Se o Business intelligence é parte do processo, as ferramentas de Business intelligence são também parte

do processo. • A ferramenta de Business intelligence que não entende processo será difícil de integrar na solução. A Plataforma Pentaho BI é a primeira plataforma de Business intelligence totalmente orientada a processos e a soluções. Como podemos demonstrar esta afirmativa?

Workflow no Centro A Plataforma Pentaho BI tem várias opções para executar atividades. O mecanismo padrão de execução é um seqüenciador de fluxos enxuto. Este seqüenciador permite ao desenvolvedor construir soluções a partir de coleções de fluxos, geralmente lineares e sucessivas, utilizando parâmetros e alguns mecanismos de looping. Por exemplo: rodar a consulta para encontrar quais departamentos estão acima do orçamento, rodar o relatório para cada departamento, e enviar email de cada relatório para o gerente do departamento. Quando o negócio requisitar interação do usuário, tarefas em paralelo, deadlines e tratamento de erros, existe suporte para utilizar um amplo mecanismo de workflow. O mecanismo de workflow utiliza a language XML Process Definição Language (XPDL) para executar os Fluxos no sistema. Um exemplo deste tipo de solução seria um processo de contratação de Recursos humanos novos onde múltiplos departamentos tem de ser notificados sobre a contratação, , ações precisam ser coordenadas e a tarefa final é verificar se toda a documentação está completa e aprovada. No caso em que a solução precisa ser coordenada externamente, qualquer Fluxo definido no sistema é disponível como web services e retorna seus resultados como pacotes SOAP. Isto permite que ações possam ser coordenadas via tecnologia de orquestração como BPEL workflow. Componentes também podem ser embutidos diretamente em uma aplicação Java. Isto pode ser importante se sua solução precisa ser parte de uma aplicação existente. Não importa qual opção de desenvolvimento você escolha: • A plataforma entende a natureza dos processos pois tudo nela é definido como um processo. • Os processos são definidos em linguagens padrão externamente visíveis, editáveis e customizáveis. • Não existe lógica de negócio escondida. A plataforma é construída em processos e definições destes.

Pág 2

Arquitetura Orientada a Serviços (SOA) Isto rapidamente está se tornando sem sentido, pois toda aplicação que aceite chamadas via URLs está declarando que tem a SOA. Quando você projeta o sistema com um mecanismo de workflow como condutor de toda atividade no sistema, toda operação de cada processo deve ser implementada como um componente separado e reutilizável que pode ser direcionado a executar a atividade. Isto não é somente SOA, mas uma Arquitetura Implementada em Serviços (SIA). Toda atividade em todo processo pode ser web serviço pois todas as atividades só poderão executar como serviços. Nao existe outro metodo de invocaçao. A regra dos web é : invocação. Serviços são os blocos de construçao de processos de negócio.

Integração de Processos Todo processo e atividade no Pentaho BI executa como serviço. Se você deseja chamar um processo ou atividade definida na plataforma de um processo externo executando em outro sistema, você pode. É fácil. Cada atividade no sistema entende como fazer parte de outro processo.

Regras, Regras, Regras Os processos da plataforma são definidos externamente, mas e as regras que governam o workflow? A XPDL possui suporte para controle de roteamento complexo, e adicionamos suporte para múltipas engines para que a lógica possa ser facilmente integrada. Múltiplas engines são necessárias pois é improvavel que a lógica de toda a decisão possa ser definida em apenas um mecanismo. Por exemplo, a regra de negócio que determina a análise de credito de um cliente pode ser descrita de três maneiras diferentes: • Um simples script: se (customerNo < 3000 ) return ‘Bob’ else return ‘Mary’ • Um algoritmo complexo baseado nas compras atuais, acordo por nível de serviço, histórico e pagamentos,

localização, etc • Uma chamada a um banco de dados ou sistema ERP para buscar este valor Se a análise de crédito de cada cliente for armazenada no sistema ERP, a manutençao da regra em diferentes sistemas será redundante e custosa, oferecendo riscos e sem valor adicional. Regras de negócio flexíveis são uma parte crítica de processos de negócio automatizados.

Fronteira entre Business Intelligence e Processos de Negócio A divisao entre business intelligence e processos de negócio é flexível no Pentaho BI. Isto por que esta divisão deve estar a cargo de você. Se você tem uma plataforma que define claramente a fronteira entre ela e outro sistemas, você provavelmente tem uma aplicação silo mais difícil de integrar. • O mecanismo de execução de processos na plataforma é baseado totalmente em workflow • A Plataforma inclui múltiplas engines de regras • Na Plataforma atividades são facilmente integradas a outro processos • O caminho inclui entrada de dados manual por usuários

Estudo de Caso Problema: quando um empregado aparece para trabalhar em uma empresa de saúde com uma licença expirada, acontece o seguinte • Isto é notado e um trabalhador mais caro de uma agencia deve substituir o empregado até sua licença ser

renovada

Pág 3

• Isto não é notado, caso em que a segurança do paciente está em risco e também a empresa sujeita a multas etc.

Objetivos de Negócio: aumentar a segurança do paciente, reduzir o risco de multas e os gastos com pessoal temporário de agências. Processo Corrente: Cada gerente mantém uma lista das datas de expiração de seu departamento. ‘Solução’ Proposta: Agendar a execução de um relatório de um banco de dados que lista, por departamento, licenças de cada empregado, e as datas de expiração.

Solução 1: Entregue o que eles pedem Crie um relatório de 50 páginas e entregue para cada departamento uma vez por mês. Processo de Negócio resultante: • O relatório não é auditado. Se ele não rodar, quanto tempo demora até alguém notar? • Gerentes de cada departamento devem ler o relatório e filtrar a informação. Relatórios sao perdidos,

gerentes tiram ferias e datas são confundidas. • Quando gerentes encontram uma licença por expirar, deixam uma nota para o empregado. Notas são

perdidas ou colocadas em lugares errados. • Empregados tentam agendar tempo para preparação, aplicação e certificação. Conflitos de agenda

ocorrem. • Empregados falham na certificação sem tempo para maiores preparações ou novo teste antes da

expiração da licença. Esta solução é incompleta por que somente automatiza a entrega de informação, não ajuda o processo real. O objetivo de negócio fica como sub-produto do relatório.

Solução 2: Entregue o que eles precisam • Crie regras de negócio que determinem o lead time requerido para a preparação adequada para cada tipo

de licença. • Rode um relatório auditado todo o dia ou semana para listar os empregados dentro deste lead time. Para

cada empregado inicie um processo definido de renovação da licença: 1. Entrega da informação eletronicamente para o gerente e o empregado 2. requisitar confirmação eletrônica do recebimento de ambos 3. direcionar o empregado para agendar seu tempo de preparação 4. direcionar o gerente a aprovar a agenda 5. requisitar ao empregado informar as datas dos testes 6. Gerar avisos caso tempo insuficiente para re-test tenha restado 7. requisitar ao gerente para validar a nova licença 8. Entrega notificação no caso de falha ao gerente e agendar nova aplicação. • Oferece relatórios on-line em tempo real do processo de renovação • Produza relatórios de auditoria mensais Esta solução resolve o problema de negócio.

Conclusão Para entregar esta solução você precisa de ferramentas de relatório e análise que : • Suportem regras de negócio • Auditem a execução de relatórios e entrega de informação • Integrem com sistemas de workflow Você também precisa de um mecanismo de workflow / processo de negócio que: • Lide com escalonamentos baseados em tempo

Pág 4

• Audits execução of atividades within the processo • Integre com ferramentas de relatório e análise Você também precisa dispor de relatórios de performance em tempo real e histórico do processo. Esta é a plataforma do Pentaho BI. A Plataforma Pentaho BI é centrada em processos e orientada a solução. O resto do documento descreve como as engines e componentes da Plataforma Pentaho BI podem ser usadas para criar soluções para suas necessidades de Business intelligence.

Pág 5

Construindo Soluções A sessão prévia descreveu nossa abordagem orientada a solução e seus benefícios. O resto deste documento apresenta a descrição técnica do Mecanismo de Solução e os documentos necessários para construir soluções na Plataforma Pentaho BI.

Audiência Esta sessão é direcionada a pessoas que tem interesse em construir soluções e conteúdo e também para quem precisar de interface com as porções de desenvolvimento da Plataforma Pentaho BI. Antes de ler este documento, você deve ler e entender o “Artigo Técnico Pentaho “ disponível em SourceForge - http://sourceforge.net/projects/pentaho. Este documento tem exemplos e referencias a arquivos distribuídos na Plataforma Pentaho BI Pre-Configured Install (PCI), instalaçao pré-configurada. É recomendado que a PCI seja baixada e instalada. Ela também está disponível no SourceForge http://sourceforge.net/projects/pentaho.

Introdução ao Mecanismo de Solução O Mecanismo de Solução é um ponto focal point de atividade na Plataforma Pentaho BI. Está colocado entre o mundo externo – clientes Web, serviços, Monitor do Sistema etc. e a camada de componentes. Veja a figura 1 –Diagrama da Arquitetura. Requisições para tarefas vem para o mecanismo de solução e são roteadas para o componente apropriado ou componentes para execução. Os seguintes termos serão usados na discussão sobre o Mecanismo de Solução:

• Solução - A Solução consiste na coleçao de documentos que coletivamente definem os processos e atividades do sistema. Estes documentos incluem Definições de Sequencia de ação, definições de processo workflow, definições de relatório, imagens, regras, consultas, etc.

• Repositório de Solução– o local onde as definições de solução e os metadados correspondentes

são armazenadas e mantidas. Requisições feitas a plataforma para que ações sejam executadas dependem da ação estar definida no Repositório.

• Mecanismo de Solução – o mecanismo que recupera a definição de uma ação do Repositório de

Solução e direciona sua execução.

• Componente – A camada de componente proporciona uma interface padrão entre o Mecanismo de Solução e a aplicação que executa a lógica de negócio. Um componente pode conter todo o código para a execução de uma tarefa ou ser apenas uma interface para outra aplicação ou sistema. Dados e instriçoes para o componente são proporcionadas via uma Definição de Ação.

• Definição de Ação – Uma definição XML especificando os parâmetros e recursos necessários para

a execução de uma tarefa em um componente específico. A Definição de Ação define qual componente chamar, que dados passar e receber do componente e qualquer informação especifica requerida pelo componente. Uma Definição de Ação não é um documento separado, mas parte da Definição da Sequencia de ação.

• Definição da Sequencia de ação– um documento XML que define a interação entre uma ou

mais Definições de Ação. Define a menor tarefa completa que o Mecanismo de Solução pode rodar. Quando o Mecanismo de Solução é solicitado a executar é passado um documento de Sequencia de ação para ele. A execução de uma Sequencia de ação pode ser autônoma ou fazer parte de outra Sequencia de ação. Definições de Sequencia de ação são armazenadas no Repositório de Solução.

• Contexto de Runtime– Sequencias de ação são transformadas de XML pelo Mecanismo de

Solução em objetos que serão interpretados pelo Contexto de Runtime. O Contexto de Runtime

Pág 6

mantém um contrato entre o Mecanismo de Solução e a Sequencia de ação e obriga um contrato entre a Sequencia de ação e os componentes.

O diagrama da arquitetura abaixo mostra como o Mecanismo de Solução, o Repositório de Solução , e os componentes se encontram na arquitetura. As Soluções, Definições de ação e Definições de Sequencia de ação são armazenadas no Repositório de Solução. O Mecanismo de Solução cria o Contexto de Runtime toda vez que a requisição é recebida. Figure 1 – Diagrama da Arquitetura Pentaho

Clients

Pág 7

SNMP/JMX SOAP/WSDL HTTP RSS

Runtime/ Solution

Repository

Audit Repository

J2EE Server

Data Mining Repository

Workflow Repository

Schedule Repository

Data Sources

Single Sign On

Web Browsers Inbox Alerter

Services / UDDI Java Server Pages, Servlets, Portlets

Navigation Components

Solution Engine

Components

Wor

kflo

w

Rep

ortin

g

Das

hboa

rds

Oth

ers

(see

tex

t)

Pivo

t Vi

ews

Audi

t Rep

orts

Auditing

Sche

dule

r

Busi

ness

Rul

es

Anal

ytic

Vie

ws

Inbo

x

KPIs

Workflow Engine

Scheduler Reporting Engine

Rules EnginesOLAP

Engine

Application Integration

/ ETL

System Monitoring

Web Service Client

Data Mart

Dat

a M

inin

g

App

Inte

grat

ion

JMS

Application Data

Control Flow Data FlowLegendArchitecture:

Customer/3rd PartyTechnology or Data

3rd Party Open Source Technology

PentahoTechnology

Server

Soluções em Detalhe A solução não é um simples documento, mas uma coleção de documentos. É um agrupamento lógico de Definições de Sequencia de ação e recursos necessários. O agrupamento é mantido pelo Repositório de Solução. Você pode ver a estrutura do Repositório de Solução navegando no diretório pentaho-solutions dentro da instalação PCI. O local padrão é : /preconfigured-install/pentaho-solutions. No diretório pentaho-solutions, são 2 soluções pré-definidas, test e samples. A Figure 2 mosta a Sequencia de ação HelloWorld.xaction dentro da solução samples. Figure 2 – Repositório de Solução

Note que existem subdiretórios dentro da solução test. Os documentos de Sequencia de ação e recursos podem estar localizados em qualquer local dentro do diretório da solução (neste caso- test) e em qualquer subpasta deste. Deste modo, podemos agrupar logicamente o conteúdo. Dentro da solução test, as Sequencias de ação são agrupadas por tipo de componente; email, relatório, workflow etc. Em um sistema real, o agrupamento pode ser por departamento, papel ou outra estrutura que faça sentido para a solução. Para localizar uma Sequencia de ação no repositório, use o endereço de três partes: solução id, path e nome da sequencia de ação. No caso Sequencia de ação HelloWorld o endereço é: samples, getting-started, HelloWorld.xaction. As duas soluções test and samples são disponívels com a PCI ou podem ser baixadas do from SourceForge. A solução test serve para verificar se os diferentes componentes do sistema estão setados e funcionando corretamente. A solução samples possui diversos exemplos, os quais oferecem um bom ponto de partida para aprendizado e construção de novas Sequencias de ação. As Sequencias de ação referidas neste documento são localizadas em samples, getting-started.

Sequência de Ação A Sequencia de ação é um documento XML que define a menor tarefa completa que o Mecanismo de Solução pode executar. É executada por um mecanismo de fluxo de processo muito enxuto que define a ordem de execução de um ou mais componentes da Plataforma Pentaho BI. Evitamos chamar isto de fluxo de processo por que faltam muitos dos recursos de um verdadeiro mecanismo deste tipo. Ele é útil para sequenciar tarefas pequenas, lineares e orientadas a sucesso, tal como relatórios e envio por mail. Possui

Pág 8

Pág 9

recursos de laço e chamada de outra Sequencia de ação e eventualmente tem capacidade de executar componentes com condiçoes. O documento de Sequencia de ação deve ter o sufixo “.xaction”. Esta é uma listagem do Documento de Sequencia de ação HelloWorld.xaction. <action-sequence> <name>HelloWorld.xaction</name> <title>Hello World Action Sequence</title> <version>1</version> <logging-level>DEBUG</logging-level> <documentation> <author>Joe Pentaho</author> <description>The most basic Action Sequence Document</description> <help>Hello World demonstrates the most basic Action Sequence document. It uses the Hello World Component. </help> </documentation> <inputs/> <outputs/> <resources/> <actions> <action-definition> <action-type>Hello World Action</action-type> <action-inputs/> <action-outputs/> <action-resources/> <component-name>HelloWorldComponent</component-name> <component-definition> <quote>(2B || !2B) That is the question</quote> </component-definition> </action-definition> </actions> </action-sequence> Alguns Nodos XML são auto explicativos como author and descrição. Nesta sessão, abordaremos os mais importantes nodos, para uma completa explicação da Sequencia de ação veja o Apêndice A. A Sequencia de ação em duas partes principais, o documento principal e os nodos de ações. O documento principal define a interface da Sequencia de ação com o mundo externo. Ele especifica as entradas e recursos que são requeridos pelos componentes referenciados pelo documento e define as saídas que irão estar disponíveis quando todos os componentes forem executados. Este exemplo não possui entradas nem saídas nem utiliza recursos. Os nodos de ações contém as Definições de Ação para executar. Existe uma correspondência um para um entre as Definições de Ação e componentes. O exemplo HelloWorld tem uma Definição de Ação, nomeada “Hello World Action”, sem inputs nem outputs. O componente que sera carregado e responderá a requisição é a Java class HelloWorldComponent. Quando o componente é carregado, o XML dentro do component-definition é passado e os parâmetros de entrada ficam disponíveis. O Componente HelloWorld não é muito empolgante, basicamente faz uma saída “Hello World“ e adiciona o que estiver no nodo quote ao console.

Pág 10

Um Exemplo Mais Complicado Esta é uma listagem do Documento de Sequencia de ação Example1.xaction. <action-sequence> <name>Example1.xaction</name> < - some header nodes deleted - > <inputs> <region type="string"> <default-value>Central</default-value> <sources> <request>REGION</request> <session>aRegion</session> </sources> </region> <from type="string"> <default-value>joepentaho@pentaho.org</default-value> </from> <subject type="string"> <default-value>Pentaho Example1</default-value> </subject> <message-plain type="string"> <default-value> This is an email from the Pentaho BI Platform - Example1 </default-value> </message-plain> </inputs> <outputs/> <resources/> <actions> <action-definition> <action-inputs> <region type="string"/> </action-inputs> <action-outputs> <rule-result type="string"/> </action-outputs> <component-name>JavascriptRule</component-name> <component-definition> <script><![CDATA[ function getManagersEmail( theRegion ) { if ( "Central".equals( theRegion ) ) { return( "joe.pentaho@pentaho.org" ); } return( "jdixon@pentaho.org" ); } getManagersEmail( region ); ]]> </script> </component-definition> </action-definition>

Pág 11

<action-definition> <action-inputs> <to type="string" mapping="rule-result"/> <from type="string"/> <subject type="string"/> <message-plain type="string"/> </action-inputs> <component-name>EmailComponent</component-name> <component-definition/> </action-definition> </actions> </action-sequence>

Neste exemplo, a Sequencia de ação tem 4 inputs: region, from, subject e message-plain. Para region, o tipo foi definido como string; tem o padrão “Central” e pode vir de uma ou duas fontes: requisição e sessão. Quando o RuntimeContext resolve a entrada region em runtime, primeiro irá olhar na requisição (provavelmente uma requisição http). Se não encontrar na requisição, irá olhar na sessão (provavelmente uma sessão http). Se não estiver disponível na sessão, o valor padrão será usado. A ordem em que as fontes são especificadas no Documento XML será a ordem utilizada na procura. O padrão sempre é usado como último recurso. As outras entradas somente especificam um valor padrão. Isto é análogo a codificar os parâmetros como valores constantes. Como o output desta Sequencia de ação é um email, não existem parâmetros de saída. Existem duas nodos action-defininition para esta sequencia. O primeiro define uma regra JavaScript e requer o parâmetro region; irá criar um novo parâmetro chamado “rule-result”. Este novo parâmetro ficará disponível para outro nodo action-defininition na seqüência. Sem entrar a fundo na regra JavaScript, o valor de “rule-result” irá ser setado para o endereço de email apropriado ao valor da região. Quando a primeira action-defininition completa, a segunda irá executar. Ela define uma interação com o componente Email. Este componente requer 4 entradas: to, from, subject e message-plain. Você pode ter notado que as entradas (action-inputs): from, subject e message-plain são especificadas na sessão inputs do cabeçalho da Sequencia de ação. O RuntimeContext irá pegar os valores de lá e disponibiliza-los para o Componente Email como entregou a region ao Componente JavaScript. A fonte da entrada “to” não está definida diretamente. É definida indiretamente como o atributo “mapping”. Este atributo especifica ao RuntimeContext para utilizar o valor de “rule-result” que foi gerado pela regra JavaScript e usa como entrada no componente “to”.

Recapitulando a Sequência de Ação As entradas, saídas e recursos no header da Sequencia de ação definem um contrato entre a Sequencia de ação e o mundo externo. A seqüência requisita que as entradas e recursos sejam passados e irá retornar as saídas especificadas. A action-defininition define um contrato entre cada componente e a Sequencia de ação. As action-inputs e action-recursos definem parâmetros que cada componente necessita para executar. As action-outputs definem quais parâmetros estarão disponíveis após o componente completar a execução. Saídas de um componente podem ser usadas como entrada a outro componente. O atributo mapping (mapeamento) das action-inputs permite que saídas de um componente tenham nomes diferentes como entradas em outro componente. Especificar as relações entre entradas/saídas e os tipos de dados permite ao sistema validar uma Sequencia de ação sem precisar executar os componentes. Uma completa solução pode ser validada e protegida de modificações nos Documentos de Sequencia de ação e eliminados erros de ligação entre estes documentos.

Pág 12

Executando a Solução O Documento de Sequencia de ação define as tarefas a serem executadas, a ordem de execução, a entrada de dados requerida e as saídas de dados disponíveis. São armazenadas no Repositório de Solução e são localizadas especificando o id da solução id, o caminho e o nome da sequencia de ação. Quando a Sequencia de ação é executada, o Mecanismo de Solução cria um Contexto de Runtime que proporciona o ambiente de execução. O Contexto de Runtime contém os parâmetros de entrada, coordena acesso a recursos, armazena novos dados e conteúdo gerado e mantém o estado da Sequencia de ação em execução. As ações são completadas, suas saídas e conteúdo gerado são armazenadas no Contexto de Runtime. Quando a Sequencia de ação finaliza a execução, a porção de dados do Contexto de Runtime é mantida (persistida) no Repositório de Runtime. Quando um novo Contexto de Runtime é criado, ele ganha um identificador de instância único. Este id é a chave que identifica o Contexto de Runtime quando este for persistido. O id de instância também é usado para auditoria e pode ser usado para rastrear qual o componente que o criou (componente pai). Certamente, existe um mecanismo de limpeza dos dados do repositório de runtime. A Sequencia de ação não precisa receber um novo Contexto de Runtime cada vez que for executada. Pode receber o id de uma instância prévia de modo que todos os dados e conteúdo dos Documento de Sequencia de ação executados anteriores fica disponível. Aqui é quando o contrato entre o Documento de Sequencia de ação se torna importante. Desde que uma saída de um Documento de Sequencia de ação anterior tenha sido especificada, estará disponível como entrada a uma Sequencia de ação posterior. Esta habilidade de encadear Documentos de Sequencia de ação através do mesmo Contexto de Runtime se torna poderosa quando utilizada junto com o mecanismo de workflow. Existem várias maneiras de executar a solução; via URL, Java Code ou chamada de Web Serviço.

URL Os exemplos contidos na instalação pré-configurada são acionados via URL utilizando o servlet ViewAction (org.pentaho.ui.servlet.ViewAction) servlet. A URL seguinte irá acionar a Sequencia de ação HelloWorld: http://localhost:8080/pentaho/ViewAction?&solution=samples&path=getting-started&action=HelloWorld.xaction O resultado retornado depende do Documento de Sequencia de ação. Você poderá visualizar um relatório, uma mensagem de texto ou somente “Action Successful.” Os seguintes parâmetros podem ser passados em uma URL: • solution, path, action – a localizaçao do Documento de Sequencia de ação a ser carregado. • instance_id – o instance Id de um prévio Contexto de Runtime • debug – setar “true” para que a informação de debug seja guardada no log de execução log.

Chamada de Web Serviço (Web Service) No grupo de exemplos “Settings and Services” da instalação pré-configurada existe um Exemplo Web Serviço. Ainda é uma chamada URL call, desta vez ao servlet ServiceAction (org.pentaho.ui.servlet.HttpWebService). A URL seguinte irá acionar a Sequencia de ação HelloWorld: http://localhost:8080/pentaho/ServiceAction?solution=samples&path=getting-started&action=HelloWorld.xaction neste caso, o resultado retornado é uma resposta XML SOAP. Os seguintes parâmetros podem ser passados via URL: • solution, path, action – a localizaçao do Documento de Sequencia de ação a ser carregado. • instance_id – o instance Id de um prévio Contexto de Runtime • debug – setar “true” para que a informação de debug seja guardada no log de execução.

Pág 13

Chamada Java A Sequencia de ação pode ser executada diretamente de uma aplicação Java. Para um exemplo de como fazer isto, abra o arquivo Java “org.pentaho.test.RuntimeTest.java” e olhe o teste JUnit para HelloWorld.

Parâmetros Existem três tipos de parâmetros que o Documento de Sequencia de ação entende; entradas, saídas e recursos. Entradas e saídas são variáveis de tipo de dados específico tal como string ou property-map (veja o Apêndice B para tipos de dados válidos). Recursos são similares a entradas exceto que especificam um tipo “mime” e caminho. Um valor padrão não pode ser especificado para recursos. Tipicamente recursos representam grandes volumes de dados tal como definições de relatório ou images (veja o Apêndice B para tipos de recursos válidos.) Parâmetros podem vir de quatro origens; runtime, requisição, sessão, globais e padrão. parâmetros de Runtime são parâmetros que são armazenados no Contexto de Runtime. Lembre, the Contexto de Runtime armazena as entradas e saídas de instâncias anteriores e as torna disponível para execuções futuras da mesma id de instância. Parâmetros de Requisição são pares nome-valor especificados em uma URL. parâmetros de Sessão são variáveis armazenadas na sessão do usuário e podem conter valores únicos para cada usuário. parâmetros Globais são similares aos parâmetros de sessão exceto que tem os mesmos valores para todos os usuários. Valores Padrão são especificados no Documento de Sequencia de ação e são usados como último recurso. Parâmetros Sessão e Global podem ser usados para proporcionar filtragem segura de dados dentro de uma Sequencia de ação. Um parâmetro de sessão é iniciado executando uma sequencia de ação quando o usuário loga no sistema. A Sequencia de ação chamada no login pode ser setada para realizar uma consulta usando o nome de login do usuário dentro de uma cláusula where. O resultado é armazenado na sessão de usuário e fica disponível Sequencias de ação subsequentes. Parâmetros Globais são iniciados quando o sistema inicia e são disponível para todos os usuários. Veja o documento “Assegurando Acesso a Dados com Filtros de Sessão e Globais” para informação de como setar os filters e usá-los. Aqui está um exemplo de entradas tipo sessão em um Documento de Sequencia de ação: <inputs> <region type="string"> <default-value>Central</default-value> <sources> <request>REGION</request> <runtime>aRegion</runtime> </sources> </region> </inputs> Este exemplo indica que o Documento de Sequencia de ação requer o parâmetro “region” (sensível ao Caps Lock.) Quando executada, o Contexto de Runtime primeiro irá verificar se o parâmetro de nome “REGION” existe na requisição. Se a Sequencia de ação foi lançada via URL, e existe parâmetro “REGION=xxx” especificado, então este valor (xxx) será substituído pela entrada “region”. Se não encontrar o parâmetro na requisição, irá procurar em seus dados de runtime por um parâmetro de nome “aRegion.” Se não encontrar no seu Contexto de Runtime este Dado, o valor “Central” será usado. O Contexto de Runtime sempre procura pelas fontes na ordem em que são especificadas e pega o padrão por último. Se nenhum padrão for especificado, então a Sequencia de ação irá retornar erro. Existem dois parâmetros implícitos instance-id e solution-id que estão sempre disponível e não precisam ser especificados como entradas ou saídas. Certamente você pode imaginar o que eles são.

Pág 14

Componentes O Documento de Sequencia de ação é a definição, o Contexto de Runtime proporciona um ambiente de execução e os Componentes são a lógica de negócio. Um Componente executa uma função simples, um grupo de funções relacionadas ou uma ponte entre a Plataforma Pentaho BI e uma aplicação externa. O componente jFree Reports é um exemplo de componente que faz interface da plataforma com o mecanismo de relatório jFree Reports. Existem duas funções principais que um Componente é chamado a executar – validar e executar. Validar é chamado para verificar se as são validas e todos os recursos requridos para executar estão disponíveis. Executar realmente realiza a ação. O nodo action-defininition no Documento de Sequencia de ação define como o componente deve funcionar. É o local para definir e mapear entradas, saídas e outro metadados ou ajustes que o componente irá requerer quando executado. O nome do componente que executa a Definição de Ação é identificado usando o nodo component-name. O nome é o nome de uma Java class que é carregada dinamicamente durante o runtime. Quando se referir aos componentes embutidos no Pentaho, o nome completo do componente não deve ser usado, somente o nome da classe. Por exemplo, use EmailComponent ao invés de org.pentaho.plugin.email.EmailComponent. Entradas Os nodos action-inputs e action-resources definem os parâmetros passados ao componente quando executar. Alguns componentes tem entradas que devem ser disponíveis ou erro de runtime irá ocorrer. Algumas entradas podem ser especificadas mas são opcionais. Por exemplo, o Componente Email requer a “to” mas o “cc” é opcional. Existem muitas maneiras de satisfazer uma entrada requerida. Pode ser passado como parâmetro com mesmo nome para o componente. Pode ser mapeado para um nome diferente e passado ao componente. Pode ser colocado no código como constante ou em alguns casos pode ser perguntado. Por padrão o email componente tem a entrada assim: <action-inputs> <to type="string" /> . . . </action-inputs> Entrada Mapping O que acontece se o componente requer uma entrada nomeada “x” e você deseja passar um parâmetro nomeada “y”? Você pode mapear qualquer entrada para um nome diferente usando o atributo “mapping”. Novamente, usando nosso Email Componente exemplo, digamos que exista uma regra JavaScript que realiza uma consulta e retorna o email de um usuário em um parâmetro de saída nomeado “EMAIL.” Digamos que você deseja usar o parâmetro como parâmetro “to” no Componente Email. O XML irá parecer com o seguinte: <action-inputs> <to type="string" mapping="EMAIL"/> . . . </action-inputs> Valores Constantes como Entradas Se o componente requer um parâmetro de entrada e não é encontrado em action- inputs, o componente irá automaticamente procurar no nodo XML como o mesmo nome, na sessão component-definition. Se encontrar, irá usar o valor dali. O XML parece o seguinte: <action-inputs> </action-inputs> <component-definition> <to>joe.pentaho@pentaho.org</to> </component-definition>

Pág 15

Parâmetros Permutáveis Todos os componentes tem a habilidade de utilizar o mecanismo embutido de template para permutar o texto usando parâmetros de entrada. Isto significa que um valor constante pode ser modificado usando o valor de uma action-input. Vejamos um exemplo: <action-inputs> <EMAIL type="string"/> . . . </action-inputs> <component-definition> <to>{EMAIL}@pentaho.org</to> </component-definition> The texto entre chaves {} será substituído por um parâmetro de entrada de mesmo nome. Neste exemplo, se o valor da action-input EMAIL for “joe.pentaho” então o valor do parâmetro passado “to” ao componente email será joe.pentaho@pentaho.org. Perguntando ao Usuário (Prompting) Alguns componentes iráo perguntar por parâmetros requeridos. A pergunta será gerada em runtime se o mecanismo de chamada permitir. Por exemplo, o Componente Email requer um parâmetro “to”. Se este parâmetro for especificado como action-input mas tiver valor nulo, o Componente irá perguntar ao runtime se é permitido perguntar ao usuário. Se a Sequencia de ação executada tiver sido acionada de um web browser, o runtime irá responder “true” e o Email Componente irá pedir ao runtime para perguntar ao usuário pelo “to”. Se a Sequencia de ação estiver rodadndo como web serviço, o runtime retorna “false” e o Email Componente irá gerar um erro de parâmetro e retornar. O action- outputs define quais parâmetros serão salvos no Contexto de Runtime e tornados disponíveis a outro Componente quando o primeiro componente termina a execução. Como um action-input, o action- output pode ser mapeado para outro nome variável usando o mapping. O nodo component-definition proporciona local específico para opções ou parâmetros de qualquer Componente. O restante deste documento descreve entradas, recursos e saídas requeridos por cada um dos componentes disponíveis na Plataforma Pentaho BI. Veja o Apêndice C para entrada, saída e definição específicas requeridas de cada Componente.

Existem Ferramentas para Ajudar? Se parece complicado, existe uma maneira mais fácil - o Pentaho Design Studio. Ele contém um ambiente gráfico para projetar Sequencias de ação. Soluções podem ser montadas sem nenhum conhecimento do XML. Entradas podem ser arrastadas de um componente e largadas no seguinte. Este é um bom momento para você testar o Design Studio. Você pode se referir aos capítulos seguintes somente quando necessário. Faca o Download da última versão e guia do usuário em http://sourceforge.net/project/showfiles.php?group_id=140317.

Pág 16

Integrando seus próprios relatórios Visão Geral Introdução Bem, você deve construir seus próprios relatórios usando JFreeReport, Eclipse BIRT ou JasperReports que usa um formato próprio de dados e agora você se pergunta: Como eu vou integrar estes relatórios com a plataforma de BI do Pentaho? Não se preocupe, vamos ensiná-lo. O Pentaho possui familiaridade com essas ferramentas para relatório, seja JFreeReport, JasperReports ou Eclipse BIRT e ele assume que você tenha disponível os seguintes recursos:

• Um relatório aprovado e codificado em XML (.xml do JFreeReport, .rptdesign do Eclipse BIRT ou um .jrxml do JasperReports). Aprovado significa que você já tenha testado o relatório fora da plataforma do Pentaho BI e que funcionou corretamente.

• O driver JDBC com extenção “.jar” do banco de dados que você está usando.

Nota: O JFreeReport é desenvolvido e mantido pelo Pentaho e por isso é o preferido e mais suportado software de engenharia de relatórios para a plataforma do Pentaho.

Suposições e Convenções gerais Este guia assume que as seguintes condições estão satisfeitas:

• Que o Pentaho já esteja instalado, configurado e pronto para uso; • Todas as barras (“/”) neste documento estarão inclinadas para a direita. Quem usa a plataforma

Windows deverá corrigi-las para a barra inclinada para a esquerda (“\”), salvo em casos específicos que serão comentados;

• O diretório de instalação pré-configurado no Pentaho será referenciado neste documento como {PCI}. Onde você encontrar caminhos de diretórios específicos, considere-os como subdiretórios do diretório de instalação como neste exemplo: {PCI}/jboss/server/default/deploy. Sendo assim, se você instalou a configuração padrão do Pentaho no drive “C” do Windows na pasta chamada pentaho-pci, então no seu caso a expressão ‘{PCI}/’ seria ‘C:\pentaho-pci\’;

• Que o leitor leu e compreendeu a sessão anterior “A Seqüência de Ação”, Apêndice A- Seqüência de Ação XML nos detalhes, Apêndice B com respeito às seqüências de ações, formato e conteúdo;

Integrando Relatórios com JFreeReport Para maiores informações sobre como usar o JFreeReport na plataforma do Pentaho por favor leia o capítulo Guia do Usuário para Relatório com o Assistente.

Definindo Relatórios no JFreeReport O JFreeReport utiliza o padrão XML para definições de relatórios e estas definições são salvas em arquivos com a extensão “.xml”, porém esta extensão não é obrigatória. O Pentaho JFreeReportComponent (org.pentaho.plugin.jfree.JFReeReportComponent) usa as definições do relatório junto com seus dados para produzir um formato de saída compreensível. Os formatos de saída gerados pelo JFreeReport são HTML, PDF, CSV, XLS e RTF.

O JFreeReport abstrai esses dados de uma Java TableModel (tabela modelo). Há uma implementação de TableModel sob medida na plataforma Pentaho que fornece uma interface amigável e uma eficiente performance operacional. Tendo em vista que o JFreeReport opera de acordo com predefinições e com uma TableModel, não há outro jeito de parametrização no JFreeReport. Isto é realizado no action-sequence (seqüência de ações) e na própria query em SQL. Usando o Pentaho Report Design Wizard (assistente para criação de relatórios do Pentaho) você poderá criar definições de JFreeReport e também uma seqüência básica de ações. Em um exemplo simples, crie um relatório em uma template (moldura) vazia e introduza uma query SQL com o seu banco de dados.

A tela acima mostra uma query SQL parametrizada para usar com o Report Design Wizard (Assistente para criação de relatórios). A coluna “REGION” é o que nós estamos usando como nosso parâmetro ou condição. O nome do parâmetro também é “REGION”, mas essa igualdade não é necessária. Na versão atual, o assistente não tem a habilidade de informar ao usuário sobre valores de parâmetros, sendo assim o valor padrão “Eastern” (oeste) foi sugerido. A especificação completa do parâmetro na query é {REGION=Eastern}. Quando o relatório é executado pelo Report Design Wizard o valor do parâmetro “REGION” é trocado com o valor padrão especificado como “Eatern” (oeste). Quando o relatório é publicado para uso na plataforma Pentaho, o parâmetro “REGION” é instalado na action-sequence (seqüência de ação) e o usuário será alertado para fornecer um valor. A action-sequence gerada pelo Report Design Wizard pode ser mais customizada pelo Pentaho Design Studio.

Criando a Seqüência de Ação (Action Sequence) Uma vez que você verificou que o relatório está trabalhando sem problemas no Report Design Wizard, você pode descansar seguro que ele estará apto para funcionar com a plataforma Pentaho. A razão disso é que o Report Design Wizard executa o relatório em uma versão autônoma da plataforma Pentaho. Não há necessidade de criar uma action-sequence uma vez que ele tenha sido gerado automaticamente pelo Assistente. Entretanto, se você tiver uma definição de relatório criada a mão no JFreeReport ou em outra ferramenta, nós lhe mostraremos uma action-sequence que o ajudará a montar um relatório básico parametrizado. Veja:

<action-sequence xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"> <name>JFreeReport-WizardReport.xaction</name> <version>1</version> <title>%title</title> <documentation> <author>Report Design Wizard</author> <description><![CDATA[%description]]></description> <icon>PentahoReporting.png</icon> <help>This action-sequence was generated by the Report Design Wizard. To edit

this action-sequence use the Pentaho Design Studio.</help> <result-type>report</result-type> </documentation> <inputs> <output-type type="string"> <default-value>html</default-value> <sources> <request>type</request> </sources>

Pág 17

Pág 18

</output-type> <REGION type="string"> <default-value/> <sources> <request>REGION</request> </sources> </REGION> </inputs> <outputs> <report type="content"> <destinations> <response>content</response> </destinations> </report> </outputs> <resources> <report-definition> <solution-file> <location>JFreeReport-WizardReport.xml</location> <mime-type>text/xml</mime-type> </solution-file> </report-definition> </resources> <actions> <action-definition> <action-inputs> <output-type type="string"/> <REGION type="string"/> </action-inputs> <action-outputs> <report type="content"/> </action-outputs> <component-name>JFreeReportComponent</component-name> <action-type>report</action-type> <component-definition> <source>sql</source> <live>true</live> <jndi>SampleData</jndi> <query><![CDATA[select * from quadrant_actuals where REGION in

('{REGION}')]]></query> </component-definition> </action-definition> </actions> </action-sequence>

Instalação do JDBC Driver Se você está usando um driver de banco de dados, sem ser da Hypersonic, você necessitará configurar o JBoss PCI para usá-lo. Vá até a seção Jasper em Configurações JDBC para mais detalhes.

Verificando a Integridade do JFreeReport na Plataforma Pentaho Neste ponto o relatório deve estar pronto para uso. Aponte o seu navegador Internet para o endereço do Pentaho (que normalmente seria http://localhost:8080). Navegue até o relatório que você criou no grupo Reporting Examples (menu Exemplos de Relatório).

Quando você entrar no relatório, uma página padrão é gerada solicitando a você que digite um valor para o parâmetro REGION que é a condição para pesquisa e geração do relatório.

Uma vez que você tenha preenchido o valor, o relatório será gerado e dependendo do tipo de saída no action-sequence você verá seu relatório no formato desejado. O exemplo acima mostra um relatório em HTML.

Integrando Relatórios BIRT Definições de Relatórios no Eclipse BIRT Um arquivo de relatório no Eclipse BIRT (report.rptdesign) são simplesmente arquivos no formato XML com uma extensão esquisita. A extensão permitirá que o Eclipse IDE reconheça o arquivo como um relatório do BIRT. O componente do Pentaho BIRTReportComponent (org.pentaho.plugin.eclipsebirt.BIRTReportComponent) é capaz de executar esses relatórios e produzir saídas nos formatos HTML, PDF, FO e FOP. Os parâmetros do Eclipse BIRT são definidos nas definições do relatório como Scalar Parameters (parâmetros escalares). No BIRT um parâmetro deve estar inserido no Data Set. Isso é bom quando criamos um Data Set ou enquanto editamos um Data Set já existente. Há uma seção chamada “Parameters” no editor do Data Set onde você definirá seus parâmetros. Quando o parâmetro é definido o “valor padrão” deve seguir a seguinte convenção: params[“SOME_PARAMETER”]. O “SOME_PARAMETER” deve coincidir com o nome de um parâmetro de relatório conforme tenha sido definido na seção “Report Parameters” do Data Explorer no BIRT.

Pág 19

No exemplo acima, com um parâmetro de relatório nomeado como “REGION”, o mesmo foi definido conforme mostramos a seguir.

Pág 20

Pág 21

Criando uma Seqüência de Ação (Action Sequence) Após verificar que o relatório no BIRT está correto podemos com segurança utiliza-lo como uma solução Pentaho. Copie o relatório do BIRT para {PCI}/pentaho-solutions/samples/reporting. O que nós precisamos fazer agora é criar um documento XML de seqüência de ação e grava-lo em {PCI}/pentaho-solutions/samples/reporting. Este documento é composto de diversas seções: documentação, entradas, saídas, recursos e definições de ação. Certifique-se que o nome do Documento de seqüência de ação deve combinar com a Tag XML <name> nele contida.

• Documentação: Esta sessão está reservada para você incluir informações do autor, descrição, um ícone para representar a seqüência de ação, um link (URL) para uma página de ajuda e um Result-Type (tipo de resultado). Neste exemplo, nós especificamos “relatório” como um Result-Type.

<documentation> <author>Michael D'Amour</author> <description>BIRT Report with Parameters</description> <icon>reporting.png</icon> <help></help> <result-type>report</result-type> </documentation>

• Entradas: Há 2 entradas: Output-Type (tipo de saída) e REGION (Região). Observe que a

entrada REGION tem o mesmo nome do parâmetro de relatório do BIRT. Isto é importante. O output-type ou tipo de saída no exemplo abaixo é “html”. Outros tipos de saídas aceitáveis são PDF, FO e FOP.

<inputs> <output-type type="string"> <default-value>html</default-value> <sources> <request>type</request> </sources> </output-type> <REGION type="string"> <default-value></default-value> <sources> <request>REGION</request> </sources> </REGION> </inputs>

• Recursos: Nesta sessão nós definimos um “report-definition” (definição de relatório) que aponta para o arquivo XML .rptdesign do BIRT.

<resources> <report-definition> <solution-file> <location>BIRT-report.rptdesign</location> <mime-type>text/xml</mime-type> </solution-file> </report-definition> </resources>

• Ações: Neste exemplo nós temos somente uma action-definition (definição de ação). O

component-name (nome do componente) identifica a classe Java que efetua a ação. Para o BIRT os relatórios usam o nome "BIRTReportComponent". Há duas entradas nesta ação: a output-type (tipo de saída) e a REGION (região). Estas entradas são definidas na seção de entradas do documento “action-sequence” (seqüência de ações).

<actions> <action-definition>

Pág 22

<action-inputs> <output-type type="string"/> <REGION type="string"/> </action-inputs> <action-outputs> </action-outputs> <component-name>BIRTReportComponent</component-name> <action-type>report</action-type> <component-definition> </component-definition> </action-definition> </actions>

Todo documento de seqüência de ação utilizado no exemplo é mostrado abaixo:

<action-sequence> <name>report.xaction</name> <version>1</version> <title>Parameterized BIRT Report</title> <documentation> <author>Michael D'Amour</author> <description> BIRT Report with Parameters </description> <icon>reporting.png</icon> <help></help> <result-type>report</result-type> </documentation> <inputs> <output-type type="string"> <default-value>html</default-value> <sources> <request>type</request> </sources> </output-type> <REGION type="string"> <default-value></default-value> <sources> <request>REGION</request> </sources> </REGION> </inputs> <outputs> </outputs> <resources> <report-definition> <solution-file> <location>report.rptdesign</location> <mime-type>text/xml</mime-type> </solution-file> </report-definition> </resources> <actions> <action-definition> <action-inputs> <output-type type="string"/> <REGION type="string"/> </action-inputs> <action-outputs> </action-outputs> <component-name>BIRTReportComponent</component-name> <action-type>report</action-type> <component-definition> </component-definition> </action-definition> </actions> </action-sequence>

Instalando o Driver JDBC O gerenciador de relatórios BIRT contém informações de conexão JDBC que serão usadas pelo BIRT para gerar relatórios. Já que estamos gerando os relatórios de dentro da estrutura do Pentaho, nós devemos pôr o drive JDBC para o banco de dados que estamos usando na pasta {PCI}/jboss/server/default/lib.

Verificando a Integração do BIRT com a Plataforma do Pentaho Neste ponto o relatório deve estar pronto para uso. Aponte o seu navegador web para o seu endereço de Host (ou PCI), que numa instalação de demonstração seria http://localhost:8080, e navegue no relatório que você criou sob o grupo Reporting Examples.

Neste ponto você é alertado para escolher um dos parâmetros ou opções de relatório. Escolha a opção e clique em “Submit”.

Sucesso! Agora é possível ver o relatório gerado em HTML.

Pág 23

Integrando Relatórios Jasper (JasperReports) Definições para Relatório no JasperReports Arquivos com definições para criação de relatórios (report.jrxml) do JasperReports são também documentos XML com uma extensão no mínimo exótica. No JasperReports os arquivos com a extensão “.jrxml” são considerados como “código fonte” do seu relatório. O componente de relatório do Pentaho chamado JasperReportsComponent (org.pentaho.plugin.jasperreports.JasperReportsComponent) é o encarregado de efetuar a compilação do relatório no formato “.jrxml” e de tudo mais que for necessário para que esteja utilizável. O JasperReportsComponent do Pentaho permite a execução destes relatórios e permite reproduzir os resultados nos formatos HTML ou PDF. Os parâmetros do JasperReports ficam nas definições do próprio relatório XML. Se você está usando iReport para criar seus JasperReports, você deve criar parâmetros em seu Object Library (vide figura a seguir) que possa referenciar o parâmetro da query do seu relatório.

O relatório acima está usando um parâmetro nomeado como “STATE”. Para que o usuário seja instruído a informar o valor do parâmetro “STATE” na solução Pentaho, você deve selecionar a opção “Is for prompting” (solicitar digitação) ao criar o parâmetro, como mostra a figura a seguir:

Pág 24

Criando uma Seqüência de Ação (Action Sequence) Agora podemos introduzir no Pentaho o relatório criado no JasperReport. Copie o arquivo de extensão “jrxml” para {PCI}/pentaho-solutions/samples/reporting. O que nós precisamos fazer agora é criar um documento XML de seqüência de ação do Pentaho e salvá-lo em {PCI}/pentaho-solutions/samples/reporting. Este documento é formado de várias seções: Documentação, entradas, saídas, recursos e definições de ações. Observe que o nome do documento de seqüência de ação deve combinar a tag XML “<name>” com o seu próprio nome. A seguir estaremos detalhando cada seção.

• Documentação: Esta seção te conduzirá a incluir informações do autor, descrição, um ícone que represente a seqüência de ação, um endereço web para uma página de ajuda e o tipo de resultado (result-type). Neste exemplo nós especificamos “report” (relatório) como o tipo de resultado.

<documentation> <author>Angelo Rodriguez</author> <description>Example of how to add a new Jasper Report to a

solution</description> <icon>reporting.png</icon> <help></help> <result-type>report</result-type> </documentation>

• Entradas: Há 2 entradas: Output-Type (tipo de saída) e STATE. Observe que a entrada STATE tem o mesmo nome do parâmetro de relatório que está sendo usado pelo JasperReport. Isso é importante. O output-type no exemplo a seguir é em “html”. Outro tipo de saída opcional é o PDF.

<inputs> <output-type type="string"> <default-value>html</default-value> <sources> <request>type</request> </sources> </output-type> <STATE type="string"> <default-value></default-value> <sources> <request>STATE</request>

Pág 25

Pág 26

</sources> </STATE> </inputs>

• Recursos: Nesta seção nós criamos uma “report-definition” (definição de relatório) que aponta

para o arquivo XML de extensão “.jrxml” do JasperReport:

<resources> <report-definition> <solution-file> <location>report.jrxml</location> <mime-type>text/xml</mime-type> </solution-file> </report-definition> </resources>

• Ações: Neste exemplo temos somente uma definição de ação. É o nome do componente que

identifica a classe Java que efetua a ação. No JasperReports usa-se “JasperReportsComponent”. Há 2 entradas nesta seção: O tipo de saída (output-type) e o STATE. Estas entradas estão definidas na seção de entradas do documento de seqüência de ações.

<actions> <action-definition> <action-inputs> <output-type type="string"/> <STATE type="string"/> </action-inputs> <action-outputs> </action-outputs> <component-name>JasperReportsComponent</component-name> <action-type>report</action-type> <component-definition> </component-definition> </action-definition> </actions>

Abaixo o original inteiro do documento de seqüência de ação usado neste exemplo:

<action-sequence> <name>report.xaction</name> <version>1</version> <title>Sample MySql Report</title> <documentation> <author>Angelo Rodriguez</author> <description>Example of how to add a new Jasper Report to a

solution</description> <icon>reporting.png</icon> <help></help> <result-type>report</result-type> </documentation> <inputs> <output-type type="string"> <default-value>html</default-value> <sources> <request>type</request> </sources> </output-type> <STATE type="string"> <default-value></default-value> <sources> <request>STATE</request> </sources> </STATE> </inputs> <outputs> </outputs> <resources> <report-definition> <solution-file>

Pág 27

<location>report.jrxml</location> <mime-type>text/xml</mime-type> </solution-file> </report-definition> </resources> <actions> <action-definition> <action-inputs> <output-type type="string"/> <STATE type="string"/> </action-inputs> <action-outputs> </action-outputs> <component-name>JasperReportsComponent</component-name> <action-type>report</action-type> <component-definition> <jndiUrl>MySqlDS</jndiUrl> </component-definition> </action-definition> </actions> </action-sequence>

Instalação do Driver JDBC Já que estamos gerando os relatórios dentro do Pentaho framework, devemos então utilizar o driver JDBC com o banco de dados desejado em {PCI}/jboss/server/default/lib. Ao contrário das definições de relatório do BIRT, arquivos “.jrxml” não contêm as definições de conexão com o banco de dados para o relatório. Esta informação necessita ser especificada na seqüência da ação. Como mostrado acima, a localização do banco de dados pode ser definida dentro das definições de ação como segue:

<component-definition> <driver>com.mysql.jdbc.Driver</driver> <connection>jdbc:mysql://localhost:3306/sampledata</connection> <user-id>jim</user-id> <password>password</password> </component-definition>

Como alternativa, o banco de dados pode ser identificado usando um nome de JNDI como segue:

<component-definition> <jndi>MySqlDS</jndi> </component-definition>

Se você pretende usar JNDI para identificar um relatório de banco de dados, você necessitará configurar o JBoss para mapear o nome do JNDI para o seu banco de dados como segue:

• Crie um arquivo no formato xxxx-ds.xml para o seu tipo de banco de dados em {PCI}/jboss/server/default/deploy. No exemplo a seguir criaremos um arquivo mysql-ds.xml com o seguinte conteúdo:

<?xml version="1.0" encoding="UTF-8"?> <datasources> <local-tx-datasource> <jndi-name>MySqlDS</jndi-name> <connection-url>jdbc:mysql://localhost:3306/sampledata</connection-url> <driver-class>com.mysql.jdbc.Driver</driver-class> <user-name>jim</user-name> <password>password</password> <exception-sorter-class-name> org.jboss.resource.adapter.jdbc.vendor.MySQLExceptionSorter </exception-sorter-class-name> <metadata> <type-mapping>mySQL</type-mapping>

</metadata> </local-tx-datasource> </datasources>

• Adicione uma referência do recurso para {PCI}/jboss/server/default/deploy/pentaho.war/WEB-INF/web.xml.

<resource-ref> <description>MySql Connection</description> <res-ref-name>jdbc/MySqlDS</res-ref-name> <res-type>javax.sql.DataSource</res-type> <res-auth>Container</res-auth> </resource-ref>

• Adicione uma referência do recurso para {PCI}/jboss/server/default/deploy/pentaho.war/WEB-INF/jboss-web.xml.

<resource-ref> <res-ref-name>jdbc/MySqlDS</res-ref-name> <res-type>javax.sql.DataSource</res-type> <jndi-name>java:/MySqlDS</jndi-name> </resource-ref>

Verificando a Integração JasperReports com a Plataforma Pentaho Reinicie o seu Pentaho Server executando {PCI}/stop_pentaho e depois {PCI}/start_pentaho. Neste ponto o relatório deve estar conectado e pronto para uso. Aponte o seu navegador web para a sua página de início (que deve ser http://localhost:8080). Navegue até o relatório que você criou dentro do grupo Lista de Exemplos (Reporting Examples).

Neste ponto você informa o parâmetro.

Pág 28

Finalmente alcançamos o nosso objetivo. Nesta figura podemos ver o resultado gerado em HTML.

Pág 29

Pág 30

Gráficos The Plataforma Pentaho BI currently employs JFreeChart as its charting mecanismo. The implementation of the mecanismo currently includes UI componentes for the following charts: Dial, Pie, Pie Grid, Bar Chart, Line, e Area. Cada chart componente pode create at least 1 tipo of chart. Several of the chart componentes pode create muitos chart types. Certain charts (where it makes sense) pode ser rendered as stacked e three dimensional. The plataforma charts render themselves as XML e then the XML is transformed to HTML via the use of an .xslt transformation.

ChartComponent The ChartComponent is a UI componente that pode create a variety of charts including Bar, Line, Pie, Pie Grid, e Area. Where applicable there são several options that pode ser applied. The following sequencia de ação utiliza the saída from an SQLLookupRule as the entrada for a ChartComponent. <action-sequence> <nome>Chart.xaction</nome> <title>Padrão Title</title> <version>1</version> <logging-level>DEBUG</logging-level> <documentation> <author>Brian C Hagan</author> <descrição>Padrão Descrição</descrição> <icon>JFree-quadrant-orçamento-hsql.png</icon> <help>Help</help> <result-tipo>regra</result-tipo> </documentation> <entradas> <chart-tipo tipo="string"> <padrão-valor>.png</padrão-valor> <sources> <requisição>tipo</requisição> </sources> </chart-tipo> </entradas> <ações> <action-defininition> <action-saídas> <result-set tipo="list" /> </action-saídas> <componente-nome>SQLLookupRule</componente-nome> <action-tipo>regra</action-tipo> <componente-definição> <source>sql</source> <live>true</live> <jndi>SampleData</jndi> <consulta> <![CDATA[select QUADRANT_ACTUALS.REGION, QUADRANT_ACTUALS.DEPARTAMENTO, QUADRANT_ACTUALS.POSITIONTITLE, QUADRANT_ACTUALS.ACTUAL, QUADRANT_ACTUALS.ORÇAMENTO from QUADRANT_ACTUALS order por QUADRANT_ACTUALS.REGION, QUADRANT_ACTUALS.DEPARTAMENTO]]> </consulta>

Pág 31

</componente-definição> </action-defininition> <action-defininition> <action-entradas> <saída-tipo tipo="string" mapping="chart-tipo" /> <result-saída tipo="arquivo" /> <chart-dados tipo="list" mapping="result-set" /> </action-entradas> <action-saídas> <chart-saída tipo="string" /> <base-url tipo="string" /> </action-saídas> <componente-nome>ChartComponent</componente-nome> <action-tipo>relatório</action-tipo> <componente-definição> <por-row>false</por-row> <chart-attributes> <!-- this is the background for the whole image --> <chart-tipo>PieChart</chart-tipo> <title>Actual vs Orçamento por Region</title> <title-position>TOP</title-position> <title-font> <font-family>Serif</font-family> <size>36</size> <is-bold>false</is-bold> <is-italic>false</is-italic> </title-font> <range-title>US Dollars</range-title> <chart-background tipo="color">#FFFFFF</chart-background> <plot-background tipo=”color”>#FF0000</plot-background> <orientation>Horizontal</orientation> <height>400</height> <width>800</width> <is-3D>true</is-3D> <is-stacked>false</is-stacked> <category-label-rotation>90</category-label-rotation> <border-visible>false</border-visible> <border-paint>#3399FF</border-paint> <include-legend>true</include-legend> </chart-attributes> </componente-definição> </action-defininition> </ações> </action-sequence> <por-row/> Requerido nodo that describes how the chart dados is aggregated. Values são TRUE ou FALSE. <chart-attributes/> Requerido por the ChartComponent, this nodo contains all chart attributes nodos. This nodo is não usado por the CategoryDatasetComponent (described below). <chart/> The chart root nodo. This item is a mandatory singleton nodo. This nodo is não usado por the ChartComponent.

Pág 32

<chart-tipo/> Opcional singleton nodo that contains the chart tipo in the nodo texto. Quando usado with the CategoryDatasetComponent, se the chart-tipo is não set in the xml definição then it must ser set on the CategoryDataset Componente directly in code (servlet ou JSP). <title/> Opcional singleton nodo that contains the requested title in the nodo texto. Valid chart tipo strings são “PieChart”, “PieGrid”, “BarChart”, “LineChart” e “Arcadaart” <title-position/> Opcional nodo that describes the position of the chart title. Valid positions são TOP, BOTTOM, LEFT, e RIGHT. <title-font/> Opcional singleton nodo that describes the chart font. Font attributes são included as child nodos. Child nodos include, <font-family>, <size>, <is-bold>, e <is-italic>. <subtitle/> Opcional singleton nodo that contains the requested subtitle in the nodo texto. <range-title/> Opcional nodo that describes the chart range (usually the y-axis). <chart-background/> Opcional singleton nodo that describes the background tipo. Valid types include color e image. Se tipo=”color”, designate the color with 6 byte hexadecimal notation. Quando tipo=”image”, the valor is a filepath (relative to the solução diretório) of an image arquivo to use as the chart background image. Note: This image replaces the background of the chart itself e NÃO the plot area. So se você set the image here você will probably see seu image under the axis labels e scales e não in the plot area. <plot-background/> Opcional singleton nodo that descirbes the plot tipo. Valid types include color e image. Se tipo=”color”, designate the color with 6 byte hexadecimal notation. Quando tipo=”image”, the valor is a filepath (relative to the solução diretório) of an image arquivo to use as the plot background image.. Note: This image replaces the background of the plot area only. <orientation/> Opcional singleton whose texto valor pode ser either “Horizontal”, “Vertical”. Defaults to “Vertical”. <height/> Opcional singleton whose texto valor is an integer that represents the height of the chart. <width/> Opcional singleton whose texto valor is an integer that represents the width of the chart. <is-3D/> Opcional singleton whose texto valor pode ser either “true” ou “false”. Defaults to “false”. Se true the charting mecanismo does it best to render a 3-D view of the chart. <is-stacked/> Opcional singleton whose texto valor pode ser either “true” ou “false”. Defaults to “false”. Se true the charting mecanismo will create a stacked version of this chart tipo (se possible). <urlTemplate/> Opcional singleton whose texto valor is usado as a template to create a drill link mapear for the image. This is não usado with the ChartComponent. <paramName/> Opcional singleton whose test values is the parâmetro nome of the innermost consulta variável. Se this nome occurs in the urlTemplate, it will ser substituído with the correct item. This is não usado with the ChartComponent. <paramName2/> Opcional singleton whose test values is the parâmetro nome of the outermost consulta variável. Se this nome occurs in the urlTemplate, it will ser substituído with the correct item. This is não usado with the ChartComponent. <color-palette/> Singleton that contains a list of <color/> nodos that make up the series palette. <color/> Opcional multiple nodos that contain a 6 byte hexadecimal notation to ser usado as an entry in the series palette.

Pág 33

CategoryDatasetComponent The CategoryDatasetComponent is a UI componente that pode create a variety of charts including Bar, Line, Pie, Pie Grid, e Area. Where applicable there são several options that pode ser applied. The creation of the chart is commonly performed por a JSP ou indirectly por creating the appropriate portlet object. See the ChartComponent for explanations of cada nodo. <chart> <chart-tipo>BarChart</chart-tipo> <title>Sample Chart</title> <subtitle>a simple sample</subtitle> <chart-background tipo="color">#FFFFFF</chart-background> <chart-background-image>test\charts\ChartBackground.jpg</chart-background-image> <plot-background-color>#FFFFFF</plot-background-color> <plot-background-image>test\charts\ChartBackground.jpg</plot-background-image> <orientation>Horizontal</orientation> <height>550</height> <width>650</width> <is-3D>true</is-3D> <is-stacked>true</is-stacked> <urlTemplate><![CDATA[/pentaho/Pivot?solução=exemplos&path=análise&action=query1.xaction&departamento=.[{DEPARTAMENTO}]&measures=.[{MEASURES}]]]></urlTemplate> <paramName>MEASURES</paramName> <paramName2>DEPARTAMENTO</paramName2> <color-palette> <color>#336699</color> <color>#99CCFF</color> <color>#999933</color> <color>#666699</color> <color>#CC9933</color> <color>#006666</color> <color>#3399FF</color> <color>#993300</color> <color>#CCCC99</color> <color>#666666</color> <color>#FFCC66</color> <color>#6699CC</color> <color>#663366</color> <color>#9999CC</color> <color>#CCCCCC</color> <color>#669999</color> <color>#CCCC66</color> <color>#CC6600</color> <color>#9999FF</color> <color>#0066CC</color> <color>#99CCCC</color> <color>#999999</color> <color>#FFCC00</color> <color>#009999</color> <color>#99CC33</color> <color>#FF9900</color> <color>#999966</color> <color>#66CCCC</color> <color>#339966</color> <color>#CCCC33</color> </color-palette> </chart>

Pág 34

Componente de Filtro Seguro (Secure Filter) O componente secure filter possui duas funções relacionadas. Permite a você customizar a pergunta (prompt) padrão realizada pelo Contexto de Runtime e pode verificar para apenas seleções válidas serem retornadas. No exemplo abaixo, o Componente Secure Filter irá checar por um parâmetro nomeado DEPARTAMENT, se não existe, irá gerar a pergunta e mostrar os valores de seleção com base na coluna “Display” do parâmetro DEPARTAMENT_FILTER. Quando a seleçao for realizada por o usuário, e DEPARTAMENT passado para a Sequencia de ação e componente Secure Filter, irá verificar se o valor retornado existe na coluna “Dept” . Se o valor de DEPARTAMENT for válido, a execução da Sequencia de ação continua até o próximo componente na sequence. <action-definition> <component-name>SecureFilterComponent</component-name> <action-inputs> <DEPARTMENT type="string"/> <DEPARTMENT_FILTER type="result-set"/> </action-inputs> <action-outputs/> <component-definition> <selections> <DEPARTMENT style="select" prompt-if-one-value="true"> <filter value-col-name="Dept" display-col-name="Display"> DEPARTMENT_FILTER </filter> <title>Select the Department</title> </DEPARTMENT> </selections> <xsl>CustomReportParameters.xsl</xsl> <target>Report_Window</target> </component-definition> </action-definition> O atributo style define o estilo do controle a ser apresentado ao usuário O atributo prompt-if-one-value pergunta sempre ao usuário, mesmo se houver apenas uma escolha O atributo title define o texto a ser mostrado ao usuário

Pág 35

Escalonador (Scheduler) A Plataforma Pentaho BI utiliza atualmente o Quartz como escalonador. A implementação é persistida via JDBC, tolerante e recuperável em caso de falhas. Exceções escalonadas são resolvidas através de uma série de regras pré-definidas. Acesso ao escalonador é feito através de org.pentaho.plugin.quartz.JobSchedulerComponent implementando um documento solução. Exemplos podem ser encontrados em test/scheduler/. Existem quatro diferentes ações disponíveis ao escalonador. “startJob”, “suspendJob”, “resumeJob”, e “deleteJob”.

Ações • startJob – cria uma tarefa (job) e o gatilho (trigger) e registra a job e o trigger para execução pelo

escalonador. No caso de uma “Simple Trigger”, a execução ocorre quando a condição da trigger for encontrada e ocorre a um intervalo de repetição definido até que o número de ciclos tenha terminado. No caso de uma “Cron Trigger” o disparo da job ocorre de acordo com regras setadas na expressão cron string (veja abaixo). A job é um documento solução que deve ser executado. Isto permite o escalonamento de qualquer outra solução existente, tal como impressão e email. No evento de uma falha tal como queda de luz, crash de sistema, etc., após o escalonador reiniciar irá aplicar regras de exceção a qualquer trigger que tenha sido interrompida. Os valores de “jobName”, “triggerType” (e as entradas associadas trigger types), “solution”, “path”, e “action” precisam ser definidas no documento solução.

<action-sequence> <name>SchedulerTest_new_job.xaction</name> <version>1</version> <title>Schedules a task</title> <logging-level>debug</logging-level> <documentation> <author>William E. Seyler</author> <description>..</description> <help>This is just a test...</help> </documentation> <inputs> <jobAction type="string"> <default-value>startJob</default-value> </jobAction> <solution type="string"> <default-value>test</default-value> </solution> <path type="string"> <default-value>email</default-value> </path> <action type="string"> <default-value>text_only_email.xaction</default-value> </action> <jobName type="string"> <default-value>MyJob</default-value> </jobName> <triggerType type="string"> <default-value>simple</default-value> </triggerType> <triggerName type="string"> <default-value>MyTrigger</default-value> </triggerName> <repeatInterval type="string"> <default-value>10</default-value>

Pág 36

</repeatInterval> <repeatCount type="string"> <default-value>1</default-value> </repeatCount> <misfirePolicy type="string"> <default-value>INSTRUCTION_DELETE_TRIGGER</default-value> </misfirePolicy> </inputs> <outputs/> <resources/> <actions> <action-definition> <action-inputs> <jobAction type="string"/> <solution type="string"/> <path type="string"/> <action type="string"/> <jobName type="string"/> <triggerType type="string"/> <triggerName type="string"/> <repeatInterval type="string"/> <repeatCount type="string"/> <misfirePolicy type="string"/> </action-inputs> <component-name>JobSchedulerComponent</component-name> <action-type>schedule</action-type> <component-definition/> </action-definition> </actions> </action-sequence>

Figure X.X -- Sequencia de ação Sample StartJob • suspendJob – Pausa uma tarefa que esteja rodando especificada. Uma vez em pausa, a única maneira

de iniciar novamente será com resume job. Uma vez que a job for reiniciada, será aplicada a regra de exceção se requerido. A única entrada para esta açao é “jobName” a ser suspendida.

<action-sequence> <name>SchedulerTest_pause_job.xaction</name> <version>1</version> <title>Pauses a scheduled job</title> <logging-level>debug</logging-level> <documentation> <author>William E. Seyler</author> <description>..</description> <help>This is just a test...</help> </documentation> <inputs> <jobAction type="string"> <default-value>suspendJob</default-value> </jobAction> <jobName type="string"> <default-value>MyJob</default-value> </jobName> </inputs> <outputs/> <resources/>

Pág 37

<actions> <action-definition> <action-inputs> <jobAction type="string"/> <jobName type="string"/> </action-inputs> <component-name>JobSchedulerComponent</component-name> <action-type>schedule</action-type> <component-definition/> </action-definition> </actions> </action-sequence>

Figure X.X – Sequencia de ação Sample SuspendJob • resumeJob – Reinicia uma tarefa suspensa anteriormente. A única entrada será “jobName” a ser

reiniciada.

<action-sequence> <name>SchedulerTest_resume_job.xaction</name> <version>1</version> <title>Resumes a task</title> <logging-level>debug</logging-level> <documentation> <author>William E. Seyler</author> <description>..</description> <help>This is just a test...</help> </documentation> <inputs> <jobAction type="string"> <default-value>resumeJob</default-value> </jobAction> <jobName type="string"> <default-value>MyJob</default-value> </jobName> </inputs> <outputs/> <resources/> <actions> <action-definition> <action-inputs> <jobAction type="string"/> <jobName type="string"/> </action-inputs> <component-name>JobSchedulerComponent</component-name> <action-type>schedule</action-type> <component-definition/> </action-definition> </actions> </action-sequence>

Figure X.X – Sequencia de ação Sample resumeJob • deleteJob – exclui uma tarefa especificada imediatamente. Entretanto, se a tarefa está executando no

momento em algum processo do escalonador então ela irá continuar a executar sem que novas instancias desta tarefa sejam escalonadas. A única entrada sera “jobName”.

<action-sequence>

Pág 38

<name>SchedulerTest_delete_job.xaction</name> <version>1</version> <title>Deletes a Job</title> <logging-level>debug</logging-level> <documentation> <author>William E. Seyler</author> <description>..</description> <help>This is just a test...</help> </documentation> <inputs> <jobAction type="string"> <default-value>deleteJob</default-value> </jobAction> <jobName type="string"> <default-value>MyJob</default-value> </jobName> </inputs> <outputs/> <resources/> <actions> <action-definition> <action-inputs> <jobAction type="string"/> <jobName type="string"/> </action-inputs> <component-name>JobSchedulerComponent</component-name> <action-type>schedule</action-type> <component-definition/> </action-definition> </actions> </action-sequence>

Figure X.X – Sequencia de ação Sample deleteJob

Pág 39

Gatilhos (Triggers) A Plataforma Pentaho BI suporta dois tipos diferentes de gatilhos (triggers). • Trigger Simples– selecionado no nodo “triggerType” como “simple”. Esta opção permite que uma tarefa

seja escalonada em um intervalo regular especificado por um número dado de repetiçoes. As entradas a esta trigger são os valores inteiros “repeatInterval” (em segundos) e “repeatCount”. A trigger irá disparar imediatamente e continuar por um intervalo até o número de ciclos “repeatCount”. Veja exemplo abaixo.

• Trigger Cron– selecionado no nodo “triggerType” como “cron”. Esta trigger utiliza definições cron task

estilo unix. A trigger recebe um “cronString” que representa a definição exatamente como uma entrada em crontab. A seguir descrevemos o formato das expressões cron string.

<action-sequence> <name>SchedulerTest_new_cron_job.xaction</name> <version>1</version> <title>Schedules a task</title> <logging-level>debug</logging-level> <documentation> <author>William E. Seyler</author> <description>..</description> <help>This is just a test...</help> </documentation> <inputs> <jobAction type="string"> <default-value>startJob</default-value> </jobAction> <solution type="string"> <default-value>test</default-value> </solution> <path type="string"> <default-value>email</default-value> </path> <action type="string"> <default-value>text_only_email.xaction</default-value> </action> <jobName type="string"> <default-value>MyJob</default-value> </jobName> <triggerType type="string"> <default-value>cron</default-value> </triggerType> <triggerName type="string"> <default-value>MyTrigger</default-value> </triggerName> <cronString type="string"> <default-value>0 40 16 * * ?</default-value> </cronString> <misfirePolicy type="string"> <default-value>MISFIRE_INSTRUCTION_SMART_POLICY</default-value> </misfirePolicy> </inputs> <outputs/> <resources/> <actions>

Pág 40

<action-definition> <action-inputs> <jobAction type="string"/> <solution type="string"/> <path type="string"/> <action type="string"/> <jobName type="string"/> <triggerType type="string"/> <triggerName type="string"/> <cronString type="string"/> <misfirePolicy type="string"/> </action-inputs> <component-name>JobSchedulerComponent</component-name> <action-type>schedule</action-type> <component-definition/> </action-definition> </actions> </action-sequence>

Figure X.X – Sequencia de ação Sample Cron Trigger // NOTA o seguinte é do javadoc para org.quartz.cronTrigger A string "cronString" é formada por 6 ou 7 campos separados por espaços em branco. Os campos (6 obrigatórios e 1 opcional) são os seguintes: Nome do Campo Valores Permitidos Caracteres Especiais Válidos Segundos 0-59 , - * / Minutos 0-59 , - * / Horas 0-23 , - * / Dia-do-mês 1-31 , - * ? / L W C Mês 1-12 ou JAN-DEC , - * / Dia-da-semana 1-7 ou SUN-SAT , - * ? / L C # Ano (Opcional) vazio, 1970-2099 , - * / O caracter '*' é usado para especificar todos os valores. Por exemplo, "*" no campo minutos significa todos os minutos. O caracter '?' é permitido para os campos Dia-da-semana e Dia-do-mês. É usado como caracter coringa simples, especialmente entre um ou dois campos. Os exemplos irão clarificar abaixo. O caracter '-' é usado para especificar intervalos. Por exemplo "10-12" no campo hora significa as horas hours 10, 11 e 12". O caracter ',' é usado para indicar valores adicionais. Por exemplo "MON,WED,FRI" no campo Dia-da-semana significa os dias segunda, quarta e sexta-feira. O caracter '/' é usado para indicar incrementos. Por exemplo "0/15" no campo segundos significa "os segundos 0, 15, 30, e 45". E "5/15" equivale aos "segundos 5, 20, 35, e 50". Você pode também especificar '/' após '*' – neste caso '*' equivale a '0' antes de '/'. O caracter 'L' é permitido nos campos Dia-do-mês e Dia-da-semana. Este caracter é o mesmo do que o "último", mas tem significados diferentes em cada um destes campos. Por exemplo, o valor "L" em Dia-do-mês significa "o último Dia-do-mês" – dia 31 em janeiro, 28 em fevereiro (anos não bissestos), etc. Se usado no campo Dia-da-semana, simplesmente significa "7" ou "SAT". Mas se usado no campo Dia-da-semana após outro valor, significa "o último enésimo dia do mês " - Por exemplo "6L" equivale a "a última sexta-feira do mês ". Quando usar a opçao 'L', é importante não especificar listas, ou ranges de valores, senão ocorrerão resultados confusos.

Pág 41

O caracter 'W' é permitido para o campo Dia-do-mês e usado para indicar o dia de semana (dia útil) mais próximo do dia dado (Monday-Friday). Como exemplo, se você indicar "15W" como valor neste campo Dia-do-mês, o significado sera: "o mais próximo dia de semana do décimo quinto dia do mês ". então se o 15º for sábado, a trigger irá disparar na sexta feira dia 14ª. Se o 15º for domingo, a trigger irá disparar na segunda 16º. Se 15º for terça, estao dispara na própria terça. Entretanto, se você indicar "1W" e o primeiro dia for sábado, entao a trigger irá disparar em segunda-feira 3º, de modo a nao pular o limite do mês em questão. O caracter 'W' pode somente ser especificado quando Dia-do-mês for um dia simples, não um range ou lista de dias. Os caracters 'L' e 'W' podem também ser combinados em uma expressao Dia-do-mês de modo 'LW', o qual se traduz como o "último dia de semana do mês ". O caracter '#' é usado no campo Dia-da-semana para indicar o enésimo dia do mês. Por exemplo, o valor de "6#3" no campo Dia-da-semana significa a terceira sexta-feira do mês (day 6 = Friday e "#3" = a 3ª do mês). Outro examplo: "2#1" = a primeira segunda feira do mes e "4#5" = a quinta quarta feira do mes. Note que se você indicar "#5" e não existir 5º dia em algum mes, entao nada irá ocorrer. O caracter 'C' é usado nos campos Dia-da-semana e Dia-do-mês significando "calendar". Significa que os valores são calculados dentro de um calendário associado. Se nada for especificado, equivale a um calendário com tudo incluído. O valor de "5C" no campo Dia-do-mês significa "o primeiro dia incluído pelo calendário ou após o 5º". O valor de "1C" no campo Dia-da-semana significa "o primeiro dia incluído pelo calendário ou após domingo ". Os caracteres legais e nomes de meses e dias não “case sensitive”. Aqui estão alguns examplos: Expressão Significado "0 0 12 * * ?" Dispare às 12pm (meio-dia) todo dia "0 15 10 ? * *" Dispare às 10:15am todo dia "0 15 10 * * ?" Dispare às 10:15am todo dia "0 15 10 * * ? *" Dispare às 10:15am todo dia "0 15 10 * * ? 2005" Dispare às 10:15am todo dia durante o ano 2005 "0 * 14 * * ?" Dispare todo minuto iniciando às 2pm e terminando às 2:59pm, todo dia "0 0/5 14 * * ?" Dispare todos os 5 minutos iniciando às 2pm e terminando às 2:55pm, todo dia "0 0/5 14,18 * * ?" Dispare todos 5 minutos iniciando às 2pm e terminando às 2:55pm, E dispare

todos 5 minutos iniciando às 6pm e terminando às 6:55pm, todo dia "0 0-5 14 * * ?" Dispare toda minutos iniciando às 2pm e terminando às 2:05pm, todo dia "0 10,44 14 ? 3 WED" Dispare às 2:10pm e às 2:44pm toda quarta do mês março "0 15 10 ? * MON-FRI" Dispare às 10:15am toda segunda, terça, quarta, quinta e sexta "0 15 10 15 * ?" Dispare às 10:15am no 15ºdia de todo mês "0 15 10 L * ?" Dispare às 10:15am no último dia de todo mês "0 15 10 ? * 6L" Dispare às 10:15am na última sexta-feira de todo mês "0 15 10 ? * 6L 2002-2005"

Dispare às 10:15am em toda última sexta de todo mês durante os anos de 2002, 2003, 2004 e 2005

"0 15 10 ? * 6#3" Dispare às 10:15am na Terceira terça de todo mês

Exceções (Misfires) Quando a trigger não consegue ser disparada por razões tais como o Escalonador tenha sido parado ou o sistema tenha caído, este evento é referido como exceção. Exceções são determinadas pela instrução de exceção de triggers. Existem tipos de exceções disponíveis para todas as triggers e algumas somente para “simple” ou “cron”. Todas as Triggers – estas instruçoes de exceção são aplicaveis para qualquer trigger.

Pág 42

MISFIRE_INSTRUCTION_SMART_POLICY: esta instrução de exceção é o padrão de todas as triggers criadas. Ela instrue a trigger a utilizar a política padrão dependendo do tipo de trigger. Para uma “simple” trigger a regra é a seguinte:

• Se o Repeat Count for 0 então a instrução seguirá o padrão MISFIRE_INSTRUCTION_FIRE_NOW. • Se o Repeat Count for REPEAT_INDEFINITELY, então a instrução será interpretada como

MISFIRE_INSTRUCTION_RESCHEDULE_NEXT_WITH_REMAINING_COUNT. CUIDADO: usar MISFIRE_INSTRUCTION_RESCHEDULE_NEXT_WITH_REMAINING_COUNT com uma trigger que possui um tempo de finalizaçao não nulo pode fazer com que a trigger nunca mais seja iniciada se o tempo de finalização tiver ocorrido (passado) durante o período da exceção.

• Se o Repeat Count for 0, então a instrução seguirá o padrão MISFIRE_INSTRUCTION_RESCHEDULE_NOW_WITH_EXISTING_REPEAT_COUNT.

INSTRUCTION_RE_ EXECUTE _JOB: Instrui ao Escalonador que a Trigger requer que o JobDetail re-execute imediatamente. INSTRUCTION_SET_TRIGGER_COMPLETE: Instrui ao Escalonador que a Trigger deve ser colocada no estado COMPLETE. Essencialmente pula a exceção da trigger. INSTRUCTION_DELETE_TRIGGER: Instrui ao Escalonador que a Trigger deve ser excluída (deleted). INSTRUCTION_SET_TRIGGER_ERROR: Instrui ao Escalonador que a Trigger deve ser colocada em estado de erro. Simple Triggers – estas instructions de exceção são aplicáveis somente a triggers “simple”. MISFIRE_INSTRUCTION_FIRE_NOW: Instrui ao Escalonador que em situaçao de exceção, a trigger deseja ser disparada agora. NOTA esta instruçao deve tipicamente ser usada somente para triggers nao repetitivas. Se for usado em uma trigger com o repeat count > 0 entao sera equivalente a instruçao MISFIRE_INSTRUCTION_RESCHEDULE_NOW_WITH_REMAINING_REPEAT_COUNT. MISFIRE_INSTRUCTION_RESCHEDULE_NOW_WITH_EXISTING_REPEAT_COUNT: Instrui ao Escalonador que em situação de exceção, a trigger deseja ser re-escalonada de modo que o repeat count permaneça conforme está. NOTA: o uso desta instrução causa a trigger ‘esquecer’ o start-time e o repeat-count que foi originariamente setado. NOTA: Esta instruçao pode causar a Trigger atingir o estado 'COMPLETE' depois de disparada, se todos os tempos de disparo já tiverem passado. MISFIRE_INSTRUCTION_RESCHEDULE_NOW_WITH_REMAINING_REPEAT_COUNT: Instrui o Escalonador que em situação de exceção, a trigger deseja ser re-escalonada agora com o repeat count ajustado para o que deveria ser se não tivesse perdido nenhum disparo. NOTA: o uso desta instrução leva a trigger a ‘esquecer’ o start-time e o repeat-count que foram originariamente setados (isto somente pode causar problemas se você necessida determinar quais eram os valores posteriormente). NOTA: Esta instruçao pode causar a Trigger atingir o estado 'COMPLETE' depois de disparada, se todos os tempos de disparo já tiverem passado. MISFIRE_INSTRUCTION_RESCHEDULE_NEXT_WITH_REMAINING_COUNT: Instrui o Escalonador que em situação de exceção, a trigger deseja ser re-escalonada até o próximo intervalo depois de ‘agora’ e com o repeat count ajustado ao que deveria ser se não tivesse sido perdido nenhum disparo. NOTA/AVISO: Esta instruçao pode causar a Trigger atingir o estado 'COMPLETE' diretamente se todos os tempos de disparo já tiverem passado. MISFIRE_INSTRUCTION_RESCHEDULE_NEXT_WITH_EXISTING_COUNT: Instrui o Escalonador que em situação de exceção, a trigger deseja ser re-escalonada até o próximo intervalo depois de ‘agora’ e com o repeat count deixado sem mudança. NOTE: o uso desta instrução causa a trigger ‘esquecer’ o repeat-count que foi originariamente setado. NOTA/AVISO: Esta instruçao pode causar a Trigger atingir o estado 'COMPLETE' diretamente se todos os tempos de disparo já tiverem passado. CRON Triggers – estas instructions de exceção são aplicáveis somente a triggers “cron”

Pág 43

MISFIRE_INSTRUCTION_FIRE_ONCE_NOW: Instrui o Escalonador que em situação de exceção, a trigger deseja ser disparada agora. MISFIRE_INSTRUCTION_DO_NOTHING: Instrui o Escalonador que em situação de exceção, a trigger deseja que o seu next-fire-time seja ajustado paa o próximo intervalo após o momento corrente (levando em conta qualquer parâmetro <code>{@link Calendar}</code>, mas não deseja ser disparada agora).

Pág 44

Fontes de Dados Os componentes de fontes de dados permitem acesso a uma grande variedade de tipos de fonte de dados. Cada tipo de implementação permite a consulta de um específico fonte de dados usando um string de consulta na syntaxe natural da fontes de dados. Por exemplo dados SQL utilizam sintaxe SQL para consulta. Dados MDX utilizam sintaxe MDX e dados XML utilizam XQuery. Os componentes de fontes de dados incluem as seguintes implementações:

• MDXLookupRule: para dados multidimensionais (a implementação atual é para o mondrian) • SQLLookupRule: para consultas a bases de dados SQL. • XQueryLookupRule: para realizar seleções XQuery em Documentos XML.

MDXLookupRule O componente MDX lookup proporciona facilidade para consulta multidimensional a fontes de dados usando a estrutura de consulta MDX. Um exemplo de sequencia de ação MDXLookupRule segue abaixo: <action-sequence>

<name>MDX_Datasource.xaction</name> <version>1</version> <title>%title</title> <logging-level>debug</logging-level> <documentation> <author>William Seyler</author> <description>%description</description> <help></help> <result-type>rule</result-type> <icon>MDX_Datasource.png</icon> </documentation> <outputs> <rule-result> <type>list</type> </rule-result> </outputs> <resources> <catalog> <url> <location>samples/reporting/SampleData.mondrian.xml</location> <mime-type>text/xml</mime-type> </url> </catalog> </resources>

<actions> <action-definition> <action-outputs> <rule-result type="list"/> </action-outputs> <component-name>MDXLookupRule</component-name> <action-type>rule</action-type> <component-definition>

<connection>] <![CDATA[jdbc:hsqldb:hsql://localhost:9001/sampledata]]>

</connection> <location>mondrian</location> <user-id>sa</user-id> <password></password> <query>

Pág 45

<![CDATA[with member [Measures].[Variance Percent] as '([Measures].[Variance] / [Measures].[Budget])', format_string = IIf(((([Measures].[Variance] / [Measures].[Budget]) * 100.0) > 2.0), "|#.00%|style='green'", IIf(((([Measures].[Variance] / [Measures].[Budget]) * 100.0) < 0.0), "|#.00%|style='red'", "#.00%")) select Crossjoin({[Region].[All Regions].[Central], [Region].[All Regions].[Eastern], [Region].[All Regions].[Southern], [Region].[All Regions].[Western]}, {[Measures].[Actual], [Measures].[Budget]}) ON columns, Hierarchize(Union({[Department].[All Departments]}, [Department].[All Departments].Children)) ON rows from [Quadrant Analysis]]]>

</query> </component-definition> </action-definition>

</actions> </action-sequence> A consulta MDX requer as entradas: <connection> NÃO REQUERIDO – esta é uma string de conexão JDBC para a fonte de dados. Se você precisa conectar-se a outra fonte de dados que o hypersonic você deve proporcionar o JDBC drivers na string, veja <mdx-connection-string> abaixo para informação em como fazer isto. NOTA: um dos dois, este nodo ou o nodo <mdx-connection-string>, deve ser especificado obrigatoriamente. <query> REQUERIDO – esta é a consulta string MDX que define os dados desejados (dataset). Para mais informação sobre consulta MDX veja a documentaçao do mondrian documentation ou visite: http://www.informit.com/articles/article.asp?p=29418&seqNum=3&rl=1 <catalog> NÃO REQUERIDO – o caminho do catálogo ROLAP. Se o catalogo iniciar com HTTP então o caminho é avaliado como URL absoluta e o sistema tentará carregá-lo diretamente. Se o catalogo não iniciar com HTTP então o caminho é considerado a partir da raiz da solução e a URL é construída de acordo e passada a fonte de dados do mecanismo (mondrian). NOTA: um dos dois, este nodo ou o nodo <mdx-connection-string>, deve ser especificado. <location> NÃO REQUERIDO – sempre “mondrian” para a implementação atual. NOTA: um dos dois, este nodo ou o nodo <mdx-connection-string>, deve ser especificado. <user-id> NÃO REQUERIDO – o usuário ID do JDBC. Se usar outro banco que não o hypersonic então você pode precisar usar o <mdx-connection-string/> para ajustar o usuário ID e password. <password> NÃO REQUERIDO – o password JDBC. Se usar outro banco que não o hypersonic então você pode precisar usar o <mdx-connection-string/> para ajustar o usuário ID e password. <mdx-connection-string> NÃO REQUERIDO - a mdx-connection-string pode ser usado no lugar de todas as propriedades de conexão acima e de fato irá sobrescrevê-las. Este string é uma lista de propriedades separadas por ponto-e-vírgula a qual é passada ao mondrian para criação da conexão. Eis um exemplo de conexão baseada em mdx-connection-string: <mdx-connection-string>

<![CDATA[ Provider=mondrian; Jdbc=jdbc:odbc:MondrianFoodMart; Catalog=/WEB-INF/FoodMart.xml ]]>

</mdx-connection-string>

Pág 46

NOTA: Quando usar este formato, o nome de usuário nome e password pode ser passado como parte da string de conexão jdbc, dependendo do driver sendo usado. Nomes de Drivers podem também ser passados nesta string. Mais informação sobre este tipo de string consulte a documentação do mondrian. NOTA: Se <mdx-connection-string> não for definida, então <connection> é requerido.

SQLLookupRule O componente SQLLookupRule é usado para conectar com fontes de dados JDBC. Um documento exemplo usando SQLLookupRule está abaixo: <action-sequence>

<name>SQL_Datasource.xaction</name> <version>1</version> <title>%title</title> <logging-level>debug</logging-level> <documentation> <author>James Dixon</author> <description>%description</description> <help></help> <result-type>rule</result-type> <icon>SQL_Datasource.png</icon> </documentation> <inputs> <dept type="string"> <default-value>Product Development</default-value> </dept> </inputs> <outputs> <rule-result> <type>list</type> </rule-result> </outputs> <resources/> <actions>

<action-definition> <action-inputs> <dept type="string"/> </action-inputs> <action-outputs> <rule-result type="list"/> </action-outputs> <component-name>SQLLookupRule</component-name> <action-type>rule</action-type> <component-definition> <jndi>SampleData</jndi> <query>

<![CDATA[select REGION, MANAGER_NAME, EMAIL from DEPARTMENT_MANAGERS]]>

</query> </component-definition> </action-definition> </actions> </action-sequence>

Pág 47

<jndi> NÃO REQUERIDO – este tag é o nome de uma fonte de dados JNDI válida. NOTA: Se você não tem uma fonte de dados jndi, então deve usar a tag <connection/> e uma string de conexão JDBC válida. <connection/> NÃO REQUERIDO – este tag é uma string de conexão JDBC válida. Quando usar este método para se conectar a um banco de dados você deve assegurar que um driver JDBC próprio jar está disponível no classpath atual. NOTA: Você deve proporcionar <connection> ou <jndi> <consulta> REQUERIDO – este é o string de consulta SQL que retorna os dados requeridos. <driver> NÃO REQUERIDO – este é o nome do driver que a connection string requer. Não requerido para JNDI ou se você usa o Banco de dados Hypersonic padrão. <usuário-id> NÃO REQUERIDO - usuário ID do JDBC. Também pode ser passado como parte de <connection> string. <password> NÃO REQUERIDO - JDBC password. Também pode ser passado como parte de <connection> string. <live> NÃO REQUERIDO – ajuste para true para não realizar “caching” do result set. Se não for especificado ou ajustado para false, etnão os dados em cachê serão retornados. NOTA: Quando usar dados em cache , mudanças feitas após a consulta não aparecerão no result set. A regra XQuery permite que consultas XQuery sejam feitas em Documentos XML. O componente irá tentar retornar um result set com os cabeçalhos apropriados. Se o Documento XML conter uma sessão de comentário descrevendo os tipos de coluna, então o result-set será montado usando o tipo especificado. Por exemplo: <result-set> <!--java.lang.String, java.math.BigDecimal-->

<row> <REGION>Central</REGION> <VARIANCE>24685</VARIANCE>

</row> </result-set> Abaixo está um exemplo de XQueryLookupRule. <action-sequence> <name>XQ_Datasource.xaction</name> <version>1</version> <title>%title</title> <logging-level>debug</logging-level> <documentation> <author>William Seyler</author> <description>%description</description> <help></help> <result-type>rule</result-type> <icon>XML_Datasource.png</icon> </documentation> <outputs> <rule-result> <type>list</type> </rule-result>

Pág 48

</outputs> <resources> <document> <solution-file> <location>books.xml</location> <mime-type>text/xml</mime-type> </solution-file> </document> </resources>

<actions> <action-definition>

<action-outputs> <rule-result type="list"/> </action-outputs> <component-name>XQueryLookupRule</component-name> <action-type>rule</action-type> <component-definition> <query><![CDATA[/bookstore/book]]></query> </component-definition> </action-definition> </actions> </action-sequence> <consulta> REQUERIDO – o único tag suportado, é o string de seleção XQuery. Se o documento definir, então o string de consulta será avaliado como caminho absoluto (absolute path). Caso contrário, então o caminho da solução será adicionado ao caminho totalmente qualificado do documento.

Pág 49

Apêndice A – Seqüência de Ação XML em Detalhes Nodos XML marcados com REQUERIDO são necessários somente se os nodos-pais estão sendo usados. Atributos mostrado em colchetes [ ] são opcionais. <action-sequence> REQUERIDO – Nodo no nível raiz do Documento de Seqüência de Ação

<nome> REQUERIDO – O nome da Seqüência de Ação. O nome deve ser o mesmo do nome do arquivo que contem a seqüência. <version> NÃO USADO – A versão deste documento <title> NÃO REQUERIDO – Nome amigável do documento. Utilizado somente visualização. <logging-level> NÃO REQUERIDO – define o nível de login para a inteira Seqüência de Ação. Valores válidos são: TRACE, DEBUG, INFO, WARN, ERROR and FATAL. Caso nenhum nível é definido, ERROR será utilizado. <documentation> NÃO REQUERIDO – contem nodos descritivos usados para gerar o documento.

<author> - NÃO REQUERIDO – O autor da Seqüência de Ação <description> - NÃO REQUERIDO – Breve (1-3 linhas) descrição da Seqüência de Ação. Esta descrição é usada pelo componente de navegação para gerar sua visualização. <help> - NÃO REQUERIDO – Descrição detalhada da Seqüência de Ação, incluindo instruções para seu uso por um usuário final. <result-tipo> - NÃO REQUERIDO – Tipo de resultados gerados por esta Seqüência de Ação. É utilizada pelo componente de navegação para gera sua visualização. Seqüência de Ação sem um <result-tipo> não serão mostradas pelo componente de navegação. Valores válidos são: Report, Process, Rule, View and None.

<icon> - NÃO REQUERIDO – Imagem do ícone de navegação utilizada para sua visualização. O caminho da imagem relativo ao diretório que o documento de Seqüência de Ação está. Por exemplo: Example1_image.png

<inputs> - NÃO REQUERIDO – Coleção de parâmetros de entrada.

<param-nome tipo=”data-tipo” > - NOT REQUERIDO – param-nome é o nome do parâmetro que a Seqüência de Ação está esperando em tempo de execução. O tipo de atributo especifica o tipo de dado do parâmetro. Veja abaixo por tipos válidos.

<default-valor> - NÃO REQUERIDO – Permite o parâmetro de entrada especificar um valor padrão, caso um valor não tenha sido especificado. Caso o nodo default-valor é presente, mas sem um valor especificado, o valor será sempre que possível perguntado ao usuário. <sources> - NÃO REQUERIDO – lista ordenada de parâmetros de entrada, em termos de ordem de chamada, necessários para definir um parâmetro da Seqüência de Ação. Valores válidos são: request, session and runtime. Nota: se o param-nome é definido, mas o default-valor e sources não sào especificados, um erro de validação irá ocorrer.

<outputs> - NÃO REQUERIDO – coleção de parâmetros de saída.

Pág 50

<param-nome tipo=”data-type” > - NOT REQUERIDO – param-nome é o nome de um parâmetro que a Seqüência de Ação está esperando ser definido, após a execução de todas as ações. O atributo tipo especifica o tipo de dado deste parâmetro. Veja abaixo por valores válidos.

<logging-level> NÃO REQUERIDO – Define o nível de login durante a execução de uma ação. Valores válidos são: TRACE, DEBUG, INFO, WARN, ERROR e FATAL. Caso nenhum nível seja informado, ERROR sera usado.

<resources> - NÃO REQUERIDO – Coleção de recursos de parâmetros.

<resource-nome > - NÃO REQUERIDO – resource-nome é o nome do recurso que estará disponível para a Definição de Ação em tempo de execução. O atributo tipo especifica o tipo de dado deste parâmetro. Veja abaixo por valores válidos.

<resource-tipo> - REQUERIDO – O nome do tipo de recurso requerido. Valores válidos são: solution-file, file and url.

<location> - REQUERIDO – O caminho para o recurso. Para um recurso-tipo igual a “solution-file”, a localização de um pathname é relativa ao nível mais alto da solução corrente. Se o tipo do recurso é “file”, então a localização é definida como o completo caminho. Para resource-tipo “url”, a localização é definida como um endereço de URL. <mime-type> - NÃO REQUERIDO – Dá uma noção acerca do tipo mime do recurso.

<actions [loop-on=”parâmetro-nome”] > - REQUERIDO – O nodo de ações contêm nodos de “definição de ações” e opcionalmente mais nodos de ações. O atributo loop-on é opcional. Quando ele é usado, os nodos sem “ações” serão executados múltiplas vezes. É necessário especificar um parâmetro que é uma lista de tipos (lista de sting ou uma lista de mapas de propriedades) e o grupo de nodos que serão executados uma vez para cada elemento da lista. Um parâmetro de entrada será gerado com o mesmo nome do atributo loop on, mas terá o valor de um elemento na lista. Por exemplo, se um atributo loop on chamado “departamento” é uma lista de strings com nomes de departamentos, então o parâmetro chamado departamento estará disponível. A cada iteração, ao parâmetro será atribuída um nome de departamento.

<actions [loop-on=”parâmetro-nome”] > - NÃO REQUERIDO – Como um simples nível de looping não é muito divertido, nodos de ações podem ser encaixados dentro de outros nodos, em quantos níveis desejados. <action-definition> - REQUERIDO (No mínimo 1) – Define uma completa chamada para um componente para executar uma tarefa.

<action-inputs> - NÃO REQUERIDO – Coleção de parâmetros de entrada de ações.

<input-nome type=”data-type” mapping=”param”> - NOT REQUERIDO – input-nome é o nome do parâmetro que estará dsiponível para Definição de Ação em tempo de execução. O atributo tipo especifica o tipo de dado do parâmetro. Veja abaixo por válidos tipos de dados.

Pág 51

O atributo mapping permite esta entrada ser mapeada para uma entrada de uma Seqüência de Ação ou uma saída de uma prévia definição de ação com um nome diferente.

<action-outputs> - NÃO REQUERIDO – Coleção de parâmetros de saída de uma ação.

<output-nome type=”data-type” > - NOT REQUERIDO – outpu -nome é o nome de um parâmetro que o Componente definirá após a sua execução. O atributo tipo especiifica o tipo de dado deste parâmetro. Veja abaixo por tipos válidos.

t

<component-nome> - REQUERIDO – O nome da classe java que executa a ação. <component-definition> - REQUERIDO – O componente específico XML. Veja a documentação deste componente específico para informações adicionais. Este nodo pode estar vazio, mas ele deve existir ou um erro de validação ocorrerá.

Pág 52

Apêndice B

Tipos de Dados das Sequências de Ação Os seguintes tipos de dados são correntemente suportados pela Plataforma Pentaho de BI. string – O padrão Java String. Exemplo: Este nodo XML define uma string com um valor default de “Central.” O RuntimeContext primeiro procurará por um par6ametro de entrada chamado “REGION” na requisição http. A seguir, esta classe solicita um objeto chamado “aRegion.” Caso nenhum destes valores exista, uma string com valor If neither “Central” é criada. <region type="string"> <default-valor>Central</default-valor> <sources> <request>REGION</request> <session>aRegion</session> </sources> </region> long – Um Java Long Object. Exemplo: Este nodo XML nodo define um objeto long com um valor default de 25. <amount type="long"> <default-valor>25</default-valor> </amount> string-list – Uma lista de Java String Objects. Exemplo: Este nodo XML define uma lista de strings denominada “to-address” com 4 entradas. Itens na lista são armazenados em nodos <list-item>. <to-address type="string-list"> <default-valor type="string-list"> <list-item>joe.pentaho@pentaho.org</list-item> <list-item>admin@pentaho.org</list-item> <list-item>sales@pentaho.org</list-item> <list-item>noxidj@pentaho.org</list-item> </default-valor> </to-address > property-mapear – Um mapa de propriedades de Java Strings. Exemplo: Este nodo XML define um mapa de propriedades com o nome “veggie-data” com 4 pares de valores. Itens na lista são armazenado em nodos <entry key=”xxx”> . Mapas de propriedades são usados para representar uma simples linha de dados a partir de uma consulta a uma base de dados. As chaves mapeiam nomes de colunas e os valores dos mapas para os dados nas colunas.

<veggie-data type="property-mapear "> <default-valor type="property-mapear"> <property-mapear> <entry key="nome">carrot</entry> <entry key="color">orange</entry> <entry key="shape">cone</entry> <entry key="texture">bumpy</entry> </property-mapear> </default-valor></veggie-data>

Pág 53

property-mapear-list – Uma lista de mapas de propriedades de Java Strings. Exemplo: Este nodo XML define um mapa de propriedades com o nome “fruit-data” com 3 conjuntos de mapas de propriedades. Itens na lista são armazenados em nodos <entry key=”xxx”>. Listas de mapas de propriedades são algumas vezes utilizadas para armazenar os resultados de uma consulta a uma base de dados. Cada mapa de propriedade na lista representa uma linha de dados com as chaves sendo mapeadas para nomes de colunas e os valores para células de dados.

<fruit-data type="property-mapear-list"> <default-valor type="property-mapear-list"> <property-mapear> <entry key="nome">orange</entry> <entry key="color">orange</entry> <entry key="shape">sphere</entry> <entry key="texture">dimply</entry> </property-mapear> <property-mapear> <entry key="nome">grapefruit</entry> <entry key="color">Yellow</entry> <entry key="shape">sphere</entry> <entry key="texture">dimply</entry> </property-mapear> <property-mapear> <entry key="nome">cucumber</entry> <entry key="color">green</entry> <entry key="shape">ellipsoid</entry> <entry key="texture">smooth</entry> </property-mapear> </default-valor> </fruit-data>

content – Conteúdo é uma vasta quantidade de dados que é gerada dentro de um componente. Um exemplo de conteúdo é um arquivo PDF gerado por um componente de relatório. Não é possível definir um valor default para conteúdos, pois ele pode ser de qualquer tipo e é representado internamente como um byte stream. Exemplo: Este XML define um nodo conteúdo denominado ‘attachment’ que é esperado existir em um conteúdo de execução chamado “relatório-output”. Neste exemplo, o componente de relatório gera um documento e o armazena como um ‘relatório-output’. O componente de e-mail irá embutir este relatório como um anexo em um e-mail. <attachment type="content"> <sources> <runtime>relatório-output</runtime> </sources> </attachment>

Pág 54

Tipos de Recursos das Sequências de Ação Os seguintes tipos de recursos são correntemente suportados pela Plataforma pentaho de BI. solution-file – Um arquivo no sistema de arquivos relativo a localização do Documento de Seqüência de Ação. <solution-file> <location>MyRelatório.rptdesign</location> <mime-type>texto/xml</mime-type> </solution-file> file – Um caminho absoluto no sistema de arquivos. <file> <location>D:\samples\relatórioing\MyRelatório.rptdesign</location> <mime-type>texto/xml</mime-type> </file> url – Uma URL. <file> <location>http://www.myserver.com/logo.png</location> <mime-type>image/png</mime-type> </file>

Pág 55

Apêndice C Definições de Componentes Os componentes na Plataforma Pentaho de BI podem ser vistos como blocos totalmente operacionais, com entradas, saídas e definições. Os parâmetros que serão disponibilizados para um componente são definidos por um nodo ‘action-inputs’. Os componentes não têm acesso a quaisquer parâmetros que não foram especificados nas ‘action-inputs.’ As action-inputs podem ser originadas a partir de: parâmetros definidos nas entradas dos documentos de Seqüência de Ação e quaisquer parâmetros definidos em um ‘action-outputs’ de um componente prévio. As ‘action-outputs’ definem quais parâmetros estarão disponíveis após a execução de um componente. Outros componentes que serão executados posteriormente poderão usar estas saídas como entradas. Quando a Seqüência de Ação termina sua execução, os dados serão temporariamente armazenados em um repositório em tempo de execução. Somente serão salvos os parâmetros definidos nos nodos ‘outputs’ de um documento Seqüência de Ação. Cada componente na Plataforma Pentaho de BI tem entradas únicas e específicas e as definições de componentes devem ser especificadas de acordo. Eles também possuem entradas e definições opcionais. Esta seção descreve suas interfaces.

HelloWorldComponent HelloWorldComponent é um componente extremamente simples. Ele simplesmente retorna o texto “Hello World” seguido por uma string entre aspas.

component-nome: HelloWorldComponent

action-entradas: Nenhuma

action-outputs: Nenhuma

component-definition: <quote>Uma mensagem para mostrar</quote> EXEMPLO <action-definition> <action-entradas/> <action-outputs/> <component-nome>HelloWorldComponent</component-nome> <component-definition> <quote>Greetings from the Pentaho BI Platform.</quote> </component-definition> </action-definition>

Pág 56

EmailComponent EmailComponent é utilizado para enviar e-mails baseados em texto ou HTML. Eles podem conter anexos. Se o tipo de dado do parâmetro to é um mapa de propriedades, então o mapa contém os pares de valores (nomes) para os parâmetros to, subject e from. O parâmetro attach deve conter o nome do parâmetro de tipo conteúdo que contem o anexo. attach-nome é o nome do arquivo em anexo para o cliente do e-mail.

component-nome: EmailComponent

action-entradas: REQUERIDO to – string ou mapa de propriedades subject – string message-plain or message-html – string OPCIONAL from – string Caso não especificado, o default do “email_config.xml” será usado cc – string bcc – string attach – string attach-nome – string action-outputs: Nenhum

component-definition: Nenhum EXEMPLO <action-definition> <action-entradas> <to type="string"/> <from type="string"/> <subject type="string"/> <message-plain type="string"/> </action-inputs> <component-nome>EmailComponent</component-nome> <component-definition/> </action-definition> Para um completo exemplo de Seqüência de Ação com HTML, texto e anexos, veja samples/bursting/send-email.xaction da solução test-solution

Pág 57

JavascriptRule O componente JavascriptRule executará o Javascript definido no nodo script da definição do componente. Parâmetros especificados como entradas estarão disponíveis para o script. O JavascriptRule pode ter uma ou mais saídas. Se a regra requer somente uma única saída, então à única instrução de retorno do javascript será atribuído aquela saída. Se existem múltiplos atributos, então o código em javascript deve retornar um vetor de saídas. A cada elemento do vetor será designada uma saída da ação. O componente também pode definir elementos de uma biblioteca na definição de componentes. Cada arquivo de biblioteca especificado deve existir na solução, e será conectado ao script que é especificado na definição do componente. Desta forma, é possível criar bibliotecas dos códigos mais usados em javascript, e incluí-los em tempo de execução. No exemplo abaixo,

component-nome: JavascriptRule

action-entradas: OPCIONAL Qualquer parâmetro especificado estará disponível como uma variável para o mecanismo de script. action-outputs: REQUERIDO Deverão existir uma ou mais saídas definidas.

component-definition: script o javascript para executar library um ou mais arquivos com javascripts para incluir. outputx Mapeamento do vetor de saída ao output. EXEMPLO

<action-definition> <component-nome>JavascriptRule</component-nome> <action-outputs> <region type="string"/> <state type="string"/> </action-outputs> <action-type>rule</action-type> <component-definition> <script> <![CDATA[ function getResult() { var result = new Array(2); result[0] = "Western"; result[1] = "California"; retorna result; } getResult(); ]]> </script> <output1>region</output1> <output2>region</output2> </component-definition> </action-definition>

Pág 58

SQLLookupRule O componente SQLLookupRule executará a consulta SQL definida no nodo consulta da definição do componente. Parâmetros especificados como entradas podem ser usados para substituir texto na consulta. A string de substituição é da forma {nome}, onde nome e o parâmetro nome deverão estar devidamente ajustados. NO exemplo, {dept} na consulta será substituída pelo valor especificado pelo dept nas ações-entradas.

component-nome:.SQLLookupRule

action-inputs: OPCIONAL Qualquer parâmetro especificado pode substituri um texto como {nome} na consulta, onde nome combina com o parâmetro nome. action-outputs: REQUERIDO rule-result – lista de mapas de propriedade

component-definition:

jndi – Se uma conexão a uma base de dados JNDI é fornecida, ela será usada prioritariamente para a ‘connection’, ‘usuário-id’, ‘password’, and ‘driver’ connection – Se uma conexão JNDI não é fornecida, o parâmetro especificado será usado para criar uma conexão para a base de dados. user-id – Se uma conexão JNDI não é fornecida, o parâmetro especificado será usado para criar uma conexão para a base de dados. password – Se uma conexão JNDI não é fornecida, o parâmetro especificado será usado para criar uma conexão para a base de dados. driver - Se uma conexão JNDI não é fornecida, o parâmetro especificado será usado para criar uma conexão para a base de dados.

EXEMPLO <action-definition> <component-nome>SQLLookupRule</component-nome> <action-entradas> <dept type="string"/> </action-inputs> <action-outputs> <rule-result type="string"/> </action-outputs> <component-definition> <jndi>sampledata</jndi> <connection>jdbc:hsqldb:hsql://localhost/sampledata</connection> <usuário-id>pentaho_usuário</usuário-id> <password>password</password> <driver>org.hsqldb.jdbcDriver</driver> <query><![CDATA[

select distinct PositionTitle from quadrant_actuals where department='{dept}' order por PositionTitle]]>

</query> </component-definition> </action-definition>

Pág 59

PrintComponent PrintComponent é utilizado para imprimir relatórios e conteúdos para o nome da impressora disponível. O conteúdo pode ser especificado da seguinte forma: (1) Especificando o arquivo como um recurso printFile ou definindo o componente (2) Definindo uma ação prévia na Have a previous action in the sequence output content to the parâmetro report-output. Atualmente, o org.pentaho.plugin.jfreerelatório.JFreeComponent, org.pentaho.plugin.eclipsebirt.BIRTComponent, e org.pentaho.plugin.jasperrelatórios.JasperComponent têm a habilidade de gerar conteúdos e relatórios como relatório-output. Caso nenhum conteúdo seja especificado para impressão, a Seqüência de Ação falhará.

component-nome: PrintComponent

action-inputs: OPCIONAL printFile – string Caso não especificado, o parâmetro report-output é utilizado. printerName – string Caso não especificado, a impressora padrão sera usadas. copies – número

-

action-outputs: last-printer-selected – string Caso não especificado nas action outputs e action-inputs, o valor não é definido. component-definition: Nenhum EXEMPLO <action-definition> <action-inputs> <copies tipo="string"/> <orientation tipo="string"/> <printerName tipo="string"/> </action-inputs> <component-nome>PrintComponent</component-nome> <action-tipo>print</action-tipo> <component-definition/> </action-definition> Para um completo exemplo de Seqüência de Ação com anexos em HTML e texto, veja samples/bursting/send-email.xaction na test-solution.

Pág 60

JobEscalonadorComponent Veja a Seção Escalonamento acima.

EscalonadorAdminComponent Veja a Seção Escalonamento acima. .

BIRTRelatórioComponent Por favor, veja Integrando Relatórios BIRT.

ContentRepositoryCleaner ContentRepositoryCleaner é utilizado para remover itens velhos do repositório. É necessário somente uma entrada, um número que representa por quanto tempo um item é permitido a residir no repositório. Se o valor 90 é usado, então itens mais velhos que 90 dias serão removidos do repositório.

component-nome: ContentRepositoryCleaner

action-entradas: REQUERIDO days_old – O número de dias que um item deve residir no repositório. action-outputs: delete_count – O número de itens a serem excluídos do repositório. component-definition: Nenhum EXEMPLO <action-definition>

<action-inputs> <days_old type="string" />

</action-inputs> <action-outputs> <delete_count type="string" /> </action-outputs> <component-nome>ContentRepositoryCleaner</component-nome> <action-tipo>rule</action-tipo> <component-definition></component-definition> </action-definition> Para um completo exemplo de Seqüência de Ação com anexos em HTML e texto, veja Advanced\Content\clean_repository.xaction no test-solution

Pág 61

SubActionComponent O SubActionComponent é usado dentro de uma Seqüência de Ação para permitir chamar outra Seqüência de Açãos, de forma muito similar a uma rotina “GoSub”. SubActions são executadas sincronicamente.

component-nome: ContentRepositoryCleaner

action-inputs: REQUERIDO solution – A solução do .xaction a ser chamada. path – O caminho da .xaction de uma solução a ser chamada. action – O nome da .xaction a ser chamada (deve incluir a extensão .xaction). OPCIONAL Quaisquer nomes de entrada da chamada .xaction que são desejadas serem enviadas à chamada .xaction action-outputs: Saídas da chamada .xaction que necessitam ser consumidas por ações subseqüentes ou necessitam ser passadas a outra Seqüência de Ação. component-definition: Nenhum EXEMPLO <?xml version="1.0" encoding="UTF-8"?> <action-sequence> <nome>SubActionTest.xaction</nome> <title>SubActionTest</title> <version>1</version> <logging-level>DEBUG</logging-level> <documentation> <author>Joe Pentaho</author> <description>Tests the Subaction Component</description> <help>Help!!! Help!!!</help> <result-type>rule</result-type> </documentation> <inputs> <solution type="string"> <default-valor>samples</default-valor> </solution> <path type="string"> <default-valor>getting-started</default-valor> </path> <action type="string"> <default-valor>HelloWorld.xaction</default-valor> </action> <quote type="string"> <default-valor> Hello World Call #1 &lt;br / &gt; </default-valor> <sources/> </quote> <quote2 type="string"> <sources/> <default-valor> Hello World Call #2 &lt;br / &gt; </default-valor> </quote2> </inputs>

Pág 62

<outputs/> <resources/> <actions> <action-definition> <component-nome>SubActionComponent</component-nome> <action-type>Call To HelloWorld 1</action-type> <action-inputs> <solution type="string"/> <path type="string"/> <action type="string"/> <quote type="string"/> </action-inputs> <action-outputs/> <component-definition/> <action-nome>SubAction Test</action-nome> <logging-level>DEBUG</logging-level> </action-definition> <action-definition> <component-nome>SubActionComponent</component-nome> <action-type>Call To HelloWorld 2</action-type> <action-inputs> <solution type="string"/> <path type="string"/> <action type="string"/> <quote type="string" mapping="quote2"/> </action-inputs> <component-definition/> </action-definition> </actions> </action-sequence> Uma pequena explanação de como este componente funciona. Primeiro, observe que a Seqüência de Ação define algumas entradas. Elas podem ser passadas ou deixadas como defaults. As primeiras três colunas (solução, caminho, e ação) definem a localização do nome do arquivo .xaction que desejamos executar (no caso, HelloWorld.xaction). Como desejamos chamar esta ação duas vezes com diferentes “quote” parâmetros, nós definimos dois quote parâmetros (quote and quote2) junto com valores default. Este processo funciona pelos dois nodos de definições de ação. O primeiro manipula as “action-inputs” listadas a partir das definições da Seqüência de Ação. Ela então chama o SubActionComponent passando-as como entradas (neste caso, solution=samples, path=getting-started, action=HelloWorld.xaction, and quote=Hello World Call #1 &lt;br / &gt;). As primeiras três entradas são usadas para executar a HelloWorld.xaction. O ultimo parâmetro (quote) é passado para o seu componente destino através de seu processamento. A HelloWorld.xaction cria uma string usando o parâmetro “quote”, e coloca seu resultado em um stream de saída. A segunda definição de ação é essencialmente a mesma da primeira, com uma exceção. Suas action-inputs adicionalmente definem um The second action-definition is essentially the same as the first one with one exception. If you notice its action-entradas it also defines a “quote” entrada tipo. Se você deixar esta linha igaula definição da primeira ação, você simplesmente repetirá as saídas da primeira action-definition. Neste caso, nós a mapeamos para a entrada “quote2”. Isto permite-nos usar diferentes strings para o mesmo parâmetro de entrada. NOTA: os parâmetros sendo passados para a .xaction de destino são colocados na requisição. Incidentemente, esta chamada para HelloWorld não funcionará com o exemplo fornecido como HelloWorld.xaction. Se você deseja modificar a HelloWorld.xaction para localizar estes parâmetros na solicitação, você deverá mudar as entradas do seqüência de ação segundo o seguinte procedimento:

Pág 63

<inputs> <quote type="string"> <sources> <request>quote</request> </sources> </quote> </inputs> E modificar os “action-inputs” na definição da ação para: <action-inputs> <quote type="string"/> </action-inputs> Quando este SubActionTest é executado do Pentaho Navigator.js, duas chamadas para a HelloWorld.xaction serão feitas, cada uma com diferentes parâmetros. Cada chamada para a HelloWorld.xaction resulta nas saídas serem colocadas em um stream de saída que é fornecido pelo SubActionComponent e os resultados aparecem no janela do navegador.