Embedded analytics is an extremely hot topic today. And I'm personally very happy about it, because the Ctools excel at that.

Since it's creation, even when all we had available was CDF, it was one of the primary choices for OEM's to use in it's products. With CDE things have changed a lot (for the better) but the same principle remains: We must be able to achieve virtually anything and integration with third party tools is an absolute must have.
Typical requirements

It all boils down to this:

There's an external application that does... whatever it does, and wants to offer Business Analytics capabilities to it's users. Implementing this capabilities from scratch is a huge task, so people usually look around for BI software that can be integrated into their application.
There's only major requirement: User's can't tell there's two applications!
This apparently simple requirement breaks down into other not so simple ones:

  • The BI platform has to support seamless integration with the main application
  • Has to be visually identical
  • Has to support single sign on (users can't login again)
  • Must be able to communicate with the main application
  • Has to obey the permissions defined in the main application

The Pentaho + Ctools combination is a perfect candidate here. The Pentaho platform give all the infrastructure around single sign on, data security, permissions, connections, etc.

Ctools give all the fine grain control over the desired behavior, being able to achieve a uniform user experience. Ctools will also be able to do the bridge with all the other Pentaho components: Analyzer, Reports, etc.

This combination allows us to achieve a great mix between pre-canned dashboards and ad-hoc analysis, usually what vendors / integrators are looking for.
I built a very simple dashboard with the very famous hello world:


There are typically two options to include this dashboard in another application:

  1. Iframe integration
  2. Div integration

We support both, by the way :)


The first one is the simple choice - define an iframe, point to the Pentaho server / dashboards and get the content back. It works, and frankly most of the times is good enough.
Since the iframe generates a totally isolated environment (apart from funky edge cases in, you got it, IE) there are usually no conflicts of CSS or JavaScript.

An iframe generates the content on a rectangle and the window context is isolated from the outside application. This makes it hard (though not impossible) to communicate with the outside environment.
If care is not taken, we can also have to face the horrible scroll bars that appear on iframes. Also avoidable, but it's hard...

Calling an iframe in html is pretty straightforward. In this example I'll put the user / pass in the url, but this won't be necessary with a properly configured Single Sign On (SSO):

Passing parameters is limited to passing them through the URL bar, which can be limiting. Another options is talking with the iframe, which works if we take into account cross-domain limitations.
Div integration


This is the natural integration. No iframes, the content is embedded as if it was generated in the same place.

In order to achieve this, the enclosing application has to be responsible for calling out the headers and the body of our dashboard separately. This is a server side operation, and requires a backend that supports that kind of operations. We've done it with custom liferay projects, jsp, php and I'm pretty sure that it can be done virtually anywhere.

In this scenario both the main application and the Ctools dashboard are running on the same place, they can freely interact; The analytics part is not a silo anymore. This brings out several advantages in terms interacting with different parts of the page. Filters and navigation are obvious candidates, as it's usually a global part of the main application that needs to interact with both the operational and the analytical application.

Since the integration is done at server side, Pentaho may never be directly exposed to the end consumer. This means that we don't need to be as careful with security as we're required to be in the iframe scenario - even though we should.

It's harder to setup. An iframe declaration is a one liner, can't be easier than that. But may be very well worth the effort.
We also need to be much more cautious with conflicts. CDE dashboards include several javascript libraries and css styles, and they can interfere with the ones used by the main application. This can be pretty challenging.

In the iframe example we call the Render method of CDE, that returns the entire page.
Like I mentioned before, in here we need to split the render in 2 calls, one for the headers and another one for the content. So these are the relevant methods:

  • GetHeaders
  • GetContent

Here's an example for GetHeaders

pedro@arpeggio:~/1/blog/embedded$ curl ''

And GetContent

$ curl ''


It's very normal that the main application and Pentaho live on different application servers. The application can be exposed through, let's say, http://www.mycompany.com/ and Pentaho, installed internally, be exposed as something like running on a different network.
For this, there are two important arguments that we can pass that can be fundamental:

  • root (string)
  • inferScheme (boolean)

If you pass a different root, all de dependency fetching will be prepended by that option. Turning off inferScheme will allow you to pass even a different protocol, which is useful if your application is behind https and pentaho isn't.

$ curl ''

Note that there's now an explicit reference to https://www.mycompany.com. This way you can make sure that your references will be found by the external client while still being able to edit your dashboards the usual way.

I'm obviously biased - but I have absolutely no doubts that when it comes to embedded analytics, the combination of Pentaho + Ctools is by far the most powerful one out there!