FDMEE and why the Open Interface Adaptor is important

In one of my previous blogs, I had spoken about how to load data into an EPM application using the Open Interface Adaptor (http://exploitsinhyperion.blogspot.in/2016/09/managing-data-load-in-fdmee-using-open.html ). In this blog, I would be talking about why the adaptor is important and try to rationalize the same. 

Now, these are the source systems that are supported by FDMEE.

Now, the choice of source systems that are supported is very interesting actually. File is the go to default value, something that has been used since the starting days of computers so it is but obvious that it will work in FDMEE as well. EBS, Fusion, PeopleSoft and JDE are all Oracle products so it makes sense that FDMEE will have integration with these tools since it basically means having a bigger pie for Oracle. SAP is too big a monster in the ERP space to be ignored my Oracle.

Now the below diagram shows at a high level the general data flow from ERP systems to EPM applications like Essbase, Planning and Consolidation with FDMEE acting as the interface between them.

The problem starts when we realize that the above diagram is actually of an Oracle Utopia. Very few companies would have a robust IT infrastructure in place with full-fledged ERP implementations. Secondly, this assumes that companies prefer using ERP systems that are flavors of Oracle or SAP. At the end of the day, an ERP solution is basically something that helps an organization plan its resources in a better way that makes business sense. I can very well build it using the LAMP stack(Linux, Apache, MySQL and PHP) at a fraction of the cost of a prebuilt ERP solution. 

The second thing to remember is that not all companies start out with a complete ERP integration plans. You will never have a company going for a big bang implementation of a full-fledged ERP solution. This is because the bigger the implementation, the more the cogs involved and the more chance you have of things failing apart and going overtime and over budget. So you may have a solution implemented at a factory or division level first and this becomes a baseline for the entire organization or you may have each division implement a solution as they see fit.  

This means that I can have a multiple systems of source systems like Postgres, MySQL, Firebird in the open source stack or you may have native file systems that are designed and used. Now comes the best part. EPM solutions are implemented at a company level for CEOs, CTOs and CFOs and this means that I have to integrate data from these disparate source systems into an EPM applications.

One way is to use the File based source systems. But I for one am not a fan of these since it basically means all my organization data will be flowing in open text files. We are in the twenty first century. Anyone can open the file and update it which means integrity can be compromised. There are better ways to do the data movement from source to target EPM applications.

The other way to go about this is to use the Open Interface Adaptor. This means that I need to just worry about moving data into the AIF_OPEN_INTERFACE table. This can be done either using a custom application script, SQL loader script or just about any way that you can think of. If you have an ETL tool, you can use the same for moving data to the Open Interface Adaptor table.

This is shown in the below snapshot. 

Once you have data in the Interface table it is a simple matter of moving the data using configuration changes in FDMEE. The Open Interface Adaptor is just a clean way of moving data from source to target. There Open Interface Adaptor has a Unix way of getting things done. So long as you get the data into the system tables in a specific format, it can be imported, mapped and exported. This means that the only headache is getting the data into the system tables. You can choose whatever is your poison to get this done. After that FDMEE works for you.