A bit of history5 years ago, Aaron, at the time a Pentaho employee, started a
thread at the forums on the following subject:
One of the replies was from a guy that didn't show much love for the concept
... or you could aim higher; Implement xactions in kettle. We have .ktr, .kjb and why not .kxa?
The way xactions work is not that different from a job; We have a start, several actions to choose from and a workflow we want it to follow. Every actionComponent could easily be mapped to a kettle step.
The only use case left to cover using xactions is to set environment variables, as
CDA removed all needs for data handling and more recently the kettle reporting step solved the bursting use case.
Not any more. 5 years later, the final blow on xactions. This new application provides a much more easier (and powerful) way to do that
Startup Rule Engine![]() |
| Startup Rule Engine |
This is not a only a tool to allow administrators to set Pentaho environment variables; It's an initialization daemon for the BA platform
How it worksThe principle is extremely simple: You drop .ktr / .kjb files in a specific directory (by default
/system/startupRules/rules) and through the UI you specify when they need to be executed. There's currently 3 options:
- Execution at platform start
- Execution at user login
- Execution at user logout
With this tool you can implement any logic you want; specific rules per group or per user, logging, alarms, triggering emails, your call.
The startup variable caseThe initial use case we wanted to cover was setting a session variable, widely used for row level security. For that we simply developed a PDI step plugin that's now available to use, much like the set/get variables step.
Here's an example of the setVariables transformation. If you ever wrote an xaction, you'll realize how simple and powerful this new approach is:
![]() |
| Set Variables Transformation |
Unsurprisingly, through the Marketplace
How it was builtUnsurprisingly too,
Sparkl!
R.I.P. xactions, you won't be missed :)
More...
