1406273 - Consulting: BDLS in BW

Symptom

Customers regularly update their QA system from their PRD systems and SAP encourages this practice as it provides a realistic testing environment for customer developments and functional system test.

Post the copy, a Logical System(LOGSYS) name change as stored in tables T000 and TBDLS and defined in transaction BD54 is required. In BI this also affects all Source System dependent objects as these are defined using the Logical System name of the Source System. This change is carried out with transaction BDLS whose function is detailed in note 121163.

In so doing it is recommended to take a few simple precautions that would avoid problems in the renaming of source system dependent objects and the associated logical system name. Common symptoms of such problems are that RSA1 cannot be accessed; Source Systems cannot be activated without error in RSA1; Source System Dependent Objects are not visible under the Source System tree in RSA1; the system may suggest a source system deletion due to already exising prefixes etc.

Other Terms

BDLS, SYSTEM COPY, LOGSYS

Reason and Prerequisites

Common issues in BDLS post system copies:

1) Illegal Datamarts
It is a regular occurrence that Datamart Source Systems are created between BI Systems within the same system landscape eg. BI-PRD->BI-QA.
If you then refresh a QA system from a PRD system containing such sources BDLS will not be able to convert the LOGSYS names correctly as this this would result in duplicate entries in various tables but most importantly in RSBASIDOC in the BI-QA System as detailed below.

Example:
RSBASIDOC in PRD (equivalent to RSBASIDOC in QA post a system copy)

SLOGSYS     RLOGSYS      OBJSTAT  TSPREFIX SRCTYPE

BIQQAS100   BIPPRD100    ACT      PA      D        (Datamart)
BIPPRD100   BIPPRD100    ACT      OA      M        (Myself System)

Detailed above is a Datamart in the PRD system from the BI QA system to itself. This system is then copied to QA and the same table must now be converted in BDLS to reflect the QA LOGSYS.

RSBASIDOC in QA post the BDLS run (Converting BIPPRD100 to BIQQAS100)

BIQQAS100   BIQQAS100    ACT      PA      D        (Datamart)
BIQQAS100   BIPPRD100    ACT      OA      M        (Myself)<<<< Fails

Such sources will always cause BDLS to fail the Myself system conversion because of the fact that it would create a duplicate entry in the RSBASIDOC table as the example above demonstrates.


2) Duplicate Prefixes
On creation of a source system in RSA1 a TSPREFIX as indicated above is created.
This prefix will stay with that source system for so long as it exists.
It is possible, through the addition of multiple copies of the same production system as source systems, to create duplicate prefixes in RSBASIDOC in the BI target system.
Care should be taken to ensure that this does not happen.

However should this already be the case - the system may prompt you to delete that source system. When deleting source sytems in BI all source system dependent objects are also deleted - this is something that could be detrimental to your test system.
The only way to reassign a source system prefix is to delete and recreate it. In order to avoid losing the source system dependent objects you are therefore obliged to save them in a transport and re-import them after the source system has been recreated.

3) Finally in all cases it is a good precaution to eliminate known errors in BDLS by implementing all BDLS notes under the BW component applicable to your SP. This is especially important in lower SP levels. At the very least all notes detailed in 886102 need to be implemented.

Solution

1) Remove the illegal Datamart as a Source System in PRD prior to the copy (SAP Recommended). SAP does not support such Datamarts!

Alternatively it can be deleted in the refreshed system prior to the BDLS run.
Or if you absolutely must retain it then the Datamart source LOGSYS name has to be changed with BDLS (for example to some DUMMY Logical System name) prior to the actual PRD -> QA LOGSYS conversion.
In this way the Datamart conversion should not interfere with that of the Myself source or any other source systems existing in BW at the time.

Equally and for the same reasons we do not recommend or support ERP QA systems connected as a Source to a BI PRD system.

Additional Information:
When running BDLS, generally four scenarios can happen:

a) no records for either the old or the new name -> table skipped

b) records with the old name exist -> conversion goes through

c) records with the new name exist -> table skipped with warning => no manual intervention needed, but doublecheck is recommended. In this case the conversion log shows '<<' at the affected tables

d) records with the old and the new name coexist -> records are skipped with warning or error (depending on the flag for existence check, which is always set except in test conversions) -> you have to analyze the records and to manually delete that records which hold the old logical name and have their identical counterparts holding the new name. In this case the conversion log shows '<<<<' at the affected tables.

You must decide and check each of these entries in turn. Duplicate entries preventing conversion should be deleted.


2) Saving source system dependent objects in a transport can be carried out as follows:

RSA1 -> Transport Connection;
Set 'Collection mode' to 'Start manual collection';
Select 'Source system assignment' button (left of the 'Conversion' button);
Select the Source Systems for which to save the Source System Dependent Objects;
Set 'Grouping' to 'Save for System Copy';
In the leftmost column click on 'Object Types';
Expand tree 'Source System' LSYS;
Double click on 'Select objects';
Select the Source Systems you want to collect objects for (the source system is now displayed in the rightmost column);
Select the Collection button 'Gather Dependent Objects',
(this may take some time);
Right click on the root of the tree and select 'Transport all below';
Expand the whole tree and check for objects locked by an other open transport request (the column 'Transport request' must be empty!);
Select the transport button.

A transport request is created. Check if the request contains all relevant objects.
Release the request, before deleting the corresponding Source System.
Adjust RSLOGSYSMAP as appropriate prior to import into the Target System.