Skip to Content

NWDI track migration

Hello Kirill

I find your posts in NWDI very helpful. Thank you

We have a uniques situation here. We have 2 NWDI system with their own SLDs in tow different networks ( NW 7.4 ), both the same version NWDI, same Software components and both deployed at the same time from a previous NWDI system sometime last year, basically both will have the same custom software and tracks

This should be really working easy but I have issues

the first NWDI system tracks were developed since the initial deployment ( we deployed fresh NWDI systems for both businesses and imported tracks from previous NWDI, same level ). The second NWDI systems tracks haven't been modified since the initial import. Now we want to bring second NWDI system the same with the first one as for all the changed software

we have multiple tracks in each, even the track names are the same except 1 or 2 tracks

I use assembly to export the custom app in NWDI ( lets say NWDI1 and NWDI2 ) or just use the file in 'archive' folder for assembled folder in NWDI1 and copy over to the inbox folder in NWDI2 folder, but the import into buildspaces fails in NWDI2.

I dont think developers are doing anything at this time on NWDI1

my question:

1. Is this the right approach in my case

2. since SC in tracks in NWDI1 is different now than NWDI2 ( which was equal initially ) , do I have to re import all sap dependant components and all others again into the workspaces before I import custom components?

3. in the past, I had issues with one track, and I literally created a new track, reimport all again to get things working. This is a long process. Do I have to do this just to apply the changes from NWDI1?

The error log below. not much other useful logs

 CBS Server Error: CBS failed to communicate with some other server( internal code: COMMUNICATION_ERROR)

Thank you

Add comment
10|10000 characters needed characters exceeded

  • Follow
  • Get RSS Feed

4 Answers

  • Best Answer
    Oct 29, 2018 at 04:11 PM

    Hello again,

    I will try to reply to your questions:

    "Both NWDI1 and NWDI2 are different sister companies, so name server conflict is not an issue. Both point their internal PI system as their SLDs"

    Comment: This should be confirmed on a network level. If the SLD could communicate between each other, it must be ensured only 1 of them is with Name Server Role. Please consider that the Name Server in the light of NWDI, has nothing to do with the DNS!

    Q:"why cant I just pull the assembled SC from NWDI1 ( say test_1 custom SC in track1 ) and place it in NWDI2's inbox after backing up the initial test_1 SC in track 1 and import it?"


    You can extract the SCA after it is successfully assembled. You have to ensure you have selected "Include Sources" option. Then you might store it in the Transport Directory of the track on the NWDI2. When this custom SCAs is added to the track, imported in Transport Studio, it will be possible to be work with it in the NWDS. This is true so far the track, on the NWDI2, is not: Development or Production ones.

    Q:"what's the best way to bring test_1 SC in track1 upto date in NWDI2?"


    Please refer to this SAP KBA 2616454 - How to Transport SCAs/DCs between 2 Tracks

    There are explained the available ways of "transporting SCAs" between two tracks. In case the NWDI (CMSs) can not connect to each other. Then only the 1st option is possible.

    Q:"Both NWDI1 and NWDI2 should have different CBS, DTR, CMS and SLD, right?"


    I mean different <nwdi1-host name>.<nwdi1-FQDN> MUST be different from <nwdi1-host name>.<nwdi1-FQDN> . I you can replace NWDI with DTR, CBS, CMS and SLD. As far as I understood you do administrate 2 separate different NWDI servers and NWDI2 server is a system copy of the NWDI1. This statement "both deployed at the same time from a previous NWDI system sometime last year" suggests a single source of data for the track details like DTR,CBS, CMS and SLD urls in the development configurations.

    Q: "one of the tracks is configured 'development only'" "What is exact use of consolidation if I can use 'development only' option, and transport software via CTS+ through the landscape? or why would I chose 'development only'?"


    Development Only tracks do not contain CONSOLIDATION. This is by design and by default feature. The idea of these tracks is to get the developed software out of it directly, without needing to transport it to a CONS system. Hence, such tracks should be considered as a different type. Moving data from "normal" track to such "DEV only" track is NOT recommended. More details about the usage of DEV only tracks here: Creating a Single System Track (development only)

    For completeness (& hopefully for sparing some other addition question :) )I would like to draw your attention to the so called "Production Tracks". Such tracks are defined WITHOUT any CBS and DTR. These tracks only contain a runtime system with an import and an approval queue. Production Tracks are especially useful when the same SCA should be deployed simultaneously to many RTS...

    Automated Deployment into Multiple Production Systems

    In summary, the most important part of any track is the custom source code! When it is lost, it can only be created from scratch. Hence, it is a good idea to either have a good backup of the database where the DTR server(s) reside, or to store assembled SCAs as a backup on some storage location. All other settings could be re-configured accordingly, but the source code - no way. In case you have a particular error please post more details to troubleshoot it.


    Add comment
    10|10000 characters needed characters exceeded

    • Hello,

      If this is true

      "now in NWD2, lets say I have test.SCA file, I am renaming it, copying the assabled test.SCA file from NWDI0 and import fails."

      then please attach the logs from the failed import. You can download them from the CMS - Transport Studio.


  • Oct 26, 2018 at 07:18 AM

    Hello Sebastian,


    When such a "replication", of NWDI servers, is taking place, it must be ensured the CBS, DTR, CMS and SLD in the tracks are relevant. I think the above mentioned error is due to the URLs of these servers is not correct. What also reinforces my hypothesis is the fact the newly created track has been working. In case the URLs are correct one, then the DTR Development Configuration data, on the replicated SLD points out to the older (source replication) NWDI server. Of course when a new track is created and correctly configured CBS,DTR,SLD,CMS URLs are set in the track, then this newly created data will be recorded on the SLD - DTR Development configuration. This DTR development configuration data is retrieved from the NWDS, when the track is imported.


    Next thing to consider is the Name Server role. There must be only 1 SLD server with Name Server role in the entire system landscape. If the SLD servers are visible to each other then you need to ensure which one of them will be the Name Server and to maintain the DC names, vendor prefixes and etc. on the SLD server which has Name Server Role.


    About your particular questions:

    Q. "Is this the right approach in my case"

    A. So far the server URLs, Name Server role and the DTR development configuration are correct - the track should work (although there contain similar data)

    Q. "since SC in tracks in NWDI1 is different now than NWDI2 ( which was equal initially ) , do I have to re import all sap dependant components and all others again into the workspaces before I import custom components?"

    A. In the DTR workspaces is imported source code. This could be custom SCAs and/or some SAP ones (f.e. ESS, MSS, MII and others).

    The required SAP SCAs must be imported in the CMS - Transport Studio. With this import, these SAP build-time dependent SCAs will be imported in the CBS. If all of the required SAP build-time SCAs are NOT imported in the CBS, the build process will not be successful. The required build-time SCAs depend on the custom SCAs (whether the custom SCA is related to EP, XI, BPM, WebDynpro or other type of functionality). These build libraries will be used in the initial build process.

    Later, when the track is imported to the NWDS, the build-libraries will be copied to the local build-space on the desktop where the NWDS is installed. Then the developers could connect the public parts of the custom DCs to connect with the public parts of the SAP required DCs, when it is necessary to be used the feature provided by the required SAP SCA.

    Q. "in the past, I had issues with one track, and I literally created a new track, reimport all again to get things working. This is a long process. Do I have to do this just to apply the changes from NWDI1?"

    A. I have explained this in points 1 & 2 .

    In case you have any further questions, please let me know.


    Add comment
    10|10000 characters needed characters exceeded

    • Hello Milen

      Thank you very much. I was able to resolve the issue. Simply restarting AS fixed the issue , indeed. Not sure why it was throwing that error message. I was thinking to stop/start but we actually only very recently had a downtime on this server.

      Nothing really lost as I believe your replies were very informative and some of the knowledge you presented during the exchange were helpful in my earlier doubts


  • Oct 30, 2018 at 06:08 PM

    Hello Milen

    Thanks again. The error was in my previous reply. I am attaching the whole log for the track import here. just a quick info about this track:

    It has two SCs in Landscape configurator. BD_COMPONENT and FSCM_BD ( both source and archive option), both SCs have custom defined dependants though FSCM_BD is actually ( i really have no clue why they did this ). I guess they modified this component in SLD but I was basically asked to do the same thing they did in source NWD0 tracks. both of these SCs and selected as 'developed' but FSCM_BD is also selected option 'exclude from deployment', also this component is included in BD_COMPONENT as its dependant.

    the other tracks import fails as well though it has no above stated mix up with and custom SCs

    Thanks always. Please know that all the info you provided previously helped answer some of the questions I had while working on the system and not able to find answers. If you can clear few of the doubts i presented in my previous reply, that would be appreciated

    Here is the logbdagco-d.txt

    bdagco-d.txt (19.6 kB)
    Add comment
    10|10000 characters needed characters exceeded

    • Hello Sebastian,

      I am glad to understand you have managed to resolve the problem. Indeed, it is strange why the CBS service was not responding. Honestly, I expected to see something different in the log than...

      CBS server trace: Unexpected response status [401 Unauthorized]

      In case the CBS service does not respond again, it would be good to have troubleshooting traces:

      * one for location

      * and one with General Security template.

      It would be good to have some thread dumps to see whether the CBS service is locked by some other process. (otherwise why the restart would have resolve this event?!)

      It is not very much likely the buildspace to have been in privileged mode

      CBS queue of buildspace D0D_BDAGCO_D is completely processed. Starting the import now.

      Neither do I think your user, has not been granted with the necessary authorization rights.

      In any case, "the resolution with the restart" has confirmed the configuration settings are correct and the error might be caused rather to a performance issues. (I hope there are no PI,XI,PO SCAs running on the server where the NWDI is).

      About my previous comments -

      "This is true so far the track, on the NWDI2, is not: Development or Production ones."

      I have been referencing to "development only" or "production" tracks. I do not mean development or production NWDI. One NWDI is enough to maintain the software logistics for all available versions of AS Java (despite of their role).

      "I really place whole assambled SAC file into NWDI inbox"

      Yes, this is the way it should be. No extraction of SCAs is required. Only export download and storage in the corresponding transport folder for the NWDI2.

      "I mean different <nwdi1-host name>.<nwdi1-FQDN> MUST be different from <nwdi1-host name>.<nwdi1-FQDN> . I you can replace NWDI with DTR, CBS, CMS and SLD."

      I will post an example:

      In case of centralized NWDI (all CMS,CBS,DTR are on the same server box)

      NWDI1 - all SLD, CMS, CBS and DTR could be accessed through:

      NWDI2 - all SLD, CMS, CBS and DTR could be accessed through

      In case of decentralized NWDI, the host and FQDN for the SLD, CMS, DTR & CBS should be different because then there will be 4 AS Java servers - each component of the NWDI is installed on a separate server box.


      As you could see, I point out that not only the host but also the network FQDN could be different for the CMS/DTR/CBS/SLD. Yet, my main point was about the accuracy of the URLs configured in the tracks.

      This was what I meant, but with your answer I think this matter was clarified. (so far no communication is possible between xyz and abc everything should be fine with regards to the usage of NWDI's Name Server - there will be no name conflicts when new DCs are created or new tracks are imported in the NWDS)

      I know a lot of information have been posted in this thread. Yet, if I need to elaborate or clarify anything, let me know.


  • Nov 05, 2018 at 09:43 PM

    Hello Milen

    Great. Understand the points better now especially after reading the links you sent earlier as well. Now I know what 'production' track is. I still have lingering questions in my head though ( sorry but I wasn't really an NWDI consultant, but took the opportunity to deploy and support it when asked so I am learning )

    as you know by now, our NWDI system (s) are simple, everything but SLD runs in the same Java NW AS

    all tracks with the exception of 1 are NOT 'development only' tracks

    as you said, when you have that option selected, you have only development buildspace and you can't define cons, test and production RTS

    my understanding is that once I 'assemble' an initial custom SCs in a track, then the developers are ready to work on that track ( via NWDS, they are able to create projects, add DCs etc )

    I also have in the tracks, disable auto deploy option not checked in the development RTS when I define RTS. That means Software being deployed automatically on the development RTS

    my Question. When does that really deploy in development RTS? when I click a custom SC to assemble in the assembly tab, does NWDI deploy that specific custom SC in the development RTS while also creating it in the OS level for the deployment of the cons, test or production RTS? ( in our case we use CTS+, so it creates a Transport order )

    also, when developers create projects in a track via NWDS, I basically don't do assembly again, they tell me to import a transport order they create into test system ( in our case we really don't have any consolidation RTS either, but consolidation exist with all but 1 track ), how is that really work at that point once developers take over the track after assembly?

    I think I still really need to be 100% clear on the consolidation RTS and consolidation buildspace while I can define a test RTS and production RTS without their buildspaces ( now understand the production only track use though ) in it. basically test and production RTS only needed if I want to use 'track connection' option to carry over software from one track to another? not for the deployment of SC to the RTS? ( as we are using it CTS+ ). Hope my question is clear. basically at this point, i really don't even need to specify test and production RTSs , indeed even consolidation RTS do not exist in any of our tracks.

    Thank you very much

    Add comment
    10|10000 characters needed characters exceeded