A while ago I got asked to come up with a solution for Smart Merge. Now I’m more a database developer then much else, so my first though was lets do it on the DB. As I spend much time coding this and I got to say I’m not yet really happy with my jython skills I’m not sharing the code, but the idea. Hopefully it will help you get trough getting it developed.

I used 2 additional artefacts on the DB. One table and one view. The view is droped and recreated during the BefLoad. Basically what I did is create a table that is similar to TDATASEG and into which before a new load to TDATASEG is done copies the lines for the pertinent CATKEY, PERIDKEY and ENTITY, to the auxiliary table.

The overview of steps executed:
I. In BefImport: Data from TDATASEG for previous relevant load is stored in TDATASEG_SM, and view TD_TO_TDSM (which holds: TDATASEG_SM – TDATASEG) is created for current CATKEY, PERIDKEY and ENTITY
II. In AftExportToDat, based on the view we append lines with NODATA

The additional candy is the fact there a function that sorts trough the file and makes a list of all entities in there, so to query dynamically which Entities are present in the file.

Got questions about it? Just leave me a comment bellow and I will try to explain, without giving out the code 🙂

UPDATE: After few months of testing I had to move the load of TDATASEG_SM into the AftLoad Event script so to ensure the data loaded in there is the data that is relevant for the next load.

I was helping out a colleague of mine so I was investigating why a script that would export data in 11.1.2.2 was not exporting anything in 11.1.2.4. Started by only using

Essbase would respond with:
Received Command [Calculate] from user [admin@Native Directory] using [EXP.csc]
DataExport detects Dynamic Calc member [KittenMbr] in the range. Exporting Dynamic Calc data may slow down performance.
This DataExport operation will export data from existing blocks only. Any FIX on sparse dynamic calc members will be ignored. Use DATAEXPORTNONEXISTINGBLOCKS ON option to export data from all potential blocks.
Data Export Completed. Total blocks: [15]. Elapsed time: [0.023].
Total Number of Non-Missing cells exported: [60].

Now this is a cube with many Sparse members on DynamicCalc – I got no influence on this part -, which was mitigated in the old version by using:
DataExportDynamicCalc ON;
DATAEXPORTNONEXISTINGBLOCKS OFF;

Same result. Hmm interesting.

After 2 minutes on Metalink, we were able to find Document 2123909.1, where Oracle development explains changed the behaviour. Short story: you are supposed to use them as:
DataExportDynamicCalc ON;
DATAEXPORTNONEXISTINGBLOCKS ON;

After using it as above, I get the response from Essbase:
Received Command [Calculate] from user [admin@Native Directory] using [ESC.csc]
DataExport Warning: This DataExport operation will export a total of [3958416] blocks. Exporting dynamic calc members from all blocks has significant performance overhead. Use DATAEXPORTNONEXISTINGBLOCKS OFF option to export data from existing blocks only.
Data Export Completed. Total blocks: [45]. Elapsed time: [508.234].
Total Number of Non-Missing cells exported: [180].

Do I got to add be careful with this? if nothing else is an indication, just look at how much more time it took for export of still such a small amount of data.

Better late than never. I got to install the new version of HP. Still not patched but that will be my next step. For now I got this:

In the installation I used: CentOS 5.11 and Oracle DB 12c.

Kernel info (you will be able to see it in the validation, later on as well):
CentOS511

The uninformed surprise (as I did not prep on the new things in the DB, this bit was much a surprise – both positive and negative one):
DB_EM_Express

I was surprised how easy the Hyperion bit was. Install was pretty much as always Next, next, next…and the configuration, tho I did it in few iterations, was very simple and without any pain.

Validation (“Green…green everywhere”):
validation

At this point I had to see a new application in the system…as seeing EAS empty made me a bit sad.

HCSample seemed a good idea. At this point I wanted to see LCM error, before all else. So imported CalcMng before just to see it error:
LCM_Errors

Sounds correct…I did try to trick you CalcMgr. Now importing “module” per module works. But did they somehow improve the import process? Almost…almost

LCM_RAF

…2min later. Did I configure FR even? Nop 😀

Okey. Lets try this again. Delete existing app and rules…just in case DS as well, so at least I know I started with a clean environment.

And ta-da:
LCM_All_In

After further check – still had to create a FR connections (5 in this case).
The FR book still does not work as expected.

On further note it all good looked in Planning (& FR), until I tried to look into CalcMgr.
CalcMgr
Turns out only some parts got imported. Reimport on it’s own and much more artifacts are present now.

Last though on this point:
– As for now I would still NOT recommend importing the whole starter kit in one go…at least from this experience.
– I’m using 8Gb on my Virtual Machine, running DB and WebLogic and Hyperion and it’s not slow – so kudos*.

*For Reference
Resources