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.
