Skip to Content

How to move transports between development systems

Scenario: Assume I am upgrading my ERP system to SPS21. I have two development systems DA1 & DA2. DA1 is in the production support path DA1->QA1-->PA1. DA2 is in the SAP upgrade path DA2-->QA2. To prepare for the upgrade I used system refresh techniques to copy DA1 to DA2 and QA1 to QA2. Then I applied SPS21 to both DA1 and DA2.

Once transports are applied to PA1 they need to be "replicated" in the upgraded systems so they can be tested again. What is the best method for getting the DA1 transports into DA2?

I was thinking of using the following technique

1) Use STMS to manually add the DA1 transport to DA2 - AFTER it is applied to the production system (PA2)

2) I will select the option to overwite originals when importing the DA1 transport to DA2

3) I will create a DA2 transport and merge the objects from the DA1 transport into this new transport

4) I will test the changes in DA2 and if it looks good I'll release the DA2 transport into QA2 for integration testing

Does this make sense? Is there a recommended way for performing this type of transport?

Add comment
10|10000 characters needed characters exceeded

  • Get RSS Feed

4 Answers

  • Best Answer
    Nov 03, 2015 at 05:17 AM


    I use a mixture of:

    1) SCWB (yes, one can get it to run without Solman, via setting up required RFC destinations in Client 000),

    2) adding transports manually to import queue of DA2 and

    3) manual download and upload

    to keep dual track landscape synchronized.

    The difficulties with SCWB are: it relies on version management, so it can't process things like Smartforms. It also doesn't support transfer of certain deletions (classes, interfaces)... so no code cleanups on maintenance track for me anymore. If you are using copy transports to deliver changes to QA1, every copy transport (every DA1 version in the right sequence) will need to be synchronized. Also, when I opened incident about the missing support for class/interface deletions, SAP told me to just stop using SCWB the way I'm using it 😊. Other than that, it's an amazing tool (the underlying functionality is that of SNOTE, I believe), which saves me lots of time in dual track landscape.

    The difficulties with adding/importing transports from maintenance track: you can easily overwrite changes already made in the DA2... You have to keep changing source system of the objects after import. You can forget to merge the objects into into new release on DA2...



    Add comment
    10|10000 characters needed characters exceeded

    • Hi,

      If I remember correctly... assuming you have development systems DS1 and DS2, you'd need to:

      - in System DS1, set up RFC destination CWBADM_DS2_000 enabling login to client 000 of DS2 (and communication user in client 000 od DS2, if necessary), something like this:

      - in System DS2, set up RFC destination CWBADM_DS1_000 enabling login to client 000 of DS1 (and communication user in client 000 of DS1, if necessary).

      That's all... if I remember correctly.

      Upon starting SCWB, you'll still receive this message (about missing Central Solman System, I assume):

      Ignore it, and this screen should be displayed:

      choose [SAP Note/Request],

      choose Source Request and enter DA2 request if retrofiting into DA1 and vice versa.

      If something doesn't work, try setting breakpoint in FM SCWB_APPLY_REFERENCE_CORR and see what goes wrong where...

      I can not stress enough, that:

      1) this isn't something supported by SAP and SAP advised to STOP using SCWB this way...

      2) not every "development object" or change/deletion can be transferred this way - particularly deletion of Classes or Interfaces, if I remember correctly;

      3) you MUST retrofit the transports (development object versions) in the right sequence.



      scwb.png (40.2 kB)
      scwb1.png (7.2 kB)
      scwb2.png (13.7 kB)
      scwb3.png (13.1 kB)
  • Mar 14, 2016 at 06:04 PM

    You still have not figured this out since last November? 😊

    We actually opt out for re-doing the changes manually (copy-pasting and new transport). This also helps with double-checking that they don't "collide" with any additional changes in the source system. But we keep any changes during upgrade to minimum, as a rule.

    Add comment
    10|10000 characters needed characters exceeded

  • Nov 02, 2015 at 04:50 PM

    Can you move this question to the SAP BASIS space

    Add comment
    10|10000 characters needed characters exceeded

  • Nov 05, 2015 at 05:41 PM

    It sounds as if the SCWB process does not work properly. The process does not need to be automated. If have no problem performing the manual process I laid out. IAre there other ideas for getting changes from one development server into another?

    Add comment
    10|10000 characters needed characters exceeded

    • Well, state of the art for Transport management would be to use Solution Manager system and "proper" retrofit. I have no experience with it, but that process would take care of customizing transports as well, if I understand the documentation correctly.

      The main reason I went for SCWB was to minimze risk that some DA2 changes would be lost during import of DA1 transports... The transaction in my experience works pretty well, once you know the drill and limitations. It's synchronizing the customizing changes where I have to devise "clever strategy" and proper way each time DA1 changes need to go to DA2. Lots of SCMP, SCU0 and SADJ...