...

• IAction - advertises that your bean has something to do and gives the platform's solution engine a method to execute.  This is the API that identifies your bean an Action.
• IStreamingAction - indicates that your bean accepts output streams managed by action sequence content outputs, such as a ServletResponse output stream.  You would implement this if you intended to write to such an output stream during execution.
• ILoggingAction - if your bean implements this, it will be provided a logger instance to which it can write errors, warnings, and debug messages.
• ISessionAwareAction - supplies your bean with an instance of the current Pentaho session
• IVarArgsAction - Allows an Action to accept inputs from the action sequence that are unspecified by the Action
• itself
• IDefinitionAwareAction - Makes an Action privy to certain details about the action definition that is responsible for executing it
• IPreProcessingAction - Allows an Action to do some preliminary work prior to execution

Actions as Java Beans

Actions, as full-fledged Components, can participate in action sequences and can be provided inputs and resources by the typical means, as defined in xaction solution files.  There is an important distinction in the way that these parameters are obtained in Components versus in Actions.  While developing a Component, you will need to essentially go and mine out the parameters and values you need from within various internal APIs.  Actions are the inverse.  The Action framework will determine what inputs you desire and hand them right to you by way of a setter method (see Java bean specification).

The Action framework expects Action objects to be Java bean compliant with respect to setting inputs, setting resources, and getting outputs.  In other words, if your action needs takes a string input, the action definition in the xaction solution file will specify this string input, and the Action framework will cause that value to be set via a setter method on the Action object.  You do not see parameter Maps and such in the Action API for this reason.  All inputs, output, and resources IO will involve Java bean reflection on your Action object to find the appropriate IO methods.

TDB: Show Example of how inputs, resources, and outputs map to Java bean getters and setters

Input Type Reference

XAction inputs, outputs, and resources map to particular Java types. Here is a list of how these types get translated. In other words, you will need to use the Java types listed here in your IAction:
• for "content", use Java type InputStream (does not apply to input types ?)
• for "long", use Java type Long
• for "property-map", use Java type Map<String, String>
• for See the Echo Plugin - a sample plugin for the BI Platform project for examples of how to get data into your IAction and how to expose the output of your IAction so something else can do something with it (i.e. display the results of your IAction, pipe them to another step in an action sequence, or bind them to a session parameter).

Here is a quick reference for how input and output types map from xaction xml files to an Action bean:

...

...

Resources

Outputs

Action Error Handling

FAQ

How are Actions different than POJO Components? I thought POJO Components already supported the ability to drop in a Java bean and have it work as a "component".