on 02-08-2011 4:39 PM
Hi All,
After a system copy from production to dev all our transfer rules and infopackages are missing.
Whats is the best way to get these back??
I have read a few post on the forum but need some clarification on the exact approach.
Thanks.
Nick.
Hi Nick,
If your production ECC source system(ECC source system in prod BI) is not deleted in you BI dev environment yet..
then collect all system dependent objects under transport for system copy in transport connection.
Run BDLS conversion and establish RFC for development ECC source system and import the transport cretaed earlier
in dev BI system.
If production SAP source system is deleted in Dev BI system already then I do not see any way to get those missing objects back othern recopying production BI to dev BI. Then executing all the system copy tasks in sequence.
Thanks,
Kalyan.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Hey Nick,
I suggest you migrate your datasources to 7x and then you should be able to automatically get your lost InfoPackage and DTPs. As for lost transfer rules, you may either collect them from the original system or simply migrate your data flows to 7x as well.
Good luck!
Thanks.
Jonas
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
You need to collect all these objects before copying from production. Please check the below SDN doc. http://www.sdn.sap.com/irj/scn/go/portal/prtroot/docs/library/uuid/e05efe9f-0062-2e10-93ac-f34b87400...
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Hi Nick,
Ask your basis people to run BDLS in both BW and R/3 systems. Then, do a restoration of the source (R/3) system in BW. Now, you should be able to retrieve all the common structure. I mean if there is some extra meta objects in Development which were not moved into production, they are lost. Hope this helps.
Thanks and Regards
Subray Hegde
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Hi,
There is no need to delete the source system after system copy. Run BDLS to change BI prod to BI dev. Run BDLS to change ECC Prod to ECC Dev in BI dev system. Change the RFC and port connection in SM59 and WE20 and Just replicate all the datasource and activate the transfer rule using the program RS_TRANSTRU_ACTIVATE_ALL. This should solve your problem.
Regards,
Raghavendra.
Hi,
Recently i found myself in the exact same situation.
After a BW system refresh to QAS the transfer rules and InfoPackages were gone.
(gurus scroll down to the last 2 sentences as this might explain the situation if you followed note 886102 and still have the described issue)
I am a BC administrator and i followed the exact same procedure as your BC guys
'Delete the source system after copy and recreate.'
However, I was well able to resolve the missing rules and InfoPackages by doing the following steps without re-doing the entire refresh.
I know it looks like allot but relax and trust me, this is peanuts compared to rocket science
Note:
Please do make sure you have the correct interpretation of the following:
Source BW system = The source of your system copy (mostly the PROD system)
target BW system = The target system of the system copy (mostly QAS or TEST)
target BW client = The BW target client of the system copy
Source system = source system in RSA1 workbench
Before you start make sure you have some backup of your BC administrator as some things need to be done BC wise during this process.
Firstly download the following sapnote as it is the standard system copy procedure for BW systems:
886102 - System landscape copy for SAP NetWeaver BW.
for a QAS refresh (copy of PRD to QAS) follow scenario B3
(if you are in the situation that the refresh is done and you only need the source systems and their dependant objects restored after you deleted them, you don't need to redo all steps in scenario B3 only execute the ones that are documented below in the same sequence)
Sapnote 886102 - Scenario B3 - Step 6.4
In this step you are required to delete all source systems in your target BW system.
In the note it is documented to do this in RSA1 this will however create an overhead by requesting you to create transports and or you might not have sufficient authorizations.
Allright here comes the magic !
make sure 'SCC4' customizing is open in your target BW client and your source system client
Delete all source systems exept the 'myself system' (in your target system) by using function module (tx: SE37) 'rsar_logical_system_delete' -> F8
I_LOGSYS = SIDCLNTxxx *
I_FORCE_DELETE = X
I_NO_TRANSPORT = X
I_NO_AUTHORITY = X
here you fill the logical system name of the source system e.g.. PRDCLNT100
if you are prompted that some things are still active just confirm (can be multiple times) and continue.
If you are prompted to delete the connections and the logical system name choose NO (if you choose to delete them make sure you recreate the logical system in BD54 and recreate the needed RFC's in both source system and target BW system)
Repeat this procedure for every source system.
After this you reopen RSA1 in your target system and you will notice that the source systems are deleted.
To recreate the source systems, right click source systems in RSA1 and choose create
(make sure 'SCC4' customizing is open in your BW client and your source system client)
Fill in the required background and dialog user + pw and click ok
(if you receive errors while trying to recreate and chose not to delete the logical system name and connections please make sure your RFC destinations are correctly maintained in SM59 of both BW and source system if you did a database restore these will be pointing to the incorrect system and need to be recreated + the user and password needs to be reentered also make sure in tx. BD54 the logical system name of your source system is maintained.)
Follow
Sapnote 886102 - Scenario B3 - Step 6.8
While creating the source system you are prompted to create the DataSources that don't exist in BI yet.
This is actually a very important question because if you choose the incorrect version you will have activation errors later on.
(Theres a visual reference to wether the DataSources are 3.x or not in RSA1 of the source BW system -> 'source of system copy' -> Open RSA1 - doubleclick the source system - in the DataSources tree window click the 9th button from the left called (HIDE/SHOW empty folders) open the DataSources tree and look on the directly on the right side of the DataSources icon. A lightblue square about 1x1mm in size should be visible for 3.x source systems if you see the blue square create your DataSources as 3.x ISFS otherwise choose RSDS <- the functional BI people should be able to give correct instructions if unsure)
Now that the source systems are recreated and you need to transport the source system dependant objects (tranfer rules, InfoPackages , ....) from the source BW system -> 'source of system copy' <- (make sure SCC4 customizing is open for this action)
Follow Sapnote 886102 - Scenario B3 - Step 2.1
Goto transport connection -> choose your source system where you want to transport the objects form (SHIFT +F7)
in the Right window click the Grouping button and choose -> save for system copy
Click the Collection Mode button -> choose manual collection
In the Middle window in the 'All Objects according to Type' tree open the tree source systems and double click 'Select Objects'
in the next 'Input help for metadata' dialog choose your source system and click 'transfer selections'.
In the right window you will see your source system is added to the collected objects. Click it and click the 'Gather Dependant Objects' button left of the grouping button.
Make sure you tick all checkboxes available!
repeat for all source systems (take care if you have allot of sources id recommend creating a transport for each one)
once done click the transport button (red yellow truck) right of the 'Grouping' button (remember SCC4 custo = open!!)
you will be prompted to create a transport -> create a new transport and note the transport number.
goto SE01 and release this transport
next this transport needs to be included in a transport of copies
got SE01 and create a new transport of copies -> target of this transport is your new BW system + client (if you cannot select a client this will be asked when importing in the target)
choose include objects from other transport requests and include the transport you created via RSA1 in your source BW system
release this transport of copies.
Close the custo of your source BW system 'source of system copy'
Goto RSA1 of your target BW system in the Workbench choose 'Tools -> Conversion of Logical System Names CTRL+F12'
make sure there is line that includes your original source system name and the target source system name
SRCCLNTxxx - NEWCLNTxxx (e.g. PRDCLNT100 - QASCLNT100)
this is needed to convert the logical system names during the import of the transport you just created in your source BW system
In your target BW system goto STMS and open the que (the transport of copies should be available in the que)
import this transport in the new BW client (this will take a while because the source systems are converted during the import)
once imported verify the return code if all went well and go back to RSA1
The source systems will have the InfoPackages, transfer rules and other that were missing before.
Remember to maintain 'SCC4' customizing again of both BW system and source system.
I hope this was helpfull to others too, and keep-up posting solutions if you found out how to resolve an issue that is still unanswered in the forums.
In my case the problem was that I recreated the DataSources as RSDS while they were actually 3.x ISFS
(the systems got upgraded trough time but all transfer rules and InfoPackages were still maintained as 3.x ISFS)
Kr,
Gerard G.
OMG !
I put like 3.5 hours of time in writing this response just to notice the entire markup messed up.
people having the issue described will not bother trying to decypher the solution when everything is jammed together like this.
please PM me if you are interested in the solution in a READABLE format.
Kr,
Gerard G.
Hi,
Recently we ran into a similar problem wherein our BI system became unusable after system copy as transfer rules and infopackages were missing. and to resolve this we had to perform a new system copy.
So now to improve our system copy procedure.
I would highly appreciate if someone can guide as to what precautionary steps we can take in fuure to avoid such problems.
Few things we have learnt:
- Never Delete a source system after system copy
- Saving source system dependent objects in a transport(Note 1406273 - Consulting: BDLS in BW)
Geerat:
I would highly appreciate if you can post a readable version of your solution for such a problem.
Thanks,
M D
Hi,
I have a problem and i hope you may help me.
We are upgrading BW from 3.1 to 7.0. We have done a system copy from old BW to a new one. Changing both BW and R/3 system name.
I've created a change request to save the objects before running BDLS. Unfortunatelly, our basis has created R/3 source system with a different name in R/3 and in BW. So we had to deleted it and we lost the infopackages and transfer rules.
Now i'm trying to recover the objects importing the request but it's not working.
I've created an entry in Tools => Conversion of Logical System Name . There is anything else to configure? The request import must be by stms transaction?
I notice that Object directory entries is missing. Does this affect anything? Have we miss some step?
Could anyone help me, please?
Thanks.
Edna.
Hi Geert,
Can you send me the readable version of your instructions above? We are experiencing the same issue where the transfer rules and infopackages were gone after the refresh. Please send it to charissma10@yahoo.com. Thank you so much!
Regards,
Cha
Hi Geert,
Besides the text formatting I could follow the procedure without problems. The problem I had is that I couldn't get the Infopackages/Rules from the source PRD system so I attempted to do so from a a differente copy of PRD we had were the datasource were inactive. This caused a lot of trouble when exporting / importing and rendered the target system inconsistent.
I had to re-did the system refresh and all is good now.
Anyways really appreciate your effort and help.
Many thanks,
Antonio Huete
User | Count |
---|---|
81 | |
24 | |
11 | |
9 | |
7 | |
5 | |
5 | |
5 | |
4 | |
4 |
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.