Killing XActions for Reporting – slowly and with pleasure

The new Pentaho-Metadata data-source scripting-extension I produced recently seems to be well-received. We now have a great opportunity to fully cut back on XActions for plain reporting uses.

Many users still have to stick with their old XAction driven reports. I assume that they do not do that because they enjoy the pain, or love programming in XML. No, the majority needs to drive parameter queries where the query itself is computed. Reasons for that are many:

  • If everything is placed in one query, the query gets insanely complex and unmaintainable.
  • The query access legacy systems with no sane data models or weird partitioned tables.
  • The data-source needs to be configured based on some other parameter before it is used.

 Now users who have been locked in by these cases can now free themselves from the slavery of weird XML-programming. I happily announce that

Pentaho Reporting now ships with sane scripting support for JDBC, Pentaho Metadata, all Mondrian and all OLAP4J data-sources.

The data-source scripting system of the old days is now a dark memory of the past. The new scripting is integrated into the data-source itself, so scripts become more reusable. Editing large scripts on the report’s “query::name” attribute was never really fun anyway.

The scripting extension allows you to configure the data-source before it is used for the first time. You can now configure all aspects of the data-source via your script, including but not limited to any supported connection-parameter like the JNDI name or additional JDBC-connection properties:

var jndiConnectionProvider = dataFactory.getConnectionProvider();
jndiConnectionProvider.setConnectionPath("java://myjndiconnection");

You cannot get away with not configuring the data-sources at all, as the report designer and all other tools love to have something static to work with. But you can always reconfigure them to your liking before the report is run. The scripts are always called before the a query is executed on the data-source, even inside the Pentaho Report Designer or the data-source editors.

I don’t believe that we will need similar scripting support for the Kettle, Java-Method-Invocation, Table or the Scriptable data-sources. These data-sources either do their own scripting anyway or would not profit from any scripting abilities.

This entry was posted in Advanced Topic, Development on by .
Thomas

About Thomas

After working as all-hands guy and lead developer on Pentaho Reporting for over an decade, I have learned a thing or two about report generation, layouting and general BI practices. I have witnessed the remarkable growth of Pentaho Reporting from a small niche product to a enterprise class Business Intelligence product. This blog documents my own perspective on Pentaho Reporting's development process and our our steps towards upcoming releases.

2 thoughts on “Killing XActions for Reporting – slowly and with pleasure

  1. Vasili

    I found XAction approach to be very clean and convenient to use. XActions are well structured, they defines parameters explicitly in each action.

    One of the main advantages of XActions is an ability to define string templates and parametrize them. This way it’s possible to create easy-to-read parts of SQL or MDX code, and put calculated parts to it as parameters. And this parameters can be computed in advance with help of scripting.

    Also I love XActions for their universality so I look suspiciously to any replacement of them 🙂

  2. Meherun

    I am using this code with PRD 5.0.1 (connected with PME 5.0.1) Global scripting

    var jndiConnectionProvider = dataFactory.getConnectionProvider();
    jndiConnectionProvider.setConnectionPath(“JNDIname”);

    But getting error

    TypeError: Cannot find function setConnectionPath. (#24) in at line number 24

    Can you please help me to pass pentaho report designer(or metadata editor) JNDI name in setConnectionPath method?

Comments are closed.