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.
