11.1.2.3 LCM – Classic planning dimension import changes

I know 11.1.2.3 has been around for a while now but I have been asked a few times about the differences with  how LCM loads dimensions between 11.1.2.3 and earlier.

I have meant to write a quick blog post on the subject for ages and never got round so here it is and then I can forget about it ?

Prior to 11.1.2.3 if you load dimension metadata using LCM to a classic planning application then the hierarchy between the source and target application will match, so basically it is replacing instead of merging, this goes against other artifacts being loaded into planning with LCM as they will follow the update/insert method and never delete.

I have always wished for an option to delete on target with LCM and Planning but that is a different story.

So let’s take an example in 11.1.2.2 and is true for earlier versions, say we have the following entity dimension which is identical between a source and target application.

The shared member “E03_310_1000” in the source application is deleted and use LCM to extract dimension.

If you take a look at the LCM output the dimension metadata is contained in an xml file.

Examing the xml file before the member was deleted it contained the following.

Obviously after the member was deleted the above information is removed from the LCM xml output.

After using LCM to load the Entity dimension into the target application the source/target should match and member “E03_310_1000” will have been deleted.

Moving on to 11.1.2.3 the method LCM uses changes and unless I have missed something in the mass of documentation I don’t see it mentioned, please let me know if I have missed it and I will update.

Running the same LCM example in 11.1.2.3 the source/target will not be matched and members in the target will not be deleted, members will only be updated/inserted.

Examining the LCM output in 11.1.2.3 you will notice that the dimension files are no longer xml and are csv.

Opening up the csv reveals the changes, now there is some xml embedded in a header block which relates to the dimension properties.

After the header block there is something very familiar if you have used the planning outline load utility, yes the format looks exactly the same.

In the planning documentation there is further information to back up the fact that the outline load utility might be used in 11.1.2.3, the admin doc has information about the header block and is reserved for internal use, I doubt you would have seen anything about HEADERBLOCK if you have been using the utility before.

The theory also holds true for the utility being used because the default load operation is update which means members will be added, updated or moved.

To confirm the utility is being used I updated the csv file to delete one member.

I added in the operation field which does not exist in the LCM export, the field has the following options:

The LCM import completed successfully.

Checking the hierarchy before and after the LCM import you will see it successfully deleted the shared member “E03_310_1000”

That pretty much confirms that LCM does use the outline load utility, it is also worth pointing out that a planning refresh will automatically happen with LCM, this is an additional parameter if the outline load utility is being used directly.

So what are the options for deleting members, well you can update the LCM csv file, use the outline load utility or the planning web version or even manually delete.

I still believe it would be nice to have an option in Shared Services to select whether it should be merge or replace import mode like that is available for EPMA.

If you intend on using LCM to migrate a planning application from a previous version then look at updating to the new format otherwise it may be painful ?