NWDI track migration

[former_member594561]

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

[former_member189220 · Accepted solution]

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?"

A:

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?"

A:

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?"

A:

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'?"

A:

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.

Regards,

[former_member594561 · Accepted solution]

Hello Milen. Thanks again very much. I learn better already with your replies but I need to keep going now to pick your brains and clear some points. I will comment when needed to your previous comments:

Your 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!

This is not an issue. Once again, we don't have name server conflicts. Both networks are seperate. There are no name server conflict errors. Both networks are different ( assume different entities, which they are ) and you cant reach from one to the other.

Your comment: 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.

Can you please clarify your statement above? I am really not sure what you mean by it ( please note each NWDI systems are one server only systems, so all the NWDI services in NWDI1 resides in the same server, they both have their DB servers on different servers. that is NWDI1 have 1 AS, 1DB server, NWDI2 has 1 AS, 1 DB server, all services run on its single AS)

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.

ok. let me be clear. We deployed NWDI1 and NWDI2 from fresh NW java installations with DI usage type ( no migration of any kind, 2 fresh installations ) . We received tracks SCA files from NWDI0. We created tracks on both systems and imported those track data into the tracks under NWDI1 and NWDI2 separately. Now, we have created tracks from the same set of SCA files and imported them for both systems. At that time, we had the same name of the tracks, same data, same SCA files imported successfully on both systems

its also important to know that both systems have their separate runtime environments ( hence I stated separate networks/entities ).

your comment 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.

Milen, by this time I am sure you understand what i am trying to accomplish here. NWDI1 has custom software changes. NWD2 had the same custom software but not changes. NWDI2 tracks are all good ( initial files from few month earlier checked in, imported ) , now I want to bring the changed custom Software in NWDI1 tracks into NWDI2 tracks. NWDI2 tracks already have the initial custom SCs in the transport inbox ( once again already imported with previous inital SCA files from NWDI0). Now in NWD2, lets say I have test.SCA file, I am renaming it, copying the essabled test.SCA file from NWDI0 and import fails. when I unzip test.sca file sI see all 4 folders including sourcearchives, buildarchive, depoyarchive, meta-inf.

Are you suggesting that I should extract assembled SCA files from NWDI1 and only copy over some files within that into NWDI2?

I really place whole assambled SAC file into NWDI inbox after renaming the original related SCA files

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

can you please clear above sentence? both NWDI1 and NWDI2 are single NWDI systems on their respective entities ( networks ). There are no other NWDI systems within each networks, so NWDI1 is development NWDI system in its landscape while NWDI2 is also development NWDI system in its landscape. based on my understanding, we dont need any other NWDI systems ( quality NWDI or production NWDI systems on each landscape ) since we will transport custom codes via CTS+ into the quality and prodection runtime envirionments of both respected landscapes

Thanks gain Milen

[former_member189220 · Accepted solution]

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.

Regards,

[former_member189220]

Hello Sebastian,

1.

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.

2.

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.

3.

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.

Regards,

[former_member594561]

Hello Milen

Thank you. I will go through your answers once again and try to see if I can resolve this, but more info and question I have

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

NWDI1's SLD is PI1

NWDI2's SLD is PI2. Obviously both NWDI systems have different domain configuration in landscape configurator, as different SAP SIDs

We created exact same SC names and dependencies in both PI1 and PI2 ( only SLD purpose here )

We deployed both NWDI systems from scratch ( no migration ). There is a source NWDI system ( say NWDI0) managed by another entity who provided us all the sap.com software SCAs and custom software SCAs to be used for each tracks

we created each exact track and its configuration both in NWDI1 and NWDI2, the same as NWDI0 ( NWDI0 is also on another network, another company )

from their initially provided SCA files, we were able to create tracks, import them all, create buildspaces fine in NWDI1 and NWDI2. Now at that time, we had exactly the same tracks, the same SCs, buildspaces on both NWDI systems using the same provided source SCs

NWDI1 systems tracks has been changed since then, but no work has been done in NWDI2 tracks. My objective is to make NWDI2 tracks up to date with NWDI1 software tracks

so we are dealing with 2 different NWDI systems, the same track configurations.

1. 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?

2. If not, what's the best way to bring test_1 SC in track1 upto date in NWDI2?

3. We imported required SCs and custom SCs in each tracks for both NWDI1 and NWDI2, so NWDI2 already have tracks available for developers ( buildspaces created, DTR working etc ) so besides the great info your provided in your answer #3, we really did import fine in both NWDI systems

4. Both NWDI1 and NWDI2 should have different CBS, DTR, CMS and SLD, right? I am not sure you you mean by saying they should have different URLs

5. Please also know that we manually created each SCs and their dependencies ( they are all match in both SLDs) in both SLDs, PI1 and PI2 separately. No export/import, the SC names and dependencies match

Hope I am much clearer now, but I will read your post again

also, one of the tracks is configured 'development only'. we obeyed that due to the fact that NWDI0 ( source) had the same. As the case with this track, there is no consolidation tab in CMS, hence no ****_C buildspace

6. Is this an issue? when developers use NWDS to connect to this track , there is no ** _C for this track. for every other track, there are both **_D and _C buildspaces they can connect to. 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'?

Thanks again. appreciate a lot

[former_member594561]

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

cheers

[former_member594561]

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

[former_member594561]

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 sap.com ( 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 sap.com 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

[former_member189220]

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: com.sap.tc.cbs.api.CommunicationException: 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 com.sap.tc.cbs

* 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:

abc.domain123.com:50000

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

xyz.domain098.com:50000

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.

NWDI1:

abc-sld.domain12.com:50000/sld

abc-dtr.domain34.com:50000/dtr/ws/...

abc-cbs.domain56.com:50000

abc-cms.domain78.com:50000

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.

Regards,