La versión Enterprise de Pentaho Data Integration incluye un scheduler con el que es muy fácil programar la ejecución de jobs de Kettle, pero si tienes la versión CE (Community Edition) no busques este scheduler porque es uno de los 'extras' que incluye la versión de pago de PDI.

La buena noticia es que, aunque no sea tan intuitivo, con la versión CE es bastante fácil utilizar las aplicaciones kitchen o pan desde la linea de comandos para ejecutar jobs y transformaciones de Kettle, respectivamente.

Después sólo hay que incluir el comando en un script ejecutable, y llamar al script desde un programador de tareas externo como el CRON de Linux, el Programador de tareas de Windows, desde otras ETL's, o desde gestores de jobs de bases de datos como PostgreSQL o SQLServer.

Ejemplo de ejecución de jobs de Kettle desde linea de comandos

Yo lo he hecho desde windows y he utilizado el Agente de SQL Server para crear un trabajo con una programación diaria que ejecuta un archivo .bat con el comando de kitchen que ejecuta un job de kettle, y este es el ejemplo de contenido del .bat:

Si necesitas parametrizar algo más que los valores de los campos que se introducen en la parte del WHERE en una sentencia T-SQL de un procedimiento almacenado seguramente vas a tener que utilizar SQL dinámico, aunque si se puede hacer lo mismo sin SQL dinámico siempre es mejor, más seguro y más eficiente.

Ejemplo de sentencias que se pueden hacer dentro de un procedure con SQL 'Estático'

INSERT INTO estadisticas(idFecha,fecha,bd,tabla,campo,filtro,funcion,valor) 
            values (@idfecha,getdate(),@bd,@tabla,@campo,'','COUNT',@valor)

SELECT @valor= valor FROM estadisticas WHERE bd=@bd and tabla=@tabla and campo=@campo

Ejemplos de sentencias que se pueden hacer dentro de un procedure con SQL dinámico

Si es necesario parametrizar el nombre de la tabla de la query, o partes de la sentencia fuera del WHERE, se puede utilizar SQL dinamico con la opción poco recomendada porque el motor no puede optimizar nada, y porque se corre el peligro de sufrir un ataque de SQL Injection de montar la sentencia en un string, y ejecutarlo directamente con EXEC.

Un ejemplo de lo que se puede hacer, pero es mejor evitar: