Open the ftp_prpt_report_w_parm.xaction file in Design Studio (Eclipse).

You will want to change the default values for each input.  Notice if you left it the way it was and ran it from PUC, you could change the default values to your FTP settings.  At first I tried to use an @ sign in the username from our Datamensional.com server, but the solution will not work with this.  It causes a problem because the output part of the .XACTION uses the @ sign to separate the username from the server name.  There may be a way to get around it through escape characters.

Go to your inputs in Design studio and change all the defaults for the following:

• reportname
• ftp_host
• user
• password
• directory

Keep all others their default.  You will want to change the solution listed under Resources to one of your own reports as well

Save it to the solution directory in Design Studio.  In the BI Server, refresh the repository and double click on the .XACTION.  After completing successfully, you’ll see “Action Successful.” Log into the directory that you saved the FTP to, and it should be there.

If you are coming from a fresh install with the sample database, you should have no problem running this .XACTION.  The only changes you need to make is to change the receiving email address, and the report being sent.  You should receive an email from the email you have set on your BI server as a default.

Make sure to put the file in the workspace when you open it through Pentaho Design Studio, otherwise it will not display any values.  The XML can still be edited this way, however.

After making your modification, save it to the solution directory from Design Studio (Eclipse) and go to PUC and refresh your repository.

Then double click on the solution.  You should see the following default message that shows the Action Sequence (.xaction) was successfully executed:

This is not all that pretty and actually could be another message.  It is simply saying that it was completed successfully and that long number is the unique ID for the document just created in the content repository.  At the end it shows what format it was.

You can execute this step using a URL into another application, another part of the suite, inside of PRD, or CDF.

In the Admin/Enterprise Console, it should look something like this:

default email address:  system@datamensional.com

User ID:  system@datamensional.com

SMTP Host:  smtp.gmail.com

SMTP Port:  587

SMTP Protocol:  smtp

Download, Setup, and Test on Pentaho Server

Begin by going to this link:

http://www.fusioncharts.com/free/download/

Find the FusionChartsFree.zip archive file.  Extract to your Pentaho install directory (ours was called pentahoSandbox):

C:/Program Files/pentahoSandbox/server/biserveree/tomcat/webapps/pentaho/FusionChartsFree/

http://localhost:8080/pentaho/FusionChartsFree

This puts it in the web directory so other Pentaho solutions can access it and it’s also protected by the same security under the Tomcat server.

Now you should test that you can run a Fusion Chart from this directory.  Go to this web address to test a Fusion Chart on Pentaho’s BI Server:

http://localhost:8080/pentaho/FusionChartsFree/Code/MyFirstChart/ChartJS.html

Your result should look like this:

Pentaho Data Integration (PDI) Transformation to create Fusion Data source

Fusion charts as well as most Adobe Flash based charts including Flex use XML as their data source.  The transformation needed allows you to create the properly formed XML document dynamically from any SQL data source.  We will use the sample database that ships with Pentaho.  Ultimately, we will link this transformation as a data source to PDI and it will dynamically create an XML file from the SQL input changes coming from PRD.

See the code in the .ktr file

1. Table input: Create a query like the below when starting to create your transformation.  This will eventually be turned into an XML file that Fusion charts can read.  Use this SQL to start without the Where clause so you return results.  Add the where clause later with the question mark in a later step. 
2. Select values: This step prepares some of the data as place holders for the XML document and changes some of the Uppercase to lowercase.
3. Add XML from set: This creates a “set” XML tag and makes all the other columns to  attributes of this tag.
4. Generate Rows: This generates the graph XML node as well as all of the attributes of that node.  These are static now, but you could potentially build this out and parameterize it so that the end-user could change various aspects of the chart.
5. Doc Template: This is the same step as step 3.  This creates the basis for all the set nodes to attach to.  Right now it’s simply a one line tag of XML.  Fusion documents only have one graph tag anyway, and it’s always the highest level tag.
6. Join Graph to Set: This step ultimately joins the two nodes together.  The set node is the child to the graph node.  Each set represents a value on the graph.  They are joined by the graph.  This currently is what a typical XML document would be.
7. Text file output: This simply takes the XML and stores it as a file.  Another suggestion is to stream the XML file instead.  You may want to experiment with that.  I called my XML file something a little different so I could distinguish it from the other default data files.  I put it in the same directory for simplicity sake:
   1. C:\Program Files\pentaho\server\biserver-ee\tomcat\webapps\pentaho\FusionChartsFree\Code\MyFirstChart\AddXMLStepData
   2. Note to make the file extension .xml.
8. Run the transformation to ensure you get data and then launch the ChartJS.html created previously to ensure that the Fusion chart reads the data.
9. Get Variables: This step gets the variables that are set in the settings of the transformation.  This is how you would use them:
   1. Go to Edit -> Settings . . .  ->  Parameters (tab)
   2. Put in ParmProduct with a default value of ‘default’.
   3. Now add the Get Variables step and connect it to the input step.
   4. Name the field “Product” and then the parameter “ProductParm”  and make the type string.
   5. Edit the table the input Step.  Add this line underneath the “From” Statement in the Table input step: WHERE “PRODUCTS”.”PRODUCTCODE”  = ?
   6. Click  “replace variables in script”
   7. Select in the drop down “Get variables from Script” and select the “Get Variables” step.
   8. Test by running again.  You should get no errors, but you should have an empty data set since no product codes equal ‘default’

Create Pentaho Report Designer (PRD) Document and integrate with Fusion Charts.

1. Open PRD
2. Create new JDBC query.  This query will be used to populate values in a “Product” filter under Data Sets on the right hand side.  Set the data source to the SampleData and use this as your query.  Use this SQL:

   SELECT

   “CUSTOMER_W_TER”.”COUNTRY”,

   “ORDERFACT”.”TOTALPRICE”,

   “PRODUCTS”.”PRODUCTCODE”

   FROM

   “PRODUCTS” INNER JOIN “ORDERFACT” ON “PRODUCTS”.”PRODUCTCODE” = “ORDERFACT”.”PRODUCTCODE”

   INNER JOIN “CUSTOMER_W_TER” ON “ORDERFACT”.”CUSTOMERNUMBER” = “CUSTOMER_W_TER”.”CUSTOMERNUMBER”

3.  Go to Parameters in the data pane and right click and then select add parameter.
4. Call your new parameter ParmProduct and fill it out like so and click OK.
5. Add a new data source by right clicking on the Data sets, and releasing on Pentaho Data Integration.
   
6. Select the PDI transformation you had saved previously to create your XML.
7. Select the table input as your data stream for your data.
8. Now click “Edit Parameters.”
9. Match the parameters on the far left side from PRD to PDI on the right like in the picture below:
10. Click OK.  On the right side, select the PDI “query” you just created and right click and select “Select Query.”  This ensures your main document is using that.
11. Drag COUNTRY and CL to the details band.
12. It’s recommended you unhide the “No Data” band so you can better understand if a problem comes up that it’s due to you selecting no data.  Drag a label there and write “No Data”.
13. Change the page setup to Landscape to better accommodate the size of the chart.
14. Drag the Report Header band so the height is at least 400 pixels to allow space for the chart.
15. Drag a label into the Report Header and expand it to the same size as the Report Header.
16. Make sure you are clicked on your text-field or label you dragged to the canvas.
17. Click on attributes.
18. Go to “append-body” under the HTML header.  Click on the ellipse for value and put this script or similar as an absolute directory within your localhost or remote if you want to access this from another machine.  I recommend doing it this way because it gets confusing when you preview from PRD or the BI Server because it references different directories and thus relative directories might change.  Your code will look similar to the one from the Fusion charts.  If you want to include JavaScript libraries and make them accessible by everyone, I recommend putting your code in the master-report append-body attribute.<script language=”JavaScript” src=”http://localhost:8080/pentaho/FusionChartsFree/Code/FusionCharts/FusionCharts.js”></script></head><h2 align=”center”>Fusion Chart in PRD with PDI data source</h2><div id=”chartdiv” align=”center”>The chart will appear within this DIV. This text will be replaced by the chart.</div><script type=”text/javascript”>

    var myChart = new FusionCharts(“http://localhost:8080/pentaho/FusionChartsFree/Code/FusionCharts/FCF_Column3D.swf”, “myChartId”, “550″, “450″);

    myChart.setDataURL(“http://localhost:8080/pentaho/FusionChartsFree/Code/MyFirstChart/AddXMLStepData.xml”);

    myChart.render(“chartdiv”);

    </script>

19. Add a Page Header if you wish.
20. Click OK.
21. Before previewing to see the Fusion chart, remember you can only use the HTML preview.  It will not show up any other way.  To do this, click on the big green play button at the top and then select HTML.
22. Your finished product should look like this and you should be able to dynamically change it on the fly.

You can also preview after publishing to the BI Server and you should get the same result and be able to dynamically change the chart by selecting another value in the drop down list.

What it should look like:

Recommendations & Notes

• Fusion charts will not work cross platform.  Relative paths are confusing when troubleshooting in PRD.  So that’s why I put the absolute address.  However I have noticed that when creating a new application folder the Fusion charts will not reference the application folder “pentaho.”  You should decide which folder you want to demo the fusion charts in and update the path to those Fusion charts accordingly and make sure the contents are there.   
• Fusion charts are not supported officially by Pentaho Support though their implementation is common in CDF and on the BI Server.
• CDF will soon have a built-in component for Fusion without needing an .xaction interface.
• You can add more line detail by creating a sub report with another query that does not aggregate and link it to the primary parameters on the master report.
• You can drag any other reporting elements to the canvas.
• You can create new Flash charts on the fly by doing the following (This is definitely advanced, but it can work!):

1. Create a new transformation in PDI.  Use the Get File Names step.
2. Use it to read the names of the charts in the directory structure for the Fusion Charts on the Server.
3. Have it flow to a dummy step.  Save it.
4. Create a new data source in PRD and point it to the dummy step you just created.
5. Create a new Parameter called “ChartType.”
6. Use the new PDI data source as the source query for your ChartType.
7. Go to Append-query of the text-field that contains our JavaScript.
8. Go to formula.  The tricky part here is you’re going to use the formula functions to actually write the JavaScript string in the value column.
9. Use the message notation or other scripting option to basically swap out the chart loading function.  In the report example, you’d want to swap out this part: FCF_Column3D.swf with the chart type parameter.
10. Thus, your code should look something like this: “JavaScript String Value Beginning” + ${ChartType} + “JavaScript String Value End”

• You can create additional inputs into PDI from PRD for the overall graph settings.  Currently, they are static as “Generate Rows” steps for the simplicity of this demo.  Thus, the user could have more control over how their chart looked.

UPDATE: As Thomas Morgner pointed out, you don’t need to use PDI to bridge the gap between PRD and XMLA, you can use OLAP4J.  The PDI method can be generalized for almost any type of datasource and perform elaborate preprocessing as needed, so keep it in mind anyways.

Set up MS OLAP XMLA Server as SOAP Web Service

1. First, copy all of the contents of the C:\Program Files\Microsoft SQL Server\MSAS10_50.MSSQLSERVER\OLAP\bin\isapi directory into the C:\inetpub\wwwroot\olap directory.  Create this if necessary.
2. Open the Server Manager by right clicking on Start->Computer and selecting Manage.  On the far left of this window, there should be the Console Tree. This can be opened by clicking on the gray button near the top of the window if it is not there.
3. Expand Roles by clicking on the plus sign next to it.  Below it should now be the Web Server (IIS) option.  If it is not there, it can be added by right clicking on roles and selecting Add Roles, and then clicking on the Web Server (IIS) checkbox when it shows up.
4. Either way, expand the Web Server (IIS) option and click on the Internet Information Services option below it.  There will now be a second selection tree next to it labeled Connections.
5. Expand the option that matches the name of the server, right click on Application Pools option below it, and select the add application pools option.  Set the name in the window that comes up to OLAP, and make the Managed Pipeline mode Classic.
   
6. Back on the Connections tree, expand the sites option. Next, expand the Default Web Sites Option below it, and then click on the OLAP option.  Of the icons that appear in the middle, double click on the Handler Mappings option.
7. Right click on any of the entries in the list and select the Add Script option.  In the window that pops up: under Request Path enter *.dll, under Executable enter C:\inetpub\wwwroot\olap\msmdpump.dll, and under Name enter OLAP.
8. Back in the Connections Tree, click back on OLAP to return to the previous screen of icons.  This time double click on the Authentication option, and make sure that the only entry in the list that is marked as enabled is the first one, Anonymous Authentication.  This will allow access to the connection without having to add extra authentication data to the query (it still requires authentication to access the server data).
9. Once all this is completed, it can be checked for response by going to the address of the dll, such as http://localhost/olap/msmdpump.dll which will give a SOAP response error.
10. It can also be tested through the SQL Management Studio by entering the address as the server name when connecting to a server.  All of the same options will be available as if accessing the server directly.

Connecting Microsoft OLAP to Pentaho Data Integration (KETTLE)

1. Open Pentaho Data Integration (PDI).
2. Go to File –> New Transformation
3. Click on the “Design” Tab if not currently selected.
4. Now look for the OLAP step.
   1. One way to do this is to browse under the folder “Input” on the left and find the “OLAP Input” or alternatively click in the search box at the top and type in “OLAP Input”
   2. Drag the step to the right and side onto the canvas.
5. Double click on the OLAP Input Step.
6. FIll in the below.  We have created anonymous login for simplification of this POC.  We recommend that set up the security appropriately in production.  We’ve also included a sample MDX query that should return 50 lines for testing purposes.MDX Query:

Configure OLAP input:

1. Now do a search for “Text file output” on the left or browse for it under the output folder.
2. Drag it onto the the canvas on the right.
3. Click on your newly named OLAP Input called MSOLAP now and hold down the shift key.
4. Drag an arrow while still holding left click and shift and connect it to the Text File output step and release the Shift and left click button.
5. Double click the “Text file output” and set it to a local file system like: C:\Users\Administrator\Documents\MSOLAP Output
6. Go to File –> Save As and save your transformation as MSOLAP.  Click the green “Run” button that looks like a play button.
7. You should have a successfully exported data from MSOLAP to a text file (you’ll know if you don’t see any error messages and it says Finished! at the bottom).

Using Pentaho Report Designer (PRD) to report from Microsoft OLAP

1. Open Pentaho Report Designer
2. Click on the “Data” tab on the right.
3. Right click on “Data Sets” on the right.
4. Go to Pentaho Data Integration.
5. Browse for MSOLAP.ktr and click Open.
6. In the name field, call it “MSOLAP.”
7. Select the MSOLAP step.
8. Click Preview to verify that it will work.
9. Click OK.  You should see three columns under Data sets under MS OLAP as a data source.  They are: Column0, Column1, [Internet Sales Amount].
10. Drag each column on the “Details” band of the report.
11. Now go back to Pentaho Data Integration and open MSOLAP.ktr from the last section.
12. Delete the text output step.  Find the dummy step on the left and drag it to the canvas and connect them with a hop as shown in the picture:
13. Go back to PRD.  Click on the preview button.  It looks like a giant eyeball in the top left hand side.
14. If you see no errors and about 2 pages of detail data (and 50 lines of data), you have successfully queried Microsoft OLAP from Pentaho report designer.
15. If you’d like to publish this to the BI Server, make sure that the PDI transformation file (.ktr) is accessible by the BI Server to use in the transformation whether by file system or stored in the PDI repository.

Requirements:

• A CAS server accessible through https.  It may be possible to get phpCAS to work without it, but it is safer and probably easier just to set up the https.
• A webserver such as Apache, but any that will be capable of running PHP will do.
• PHP5 with cURL installed on the machine.

Directions:

1. The easiest way to install is through PEAR with the command “pear install  http://downloads.jasig.org/cas-clients/php/current.tgz”.  If PEAR is not already installed, it will tell you the command needed to install it.  If on Windows or a flavor of linux that does not provide a command to install PEAR, a manual install would probably be easier.  Just download from the link in the command above and extract somewhere logical (if you’re on Windows, you’ll need something like 7zip to open the .tgz) and add the include_path to your php.ini file.
2. Go to the directory web pages are served from for that server (/var/www/) and copy config.php and example_simple.php from the examples directory provided with phpCAS’s documentation (/usr/share/php/doc/CAS/docs/examples).  Other examples can be copied if desired, but this is all that is necessary to test the connection.
3. Modify Config.php to reflect the setup of the machine it is install on.  This file is included in all of the example files, so you should only need to change this once.  For a typical machine, the following changes were made:
• $phpcas_path = ‘/usr/share/php’;
• $cas_host = ‘localhost’;
• $cas_context = ‘/cas-server-webapp-3.4.8’;
• $cas_port = 8443;
4. In a web browser, go to http://localhost/example_simple.php to test the server. It should redirect you to the CAS login page and then return you once logged in.  If you were already logged in through another app, it will automatically take you to the requested page.

While it may not seem like much as it is, the examples included with phpCAS will give you a good basis for using this client with your own PHP applications.  Do keep in mind that Single Sign On with CAS does not mean Single Sign Off, so always log out of your applications separately.  Also remember that Authentication and Authorization are separate concepts and CAS will only decide if a valid username and password were provided.  It is up to your application to determine if that username should have access.

Find the kettle.properties file

You’ll want to modify your kettle.properties file which is in the user folder of both Linux and Windows.   Spoon, Carte, and the BI Server will all look in the same place.  Find your  kettle.properties in these locations depending on your OS:

• Windows:  C:\<User>\.kettle\kettle.properties
• Linux: /home/<User>/.kettle/kettle.properties

The .kettle folder might be hidden.   Open with a great Text Editor like Notepad++

Setting up the connections to your Database

Ensure that you have full access to do inserts and create tables.  It’s recommended you set up your connections on your BI Server and/or Carte as JNDI connections.  Ensure you have the proper JDBC drivers locally as well as on the servers.

Make sure that they have the same connection name.   See the directions on how to setup a local JNDI connection in Spoon.  You could potentially just store the connection information within the Spoon job as well and not setup Server based connections and avoid JNDI altogether.  Though that would make it more difficult to pool connections and switch from Development and then production environments.

Adding the Variables:

Because of a bug in Pentaho, you should not fill in any variable related to Schema, especially if it’s implied what the default schema is.  Add the following to your kettle.properties on both your server and local machine you use Spoon on:

Testing Logging to Database on Spoon

Save your file locally first in on the specified .kettle folder depending on your OS.  Make sure you shut down Spoon if it’s not shut down already.  Then reboot the application.

Check to see that your Kettle.properites file was properly loaded.  Go  to Edit  Edit the Kettle Propreties File.  You should see variable names on the left correspond to the values on the right you just edited in the file.  If you don’t see any values filled out, you’ve got your file in the wrong place.  The picture below actually shows a file with empty log variables.   You could optionally fill in the values here or go back to your file.  Either way, you’ll have to restart Spoon after making your modifications.

Set up your Jobs and Transformations for Logging

Next, open a Job you want to log into your logging tables.   Go to Edit and then Settings.  Click on the logging tab.  There are three sections each representing a different logging table for jobs.  Make sure for each section all the appropriate fields are selected and that you fill out all the appropriate environment variables you defined in the kettle.properties file.  Most people will pick all of them.  If you haven’t done so already, click on the SQL button.  It will create all necessary tables for all sections.

Now open a transformation, and go through exactly the same motions as a job.  Notice there 4 sections instead of three.  Make sure everything is checked and that all tables are created.

Moving your Logging to Carte or BI Server

This assumes that you have created a JNDI connection in Spoon with the same name as the connections on your server.  Also, you’ve verified the connections work and have all the appropriate database drivers.

Make sure you move the kettle.properties file you’ve already configured locally to the server in the appropriate user folder and the .kettle folder as illustrated above.  You’ll have to shutdown and restart the server since you are adding new environment variables to the server instance.

Now that everything is configured locally, on the sever and  we’ve made the appropriate changes to the solution files, we can move the solutions to the server.  Simply move them to Carte or for the BI Server, move the solution files with corresponding XACTIONs that execute the solution files.  You’ll have to refresh the repository as necessary.

Execute the solutions on the server.  All logging should go to the exact same place locally as well as remotely.

Hot Tip:

Make a template for both Job and Transformation files with all the appropriate logging configuration setup.  This way you don’t have to make them over and over again.  If you have one job executing other jobs, it will pick up the logging of the children jobs.  If executed alone, it will not.  The master job will not pick up the transformation logging unless specified in the file itself.

Extra Hot Tip: Kinda a big deal if your tables begin to lock:

Since PDI is designed to be platform agnostic, the logging table mechanism attempts to find a happy medium between all databases.  However, there are some database specific things up you must do especially if you’re processing a lot of data to avoid concurrency issues and you may get a table lock.  We ran into this problem with Oracle 11g when processing about 8000 rows/s through PDI.   Matt Casters, the founder of the Kettle project, has a Pentaho Forum post that shows you how get around the concurrency table lock issue using both Oracle and MySQL on this Pentaho Forum post.

Update: Michael D’Amour of Pentaho informed me that the scheduling mechanism will be completely re-written in the Sugar release which is the next generation of the Pentaho Suite.  The data below is still relavent for most or all versions 3.x and 4.x.  You can read more about the next version of scheduling.

The information provided below was tested with the 3.8 Suite on the Pentaho BI Server (which I believe is the 3.8 BI Server).  The module is virtually the same in the new 4.1 Suite (not to be confused with the BI Server version, which would be 3.10 in this case).  If you notice any differences let me know.  I have not seen any differences between these two versions with scheduling.

If you have appropriate access, you can simply right click and go to schedule to schedule your own job by simply right clicking on the solution file in the Pentaho User Console (PUC).  You can run these under your username, so others should not be able to see these jobs unless they are administrators.

You can view your schedules in the work space.  If they have already completed, you can view the return information from the XACTION (if that’s what you were running).  Click on the yellow icon at the top.  See below:

Notice how public schedules can be created as well and all users could see those schedules.  Notice how the PentahoSystemVersionCheck Job is actually private if viewed in the Enterprise/Admin Console (a.k.a. PEC or PAC).  However, since I’m logged in as Joe, and Joe is in the Admin role, I can view both Private schedules and all other schedules that any user creates.

Notice below that the Test Private Schedule I have below.  No other user should see it except the admin in PUC.  I have this running every three minutes just to ensure it works:

If you click the checkbox next to the schedule you want to modify or if you’re creating a new one, there is a checkbox to make it public or private.  By default, it is private.  At the time of this writing, I have not been able to get a private job to work with Community Edition on the client’s site.  Though a public schedule or user created schedule will work.

Note: you are not able to change a private schedule to a public schedule because it will not replace the old one.

If you right click on a solution file and go to Properties, you can then click on the Advance tab in the pop-up.

There you will see a list of public schedules and manipulate them to attach to your files:

You should now be able to test your schedules.  I recommend trying to use a quick running report or an xaction that executes a transformation or job with an email step or output to a text file. This way, the scheduled job runs quickly and you get results back quickly with a log of what’s wrong with your PDI job or report if executing one from an xaction.

Let us know if you have questions or comments.

Version compatibility

Many people seemed to have trouble with the directions using more recent versions of the software than this was made on.  I have successfully connected Pentaho 4.1 to CAS 3.4.11 following these directions, so they will most likely remain valid until Pentaho implements a more recent version of Spring Security (which would probably be Pentaho 5 at the earliest).  The only part of the install that is absolutely version specific is the spring-security-cas-client-2.0.5.RELEASE.jar file.  A later version of this jar will not work.

The difficulty connecting that many people seem to have most likely comes from applicationContext-spring-security.xml file.  Since the directions were made with a specific version of CAS, all of the URL references in it are made to the “http://localhost:8080/cas-server-webapp-3.4.8/” version of the webapp.  Since you can technically name the webapp anything, these URL references need to be changed to match, such as “http://localhost:8080/cas-server-webapp-3.4.11/” for the current version.

Security

While CAS will complain on its login page about not using SSL, I am as of yet to find a version that will actually not allow pentaho login. This does not mean that certain setups will not run into this problem, and many other CAS clients require SSL connections  Either way, setting up your server to use SSL is always a good idea.  The instructions apache provides (http://tomcat.apache.org/tomcat-6.0-doc/ssl-howto.html for the version of tomcat pentaho uses) should be sufficient for setting this up, and remains mostly consistent between later versions of tomcat.

Again changes need to be made to the applicationContext-spring-security.xml file’s URLs, this time make sure to change the “http://localhost:8080″ to the equivalent secure URL such as “https://localhost:8443″ to make sure it actually uses the SSL.

XML Encoding

This is something that I’m sure some people have run into before, namely that when copying the XML over it sometimes cannot be read by the server.  The primary cause of this is due to the XML file requiring UTF-8 encoding, and many text editing programs (especially in Windows land) tend to automatically save to more modern text encodings.  So When editing these files, make sure to force UTF-8 encoding when you save.

Authentication vs Authorization

CAS like its spelled out name implies is designed to handle authentication, i.e. verifying a valid username and password combination.  This does not include authorization, i.e. checking if a user is actually allowed to access something.  Authorization is handled on the client end, in this case Pentaho.  Any time a user successfully logs in to CAS but does not have any authorization in pentaho, they will be redirected to the default public/casFailed page which does not exist by default.  As usual, this can be changed in the applicationContext-spring-security.xml file.

Normally both are handled in Pentaho, with authentication handled in the applicationContext-spring-security.xml that is modified as part of the CAS integration, and also in another file that is imported through the pentaho-spring-beans.xml file, the default being called applicationContext-spring-security-hibernate.xml. After CAS is integrated, this imported file is mostly ignored, as CAS is bypassing all of the beans in it.

Authorization is handled primarily by another file imported through the pentaho-spring-beans.xml file called applicationContext-pentaho-security-hibernate.xml by default.  Like the similarly named file mentioned previously, there are a number of alternate versions that can be used instead of the default hibernate version, such as -jdbc (checks against a database query), -ldap (checks against an ldap server), -memory (checks against data written directly in the XML file).

I haven’t fully explored all of the possibilities those different authorization options may provide, so it is very possible that there is an elegant solution available in modifying those files.  If the user base for a pentaho deployment is not especially large and/or does not change often, updating user permissions by hand may be a more cost effective solution than spending hours coming up with a custom solution.  When confronted with this same problem with a client who had potentially thousands of users, I went to the Pentaho developer’s multipurpose tool:  PDI.

This ETL is designed to check the USERS table found in the hibernate database that Pentaho CE comes with against an LDAP server and make comparisons for any new users, which it then adds to the Hibernate database with the basic Authenticated role.  The main advantage of this technique is that it is not difficult to implement against any size, and can be scheduled to run regularly to keep the records up to date.  It also allows the Admin Console to still be used to add additional roles to the users.  The main disadvantage is the fact that there will always be a time delay until its next scheduled run or the next time someone manually does so.  It also lacks flexibility, as it grants the same permission to every user it adds, so still requires human intervention to make users an admin or some other role. This could probably be overcome with further development and more precise deployment specifications from a client, and in its current form is still very effective at authorizing large groups of users at once.

If there are any other solutions out there, or other comments about these or any other issues, let me know.

I’ve had the implications of poor internal controls beat into me many moons ago when I managed an IT Auditing group for an international firm.  As a result, I can’t shake the butterflies when I see organizations relying on these tools for complex and manually intensive data analysis and reporting.  Splitting large files into chunks of under one million rows for PowerPivot and combining the reporting results on the back can introduce an opportunity for inconsistency.  Combining that with the manual intervention necessary to integrate multiple data sources compounds the risk of inconsistencies; particularly if the individual with all the knowledge of manual manipulation is not available for whatever reason.  Ouch.

To be clear, I am not discouraging the use of Excel and PowerPivot.  They are excellent tools and I use them quite effectively on an ongoing basis.  However, if you need a repeatable, reliable process to generate information used in key decisions, get yourself a production worthy tool.  Spend your time utilizing the information as opposed to manually crunching it.  The number of affordable solutions that can solve your production challenges might surprise you.