Todos aqueles que ja tiveram a oportunidade de trabalhar com os jobs no Kettle, perceberam a necessidade de comunicacao entre as transformations que o compoem. Isso acontece, obviamente, porque nem sempre as transformations sao completamente independentes entre si, ou seja, apesar de processos diferentes, elas podem possuir uma sequencia de comandos e transformacoes em cima dos mesmos dados.Para garantirmos que os dados de saida de uma transformation sirvam como insumo para a execucao da proxima, precisaremos dos steps "Copy rows to result" e "Get rows from result", localizados na pasta Job.Copy rows to resultEste step nao 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 ate aquele momento serao passadas adiante, ou seja, para a proxima transformation.Por este motivo, o mais provavel e que este step seja alocado ao final do fluxo, ja que, na etapa final da transformation, os dados ja estarao devidamente tratados e manipulados.Get rows from resultPara que a proxima transformation recupere os dados enviados pela transformation anterior, usaremos este step para definir quais campos serao 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 entrarao nesta transformation. Apesar de podermos escolher os campos, nao podemos definir a quantidade de linhas de input. Para chegarmos a este nivel de controle, precisariamos controlar a saida dos registros na transformation anterior, ou trata-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, nao sendo necessario haver outro step de input para que a transformation inicie corretamente.As imagens abaixo ilustram duas transformations que contem os steps mencionados acima, em uma aplicacao pratica dos mesmos. O uso deste step e seu entendimento fica extremamente simples para aqueles que possuem alguma experiencia com a linguagem SQL. O resultado deste componente e semelhante a um comando JOIN entre duas tabelas, porem no ETL ele faz a juncao entre dois (e apenas dois) fluxos diferentes.Para incluir a juncao entre mais de dois fluxos, deverao ser utilizados outros componentes iguais na sequencia do fluxo.Observe atraves da figura acima que estamos juntando exatamente dois fluxos. O primeiro tem origem em um step de ordenacao, enquanto o segundo vem diretamente de um Table Input. Independente das origens, precisaremos especifica-las dentro do step, decidindo qual sera a primeira e a segunda fonte.Esta definicao sera importante para o uso do LEFT, RIGHT ou FULL OUTER JOIN. No caso de um INNER JOIN, a definicao do primeiro ou segundo step influenciara apenas na ordem das colunas, porem nao no resultado.Para deixarmos claro o porque desta definicao, caso decidamos utilizar o LEFT JOIN, o resultado do step sao todos os registros da primeira fonte, juntamente com os registros da segunda fonte onde haja