Updated Guidance on Customizing the FDMEE Open Interface Adapter

Justin Biard -

Please skip ahead to the next section if you already know about FDMEE and the history of the product otherwise please continue for a brief introduction. FDMEE is the amalgamation of two separate products historically. Just a few major releases ago Oracle introduced a product known as ERP Integrator (ERPi) which had some complementary features to an existing product known as Financial Data Quality Management (FDM - the Q is not typically included in the acronym though some may say FDQM). FDM is used to load various sources of data to target Hyperion applications and ERPi (along with Oracle Data Integrator) was Oracle’s solution to unlocking direct integration with General Ledger systems (GL) for metadata and data including Extract, Load to Target and Drill-back to source ERP screens. From here on I may use the terms GL and Enterprise Resource Planning (ERP) interchangeably. I realize these terms are not completely synonymous but for this post assume that I mean the General Ledger of your ERP.

In the beginning, ERPi could be configured to work with FDM and as the product matured, it was eventually combined with FDM into a single product called Financial Data Quality Management Enterprise Edition (FDMEE - yep, the Q is still silent) FDMEE incorporates the architecture from ERPi to integrate with various ERP systems through something called an adapter. To get access to these adapters Oracle licenses an add-on to FDMEE called the “Adapter Suite” which includes various adapters that can be used to integrate with specific ERP versions / vendors. If your ERP is not one of those supported “out of the box” by FDMEE (the ERP-specific adapters included in the FDMEE adapter suite) then you may be able to leverage another option from the adapter suite that is meant to fit the “all other” category. This adapter is known as the “Open Interface Adapter” or sometimes shortened to “Open Adapter”.

It is important to note that FDMEE uses Oracle Data Integrator (ODI) as the execution engine that performs the extract, load and transform behind the scenes. (ELT is Oracle’s take on ETL) The “Adapter Suite” is essentially a library of prebuilt ODI projects, packages and interfaces supplied by Oracle (except for SAP which is provided by an Oracle integration partner: Bristlecone) The Open Interface Adapter is also a set of ODI objects, however, for this adapter specifically, the objects are meant to serve as a starting point that should be first copied and then customized.

Updated Guidance

In previous releases of FDMEE Oracle’s documentation for customizing the Open Interface Adapter was a bit simplistic in my opinion. There are several challenges you may run into with customizing this adapter if you are not familiar with some of the nuances of the limited-use ODI repository that comes with FDMEE. Here is a snippet of the original steps supplied by Oracle here. (starting on page 269) This was essentially the same up through 11.1.2.3 and some subsequent patches.

  1. Copy the Open Interface Project.
  2. Add necessary data model for the custom source.
  3. Add necessary interfaces to populate the open interface table.

Yeah! 1, 2, 3 and done!

Or… not so much. If you review the updated documentation for FDMEE starting from 11.1.2.3.520+ you should now see expanded instructions that will help you later on when customizing the Open Interface Adapter. This process will also give you a more development lifecycle friendly process for customizing the adapter and promoting your code changes instead of re-configuring the adapter in each environment.

Note: Customizing the FDMEE Open Interface Adapter requires access to - and knowledge of -Oracle Data Integrator Studio (ODI Studio). If you have never used ODI before or the FDMEE Open Interface Adapter, I would recommend that you bring in some help (internal or external resources), head over to KScope or get some product training on the tools involved (primarily ODI and FDMEE). FDMEE by itself does not necessarily require a deep knowledge of ODI but when you are implementing the Open Interface Adapter a good working knowledge of ODI is recommended.

  1. In the FDMEE repository, export the Open Interface Adapter Model and ERPI Target Model folders.
  2. In the FDMEE repository, export the Open Interface Adapter Project.
  3. Create a new work repository with a new ID.
    Use a repository ID of 900 or higher to avoid conflicts with Oracle shipped components. This is your development repository when performing customization. It is referred to as the “custom repository” in the following steps.
  4. In the custom repository, import the model folders named: Open Interface Adapter Model and ERPI Target Model.
  5. In the custom repository, import the Open Interface Adapter Project.
  6. Perform any customizations in the custom repository.
    When customizing objects, do not modify FDMEE seeded objects imported from the FDMEE repository. Instead, copy needed objects, use the“ Custom” suffix in names to identify them, and then modify them.
    For example, copy the “Open Interface Balances” package as “Open Interface Balances Custom,” and make any edits to it.
  7. Export customized objects (for example, Project, Packages, Interfaces) from the custom repository and import them into the FDMEE repository.
  8. Using the FDMEE Source Adapter user interface, copy the Open Interface Adapter to a new adapter and complete the following:
  • For the new adapter, provide a new adapter key. The adapter key can be ten characters long. Once it has been created, it cannot be modified.
  • Make any necessary modifications to the Display Names. Display Name are shown in the Import Format and Data Load Workbench.
  • Specify the ODI Package Name and ODI Project Code as specified in the custom project.

The above list is the updated guidance from Oracle but please follow the documentation links to Oracle and get it straight from the source in case they update this in the future.

ODI Pro Tip: FDMEE ships with an embedded ODI 11g repository (11.1.1.7 I believe). The Work repository is identified numerically as 501 and if you try to migrate objects between two repositories with the same ID you will get an error message from ODI. In traditional ODI development (with stand-alone ODI repositories) you would provide unique identifiers for each environment so that ODI can properly identify the lineage of your code. (Dev = 10, QA = 20, PRD = 30, etc…) With FDMEE, ODI is embedded (not stand-alone) and Oracle has fixed the Work repository ID at 501. Thus code migration will be impacted if you start your development in the FDMEE Work repository. Also, keep this architecture change in mind if you still need to upgrade ERPi to FDMEE and you are using an early version with custom ODI code.

I hope this additional detail gives you some ideas on improving the process of customizing the FDMEE Open Interface Adapter. I encourage you to use the latest documentation for your products and their respective patch levels as supplied directly from Oracle. (Also, long live ODI!!!)

Cheers!