Skip to Content
Author's profile photo Former Member

Approach to SAP Note 1823400 | Consistent Attribute Names after Transport


I thought I would take the chance to share my experience when attempting to implement SAP Note 1823400.  The note itself left quite a lot of questions unanswered and for a relatively newcomer to the BPC world, it was quite a nerve-racking proposition to follow some of the below steps in a live environment!

  • Backup the data
  • Delete the data (model & dimensions)
  • Delete the properties of dimensions
  • Transport dimensions from Dev
  • Load back the data.

Blimey!  Certainly not a job for the faint hearted and one which I chose to thoroughly test and research first.  In this post, I detail the steps I went through to successfully implement the fix.  I do not profess to being an expect with BPC just yet so I would welcome any comments on a better approach!

So… How did we begin facing this problem? It was decided by our company that we would start reporting on BPC data via Business Explorer.  Fine.  This meant setting up a BW structure which would retrieve data from the BPC model / cube (this also required a fix to keep technical names of models the same following a full optimise. See Note: 1689814 ). Unfortunately, we found that newly created BW structure failed to work when arriving in QA due to all of the dimension property technical names (which we referenced in our transformations) being completely different in other environments!!  What a pain.

At this point, if you are facing the same problem, it would be worth you reading through the 1823400 note to be sure the problem you are facing is exactly as described.  The remainder of my post details the steps I took to successfully implement the note.  I was probably overly cautious in my attempts to mitigate the risk of anything terrible happening but I’m a firm believer in preparing for the worse case scenario in order to cover one’s own backside.

1. Implement SAP Note

This is relatively straight forward.  Make sure you complete the manual steps as outlined in the note before following your standard procedure for implementing notes.  Ensure this is transported throughout your environment.  Our basis team took care of this for us.

2. Test the Note

To be sure the note has successfully fixed the underlying problem, create a dummy property within a dimension already in existence and transport it through your landscape.  This property / attribute should appear with the exact same technical name when viewed in the BW back-end.

3. Back-up!

Start with your QA environment to be sure that if everything does go belly up you’re not interfering with your production instance of BPC.  I took my backup using the UJBR tool.  This has worked really well for me in the past and I trust it.  I backed up data selecting meta data, transactional data and master data.

Just incase the UJBR failed (I’ve only know it to when doing a copy-back of data from Prod to QA when the dimension structures were different) I took an export of the dimension data via the front end export feature.

4. Get Deleting

– Delete all data from your BPC model via the BW delete function

– Delete all master data from BPC.  We did this manually in the front-end web client by deleting our way up the hierarchy (it won’t let you delete anything which is a parent to another member still in existence).

– Delete all properties from the dimension structure.  (Note, there will be some dimensions which may not delete if referenced elsewhere (e.g., in BPF’s).  You will need to remove the reference objects and re-transport or open the system and delete attributes required in BW reports.

Note: All of the above deletion steps were carried out in the QA environment.

5. Transport Dimensions

It’s now time to transport (Dev > QA) the dimensions you have been playing with in QA.  This will re-instate the properties you have just deleted but now with the same technical names as those in Dev!  Brilliant.  Make sure you only transport the dimensions and not the members as well.

Check to make sure the dimensions are back to how you would expect.  Note: the transport of these dimensions may fail with an 8 as referenced members may no longer be available in QA following the cull you did in step 4.  Don’t worry about this, the dimension structure will still be transported to QA – it’s just the environment check which failed.

6. Restore Data

It’s now time to run the UJBR tool again and restore the data back to QA.  Do not include the meta-data option here as you do not want to overwrite the design with that of the mis-matched technical names you backed up before the transport!!  You will need to run a Lite Optimize on this newly added data to improve performance.  Ensure the statistics are also up to date before you do so!

Give everything a good check and you’re done.

7. Moving to Production

Moving to production will follow the exact same steps as above.

Tips:  I gave myself an entire 2 days to complete this process in QA and the same for Production leading up to the weekend in case I needed more time.  During this time, I took the environment offline and insisted that only I could work with it.  In reality, you could get this job done in just under a day but you do need to wait for back-up and restore delays depending on how much data you have in the environment you are trying to fix.  A little buffer is always good in case something goes belly-up.  It also takes an age to delete master data.  If anyone has a better method for this – let me know!!  Because of the dependency of hierarchies, I was not able to right click on the dimension in BW and ‘Delete Master Data’.

Good luck and feel free to contact me if you have any specific questions.

I hope this saves someone a little time!


Assigned Tags

      Be the first to leave a comment
      You must be Logged on to comment or reply to a post.