This post focuses on making calls to Essbase in SQL but for background purposes here are the steps for achieving the integration.
1) Creating .NET (I use C#) methods that make XMLA web api calls. The idea is to only create a few methods that are dynamic and can work on any cube.
2) Compiling the methods into an assembly.
3) Adding the assembly to a SQL Common Language Runtime (CLR) Environment. Both Microsoft SQL Server and Oracle DB have this feature.
4) Creating CLR Table Value Functions (CLR Functions) that call the .NET methods in the assembly.
5) Wrapping the CLR Functions into more easy-to-use normal SQL Table Value Functions (TVFs) and stored procedures.
For this demonstration there are only two C# methods. One method is able to pass and parse any type of discover request to create metadata calls. The other is a execute request for data calls.
These functions work on any cube because instead
of returning multiple fields they return a single xml field that represent each row
which can be parsed in SQL into a normal multicolumn table result.
[NOTE: The examples are querying Essbase applications hosted on an instance of the SampleApp607 VM image]
Metadata Calls
Here is a base discover call that will return all the dimensions in the ‘Basic’ cube of the ‘Demo’ application. The basic Discover function has 6 parameters
2) XML List of Restrictions
3) Essbase Cluster
4) Host APS URI and Port Number
5) Username
6) Password
Example base Discover call
|
Obviously, this xml result is not readable for humans and you can't join it to other data sources, but it can easily be parsed into a normal table.
Parsed Discover request |
Because you don’t want to have to write a well-formed xml strings, login credentials, and parsing cross apply's every time you want to know what dimensions exist in a cube you can save the login info in a table (that can be encrypted) and wrap the request into another easier to use TVF.
Saved login info |
Wrapped function call |
Members function Call |
I won't go into all the parameters right now, but the second one can be used to limit members returned to ones under only certain member(s)
Data Calls
Execute or data calls work in a similar way, the base Single_Access_Slicer function has nine parameters but most of those are connection parameters so I will leave those out for this example and just use an already wrapped function called Single_Access_Slicer_Connection. Here is a basic call that I will break down
Example data call |
The four parameters for Single_Access_Slicer_Connection are
2) Attribute List: List of attributes to be returned with level 0 members if the attribute dimensions are not part of the first argument passed. For demonstration purposes I added an attribute dimension called 'Category' to the Product dimension.
The possibilities are endless with what you can do with these calls. There is a little bit of a learning curve with them but that allows them to be more dynamic. Because applications and enterprise reporting applications work off normal SQL databases this makes it easy to integrate Essbase with other systems. For example, making the calls via a report in a application such as Tableau and then being able to drill through using the member set functions. In addition, it makes overall cube management easier because it can join to data outside of Essbase and apply logic - Essbase administrators do not need to update cubes for every little reporting requirement.
I keep getting request to alter cube extraction due to different requirments, this is solving my task drastically. Thanks for writing this post.
ReplyDeleteThat is great! I would love to hear how you are using it. Feel free to share what you are doing here or send me an email!
ReplyDelete