so same import for 5 different locations which actually have different mappings and then load it into 5 HP apps, right?
in any case you will need source data 5 times in your FDMEE app. Otherwise how are you going to perform the mappings for the 5 locations?
If you want to avoid extracting data 5 times you could have only the 1st data load rule extracting the data, and the other 4 copying the data being imported in first place instead of importing it from Fusion. Then probably, you would to have to configure 4 of the locations with open interface locations.
But I guess you will need to have imported data 5 times any way :-(
Many thanks for the reply.
I understand what you say. I did wonder about using the Open Interface in the way that you mentioned, however it would still mean 5 copies of the data and the performance overheads etc.
I did wonder if after after the first load, if in an FDMEE event script, some SQL could update the FDMEE tables for the first import in order to effectively swap the location of the data, and change the status to imported?
Then it would be a case of running the validate (to re-map) and export on that data for the new location, and repeating for the remaining locations?
There is no requirement to maintain Drill Back, so the data not existing for the first 4 loads is not an issue, but my concern is firstly over the feasibility in doing this via SQL (in the TDATASEG etc), and secondly how to run from the Validate stage programmatically, as the old FDQM even stages don't seem to exist in FDMEE, and although in Data Load Workbench imported data can be re-validated, I'm not sure what event is exposed to run from this point without importing again?
The other idea I had was to somehow effect the view of the data in the generated Essbase Load Rule. So as the data comes in once, via 1 standard FDMEE location using standard Fusion/Planning adaptor, it is only "burst" into 5 lots of data in the Essbase Import (via the Essbase DataLoad rule and SQL view dynamically created by the FDMEE Export). As the mappings will be maintained via DRM Exports to custom FDMEE mapping tables anyway, (so the FDMEE mappings would all be #SQL "like" mappings), the view of the data used in the Essbase imports would just be a different SQL statements for each of the 5 applications. (The select and where would differ for each based on how the SQL mapping logic works, but the FROM in the SQL would be the same).
Again, I'm not sure how possible it is in an after export to update the SQL view of the Essbase Data Load Rule and point to a different Essbase application and re-run? I assume the objects exist somewhere, as is the ability to instigate a load via calcs etc, so it must be doable somewhere I would hope - if indeed this makes sense?
Anyway, I hope that made some sense, and if you have any thoughts on this, it is greatly appreciated.
I'm aware that this seems like a lot of trouble for what it is doing, however the data volumes are very large and performance requirements will generally highlight duplicate FDMEE imports as unacceptable.