Data Integration (DI) — the EPM Cloud evolution of FDMEE (Financial Data Quality Management Enterprise Edition) — is Oracle’s data management application within the EPM Cloud suite, responsible for extracting data from source systems, applying transformation and mapping rules, validating the result against defined controls, and loading the transformed data into EPM target applications. DI is purpose-built for EPM data flows, with native integration to Oracle’s EPM applications (PBCS, FCCS, PCMCS, ARCS) and a mapping framework designed around EPM dimensional concepts. Every production EPM environment that loads data from an ERP or other source system should use DI as the integration layer rather than loading data directly through file imports or API calls without the mapping and validation controls DI provides.
DI Architecture
A Data Integration load process has four stages. First, the source system extract — DI connects to source systems (Oracle EBS, Oracle Fusion, SAP, or any JDBC-compatible database) through source system adapters, or accepts flat file uploads from systems without a direct adapter. Second, import format mapping — the source data’s structure is mapped to DI’s internal staging structure. Third, dimension mapping — each source dimension value is mapped to the corresponding EPM target dimension member through mapping rules, which may be explicit (account 4100 maps to “Revenue — Products”) or pattern-based (accounts beginning with 41% map to the Revenue hierarchy). Fourth, load execution — the mapped, validated data is written to the EPM target application through a data rule execution.
DI maintains a full audit trail of every load — source record count, mapping exceptions, loaded record count, and load status — accessible through the DI workbench. This audit trail is the primary evidence for data load quality reviews and is the starting point for investigating discrepancies between EPM data and source system data.
Design Considerations
Mapping rule design in DI is the most time-consuming and business-critical configuration task in an EPM data integration implementation. Every combination of source dimension values that can appear in the source data must have a mapping rule that resolves it to a valid EPM target dimension member — or a defined exception handling behaviour. Mapping rules that cover 95% of source records but have no rule for the remaining 5% produce loads that are 95% complete — and the 5% that is missing is discovered when reconciliation reveals a material balance discrepancy.
What Goes Wrong in Practice
The specific DI failure that most frequently produces unexplained EPM balance discrepancies is mapping rules processed in the wrong sequence. DI applies mapping rules in the order they are defined, and a more specific rule that should take precedence over a wildcard must appear before the wildcard in the rule sequence — otherwise the wildcard matches the value first and the specific rule is never evaluated. When a wildcard rule maps “all accounts beginning with 41” to one target, but account “4100” should map to a different target, the specific rule must precede the wildcard in the mapping rule list. If it does not, account 4100 is silently mapped by the wildcard rule — the load completes without failure, but the data appears in the EPM application in the wrong account, discovered in reconciliation.
How Loop Wise Solutions Handles This
We include DI mapping rule testing as a formal test phase — generating test records that exercise every mapping rule and every edge case, running them through the DI process, and validating that each record maps to the expected EPM target. Mapping rule sequence is documented and reviewed as part of the DI design review. We do not accept a DI implementation as complete until the full mapping rule set has been tested against representative source data.
Answers before you ask.
DI is EPM Cloud's data management layer for loading data from source systems into EPM applications, handling source-to-target mapping, transformation, validation, and load reconciliation. It is the successor to FDMEE, carrying forward the same core mapping-and-load concepts into the cloud interface. It sits between source extracts and the EPM cube.
A source (file or direct connection), a target application, an import format defining the source layout, a location grouping the setup, and mapping rules that translate source members to target dimension members. Data loads through these mappings, with validation and a reconciliation drill-back so loaded figures can be traced to source.
Through dimension mapping rules — explicit, range, or conditional — that convert source values into valid target members. For example, a range of source cost-centre codes maps to one target entity. Well-designed mappings are what keep loaded data valid and reconcilable; unmapped or mis-mapped members are a leading cause of load failures.
Through file-based loads or direct integrations, and for on-premises sources via the EPM Integration Agent, which lets DI query an on-premise database and bring results into the cloud. Understanding which connection method a source requires is prerequisite to designing a reliable, automatable data flow.