Planning Metadata CSV parser

Hyperion Planning is a cool tool built around a HOLAP framework. It does a lot of things to ease administrative tasks from a process perspective compared to Essbase which can be looked at as a data engine. But there are some things which are good in Essbase but not so in Planning. One of them is the hierarchy view for members…While EAS console allows me to see all the metadata in a hierarchy in a single window, Planning does it one step at a time… (This is again a case of tradeoff since communicating information of a hierarchy having potentially thousands of members from which only 10 to 15 would be queried on web is more expensive than on a thick client since a thick client can be optimized internally). However, sometimes you just need to see the hierarchy in its full form, particularly with shared members since I would like to see how they roll up, under which parent and so on…And with PBCS in the picture, I cannot go to the backend EAS console and see the metadata…

Well, I got tired of expanding nodes in the workspace and I thought of designing my own metadata parser… 

Starters, this is alpha so not much is available by way of error codes and so on…Still working on it…

This is the hello world for the jar file when you launch the metadata parser…

The file name field can be manually updated to enter the full file path of a CSV file or we can click on the Browse button that is shown below to access a file using a Navigation wizard… 

The Process button shown below is used to process the CSV extract that you have chosen…

The search button that is shown below can be used for doing a case insensitive search for members in the hierarchy…

 

If you click on the browse button, a file navigation wizard opens up that allows you to choose a CSV planning metadata file…Below is a snapshot of the browsing for the file and choosing one…

As soon as you hit the open button, the file would be loaded and parsed as shown in the below snapshot….

Note that in the above snapshot, the metadata was parsed for account dimension and it shows the metadata as a tree format…

If you manually update the full file name, you need to hit the process button to initiate the processing of the extract….

Now, to search for a node like “assets” you enter it in the search field and hit the search button… Snapshots are shown below…

Observe that the members are shown in in breadcrumb path since this was the main problem I wanted to solve, that is see the rollups in a hierarchy so that I can make logical inferences and correct errors if any...

Now, for the best part….

If you click on a node in the main hierarchy, it will pop up the list of associated properties of that member… below snapshot shows the properties of Balance sheet member parsed and in a simple easy to read format…

Its way faster than the same thing over the web since all of the web communication is done away with using the Planning CSV extract…

Now, I am still working on a few ifs and buts and adding a couple of JOptionPanes for error message display and stuff… However, if you would like to test it out let me know… I would upload it on GitHub and am looking for folks to test it out since I might have developer bias…

Will keep you posted…

 

PBCS EPM Automate – Why is Identity domain needed

Well, for starters, this is a speculative blog… I do not guarantee that what I am saying is the truth and nothing but the absolute truth (manic laughter here…Never thought I would use this phrase)… I can be woefully wrong as well…

This is the way, we login to a cloud PBCS instance using EPMAuotmate…

Below is the list of the parameters for epmautomate login…

Now this is what bothers me… Why do we need a separate identity domain…The reason being that it the identity domain is very well contained in the URL…Why do you need a separate field just for something that can be derived from some other parameter?

And this is the best reason why you need the identity domain separate that comes to my mind…

If you have tried connecting to the PBCS either using FR Studio thick client or using the Planning REST API, you will know that Oracle PBCS expects you to give something which is called as fully qualified name that is, your user name is actually a combination of your identity domain and user name separated by a period symbol…

So if you have your user name to be captainkirk@enterprise.mil perhaps (too bored to Google Star Wars wiki) and your identity domain is z999999, if you are trying to connect to PBCS using either the FR Studio or Planning REST API, you will need to enter your user name as follows: -

Z999999.captainkirk@enterprise.mil

Then you can connect… Else, you keep getting weird authentication messages… (Well, if you are network security guy you will know this is not weird authentication messages, its “Security by obfuscation” in bold and capital)

So technically, the last parameter that you pass to EPM Automate is used in combination with your user name to derive your user name and to enable the derived user name to connect to PBCS…Hope that makes sense…I read it thrice and it looks good I think…

And this is what makes me smile… If I was coding EPM Automate, I would do the same…Who would code something separately to get a derived field along with all the associated error checking and exception tracking… And who would like to document how to give your user name… Not me for one…

I would just say pass it separately and since Java in my poison, I would code it this way

userName=identityDomain.concat(“.”).concat(userName);

Don’t we all programmers think same… I think it is called the path of least resistance…All innovation is driven by this one thing…