Substring

Existem algumas formas de obtermos pedaços de um texto ou string no Kettle, no entanto gostaria de demonstrar rapidamente como usar a maneira mais simples e adequada, através do step Strings Cut, que pode ser encontrado na aba Transform.

 

Primeiramente, é importante deixar claro que, caso o usuário tente pegar o substring de um campo numérico, data, ou qualquer outro que não seja um string/texto, o Kettle interromperá a execução e exibirá um erro.    Se em alguma parte do processo isso for necessário, será importante realizar a conversão prévia do data type.

 

Observe abaixo que, em nosso exemplo, vamos utilizar o step Generate Rows para criar um campo e simular um valor para recuperarmos o substring.

 

 

 





 

 

Vamos para as propriedades do Strings Cut:

1. A contagem começa do zero, ou seja, a primeira posição é o 0;
2. O step corta os pedaços de acordo com a posição inicial e a posição final.    É muito comum confundirmos o uso deste step com a lógica da função substring do SQL ou Javascript, que normalmente recebe a posição inicial e o número de casas/caracteres a partir dela.    Neste caso, coloque no campo Cut from a posição inicial e no campo Cut to a posição final;
3. O campo In stream field recebe o campo texto onde será aplicado o corte;
4. O campo Out stream field recebe o nome do campo criado com o corte;
5. Caso você coloque o Out stream field com o nome de um campo que já existe, o Kettle criará um novo campo seguido de _1.    Ex: se voce colocar o nome do Out stream field como CampoSubstring e este campo já existir, o Kettle mantém o campo original com o mesmo nome e valor, além de criar o campo CampoSubstring_1, que receberá o campo criado neste step.

 

 

Por fim, fazendo um simples preview, teremos o seguinte resultado:

 

 

 

Além do step Strings Cut, poderíamos utilizar o step Formula ou até o Modified Java Script Value para obter o mesmo resultado, porém é aconselhado evitar o uso de scripts quando desejamos melhorar a performance de execução do ETL.

 

Group by e Funções de Agregação

Até hoje não explicamos como aplicar a cláusula Group by no Kettle.   Para quem já tem uma ideia de como aplicá-la em um Select, não haverá problemas para identificar a melhor forma de preencher os atributos do step que já leva o mesmo nome da cláusula.

Para encontrar o step Group by, basta acessar a guia "Statistics".    

A única premissa para a utilização deste step, é a de que os campos agrupados precisam estar ordenados antes de chegar ao step.    Adotando uma prática simples, o ideal é que sempre utilizemos um step Sort Rows imediatamente antes do Group by, para garantir que os dados chegarão devidamente ordenados ao step de agrupamento.

Observe pela figura acima que estamos selecionando todos os alunos matriculados durante o ano letivo de 2012 em uma determinada instituição de ensino, buscando seus respectivos cursos, matérias cursadas e notas recebidas em cada matéria.

Com um cenário deste, podemos imaginar uma série de exemplos de agrupamento.    Podemos pegar o aluno de maior ou menor nota, a média das notas de cada aluno durante todo o ano, a média de notas em determinado curso, em determinada matéria, entre outros.

Mostraremos agora um pequeno exemplo de utilização do step Group by, com o intuito de obter apenas a média de notas de cada aluno em todas as matérias cursadas por ele durante todo o ano.

Ex:

Luciano Peixoto - Cálculo A - 6,5

Luciano Peixoto - Lógica Computacional - 8,0

Luciano Peixoto - Gerencia de Projetos - 7,0

Luciano Peixoto - Engenharia de Software - 6,0

O resultado deste agrupamento seria:

Luciano Peixoto - 6,875

Para isso, teríamos que primeiramente ordenar os registros de nosso fluxo pelo nome dos alunos, utilizando por exemplo, o Sort Rows.

Depois disso, definimos apenas as características de nosso agrupamento no step Group by, conforme demonstra a figura abaixo:

Apenas de termos escolhido realizar o cálculo da média de notas de cada aluno, poderíamos de feito a soma destes valores, contado o número total de valores ou o número de valores distintos, escolhido o maior ou menor valor de nota para cada aluno, concatenado todos os valores divididos por vírgulas, entre outras opções.

É importante lembrarmos que apenas os campos selecionados como agrupadores e os campos criados neste step continuarão no fluxo.   Todos os outros campos não passarão adiante, visto que, caso continuassem, o agrupamento não faria o menor sentido ou causaria uma grande confusão na visualização dos dados.

Além disso, todos os valores numéricos sairão deste step com formatação 0.0.   Isso significa que, primeiramente, o resultado de nosso exemplo ao invés de aparecer como 6.875, seria arredondado para 6.9.    Utilizando o step Select Values logo em seguida e convertendo o formato deste campo (mediaNotas) para Number com formato 0.00 ou 0.000, ele converteria o número para o seu resultado correto.

Executando Scripts SQL e Stored Procedures

Quando tratamos sobre o step Table Input, vimos como inserir dados no fluxo provenientes do banco de dados.    Também abordamos outras possíveis formas de utilização deste step durante o fluxo, ao invés de utilizá-lo apenas para dar início ao processo.

Independente da posição em que este step encontra-se no fluxo de dados, sabemos que seu comportamento é o de inserir dados no fluxo, ou seja, independente do script que é executado nele, seu final deve conter uma cláusula SELECT, a fim de que os dados sejam extraídos do banco de dados direto para o fluxo que se inicia (ou continua).

Por exemplo, caso utilizemos este step apenas para executar um comando DELETE ou INSERT, o Kettle gerará um erro e interromperá a execução.   Isto acontece porque uma inserção de dados no fluxo sempre será esperada. O que é possível fazer como alternativa, em casos específicos, é executarmos um comando DELETE ou INSERT sucedido por um SELECT.

Considerando qualquer uma destas hipóteses, ainda podemos considerar que há uma forma mais interessante e correta de executarmos apenas comandos SQL que não necessariamente venham selecionar dados e inseri-los ao fluxo.   Para isso, existe o "Execute SQL Script", disponível na guia "Scripting".

Com este step, será possível executar um ou mais comandos SQL, assim como capturar a quantidade de registros afetados por cada comando.   

De acordo com a imagem acima, podemos ver diversas opções semelhantes àquelas disponíveis em outros steps.

O print destaca três propriedades do step em questão.    A primeira, indica que podemos definir se o script será executado uma única vez, ou será executado em cada linha que passar por este step.

A segunda define possíveis campos que podem ser utilizados como argumentos no meio do código, representados pelo ponto de interrogação (?). A terceira mostra como definir e dar nomes aos campos que retornarão a quantidade de registros afetados por cada comando (SELECT, INSERT, UPDATE e DELETE) no script.

A figura abaixo mostra um exemplo comum de utilização do "Execute SQL Script".   Este step, por não produzir uma saída de dados (apenas executa um script), não deve ser colocado no início do fluxo.    O fato de colocarmos um SELECT no script não significa que os campos do select serão inseridos no fluxo.   Reforçamos que este step não possui este comportamento.

Quanto ao uso de stored procedures, podemos utilizá-la em qualquer step que permita a construção de uma query, mas da mesma maneira que possuímos steps específicos e mais recomendados para extração de dados do BD para o fluxo (Table Input) e steps para simples execução de scripts (Execute SQL Scripts), também temos um step específico para isso.

Este step é o "Call DB Procedure".

Este step também pode ser inserido em qualquer ponto do fluxo, porém não recomendo que seja no início.    Observe que é muito simples configurar o step para a execução da procedure, principalmente para quem já desenvolveu ou executou uma anteriormente.

O usuário deverá definir pelo menos a conexão, o nome da procedure, além dos parâmetros da mesma, caso seja necessário.

Além disso, caso esta procedure retorne algum resultado, semelhante a uma FUNCTION no SQL, você poderá definir o nome do campo que conterá este resultado, assim como seu tipo.

Da mesma forma, caso queira executar uma stored procedure que retorne diversas linhas e colunas como resultado, ou seja, quando o código da procedure termina com um SELECT, e você entenda que é importante inserir estas informações no fluxo, você deverá utilizar o Table Input.     Se a procedure terminar com qualquer comando que não seja um SELECT, e você utilizar o Table Input para executá-la, o Kettle gerará um erro, visto o comportamento deste step, o qual já apresentamos no início deste post.

Para quem já executou procedures utilizando script, não há qualquer diferença ao fazê-lo no Table Input.    Além disso, caso queira utilizar variáveis ${VAR} ou parâmetros (?), basta seguir o mesmo conceito apresentado durante o post sobre o Table Input.

Como alterar data types

O Kettle permite que alteremos o tipo de cada dado com extrema facilidade.     

Primeiramente, é importante que tenhamos o controle do formato e do tipo de cada dado que entra no fluxo, já que, quando extraímos dados de diferentes bancos de dados, os formatos nem sempre são exatamente iguais para uma data, número ou até mesmo um texto.    Desta forma, ao invés de tentarmos realizar uma possível conversão e padronização para cada input, podemos simplesmente utilizar o step "Select Values" para converter todos os campos desejados.

Uma forma de visualizar os dados e seus tipos em qualquer parte do fluxo é clicando com o botão direito em qualquer step e visualizando os dados de entrada e/ou de saída, através das opções "Mostra campos de entrada" e "Mostra campos de saída", conforme vemos na figura abaixo:

Ao clicar na opção para exibir os campos de saída do step, veremos os campos (e não os valores) e seus tipos, da forma como entrarão no próximo step, ou seja, incluindo qualquer modificação que tenha sido realizada dentro do step.    Além disso, esta opção também é interessante porque mostra qual é o step de origem de cada dado, permitindo o acesso direto ao step de origem.

Como estamos ilustrando nosso tema com o step Select Values, utilizaremos o mesmo para alterar agora os data types que nos for conveniente.

Sendo assim, podemos acessar a aba Meta-Data e incluir os campos que desejamos alterar.   Observe que, mesmo havendo oito campos no fluxo, só queremos editar o data type de três deles, por isso inserimos apenas os três campos desejados.     Observe também que, conforme a figura acima, os dois campos numéricos já eram numéricos anteriormente, assim como o campo "data_venda" já era do tipo Date.    O que estamos fazendo aqui é apenas dando uma formatação específica para estes campos.    Embora tenhamos utilizado esta maneira de exemplificar a conversão, é importante saber que qualquer conversão possível em um banco de dados, por exemplo, também será possível realizar no Kettle.    Conversões que geralmente são proibidas, provavelmente também serão proibidas, gerarão alguma mensagem de erro ou um resultado inesperado no Kettle.   Resumindo, não há surpresas nem milagres.

Coloco aqui apenas um cuidado, que é o fato de utilizarmos o Select Values também para a exclusão de campos do fluxo ou para renomeá-los quando necessário.    Quando quisermos alterar o data type, aplicar uma formatação e também renomear o campo, podemos fazer tudo na aba "Meta-Data", ou seja, não precisamos usar a aba "Select e Alter" para renomear e a "Meta-Data" para converter.

Por fim, para garantirmos que alcançamos o resultado desejado, é bom visualizarmos novamente os dados de saída deste step ou os dados de entrada do próximo para percebermos as diferenças.   Aconselho também a realização de um preview nos dados, para evitarmos erros ou surpresas desagradáveis em partes posteriores do fluxo.

Exibimos neste post uma das possibilidades na conversão dos dados, sem a necessidade de scripts (javascript), além de salientarmos mais uma vez a importância de observamos criteriosamente os dados que trafegam durante a transformation, à medida que desenvolvemos a mesma.

Como buscar informações do Banco de Dados

Em nosso último post, explicamos alguns conceitos importantes sobre o início do desenvolvimento de um processo de ETL.

Após extrairmos as informações disponíveis de uma determinada fonte, pode ser necessário procurarmos informações complementares em uma ou mais tabelas no banco de dados.    Isso pode acontecer, por exemplo, quando temos ao nosso dispor o código de um produto e precisamos buscar outras informações em tabelas do BD, tais como o nome do produto, a quantidade de produtos no estoque, a quantidade de produtos vendidos, o preço do produto, etc.

Caso tenhamos no Kettle um componente onde podemos comparar um campo do fluxo com um campo de uma tabela (chave) e com isso recuperar outras informações deste registro, supriremos nossa necessidade com certa facilidade.

É com este objetivo que explicamos em posts anteriores o funcionamento do step "Database Lookup".   Através deste e outros steps, podemos recuperar informações do banco de dados a partir das informações que temos à nossa disposição.

Observe pela figura acima que modelamos um processo de ETL extraindo informações sobre a venda de produtos de uma tabela do Excel, com a finalidade de gravar estas e outras informações no banco de dados.    Na metade de nosso processo, temos um Database Lookup com a seguinte configuração:

Observe novamente que iremos extrair informações da tabela de produtos.   Como a única informação que temos na planilha excel é o ID do produto, cujo nome do campo é "id_produto", iremos comparar este campo com o campo "COD_PRODUTO" da tabela de produtos, para recuperarmos, conforme mostra a parte inferior do print, as colunas "nome_produto", "preco" e "quantidade" que estão gravados nesta tabela.

A parte final deste processo mostra os dados sendo inseridos em uma tabela de venda de produtos.

O objetivo deste post não é mostrar os detalhes deste step, mas sim o seu comportamento principal, visto que já existe um post exclusivo sobre o Database Lookup.   
Através destas instruções, você poderá recuperar a partir de agora, informações importantes gravadas em tabelas do banco de dados.

Os steps "Stream Lookup" e "Database Join" também podem nos ajudar neste objetivo, porém com uma abordagem diferente.

Por último, aconselho uma "releitura" do post sobre o Database Lookup, para que possam relembrar os detalhes importantes sobre este step.

Como começar uma transformation

Para aqueles que estão iniciando o desenvolvimento de uma transformation, pode existir a dúvida de como iniciar o processo, ou seja, de quais steps utilizar para dar início ao novo processo.

Resumindo de forma bem simples, destacamos que uma transformation, salvo raras exceções que serão mostradas adiante, sempre devem começar com um step de Input.     São os steps de Input que são responsáveis por extrair as informações que serão inseridas e trabalhadas no fluxo e automaticamente criar o stream de dados que passarão por todos os steps de nossa transformation.

Desta forma, podemos entender que, caso tentemos dar o start em uma transformation sem que haja um step para inserção dos dados no fluxo, o kettle reproduzirá um erro ou simplesmente não fará nada.

Seguindo esta linha de pensamento, concluímos também que, independentemente da posição dos steps de Input no fluxo, um novo fluxo de dados será iniciado em cada um dos steps de Input, ou seja, se tivermos 3 steps de Input, teremos nossa transformation iniciando em 3 pontos diferentes que, posteriormente, podem ou não convergir em um único fluxo através da utilização de um step de Join, por exemplo.

Observe pela figura acima, que nossa transformation de exemplo possui um Excel Input, um Table Input e um Text File Input.   Com este cenário, teremos nossa transformation sendo iniciada em três pontos diferentes, porém o step  Join Rows é responsável por unir dois destes fluxo, enquanto o step Append Stream (Union) converge o terceiro.

Se por algum motivo você utilizar um step de Input no meio de um fluxo, como por exemplo executar um script SQL utilizando um Table Input ou adicionar um Text File Input no meio do caminho, conforme demonstra a figura abaixo, teremos a transformations sendo iniciada em todos os inputs, o que poderá nos levar a um resultado indesejado, caso este comportamento não esteja previsto ou controlado.

O desenho acima não faz muito sentido, visto que teríamos dados saindo do step de Texto e chegando ao final antes mesmo de muitos dados terem saído da planilha Excel.    Sinceramente, não conheço nenhuma aplicação prática para isso, o que constitui uma ação inconsistente.

O que poderíamos ter, conforme já mostramos em nosso post sobre o Table Input, é o recebimento de parâmetros de entrada que serão utilizados nestes steps de input, como um dado que será utilizado dentro do script, uma variável ou até mesmo o nome do arquivo de onde serão extraídas as informações que também pode ser recebido como parâmetro de um step anterior.

Exemplo com o Excel Input recebendo o nome do arquivo como parâmetro do step anterior

Table Input recebendo um valor que será utilizado dentro do script como parâmetro do step anterior.

Estes dois exemplos acima (Excel e Table Input) mostram como utilizar um step de input no meio do fluxo sem que necessariamente o fluxo inicie duas vezes em dois pontos diferentes, pois para que o step de input insira os dados extraídos via SQL, ele precisará receber uma informação do step imediatamente anterior.

Aprendemos, portanto, o comportamento correto da transformation no caso dos steps de Input, deixando claro que o início de uma transformation e a ordem do fluxo depende da posição e de quantos steps de Input existem em nosso processo.

A única forma de iniciar uma transformation sem utilizar os steps de input é utilizando os steps da guia "Job", através dos steps  "Get rows from result", "Get Variables", etc, cujos comportamentos já foram explicados em posts anteriores.

Alinhando os Steps

Este post tem o objetivo apenas de dar uma dica simples sobre como melhorar a aparência de uma transformation ou de um job.

É comum, em diversas situações, após a criação e posicionamento dos steps no workspace gráfico do Spoon, visualizarmos nosso trabalho da seguinte forma:

Para alinharmos os steps, a fim de deixar a visualização um pouco mais agradável e até mesmo intuitiva, siga os seguintes passos.


1- Com um clique-e-arraste do mouse, selecione todos os steps que estão na horizontal, conforme a figura abaixo.

Quando os steps estiverem selecionados, eles estarão com a borda destacada em preto, como mostrado nesta primeira figura.


2- Para alinhar os steps na mesma linha horizontal, você deve pressionar CTRL+baixo para alinhar os steps no nível do step mais abaixo desta linha horizontal, ou CTRL+cima para alinhar os steps no nível do step mais acima desta linha.


Observe na figura abaixo o resultado de um CTRL+baixo

Agora que os steps já estão alinhados horizontalmente, ajustaremos por fim os steps que estão (ou deveriam estar) na mesma linha na vertical.


3- Para isso, selecione com um clique-e-arraste os três steps que estão na vertical e pressione CTRL+direita (conforme figura abaixo) ou CTRL+esquerda.

Aprendemos, desta forma, a organizar e melhorar o alinhamento dos steps, permitindo uma visualização mais agradável, além de não precisarmos mais "apanhar" do mouse para alinhar dois ou mais steps.
Apesar de utilizarmos uma transformation neste exemplo, o mesmo conceito aplica-se na organização de componentes dos jobs (job entry).

Add Sequence

Como o próprio nome diz, este step adiciona uma sequencia numérica ao fluxo de dados da transformation.

Veremos rapidamente neste post como utilizar o step Add Sequence, e em quais casos seria interessante a utilização do mesmo.

Observe que existem duas maneiras de obtermos esta sequencia.   A primeira é através de uma sequence existente no banco de dados.    Marcando o checkbox com a descrição "Usa BD para obter a sequencia", você poderá recuperar uma sequence existente em um schema do banco de dados.

A opção mais utilizada neste step é a criação de uma sequence pelo próprio Kettle.    Marcando o checkbox "Use o contador para calcular a sequencia", voce poderá definir o valor inicial da sequence gerada, seu incremento e valor máximo.

Para deixarmos claro estas últimas opções, caso escolhamos o valor 10 como inicial, 2 como incremento e 30 como valor máximo, teremos uma sequencia iniciando com o 10 na primeira linha do fluxo que passar neste step, crescendo de 2 em 2 (10, 12, 14, 16..) e que será reiniciada quando chegar no valor 30 (ex: 26, 28, 30, 10, 12..).

A primeira e mais óbvia utilidade deste step é a geração de uma sequence para popular uma tabela do banco de dados que não tenha uma sequence automática.     Esta abordagem também pode ser útil para criar sequences e deixar mais claro o número da linha ao popularmos um arquivo xls, csv ou txt.

Outra utilidade para este step, que também pode ser feita com outros steps, é o controle do fluxo.   Em determinado contexto, poderia ser necessário exportar para um arquivo uma lista com os 1000 produtos mais vendidos durante determinado mês.   Para isso, poderíamos obter a quantidade de vendas de cada produto (utilizando o step Group by), ordenar o fluxo pelos produtos mais vendidos (Sort Rows), numerar as linhas com o Add Sequence e utilizar qualquer step de controle (Filter Rows, Switch/Case, etc) para manter os mil primeiros registros até o final.

Conforme falado anteriormente, esta segunda abordagem apresentada também pode ser realizada sem a geração de uma sequence, pois o step "Sample Rows", na guia "Statistics", também é capaz de realizar este controle.

De qualquer forma, todas as vezes que for necessário controlar o fluxo e gravar o número das linhas, seja para adicioná-las em tabelas, para retirar registros desnecessários, identificar o número de linhas, identificar o número do último registro escolhido, etc, poderemos nos beneficiar da funcionalidade do step Add Sequence.

Exemplo de utilização do Add Sequence abordado neste post

Merge Join

O uso deste step e seu entendimento fica extremamente simples para aqueles que possuem alguma experiência com a linguagem SQL.     

O resultado deste componente é semelhante a um comando JOIN entre duas tabelas, porém no ETL ele faz a junção entre dois (e apenas dois) fluxos diferentes.

Para incluir a junção entre mais de dois fluxos, deverão ser utilizados outros componentes iguais na sequência do fluxo.

Observe através da figura acima que estamos juntando exatamente dois fluxos.   O primeiro tem origem em um step de ordenação, enquanto o segundo vem diretamente de um Table Input.    Independente das origens, precisaremos especificá-las dentro do step, decidindo qual será a primeira e a segunda fonte.

Esta definição será importante para o uso do LEFT, RIGHT ou FULL OUTER JOIN.   No caso de um INNER JOIN, a definição do primeiro ou segundo step influenciará apenas na ordem das colunas, porém não no resultado.

Para deixarmos claro o porquê desta definição, caso decidamos utilizar o LEFT JOIN, o resultado do step são todos os registros da primeira fonte, juntamente com os registros da segunda fonte onde haja correspondência entre os campos chave - key fields - de comparação .  Caso não haja correspondência, as colunas da segunda fonte retornarão nulas.

Não pretendemos demonstrar os tipos de resultados - através de prints - que são obtidos através deste step, já que, tendo ficado claro o conceito explicado no parágrafo acima, o retorno esperado será o mesmo que o retorno obtido através de uma query SQL.

Premissas e Cuidados

Observe que, ao clicar no botão Ok após a configuração do step, o Kettle exibirá a seguinte mensagem:

Esta mensagem alerta sobre uma premissa básica para o correto funcionamento do Join, que é a ordenação dos campos chave usados na comparação.   Esta premissa explica o step de ordenação que colocamos em nosso exemplo.   Neste exemplo, estamos ordenando o campo ID, que será comparado ao campo ISSUE proveniente do Table Input denominado CUSTOMFIELDVALUE.     Como é possível perceber, não colocamos outro step de Sort Rows após o Table Input porque já podemos ordenar os campos na própria query SQL.    

O Kettle exige estas ordenações pela forma que o step realiza o Join, ou seja, para garantirmos o funcionamento 100% correto, assim como o resultado esperado, devemos seguir esta instrução.

O último cuidado que devemos tomar ao utilizarmos este step, é o mesmo de quando utilizamos o Filter Rows, ou seja, não podemos esquecer de especificar corretamente a primeira e a segunda fonte (deixar o campo em branco), ou de trocá-los quando inserirmos outro step antes do Merge Join.   Isso é bem comum quando realizamos alterações no fluxo após a inserção do Merge Join.     Caso alguma das fontes fique em branco ou esteja apontando um step errado, a execução será interrompida por causa deste erro.

Movimentando dados entre várias transformations

Todos aqueles que já tiveram a oportunidade de trabalhar com os jobs no Kettle, perceberam a necessidade de comunicação entre as transformations que o compõem.   Isso acontece, obviamente, porque nem sempre as transformations são completamente independentes entre si, ou seja, apesar de processos diferentes, elas podem possuir uma sequencia de comandos e transformações em cima dos mesmos dados.

Para garantirmos que os dados de saída de uma transformation sirvam como insumo para a execução da próxima, precisaremos dos steps "Copy rows to result" e "Get rows from result", localizados na pasta Job.

Copy rows to result

Este step não possui qualquer propriedade a ser definida.   O fato de inserirmos o Copy rows to result em qualquer parte do fluxo, indica que todos os registros e todas as colunas do fluxo até aquele momento serão passadas adiante, ou seja, para a próxima transformation.

Por este motivo, o mais provável é que este step seja alocado ao final do fluxo, já que, na etapa final da transformation, os dados já estarão devidamente tratados e manipulados.

Get rows from result


Para que a próxima transformation recupere os dados enviados pela transformation anterior, usaremos este step para definir quais campos serão inseridos nesta transformation.

Caso a transformation anterior tenha terminado com 120 linhas e com as colunas id_fornecedor e nome_fornecedor, estamos definindo, de acordo com a imagem acima, que apenas as colunas id e nome do fornecedor entrarão nesta transformation.   Apesar de podermos escolher os campos, não podemos definir a quantidade de linhas de input.   Para chegarmos a este nível de controle, precisaríamos controlar a saída dos registros na transformation anterior, ou tratá-las em steps posteriores nesta nova transformation.

Sendo assim, podemos considerar o step Copy rows to result basicamente como um step de output, em virtude do seu comportamento, enquanto o step Get rows from result pode ser considerado como um step de input, não sendo necessário haver outro step de input para que a transformation inicie corretamente.

As imagens abaixo ilustram duas transformations que contêm os steps mencionados acima, em uma aplicação prática dos mesmos.

Índice de Postagens

Acabei de criar um pequeno índice para organizar melhor as postagens, confome o link exibido à direta da tela (Índice de Postagens).

A medida que postar qualquer conteúdo, atualizarei o respectivo tópico na listagem de postagens.

Dessa forma, esperamos que todos encontrem o conteúdo desejado com mais facilidade e rapidez.

Input e Output Fields

Como posso saber quais campos estão passando pelo fluxo e entrando ou saindo de um step?

Existe uma forma simples de fazê-lo.   Entre as opções apresentadas no menu que aparece ao clicarmos sobre o step com o botão direito do mouse, temos as opções "Mostra campos de entrada" e "Mostra campos de saída", conforme mostra a figura abaixo:

• Mostra campos de entrada: campos que estão passando pelo fluxo até o step selecionado;
• Mostra campos de saída: campos que estão passando pelo fluxo, inclusive os que foram gerados no step selecionado;

No caso da imagem acima, clicamos com o botão direito sobre o step "Database Lookup".   Este é um componente típico de recuperação de dados em uma tabela, ou seja, procuramos um valor dentro da tabela especificada cujo ID da linha (ou qualquer outro campo comparativo) seja igual a um ID proveniente do fluxo.   Se os valores baterem, ele retorna a coluna desejada da tabela, senão, traz um valor nulo ou default para esta coluna.

No caso desta transformation, se eu escolher a opção "Mostra campos de entrada", saberemos todos os campos que saíram do step Table Input com o nome de Get Vendas.    Se escolhermos a opção "Mostra campos de saída", visualizaremos os campos que vieram do Table Input juntamente com os campos gerados no componente Databse Lookup, neste caso, o campo codigo_funcionario.

 Campos de entrada / Campos de saída

Quando você abrir a janela com os campos de entrada ou saída, observe ainda que, além do nome das colunas, há várias outras informações sobre as colunas, inclusive o step em que aquele campo/coluna foi gerado.   Isso poderá ser extremamente útil quando tivermos transformations complexas, com muitos steps, e estivermos procurando a origem de alguma falha relacionada a um campo.

O botão "Edit origin step" o levará diretamente ao step que originou o campo escolhido.

Fique atento às próximas dicas rápidas do Kettle Beginners e trabalhe com mais eficiência no PDI.

Executando um processo no modo Preview

Executar um processo no modo Preview permite que o usuário visualize quais registros (dados) estão passando por cada step de nosso ETL.

O modo Preview só está disponível para as transformations, ou seja, só podemos ver os dados que estão trafegando durante a execução de uma transformation, e não de um job.

O modo Preview é executado pelo botão 

Ao executarmos a transformation neste modo, precisamos definir em qual step a execução será interrompida e os dados serão exibidos, o que fica claro através da figura abaixo.

Note pela figura acima que, antes de executarmos o preview, selecionamos o step Select Values.  Além disso, o campo Number of rows to retrieve está preenchido com o número 1000.    Isto indica que queremos visualizar as 1000 primeiras linhas que passarem pelo step Select Values, e apenas após a visualização destas poderemos decidir entre visualizar os próximos mil registros ou parar o preview.

Caso tenhamos executado o preview sem selecionar um step específico, poderemos fazê-lo selecionando um dos steps na lista à esquerda da janela.

Observe também que é possível definir uma outra condição de pausa, além do número de linhas.    Se marcarmos o checkbox “Pause transformation on condition”, poderemos definir uma ou mais condições onde nosso processo será interrompido, seguindo o mesmo padrão de condições do step “Filter Rows”, cujo funcionamento já foi visto em nosso blog.

Caso a execução de nosso ETL dependa de variáveis, parâmetros ou argumentos que são provenientes de um job ou de outra transformation, podemos definir valores para estes parâmetros/variáveis/argumentos clicando no botão “Configure”.

Ao apertarmos o botão “Configure”, a mesma janela do modo de execução “Run”, que é a execução normal do ETL, será exibida.   A figura abaixo nos mostra exatamente onde preencheremos estes valores, caso sejam necessários.

Tendo em vista estes conceitos, podemos realizar testes com mais eficiência, encontrar problemas e prever diversas situações ao enxergamos com facilidade os dados que estão trafegando em um determinado momento (específico) de nosso processo.

Get System Info

Este é um step da categoria de "Input", que nos ajuda a recuperar algumas informações do sistema, tais como a data do sistema, o primeiro e último dia do mês, o nome de uma transformation existente, o hostname e ip da máquina, além de dezenas de outras informações que podem ser inseridas rapidamente no fluxo.

Além disso, podemos receber um valor externo ao PDI.   Particularmente, costumo utilizar bastante o tipo "command line argument" para receber um ou mais parâmetros de uma xaction, e executar o processo de ETL recebendo estes valores externos dinamicamente.

Sabendo que é possível, por exemplo, utilizar um ETL para gerar um resultado para um relatório criado no Pentaho Report Designer, podemos receber parâmetros que seriam os filtros a serem utilizados em um select, ou qualquer outro valor que o usuário entenda como importante e que precisará ser considerado na execução do job ou da transformation.

A coluna “Name” define o nome que será dado ao valor recebido ou extraído do sistema, enquanto a coluna Type define o tipo de informação que será extraída do sistema.

Como temos dezenas de tipos de informações disponíveis na coluna Type, sugiro que acessem o endereço  http://wiki.pentaho.com/display/EAI/Get+System+Info  para que entendam melhor a função de cada um.

Tendo uma boa compreensão do funcionamento deste step, estaremos dando um importante passo na utilização conjunta das diversas ferramentas da suíte Pentaho de BI, já que é muito interessante a integração que é possível realizar com estas ferramentas.

Excel Input

O armazenamento de dados em planilhas do Excel é muito comum e muito importante em diversas situações.    Através do componente Excel Input, podemos manipular os dados gravados nestas planilhas, aproveitando inclusive o título das colunas, caso existam.

Observe abaixo as opções do componente:

Aba Files:

Começaremos pela primeira aba, a aba Files.

Nesta aba selecionaremos os arquivos que serão processados.   Poderemos escolher um ou mais arquivos diretamente do diretório onde se encontram, ou o nome / caminho do arquivo podem chegar através de um parâmetro ou campo.

Quando os arquivos forem escolhidos, os mesmos aparecerão na coluna File/Directory.    Na coluna Wildcard(RegExp), poderemos colocar uma expressão regular que valide os arquivos que queremos importar.

Se desejarmos receber o nome de um arquivo por meio de um campo do fluxo, marcaremos a opção “Accept filenames from previous step”, selecionaremos o step que está ligado ao Excel Input e definiremos o campo que possui o nome/caminho do(s) arquivo(s).

Após determinar os arquivos e pastas, poderemos ver os que fazem parte de nossa seleção através do botão “Show filename(s)...”

Aba Sheets:

Na aba Sheets, definiremos quais planilhas entre os arquivos selecionados usaremos para extrair os registros e inseri-los ao fluxo.

Aba Contents (Conteúdo):

Na aba Content, definiremos outras opções, entre elas:

• Header: se o cabeçalho das colunas será inserido ao fluxo;
• No empty rows: se linhas vazias entrarão no fluxo;
• Stop on empty row: para o processo caso encontre uma linha vazia;
• Limit: limite de linhas que entrará no fluxo;
• Spread sheet type: formato do arquivo que contém a(s) planilha(s), ou seja, xls, xlsx ou ods.

Aba Error Handling:

A aba Error Handling possui algumas opções para o caso de incidência de erros durante o processamento deste step.   Através das opções disponíveis, podemos decidir qual ação o fluxo deverá tomar caso haja um erro originado especificamente por este step.

Aba Fields:

Na aba Fields, escolheremos entre os campos das planilhas selecionadas aqueles que entrarão no fluxo.   Ao definirmos os campos, poderemos escolher os tipos, tamanho, precisão, formato, etc.

Observe a figura abaixo e perceba que através do botão “Get fields from header row...” podemos adicionar todas as colunas das planilhas automaticamente, sem necessidade de digitá-los um por um.