Oracle Data Integrator (ODI) & FDMEE Consulting

Three ways, and they combine. An assessment of the integration estate – what runs, on what schedule, against which targets, and what happens when a load fails. A defined piece of work with a measurable outcome, such as a Knowledge Module customisation, a mapping strategy rebuild, a drill-back repair or a rejected-record handling process. Or ongoing support across the load calendar, with enhanced cover through close and budget cycles.

Support is delivered remotely by default, subject to agreed access, security, scope and support hours, with on-site attendance where the work requires it. Engagements supplement your internal team rather than replace it, and because integration work touches source systems you may not own, we agree the access and change path with your DBAs and ERP team before anything is altered.

ODI is used to move and transform data between enterprise systems: data warehouse loading, application integration, migration and ongoing synchronisation. It generates native code that executes on the source or target database rather than processing data in its own engine.

That E-LT architecture is the main technical distinction from conventional ETL tools. It uses database capacity you already have, which suits high-volume work against well-tuned infrastructure and performs poorly against a database that is already the bottleneck.

Conventional ETL extracts data, transforms it in a dedicated engine, then loads the result. ODI extracts, loads, then transforms using code executed by the target database. No separate transformation tier is required.

The trade-off is real. ODI removes a tier to buy and maintain, and it makes your database performance directly responsible for your integration performance. Where the database has headroom this is efficient. Where it does not, adding integration load makes an existing problem worse.

A Knowledge Module is a reusable template defining how ODI performs a category of operation, and it generates the actual code that runs. LKM handles loading, IKM handles integration into the target, CKM handles data quality checks, RKM handles reverse engineering and JKM handles changed data capture.

Understanding KMs is what separates a working ODI implementation from a good one. Stock modules are generic by design. Customising them for your specific source, target and volume is usually where the significant performance gains are.

Check the database before checking ODI. Because transformation executes on the database, a slow load is frequently a missing index, stale statistics, insufficient temporary space or contention from other work. After that: the wrong Knowledge Module, full loads where incremental would do, and load plans running sequentially where they could run in parallel.

The diagnostic order matters. Teams often rebuild mappings before discovering the target table lacked an index, which would have been a considerably shorter afternoon.

FDMEE loads data into Oracle EPM applications with mapping, validation and drill-back. It lets finance own the mapping between source account codes and EPM members, validates data before it loads, and allows drilling from a consolidated figure back to the source transaction.

The drill-back is what makes it worth having. When an auditor asks where a consolidated number came from, drill-through answers it directly instead of triggering a manual reconciliation exercise.

FDMEE is part of the Oracle Hyperion application family, covered under Applications Unlimited with Premier Support through at least 2037. ODI is a separate Oracle product on its own release and support cycle, so check it independently rather than assuming the EPM date applies.

That distinction catches people out. An organisation can hold a valid support position on its Hyperion applications while running an ODI release that is behind, because the two are governed separately. Confirm each against Oracle’s Lifetime Support Policy for the specific product and release rather than treating the estate as one commitment.

Data Management is the EPM Cloud successor to on-premises FDMEE. The concepts are largely the same: locations, import formats, mappings, data load rules and drill-back. The interface and some capabilities differ, and cloud releases evolve on Oracle’s update cadence.

Migrating from FDMEE to Data Management is not a direct export and import. Mappings and load definitions need rebuilding and revalidating, which is a cost regularly missing from cloud migration business cases.

Data Management sits inside Cloud EPM – see Oracle EPM Cloud consulting for the wider migration picture.

Usually because rejected records go somewhere nobody looks. In ODI, the CKM writes rejected rows to E$ error tables that require deliberate monitoring. In FDMEE, records failing mapping can be excluded without the load reporting failure.

The fix is process rather than technology. Every load needs a defined success criterion beyond “it completed”, a visible record count reconciliation, and an owner who checks. Building that once removes an entire class of month-end surprise.

Yes. ODI connects to SQL Server, DB2, Teradata, PostgreSQL, MySQL, flat files, XML, JMS, web services and cloud sources through the appropriate technologies and Knowledge Modules. The E-LT approach means the generated code targets whichever database is involved.

Heterogeneous environments are where topology design pays off, because the abstraction between logical and physical schemas is what keeps mappings portable across technologies.

Frequently yes, for different jobs. FDMEE for finance-facing loads into EPM applications where mapping ownership, validation and drill-back matter. ODI for general enterprise integration, warehouse loading and anything outside the EPM estate.

Since FDMEE uses ODI underneath, this is not duplication. It is using the finance-appropriate interface where finance owns the mapping, and the general-purpose tool everywhere else.

Yes. We start by documenting what actually exists, which is usually the first time anyone has: repository contents, topology, active load plans against dormant ones, custom Knowledge Modules and the undocumented dependencies between jobs.

Inherited ODI environments commonly carry scenarios nobody can identify, running on schedules nobody set, feeding targets nobody has verified. Establishing what is genuinely in use is the necessary first step and it is often the most valuable single deliverable.

Yes, where the requirement is the integration and data flow into Hyperion or EPM. The exact source application, connector, interface method and ownership boundaries are confirmed during discovery.