In the past months we had to deal with a new business requirement: we had to add a new dimension in a productive Application implemented in a BPC75NW. This article deals with the procedure we decided to follow in order to preserve landscape consistence, in order to have a "transport controlled" system.
In SDN we found no reference to a similar scenario (see BPC75NW Transport a New Dimension in existing Application), so we decided to resume and share our experience.
CTS Correction and Transport System in BPC75NW does not allow to trasport single objects: change request are created via a specific Transaction UJBPCTR. About this topic see Life Cycle Management and SAP BusinessObjects Planning and Consolidation Version for NetWeaver.
With BPC NW it's easy to move from a transport controlled ApplicationSet, to a scenario where direct changes in Prod or QA sys are allowed. This happens when business users are allowed to to make changes directly in Prod environment.
Some days / weeks after initial transports a brand new ApplicationSet in the Prod environment can be totally different from the one in Dev environment: as a consequence CTS becomes much more that unusable: it becomes dangerous!
In our scenario BPC75NW was managed via CTS (using the typical Dev>QA>Prod development landscape) and so we had to plan the steps to reduce time needed to apply such a modification ti target Application. Our primary aim was minimizing Applicaiton Set "offline" time.
So we decided to clarify what was going to be included in transport: in order to include a Dimension in any Application it must contain at least one base member.
But which member? We tried to analyze the so called "Shadow Table" UJT_TRANS_OBJ and noticed that, for any Dimension, UJBPCTR was including details on one base member (just filter table UJT_TRANS_OBJ with APPSET_ID = <your_appset> AND TABNAME = UJT_TRANS_MBR).
Suddenly we discovered that transported members were not the "first" base.
According to us the transported member had to be the one with CALC = N and the lowest MBR__SEQ
So we thought we had to work on table UJT_TRANS_MBR, to force the base member to be trasported.
But then we discovered that UJT_TRANS_MBR is deleted and re-populated at each execution of UJBPCTR (see method COPY_PROD_DATA_TO_SHADOW of Class COPY_PROD_DATA_TO_SHADOW).
At the end we found that the base member to be trasported is choosen with this call in the same method:
So, before releasing the change request we did modify Shadow Table UJT_TRANS_OBJ in order to transport the desired base Member of the new dimension.
To do this:
a. find the ROWINDEX value in Table UJT_TRANS_OBJ corresponding to:
TABNAME = UJT_TRANS_MBR
ATTRIBUTE_NAME = ID
DIMENSION = <your_dim>
b. In change mode edit FIELDVALUE corresponding to FIELDNAME = ATTRIBUTE_VAL
We decided not to act on all properties of our Dimension: the most important thing to us was avoiding a "Move" DM Package execution in target system, because of the large amount of data.
For safety reasons, we decided also to backup (TCode UJBR) in all target systems (QA and Prod) before importing mentioned change request, in order to have a "RollBack" point to go to, in case of errors). By luck it, Restore option was not necessary at all!
Hope it helps
- SAP Managed Tags:
