Saturday, 14 May 2011

Planning – Automate pushing of Reporting Application data

One of the new features in planning 11.1.2 was the ability to map and push data to a reporting application, I covered the reporting functionality in an earlier blog which you can read here, one of the drawbacks was if you wanted to push the data to an essbase database it had to be done manually, depending on the size of the data the export/import could take a while and it would be something you would want to schedule out of hours.

With the release of a new command line utility called PushData has been created, the utility provides the functionality to automate the pushing of data for any Reporting Applications that have been set up in a planning application.

The utility is available with the other planning utilities in the directory <MIDDLEWARE_HOME>/user_projects/epmsystem1/Planning/planning1

The parameters to use the utility are -

PushData [-f:passwordFile] /U:username /A:sourceApplication / M:applicationMapping [/C]

Most of the parameters are self-explanatory, if optional /C is used then the data on the target is cleared first.
If you want to understand how to create a password file have a read here

PushData.cmd /U:admin /A:PlanSamp /M:PLANASO /C

The utility also produces a log available at -

The log will capture whether the pushing of data was successful or not and any members that are skipped due to not existing in the target.

It is also possible to check the status through the Job Console within the planning application.

I did notice some strange anomalies in the log as shown above.

After successfully running the command line utility it can be batched up and scheduled using your chosen scheduler to run at required intervals.


  1. Quite helpful....

  2. Real time fully aggregated data in Planning ... with over 2000 mini-pushes per day. We use a similar approach to push subsets of data to an ASO cube with a partial clear. A custom function (CDF) in business rules enables users to automatically launch the push on save. Form POV determines which part of the data moves. Next we bring the data back to the BSO Planning cube through a transparent partition.

  3. Mike,
    This looks like a very interesting option. I assume this custom function was tailor made and is not freely available?

  4. Thank you for writing about this utility. I am trying to automate the data transfer between a BSO and ASO plan type with this utility on, but I am hitting an issue in the case when my dimensionality changes (but is kept constant between both plan types). Despite having defined the mapping with the lvl0 function (ILvl0Descendants(All_Accounts)), I am required to refresh the mapping prior to running it if new members have been added to the lvl0 pool. So far, I have only been able to manually refresh the mapping in Workspace. Are you aware of any hidden parameters that can handle the refresh in order to achieve full automation of this process? Thank you.

  5. Julia (and I suppose everybody else!)

    did you ever find an ability to refresh the mappings without going through the front end? We've got the same problem.

    Currently we're figuring it's just a SQL query somewhere - it might be possible to setup some logging to work out what/where it's happening and then schedule it on demand somehow.


  6. Does anyone know if this functionality actually produces and stores a calc script the with the dataexport syntax anywhere?

  7. Philip - did you ever find the mra script?


Note: only a member of this blog may post a comment.