cancel
Showing results for 
Search instead for 
Did you mean: 
Subscribe

Hi

We have refreshed our EC, BW & F&R Development systems (from a QA copy, which is a TDMS slice of Prod). We have been able to restore our source systems in BW for both EC and F&R.

We initially had some issues with the InfoProviders & transformations for our EC source system, but we overcame this by running a combination of RBDLS2LS, RSTRAN_BDLS & RSDG_TRFN_ACTIVATE - these now work.

However, we still cannot get the InfoProviders to work in our F&R source system. If we try and display or change them within RSA1 we get an error: Source does not exist (Message no. RSTRAN803). I.e. a blank source name.

When we run RSDG_TRFN_ACTIVATE we get many activation errors such as:

Object 'ZFR_W_AGG_ORD_FC_MAX_TRAN FRDCLNT001' (ZFR_W_AGG_ORD_FC_MAX_TRAN FRDCLNT001) of type 'DataSource' is not available in version 'A' (Message no. RSO252)

Source RSDS ZFR_W_AGG_ORD_FC_MAX_TRAN FRDCLNT001 not active (Message no. R7000)

Yet we can see in RSA1 that the FRDCLNT001 does appear to be active/no errors when running a check. If we do an Activate (and 'Replicate As Well') it all looks good, but again, when we look at the InfoProvider, we get the same issue.

We cannot activate them 'manually' via RSA1 as we get the error about the source system not existing when we try and make a change.

A 'Restore' in RSA1 yields the same results.

The Logical System in WE20 shows as active, in BW and F&R.

There are no 'rogue' entries in tables RSBASIDOC and RSTRANS between the systems.

All the RFC connections between BW and F&R are working and authorisations checks are successful.

All the steps from "886102 - System Landscape Copy for SAP NetWeaver BW" have been followed, we've ran all the reports:

RS_BW_POST_MIGRATION
RSDG_CUBE_ACTIVATE
RSDG_ODSO_ACTIVATE
RSDS_DATASOURCE_ACTIVATE_ALL
RSDG_TRFN_ACTIVATE
RSDG_MPRO_ACTIVATE

As well as FM:
BAPI_ISET_ACTIVATE

Any suggestions please?

Regards
Ross

0 Likes
View Entire Topic
Former Member
0 Likes

We have now noticed that table RSBKDTP does still have some incorrect entries in it (FRACLNT001 and FRDCLNT020) - the programs RSBKDTP_BDLS & RSBK_REPAIR_BDLS do not appear to be changing these...