I am just a starter but will try to answer to best of my ability,
I believe you mean 2 plan types and not instances. You can create 3 BSO, 3 ASO plan types as part of single PBCS subscription/instance.
Data Management supports Flat file based data sources, EPM SAAS cloud services and Fusion GL cloud(probably few other SAAS applications). On Prem Data sources are not supported as of now. Check the limitations for cloud Data Management when compared with On prem FDMEE,
For integration between plan types smart push is a valuable feature but it has some limitations, (Very useful to move small sets of data)
Hope this helps,
Hey Manoj thanks for replying! Why do you believe its one insance, since we have two?
Data Management( you can utilize EPM automate for automation etc) is the tool use to move data between instances.
You would want to review the Data Management Admin documentation:
The well known J Goodwin has also written blogs on this which you would want to review.
1 person found this helpful
You mentioned about integrating two plan types. Are these plan types related to two separate PBCS PODs or a sinlge PBCS POD?
If your inst01 and inst02 plan types are part of two separate PODS smart push may not work.
You have the option only to select plan types from the same PBCS POD in source and target while creating Data Maps.
I am not completely sure but the same may apply for Xref/Xwrite. (If plan types belong to 2 separate pods)
Two separate Pods. I was afraid it would not work too
Others may see this differently but for me Cloud Planning and Budgeting is not yet as scaleable as on premise, for organisations that had a long history and have built several on premise solutions I personally see PBCS as a step backwards.
I find it lamentable that Oracle are effectively making on premise a legacy solution whilst the Cloud based equivalent, whilst it contains some useful new functionality, cannot yet fulfil the same as on premise could.
Being able to directly query the rdbms - gone
Shared library - gone
Multiple applications - gone
Direct database exports - gone
Maxl - gone
Essbase outline edits - gone
Robert, thanks for your comment. I believe that the cloud is the way to go
I would use the REST API to download the data (export/download) and upload to the other POD (upload/import). Also, whatever language you use to interact with the REST API can translate the data if needed.