Essbase Integration Services (more commonly referred to as EIS) has been officially end of lifed. I have always been a huge EIS fan since I first learned about it, and can’t help but feel a little nostalgic about my early days with it. It was even the basis of a number of my early blog articles going all the way back to 2009 or so, and to this day those articles remain some of my most popular, if only because there are precious few articles on EIS out there.

Most of you readers are probably familiar with EIS and its position in the greater Essbase landscape, but for those who aren’t familiar, here’s a rundown: EIS is can create and update Essbase outlines and data using data stored in a relational database. Don’t be fooled into thinking this is just an Essbase load rule that is pointed to a SQL table. EIS is a veritable Swiss army knife in terms of building outlines, with much flexibility with generating the levels, parent/child builds, setting member properties (formulas, UDAs, consolidation operator), and then loading the data.

EIS really shines when you have a well-designed database schema to use as your basis: primary keys, foreign keys, proper data modeling, and so forth. This might seem pretty obvious but the fact of the matter is that many of the environments I have seen using EIS have implemented it with a poorly constructed data source. EIS still works in this scenario, of course, but sometimes it’s just not as great.

You may already know that Essbase Studio is the successor (perhaps more spiritually than technically) to EIS, in that it provides the ability to create cubes/outlines and load data from relational tables. Essbase Studio improves upon EIS in many ways, but also significantly changes things around. I am an expert with EIS but by no means an expert with Essbase Studio (just to provide a somewhat narcissistic reference point for how much of your EIS knowledge might transfer over to Studio).

One of the big things that EIS and Studio bring to the table is the ability to implement drill-through. So perhaps you’re loading some transactional data that has been consolidated somehow, implementing drill-through with EIS/Studio enables you to provide the ability for users to see a number in the cube and then drill through to the individual rows that make up the value for that cell.

This drill-through ability is one of the bigger use cases for EIS/Studio, in fact, it’s such a compelling feature that I have seen a number of environments that have done a skeleton EIS/Studio implementation so they could get drill-through, but then keep managing the outline with EAS and use their normal automation. I have seen and used both HAL and ODI to populate metadata tables for EIS/Studio to use in these instances.

That all being said… Don’t build a pretend EIS/Essbase Studio environment just to get drill-through.

If the only thing you want from EIS or Studio is its drill-through abilities (in other words, you wouldn’t otherwise have relational tables to source data from), then Drillbridge is an incredibly compelling alternative.

Drillbridge, as I have extensively written (maybe I should call this Jason’s Drillbridge Blog), is a drop-in solution for drilling from Essbase to any relational data you have. Drillbridge works with SQL Server, Oracle, DB2, MySQL, and should work with any database for which a Java driver exists (hint: practically every database out there).

I’ll be writing more about this in the coming weeks, but besides being a good solution in its own right, Drillbridge could significantly improve and simplify the architecture and automation of any environment with a “fake” EIS/Studio setup. In other words, if you are feeding data to relational tables only because you have to in order to get the EIS/Studio outline “overlay” to work and provide drill-through, you could instead drop the use of EIS, the automation for extracting dimensions/populating tables/updating the outline, and instead just drop in Drillbridge and create a mapping from your metadata (outline) to your relational data.

For the record, I like Essbase Studio and this is nothing against it, particularly when solutions that involve it are constructed properly. But this particular use case is just such a slam dunk for Drillbridge that could improve numerous environments I’ve seen, I just have to point it out, especially in light of EIS being end-of-lifed.