Easy Hyperion Drill Through and the road to Drillbridge 1.0.2

I feel like I’m repeating myself but I have to say again that the response to Drillbridge has been absolutely incredible. A lot of you are providing some awesome feedback. Perhaps one day this little tool will be up there with the venerable Outline Extractor.

In any case, I’ve actually been incredibly (actually, unbelievably) busy with other projects, but Drillbridge is like a hobby for me so I have a few updates planned for the next release. This will be version 1.0.2:

  1. Paginate returned results if desired
  2. Create, edit, and update server and cube mapping definitions, and deployment specifications (the members that are drillable)
  3. Maybe (I thought this wasn’t in the Java API but apparently it is, at least for modern Essbase versions): deploy drill-through definitions to a cube mapping

I’m trying not to bite off more than I can chew for a single release. There are a number of things that are planned for an as-of-yet unnamed future release:

  1. Drill to descendants of upper-level  member (i.e., drill on Qtr1 to do a drill using Jan, Feb, Mar)
  2. Custom image/header/footer on results pages

And looking way down the road:

  1. Drill from a drill – this is actually fairly complicated so I want to make sure I get this right. But basically you’d be able to keep drilling through data. A lot of people are interested in this for drilling to invoice PDFs, other tables, and so on.

Please keep the awesome feedback coming and know that I’m dedicating all the energy I can to making this a useful tool!

3 thoughts on “Easy Hyperion Drill Through and the road to Drillbridge 1.0.2

  1. I think you are heading in the right direction with drillbridge. I do have 2 questions though.
    Drill back to detail has always had the issue of being unsecured once you get to the actual query.
    Are there restrictions to keep people of data they do not have access to?

    In addition, will drillbridge work within Financial Reporting?

    • Hi David,

      The cleanest architectural approach is to just map in a JDBC connection with fixed credentials (rather than the credentials of the user in Hyperion). So the simplest route seems to be to just leave it so that if the user has #NoAccess on the cell then they can’t drill on it. That being said, it would be possible in Drillbridge to instead pass the credentials from Hyperion to execute the SQL query so that access on the relational side would be more locked down. I don’t have this on the roadmap for now but if that were a dealbreaker for people I might look into it.

      I believe Drillbridge works from Planning and FR but I haven’t had a chance to test it properly just yet. I am hoping to have some people help out/confirm that when 1.0.2/1.0.3 comes out with a raft of improvements that make deployment even easier than before (such as eliminating the need for mapping tables/views in 90% of use cases).

  2. estafana perryman

    Useful commentary ! For my two cents , if you is interested in merging of PDF files , my friend merged a tool here https://goo.gl/hnCHXW.

Leave a Reply

Your email address will not be published.