FDMEE and Java – A definitive proof perhaps

FDMEE I would say is an advanced version of the Financial Data Quality Management. Advanced because it tries to not be tied down to a particular operating system (read VBScript here) and make it platform independent and succeeds to do this to some level with the help of Java. Now, platform independence is needed since it basically means that the inner nuts and bolts that make up my system would not affect the workings of a software system which is theoretically at a higher level of abstraction. Also, a platform independent code would mean that testing forks are reduced for the development team. However, do we actually see the platform independence in play when we work with FDMEE on a day-to-day basis? The answer is a yes, and therein lies the beauty of it since this is not very obvious to us.

The first is how FDMEE pushes data to an Essbase application. While you can have a variety of source systems if your target is an Essbase application, internally FDMEE creates a rule file for pushing the data from the FDMEE staging tables to the application. How does FDMEE create a rule file? Well, it uses the Essbase Java API for this purpose. 

The above snapshot from a log file shows that the rule file was saved to the Essbase server and executed using a method called executeDataRuleFile. Now internally I am assuming FDMEE calls the loadData method from IEssCube to save the data. Also, since HFM applications are not using Essbase for data storage but rather a relational system, you need a wrapper function that basically identifies the type of application and using that information run a particular Java function for loading the data.

The second proof of Java in action for FDMEE is this drill through query as shown below.

 

2016-09-16 00:59:06,123 INFO  [AIF]: drill down query:SELECT

 abdv.partitionKey ,abdv.catKey ,abdv.periodKey,

 tpovpartition.partname as LocationName, tpovcategory.catname,  COALESCE(TPOVPERIOD.periodDesc,abdv.ATTR5) period,

 UD1X Dummycol,

 ENTITYX

,ACCOUNTX

,NULL ICPX

,UD1X

,NULL UD2X

,NULL UD3X

,NULL UD4X

,NULL UD5X

,NULL UD6X

,NULL UD7X

,NULL UD8X

,NULL UD9X

,NULL UD10X

,NULL UD11X

,NULL UD12X

,NULL UD13X

,NULL UD14X

,NULL UD15X

,NULL UD16X

,NULL UD17X

,NULL UD18X

,NULL UD19X

,NULL UD20X

,

 SUM(AMOUNTX)

, AIF_BALANCE_RULES.RULE_NAME,ABDV.CURKEY

 FROM AIF_TDATASEG_ALL_V abdv

 JOIN tpovpartition on

 abdv.partitionkey = tpovpartition.partitionkey

 JOIN tpovcategory on

 tpovcategory.catKey = abdv.catKey

 JOIN AIF_BALANCE_RULES on

 AIF_BALANCE_RULES.RULE_ID = abdv.rule_id

 LEFT OUTER JOIN TPOVPERIOD

   ON TPOVPERIOD.PERIODKEY = abdv.PERIODKEY

 WHERE 1=1

 AND tpovpartition.partitionkey in (

 ?

 )

 AND tpovcategory.catKey IN (

 ?

 )

 AND TPOVPERIOD.periodKey IN (

 ?

 )

  AND ENTITYX = ?

 AND ACCOUNTX = ?

 AND UD1X = ?

 GROUP BY

 ENTITYX

,ACCOUNTX

,UD1X

,

 abdv.partitionKey, abdv.catKey, abdv.periodKey,

 tpovpartition.partname, tpovcategory.catname, COALESCE(TPOVPERIOD.periodDesc,abdv.ATTR5), AIF_BALANCE_RULES.RULE_NAME, ABDV.CURKEY  

 

In the drill through query above, I have highlighted the parts that are of interest to us.

Now if you are a SQL guy who has worked with Java and some JDBC, you will realize that the above query is actually a PreparedStatement where the parameters are substituted at runtime using the values of the drill through. Advantage of parameterization and the platform independence of Java all combined in one simple statement.