Copy Version Snapshot in ASO model

Something that comes up regularly is creating a snapshot of Scenario & Version, often a copy of “Budget” “Working” into “Budget” “Final” and locking the data as read only.

Data Copy in BSO

In a BSO or Hybrid model it’s pretty straight forward and you’d do something as simple as this:

It’s quick, simple and efficient, even with copying the upper level blocks on my test model it took 1min 30secs. Not much more to say on this really.

Data Copy in ASO

In the past, for an ASO model this would have been neigh on impossible, but now we have some options that we can explore.

  • In Groovy
    • Data Exporter/Data Import Request
    • Flexible Data Grid Export/Grid Builder Import
    • Custom Calculation
  • Data Manager
  • Create an Export file, parse the file to replace values and import

I’m only going to look at the Groovy options as exporting a file feels a bit clunky.

Groovy Options

Data Exporter/Data Import Request

I’ll start with createDataExporter/createDataImportRequest as this was the simplest to code and would work over a large data set. First I wanted to see what data I’d get from the createDataExporter so I set up an export with some row filters to reduce the data set size.

File Output

n.b. Using a filter of account members “setRowFilterCriteria” results in an empty set being returned and the script exits with a success code.

Using the “CELL_FORMAT” I get a single data column

If I comment out the “CELL_FORMAT” across the columns are the Compression dimension: Accounts

Just to see how it worked, I added this line and changed the output #Mi to 11

  Map<String, String> values = rowData.valuesMap.collectEntries { k, v -> [(k): (v && v == “#Mi” ? “11” : v)] } as Map<String, String>

Properties Output

Then I wanted to see the properties of the RowData Object and the Tuple Object so I updated the filters to output 1 cell. Given that the accounts are in the columns as the compression dimension, I added “setColumnMemberNames” to filter accounts.

Here are the properties output:     

The ones I’m interested in changing for the target of the copy is the Tuple for Scenario and Version.

Copy Script

As an aside, CELL_FORMAT or COLUMN_FORMAT, either way it made no difference to the execution time of the data copy, on my test model it took 6 mins to copy a full Scenario/Version pair for all other members using the script below:

 

Difference in EPCM

I tried the same script in EPCM and got no results. Quite mysterious. After some trial and error I discovered the way to do it in EPCM. In EPBCS we need to replace this line

 dataImporter.addRow(createRowData(targetMembers,  rowData.columnMembers, rowData.getValuesMap() ))

with this

dataImporter.addRow(targetMembers, rowData.values)      

However if I substitute this line into the EPBCS script I get this error

Don’t know why this is the case but the Oracle documentation is how it works in EPBCS.

Oracle example for EPBCS

In the documentation, the example uses the createRowData method

https://docs.oracle.com/en/cloud/saas/enterprise-performance-management-common/groov/oracle/epm/api/model/DataImportRequest.html

Flexible Data Grid Export/Grid Builder Import

I tried the flexibleDataGridDefinitionBuilder/dataGridBuilder to see if it would work. For a limited data set it was very efficient, this took 2 seconds to run whereas with the dataExporter on the same cohort of data, it took 43 seconds.

After expanding the member selections on the “addRow” with :

I had this issue with the grid size.

I suppose I could have looped through a list of the periods and accounts, closing the grid each time but with 940 accounts * 20 periods * 2 seconds per grid would be estimated 10 hours run time, I was not optimistic enough to put it to the test. So this definitely has it’s place though for a smaller data copy.

Custom Calculation

On the small cohort of data as used with the previous tests, with a focused clear that matched the target cohort, the executeAsoCustomCalculation took 1 second to run. The best yet. Expanding the cohort with all departments, periods and accounts still only took 8 seconds, so a much bigger data selection than the flexibleDataGridDefinitionBuilder could handle. Adding all the years took the copy up to 3min 50 secs. All currencies took it to 7min 30secs. Expanding the data set to all the level 0 members and the calculation took 13min 40secs.

Making use of the “use_optimized_way” & “NONEMPTYTUPLE” made matters worse on the performance of the calculation.

n.b. on a larger test environment I did encounter a cell limit issue so this could be a limiting factor and given the complexity of the code, I’d prefer the createDataExporter method.

Leave a Comment