Oracle Data Integrator questions, answered clearly.

Oracle Data Integrator (ODI) is Oracle’s data integration platform for moving and transforming data between databases, applications and files. It works on an extract, load and transform pattern: data is loaded into the target database first and transformed there, using the database’s own engine, which is why it handles large volumes well. Developers build mappings in a graphical designer, package them into scenarios and load plans, and run them through agents on a schedule. In the EPM world it matters for two reasons: it is the engine underneath FDMEE, and it is the tool for loads that FDMEE’s financial model does not fit, such as operational data into Essbase or a data warehouse feeding Planning.

Any integration that is too large, too frequent or too non-financial for FDMEE. Typical South African uses are loading sales, production or operational volumes into Essbase cubes from point-of-sale, mining or manufacturing systems; building the data warehouse or data marts that feed EPM and analytics; loading metadata into Planning and Essbase from master data systems; replicating data between databases with change data capture; and moving data between on-premises systems and Oracle Cloud. Where a finance team needs mappings, validation and drill-through, FDMEE sits on top; where the job is volume and transformation, ODI does the work directly.

Performance on large volumes, because transformations run inside the target database rather than in a separate engine; reusable Knowledge Modules that encode how to load each kind of source and target, so the same pattern is applied consistently; a single repository holding every mapping, so integrations are documented by construction; operator logs that show exactly what ran, what failed and how many rows moved; and native support for Oracle and non-Oracle databases, files, XML, and the EPM applications through dedicated Knowledge Modules. For a group with many feeds, it replaces a collection of undocumented scripts.

ODI 12c is the current on-premises release line, with 12.2.1.4 the long-term supported version; Oracle continues to patch it and supports it under its published lifetime support policy. ODI 11g is on Sustaining Support and should be treated as a migration project rather than an environment to invest in. Oracle also offers ODI on Oracle Cloud Infrastructure through the Marketplace, and OCI Data Integration as a cloud-native service for new work. The ODI embedded in FDMEE follows the EPM System release it ships with, so an EPM 11.2 upgrade is also an ODI upgrade for that component.

By delivering the data that reporting depends on, complete and on time. ODI loads the operational and financial data that Essbase, Planning and data warehouses report on, applies the transformations that make sources comparable, and logs row counts and errors so that a report built on last night’s load can be trusted. Change data capture keeps near-real-time feeds current without full reloads. For EPM specifically, it can also load metadata, so hierarchies in Essbase and Planning match the source systems the reports are compared against.

Yes. ODI connects to the databases behind SAP, Oracle E-Business Suite, JD Edwards, Microsoft Dynamics, Sage and other ERPs through JDBC, to their application layers through specific adapters where Oracle provides them, and to any flat file, XML or web service source. It is the technology FDMEE uses for its SAP and other adapters. In South African estates it is most often found extracting from SAP and Oracle ledgers into a staging database, and from operational systems such as point-of-sale, production control and billing into Essbase or a warehouse.

Yes. Oracle provides Knowledge Modules for Essbase, Planning and HFM that load data and metadata directly, and ODI is the engine inside FDMEE, so it already touches every FDMEE load. For Oracle EPM Cloud, ODI can prepare and stage data that Data Integration then loads, or push files to the cloud through EPM Automate. The usual division of labour is ODI for volume, transformation and non-financial sources, FDMEE or Data Integration for financial loads that need mapping, validation and drill-through.

FDMEE is a finance application built on ODI: it adds locations, import formats, period and category mappings, data load mappings, validation, the import-validate-export-check workflow and drill-through, all designed for a finance team to operate. ODI is the general-purpose engine underneath, operated by an integration developer, with no financial model but far more flexibility and throughput. Use FDMEE where the finance team owns the mappings and auditors want drill-through. Use ODI where the job is high-volume, operational or warehouse data, or where the transformation logic does not fit FDMEE’s model. Most EPM estates use both.

Yes, for the data movement part of them. Scenarios and load plans run on schedules through ODI agents, with dependencies, restart points and notifications, so the overnight loads that used to be a checklist run unattended and report their own failures. Change data capture removes the manual full extract. Procedures and packages handle the housekeeping around a load, such as archiving files, refreshing Essbase cubes or triggering an FDMEE batch. What remains manual is deciding what a new source field means, which is a business question rather than an integration task.

ODI has its own security module with users, profiles and object-level privileges, and can be integrated with an enterprise directory. Database credentials are held in the topology and can be stored in an Oracle wallet rather than in scripts. Agents run under service accounts with only the access they need, and all data movement is logged in the operator with row counts and errors. Data stays inside your databases and network; nothing is staged outside them unless you design it that way. As with any integration platform, the practical risk is an old, unpatched 11g installation with shared passwords in plain text, which an upgrade and a credential review resolve.

Organisations with many data feeds, large volumes or both: groups loading operational data into Essbase for management reporting, companies building or maintaining a data warehouse alongside EPM, financial services firms with high-volume transaction feeds, retailers with daily point-of-sale loads, and any group already running FDMEE, which contains ODI whether or not the team uses it directly. A small estate with one ERP and one EPM application usually needs FDMEE alone; a group with a dozen sources and a warehouse needs ODI.

Knowledge Modules are the reusable templates that tell ODI how to perform each step of an integration for a specific technology: loading Knowledge Modules move data from a source, integration Knowledge Modules write it into a target, check Knowledge Modules validate it, and journalising Knowledge Modules capture changes. Oracle ships modules for Essbase, Planning and HFM that understand cubes, load rules, metadata and calculation triggers, which is what makes ODI able to load EPM applications natively. They matter because an EPM load built on the right module is fast and supportable, and one built on a generic module with custom code is the kind of integration that only its author understands.

ODI is the integration engine of the wider Oracle estate rather than an EPM module: it powers FDMEE, loads Essbase, Planning and HFM through dedicated Knowledge Modules, feeds the data warehouses and marts that EPM reports against, and moves data to and from Oracle Cloud. In an EPM estate it sits below FDMEE, beside Data Relationship Management for master data, and above the ERPs and operational systems as the layer that makes their data usable.

Yes, at two levels. On the data itself, ODI is often the tool that assembles the clean, joined data sets that AI models and assistants need, so it is part of any practical AI programme on the finance and operational estate. On the integrations, AI can help analyse operator logs for recurring failures, suggest mappings for new source fields and document undocumented packages. Namandla’s approach is to apply AI to the data and integrations you already have, with a person confirming every change to a mapping or a load, rather than to treat AI as a reason to replace a working platform.

Namandla is a South African consultancy whose senior team has built and supported ODI integrations for about two decades, standalone and as the engine inside FDMEE, into Essbase, Planning, HFM and data warehouses, and the person who reviews your integrations is the person who fixes them. We are independent on the on-premises versus OCI question and answer it on your sources, volumes and skills. Contact info@namandla.com or 087 188 3388.