How to Handle Dynamic Reference-Number Members in Oracle EPM Planning Using Data Integration

In some Oracle EPM Planning implementations, incoming reference numbers need to be represented as members in a Planning dimension.

For example, an incoming reference number may follow a naming convention such as:

RF_260617153457

When these reference numbers are received through an inbound process, manually creating members can become repetitive. Data Integration can be used as part of a repeatable process to handle these inbound values and map them to the required target dimension properties.

In this article, I will walk through a practical example using a Reference Number (RF) dimension.

Note: The exact member-creation behavior depends on the integration/load type and the Oracle EPM Cloud release being used. Mapping a source column to a property such as Member Name does not, by itself, prove that a new member will be created.

High-Level Process

The overall process consists of the following steps:

1. Prepare an inbound file containing the RF column.
2. Configure the import format.
3. Create or configure the Data Integration.
4. Configure the required dimension properties.
5. Define the member mapping pattern.
6. Run the integration.
7. Review the process log.
8. Validate the member and its properties in the target dimension.

The overall flow is:

Inbound File → Import Format → Data Integration → Dimension/Property Mapping → Member Mapping → Integration Run → Validation

1. Configure the Data Integration

The first step is to create or edit the integration in Data Exchange/Data Integration.

Configure the required:

• Source
• Target Planning application
• Category
• Location

In my example, the integration uses an RF inbound source and a Planning application as the target.

Data Integration General Settings

Figure 1: Data Integration General Settings with anonymized source, target, category, and location values.

The important part of this configuration is establishing the correct source and target before moving on to the dimension and member mapping configuration. Oracle_EPM_Dynamic_RF_Member_Cr…

2. Configure the Import Format and Dimension Properties

After configuring the integration, the next step is to associate the appropriate import format.

The source column containing the reference number needs to be identified correctly.

In this example, the source column is:

RF (Reference Number)

The RF value can then be associated with the appropriate target dimension properties.

Depending on the load requirement, these properties may include:

• Member Name
• Parent
• Data Storage
• Alias
• Other dimension-specific properties

Dimension and Property Mapping

Figure 2: Data Integration dimension-property mapping using the RF reference number.

One important point to understand here is that mapping a source column to a property labelled Member Name does not, by itself, prove that the integration will create a new member.

The actual member-creation behavior depends on the integration type, load approach, and Oracle EPM Cloud release being used. Oracle_EPM_Dynamic_RF_Member_Cr…

This distinction is important when designing or troubleshooting metadata-related integrations.

3. Define the Member Mapping

The next step is to configure the member mapping.

For the RF naming convention, a pattern such as:

RF_*

can be used when the incoming values and intended target member names follow the same convention.

For example:

RF_260617153457

matches the:

RF_*

pattern.

Map Members Configuration

Figure 3: Data Integration Map Members configuration using the RF naming convention.

The mapping configuration should be reviewed carefully to confirm that the rule type is appropriate for the intended member-mapping or metadata/member-load process. Oracle_EPM_Dynamic_RF_Member_Cr…

4. Run the Integration

Once the integration, import format, dimension properties, and member mapping are configured, the integration can be executed.

After running the integration, review the process status and detailed process log.

The log can help identify issues such as:

• Invalid member names
• Missing parents
• Invalid property values
• Mapping mismatches
• Duplicate names
• Naming-pattern mismatches

For dynamic reference-number processes, reviewing the process log is particularly useful because the incoming values may change from one integration run to another.

5. Validate the Result

After the integration completes, the next step is to validate the result in the Planning application.

Verify the RF Member

Confirm that the expected RF member exists in the intended dimension.

Get Anilurs Hyperion’s stories in your inbox

Join Medium for free to get updates from this writer.

Remember me for faster sign in

For example:

RF_260617153457

Verify the Parent

If the member is expected to exist under a specific parent, verify that the hierarchy is correct.

Validate Member Properties

Check the required properties, such as:

• Parent
• Data Storage
• Alias
• Dimension-specific attributes

Test New and Existing RF Values

It is also useful to test both:

• A new RF value
• An existing RF value

This helps confirm how the integration behaves in both scenarios.

Check for Potential Issues

Validate that there are no:

• Duplicate names
• Invalid characters
• Missing parents
• Naming-pattern mismatches

If members need to be created under a particular parent, also verify how that parent is supplied and whether the selected load method supports the required hierarchy update. Oracle_EPM_Dynamic_RF_Member_Cr…

Important Considerations

There are a few important points to keep in mind when implementing this type of process.

1. Member Mapping and Member Creation Are Different

One of the most important lessons is that member mapping and metadata/member creation are distinct concepts.

A mapping rule identifies how source values correspond to target values, but the actual creation of a new Planning member depends on the integration type and supported metadata/member-load workflow.

Therefore, the complete configuration should always be validated in the target environment. Oracle_EPM_Dynamic_RF_Member_Cr…

2. Use a Consistent Naming Convention

A consistent naming convention makes dynamic reference-number processing easier to manage.

For example:

RF_*

provides a predictable pattern for RF members.

3. Validate the Parent-Child Relationship

If an RF member needs to be created under a particular parent, make sure the required parent information is supplied and that the selected load method supports the required hierarchy update.

4. Test Before Production

As with other metadata-related changes, test the configuration in a non-production environment before promoting it to production.

Also make sure that screenshots used for public documentation do not contain client names, tenant URLs, application names, locations, or real business reference numbers. Oracle_EPM_Dynamic_RF_Member_Cr…

End-to-End Flow

The complete process can be summarized as:

1. Receive the RF value

↓

2. Identify the RF column in the inbound file

↓

3. Configure the Import Format

↓

4. Configure the Data Integration

↓

5. Map the RF value to the required dimension properties

↓

6. Configure the RF member mapping pattern

↓

7. Execute the integration

↓

8. Review the process log

↓

9. Validate the RF member and its properties

This provides a repeatable approach for handling reference-number-driven dimension requirements.

Practical Takeaway

The key takeaway is that dynamic reference-number processing is not simply about creating a mapping rule.

The integration configuration, import format, dimension properties, member mapping, and supported metadata/member-load process all need to work together.

It is also important to validate the actual member-creation behavior in the specific Oracle EPM Cloud release and integration type being used.

Conclusion

Dynamic reference-number requirements can be handled through a structured Data Integration approach in Oracle EPM Planning.

By using a consistent RF naming convention, correctly configuring the integration and dimension properties, defining the appropriate member mapping, and validating the resulting hierarchy and properties, the process can become repeatable and easier to maintain.

The most important lesson is to distinguish member mapping from actual metadata/member creation and to validate the complete workflow in the target environment before moving it to production.