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.
