Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 7 Next »

..this page is under construction and will be completed shortly..

Intro

Actions are the lightweight alternative to Pentaho BI Components.  For an understanding of how and why they are different, let's take a step back and examine what a BI Component is and how it is used.  A BI Component is historically a Java class that does some work, yielding some output, when it is provided certain inputs and resources.  The work done as well as the inputs and resources required are entirely up to the component developer.  It's purpose is to perform some work in a sequential success-based workflow (action sequence).  A saavy BI Platform user with a bit of inclination for Java coding can implement his or her own custom component to do just about anything.  However, this is not an easy endevour since developing your own BI Component requires intimate knowledge of internal Pentaho APIs.  When you are done writing your custom component, the code you have written will be tightly coupled to the Pentaho BI Platform, so much so, that it will be difficult to unit test and may be difficult to maintain.

These are some of the problems that the Action API seeks to solve.  As we mentioned earlier, Actions are the lightweight alternative to developing Components.  So, what do we mean by "lightweight"?  Well, we have taken the complex set of APIs required to implement a Component and reduced it to a handful of concise APIs.  Moreover, we allow you to write a Java bean that performs the action you desire, and simply decorate it with the appropriate API for the desired interaction with the platform.  These platform interaction APIs will discussed in more detail later, but they are essentially:

  • 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

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 "property-map-list", use Java type List<Map<String, String>>
• for "string", use Java type String
• for "string-list", use Java type List<String>
• for "object", use the appropriate actual type or Object

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".

  • No labels