A bit of history
5 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 conceptTell Us How to Improve the Action Sequence story
... 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 |
What is it
This is not a only a tool to allow administrators to set Pentaho environment variables; It's an initialization daemon for the BA platformHow it works
The 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
The startup variable case
The 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 |
How to get it
Unsurprisingly, through the Marketplace
How it was built
Unsurprisingly too, Sparkl!R.I.P. xactions, you won't be missed :)