Replication of tracks from one NWDI to another

[Soumya]

Hi All,

I am new to NWDI. Currently we have to move some tracks from old NWDI [for 7.0 portal] to a new one [for 7.3]. It was agreed upon to follow the procedure as per the link "http://help.sap.com/saphelp_nw73/helpdata/en/49/101b273d9d132ee10000000a421937/frameset.htm" as all data and history has to be maintained. As per method desribed here ".. >> Choose the Change Management Service link. >> Choose the Landscape Configurator link and change the DTR URL in the track configuration of TRACK1 from SRCDTR to TGTDTR. >>To create a copy of TRACK1, choose Save As. Name the track TRK1CPY .." This "Save As" operation is throwing error as it cannot access the target DTR. Since we are performing the steps in old NWDI CMS, it should be able to access the new NWDI DTR [with separate CMS, SLD, CBS, DTR]. But cannot figure how to do it. Do we have to maintain same CMS Admin user id and paasowrd in the new NWDI as the old one??

Please help.

... -.-.

[ErvinSzolke · Accepted solution]

Hi,

the "Save as..." trick is only used to create the DTR workspaces in the target DTR.

What you can do is to go to the target CMS webui, and simply create a track (this action will also create the CBS buildspaces and all the 4 DTR workspaces). Once it is done, you can skip in the guide the tricking with the "Save as " feature and with the renaming of the track, etc, and you can proceed with the replication right away.

I believe this is a much simpler and less error prone solution then the one described in that guide.

(alternatively you can also use the DTR console to create all the 4 DTR workspaces (dev active/inactive and cons active/inactive), but that requires some experience with the DTR console. On the top of that track creation in CMS does this for you anyway.)

I hope this helps.

Best Regards,

Ervin

[Soumya · Accepted solution]

Thanks Ervin,

I will surely let you know when we try your method, but currently we are thinking in a different line. If we can possibly make the new DTR connected with old CMS or SLD or the new CMS / SLD connected to the old DTR. Haven't made any mentionable progress though...

Thanks

... -.-.

[ErvinSzolke · Accepted solution]

Hi,

well, if you simply go to the old CMS webui, to the TRACK Data tab (Landscape Configurator), select the track in question and then rewrite the DTR URL to the new DTR URL, then it should work. The same user with the password has to exist on the server where the new DTR is located of course, and it should not mismatch from release and support package version point of view I assume.

Even if you use only DTR on the new server, the other NWDI related SCs like (DI_CMS, DI_CBS musn't be uninstalled in any way).

I hope this answers your question.

Best Regards,

Ervin

[former_member787462 · Accepted solution]

Hi Ervin and Sowmya,

We are also planning to migrate only DTR data from 7.0 to 7.3 of NWDI. We have the same Track ID in both the system ( DTR workspace) .

Now , we have to use the "replicate" command for replicating DTR data from 7.0 to 7.3. At this point of could you please help me , where to execute and how?

I have the script but, not sure how to proceed further. Please guide me the steps. Thanks. Example script.

connect targethost:targetport user password targetID

connect sourcehost:sourceport user password sourceID

replicate -r -d c:\temp\replicate /ws/TRACK1/SC1/dev/inactive targetID /ws/TRACK1/SC1/dev/inactive

replicate -r -d c:\temp\replicate /ws/TRACK1/SC1/dev/active targetID /ws/TRACK1/SC1/dev/active

replicate -r -d c:\temp\replicate /ws/TRACK1/SC1/cons/inactive targetID /ws/TRACK1/SC1/cons/inactive

replicate -r -d c:\temp\replicate /ws/TRACK1/SC1/cons/active targetID /ws/TRACK1/SC1/cons/active

best regards,

Manoj K

[Soumya · Accepted solution]

You have to run the script from DTR Console. The path is mentioned in the article: http://help.sap.com/saphelp_nw73/helpdata/en/49/101b273d9d132ee10000000a421937/frameset.htm

I suppose you can run the DTR Console by other means too. I also think you can even copy-paste the entire Windows OS DTR folder from the server to local Windows desktop and run the "run.bat".

Thanks

Soumya

[ErvinSzolke · Accepted solution]

Hi,

yes, you have to run the run.bat of the replication script.I recommend to use the tool from this note:

#1377679 DTR Console "replicate command" don't work

No need to deploy, just extract it and you can use it right away.

Yes, you can copy-paste this dtr console folder anywhere you wish, but it is recommended to run the script on a windows system as also pointed out by Soumya. (hint: if you replace the ";" in the script by a ":" then you can also run it on unix based systems.)

Best Regards,

Ervin

[former_member787462 · Accepted solution]

Dear Sowmya and Ervin,

Thanks alot for quick response.

Let me explain what I have done so far.

->1) I have 7.0 DTR track created with the name : DEVTrack1 and the workspace location as follows "/ws/DEVTrack1/DEV_Test_SC/dev/inactive". ( This is a different server)

->2) I have 7.3 DTR track created with the name : DEVTrack1 and the workspace location as follows "/ws/DEVTrack1/DEV_Test_SC/dev/inactive". ( This is a different server)

    Now the workspace locations are same in the both the environment and I have to "replicate" the DTR content.

To do that, I have done the following.

1) -> logged into the putty for the DTR system 7.0 and launched the DTR console. Now I am in the DTR console ( I can do help replicate option now , it shows me the options how to work with replicate).

2) -> Now i wanted to connect to the system as mentioned in the documents , when i do that i am getting the below error .

    Command:   > connect xxxxt:yyyyy username password DEVTrack1

Error:

Created session "DEVTrack1"

Warning: Session is invalid. Check host, port, user, and password of this session and that the repository is available

=> Kindly let me know in this case, what hostname and the port i should and the username and password? ( what kind of authorization this user should have).

Once I execute the above command i am getting below entry in the DTR console ->

DEVTrack1>

If i execute the replicate command, i am getting one more exception.

    Command : replicate /ws/DEVTrack1/DEV_Test_SC/dev/inactive/    DEVTrack1   /ws/DEVTrack1/DEV_Test_SC/dev/inactive

Error:

Error: Received "401 Unauthorized" response for the request: PROPFIND /dtr/ws/DEVTrack1/DEV_Test_SC/dev/inactive

Could you please help me resolving this issue. thanks in advance.

best regards,

Manoj K

[ErvinSzolke · Accepted solution]

Hi,

Command:   > connect xxxxt:yyyyy username password DEVTrack1

Here the username and password has to be the username and password maintained on the Domain Data tab of the given CMS's Landscape Configurator.

I believe the user has to be the NWDI communication users.

As far as I remember when doing the replication you have to execute this connect command twice, once for the source, and then for the target DTR. Both command are displaying the warning

"Warning: Session is invalid. Check host, port, user, and password of this session and that the repository is available" ?

When you do this connection test, can you log on to the DTR webui with the mentioned user and pass?

I hope this helps.

Best Regards,

Ervin

[former_member787462 · Accepted solution]

Hello Ervin,

Thanks for the inputs.

Now i copied the "com.sap.dtr.console" to my local file system and executed the run.bat file and used the below two commands to connect.

>connect xxxxx:xxxxx testuser testpassword DEVTrack1

Created session "DEVTrack1"

DEVTrack1> connect xxxxx:xxxxx testuser testpassword DEVTrack1

Created session "DEVTrack1"

DEVTrack1>

Till above line, i am able to connect and also i can able to view the files,( as you asked me to check the username and password are the one , which are present in both the servers and has the NWDI.administrator group.But,

If I execute the replicate command I am getting below error.

DEVTrack1>replicate /ws/DEVTrack1/DEV_Test_SC/dev/inactive/    DEVTrack1   /ws/DEVTrack1/DEV_Test_SC/dev/inactive

Error: DEVTrack1:/ws/DEVTrack1//DEV_Test_SC/dev/inactive/ already exists

And if i try to execute the following i am getting one more exception.

DEVTrack1:/>replicate -r /ws/DEVTrack1//DEV_Test_SC/dev/inactive/ DEVTrack1 /ws/DEVTrack1//DEV_Test_SC/dev/inactive/

ERROR:

Set the state of the workspace DEVTrack1:/ws/DEVTrack1//DEV_Test_SC/dev/inactive/ to restricted

Replicating integrations of /ws/DEVTrack1//DEV_Test_SC/dev/inactive/

Error: Received "403 Forbidden" response for the request: REPORT /dtr/

Precondition: XCM:missing-argument

I am bit confused, how this works and how can i replicate the content from my OLD dtr to NEW dtr. Please let us know if I am missing something.

__________________________________________________________________

Above things will not work , when you use the old console. But, I have implemented the below SAP note.

1377679 -- DTR Console "replicate command" don't work

And i went to inside the SDA and launched the DTR console and I am able to execute the command "replicate"

    -> But, the newtrack is getting created in the old DTR itself.

Can you please help, is there any sequence should be followd to run the commands. How can we make sure , whether the OLD DTR to talking to NEW DTR.

Please help us.

regards,

Manoj K

[Soumya · Accepted solution]

Hi Manoj,

The lines mentioned are;

connect targethost:targetport user password targetID

connect sourcehost:sourceport user password sourceID

Please do not use use same ID "DevTrack1". Use the SIDs of the respective systems instead. Not sure whether this will solve your error though.

Sequence is as mentioned in the sample script. First connect to

Target, then connect to Source.

Hope it helps.

[Soumya]

Another question: Which is the correct method of creating tracks - 1> Via NWA  or 2> Via CMS and why ??

Thanks,

... -.-.

[ErvinSzolke]

Hi,

what do you mean by NWA? The Track creation wizards?

I personally prefer simply go to CMS and create the track on my own, because I can see what I am doing then and can keep the complete track creation process under control, while NWA is a point and click solution and hides all these tasks from the user. So I think both has its advantage and disadvantage.

Doing with the wizard you need to specify only couple of data and it does the job for you, but if it crashes at any point it is perhaps more difficult to track back what was wrong and fix it. If you do everything via CMS, you need to have a bit deeper understanding on the track creation process. NWA may be quicker but ... while doing it on your own without NWA, it keeps you in practice and good shape. It is like asking someone to execute a tutorial for you and then asking him to tell you what he experienced, OR doing it on your own and experience it yourself, but as mentioned at the very beginning this was my personal opinion only still I hope it helped.

Best Regards,

Ervin

[Soumya]

Thanks Ervin,

I found out why it is throwing the error that "Track ID is used in another CMS Server". It is because of the small step we overlooked in Method 1 . Forgot to delete the CMS entry of ABCDCPY from CMS 1. We missed this step and went on to rename the folder in DTR 2 and then proceeded with the replication script.

For track creation, I have one doubt. Since I am new to NWDI, I am not sure even if the question is sensible.

While creating track in CMS2: In Landscape Configurator mode I am adding SC [SAP_MSS 600], giving Track ID and Name and creating a track.

Reviewing the job I came across tabs : Check-In, Development, Consolidation etc under Transport Studio. In CMS 1 there are so many SCAs found under Check-In tab which I am not able to add to the track in CMS 2. The Check-In button is disabled, though I have NWDI Admin role.

What are these Check-In / Dev / Assembly tabs for and how to make them populate with same data as CMS 1??

[Edit: Check-In tab is to be populated by placing the SCAs in CMS/Inbox folder and that list gets populated as per the SCs added for the track. Just figured out by checking with basis team and online articles. But still don't understand how the other tabs could be populated.]

Journey through this NWDI migration is a great learning curve for me and your mentoring has really helped me a lot, Ervin.

Thanks,

Soumya

Message was edited by: Soumya Chanda

[ErvinSzolke]

Hi,

I am glad if I can help, Soumya! 😉

in CMS2 please go to the Domain Data tab (in Landscape Configurator) and check the Transport directory. Check this location on your filesystem, and go into its CMS/inbox subfolder.

This is where you need to have the SCA files for Check-in. If this folder is empty them there is nothing to be checked in, and this case the list will be empty and since it is, I assume the buttons are grayed out as well. For reference, you can compare these data (like transport folder, its content, etc) with CMS1.

Check-in lists all SCs that are available physically in your CMS inbox AND defined on the track data tab of the given track. But this stage is a release independent step, or more precisely this is the place and moment when you can decide what exactly to check in, since you may have varios releases and SPs for the same SC (having the same name) in your CMS inbox, so this is the place and moment where you decide which release and SP version of the given SC you want to work with.

If you believe you proceeded properly but still the SCAs are not showing up on the Check-in tab, then check this note: #1259604 – CMS check-in tab: Not all files from inbox are displayed

The development flow goes on then this way (just a rough overview without going into details):

You check all of the SCs in which you require, and these will show up on the Development tab and will having the state "waiting for import". Once you import these SCs into Dev, the CBS buildspace will be filled up with the DCs, included inside the SCs to be imported. You do the same for Cons. Then you can start your development. This is the first moment when it makes sense to launch your NWDS and import the development configuration of the track you created in CMS and which is prepared properly by succesfully finished imports to dev and cons. You check out a file in NWDS, you do modifications on it, you check-in (not to be confused with Check-In tab in CMS webui), you release (at this point the change is showing up on the consolidation tab). You import it into Cons, and then you have the possibility to assemble, meaning to generate an SCA file that will include your custom changes you just did. Important to know that assembly always generates the SCA out of the cons/active workspace. Meaning that the SCA will include only those changes that you have imported to cons. The goal of inactive and active workspaces is the follwing. An activity can be activated only if it can be built, and if it can, it will be transfered to the active workspace. This ensures that you can generate an SCA file only from a software that can be built.

Now the assembled software shows up on the Test tab (if you configured a Runtime system for it) which you can import again towards Approval (approval has other key importance from track connections' point of view, but let's just skip this part for now). Once the software is approved the software is showing up on Production (again if you configured a RunTime System for it), and once you import it into Prod, you are done, your software reached the production system and ready for use by your colleagues or customers who has access to the production system.

Let me also send you a link for reference:

http://help.sap.com/saphelp_nw04s/helpdata/en/03/f6bc3d42f46c33e10000000a11405a/frameset.htm

(this is a document for 700 but the procedure is so fundamental that this is still valid for any releases).

You may find this sub page of the above link useful too:

http://help.sap.com/saphelp_nw04s/helpdata/en/d2/4551421705be30e10000000a155106/frameset.htm

I hope this helps.

! I also suggest that if you have follow-up questions, please open a separate thread. I would like to achieve that this thread goes mainly about replication, else the subject of this thread will be confusing.

Best Regards,

Ervin

[ErvinSzolke]

Hi,

here another useful link for the development process in general:

http://wiki.sdn.sap.com/wiki/display/Java/NWDI+FAQ#NWDIFAQ-FAQNWDI0

Best Regards,

Ervin

[Soumya]

Sure Ervin, I will open a new thread if I have query other than DTR replication.

Getting back to replication one of my track with live data [data to be finally replicated for enduser purpose] is throwing error while running the script. Till date I was experimenting on some old unused tracks. I am following the tried and tested, Method 2, to replicate two tracks with live data and it were successful, i.e No errors.

There are couple of more steps added in Method 2 regarding custom SCs and Products used in tracks, i.e. Export / Importing them via SLD.

The third track is throwing an error: Error: Received "500 Internal Server Error" response for the request: INTEGRATE /dtr/ws/ABCDTRCK/sap.com_SAP_ESS/dev/inactive.

I am trying to figure out: Where [In Target DTR or Source DTR] is the error occuring and Why?? If possible how to recreate the error on any test tracks.

Since it has live data, I am not trying to experiment on this.

Thanks,

... -.-.

[Soumya]

While analysing the logs I came across two errors for the same track.

First one was some days back. May be one of my team had tried something regarding replicating.

Second error is repetitive and on same times when I got the error while trying to replicate [4 - 5 times, thought could be syntax or permission issue] .

First error in log:

500 Internal Server Error is returned for HTTP request [http://<servername>:80/dtr/ws/ABCDTRAK]:

component [DTRServlet],

web module [dtr],

application [sap.com/tc~dtr~enterpriseapp],

DC name [sap.com/tc~dtr~enterpriseapp],

CSN component[BC-CTS-DTR-SRV],

problem categorization [com.sap.ASJ.web.000137],

internal categorization [-809674053].

[EXCEPTION]

javax.servlet.ServletException: com.sap.exception.BaseRuntimeException: Cannot get OutBuffer: -7 connection to partner broken.

Second error (This appears exact number of times, I tried to run the script):

500 Internal Server Error is returned for HTTP request [http://<servername>:80/dtr/ws/ABCDTRAK/sap.com_SAP_ESS/dev/inactive]:

component [DTRServlet],

web module [dtr],

application [sap.com/tc~dtr~enterpriseapp],

DC name [sap.com/tc~dtr~enterpriseapp],

CSN component[BC-CTS-DTR-SRV],

problem categorization [com.sap.ASJ.web.000137],

internal categorization [-1500242124].

[EXCEPTION]

javax.servlet.ServletException: java.lang.OutOfMemoryError: Java heap space (failed to allocate 1073741840 bytes)

The second error seems like a memory issue. I have already asked the Basis team to look into it. still awaiting their reply.

Please suggest.

Thanks

... -.-.

[ErvinSzolke]

Hi,

for the outofmemory error the note that crosses my mind is this:

#1001502 - OutOfMemory error during CMS import on Oracle 10g database

Best Regards,

Ervin

[former_member787462]

Hi Sowmya,

Finally , I am able to replicate from old DTR to new DTR.

I have done the replication for one SC( This SC component is custom developed one). And I have other SC's also custom developed. When i try to replicate the /active part for the SC(replicate -r /ws/XX/yy/dev/active TrackID /ws/X/yy/dev/active) it works fine and replication is happening.

But, When i try to replicate the inactive part of the same SC (replicate -r /ws/XX/yy/dev/inactive TrackID /ws/X/yy/dev/inactive) I am getting below error.

Error: Received "500 Internal Server Error" response for the request: INTEGRATE /dtr/ws/TrackID/yy/dev/inactive

I could see in the same post, you also faced the similar issue, could you plesae let me know , how did you resolved the issue?

Further to my investigation , I checked the logs from below location of Old and New DTR , but i m not able to find any reason why this issue is happening!!!!

-usr\sap\<SID>\<central instance>\j2ee\cluster\server<n>\log\defaultTrace.<n>.trc

-usr\sap\<SID>\<central instance>\j2ee\cluster\server<n>\sap.com\tcdtrenterpriseapp\dtr.<n>.log

-usr\sap\<SID>\<central instance>\j2ee\cluster\server<n>\log\services\tc.CBS.Service\cbs.<n>.log

Please advise.

Best Regards,
Manoj K

[former_member787462]

Hi Sowmya,

Can you please help us in , how to resolve the below issue.

Error: Received "500 Internal Server Error" response for the request: INTEGRATE /dtr/ws/TrackID/yy/dev/inactive

best regards,

Manoj K

[Soumya]

Hi,

Please share the reason which caused the Error: Received "403 Forbidden" and the solution. The /inactive respository error was not worked upon by team as the project is currently on backburner and the error was encountered on the last track in our case. Go through server logs / traces for detailed report.

Please do share the solution and reason for "403 Forbidden" error.

[former_member787462]

HI Soumya,

The reason for 403 issue , is cuz of the users which you have used to migrate should have NWDI.Administrator roles assigned on both the systems.

And , the issue which i reported was fixed by doing the following.

Tried deleting the /active and /inactive entries from the
new NWDI system under each SC ( /ws/SCname/dev/active and
/ws/SCname/dev/inactive), then we tried replicating the same from old
NWDI. It worked successfully( we did not do any thing , and not sure whyit worked, but the result was successful and we were able to perform allthe actions from NWDI).

OR ( Might work , please try out)

And also from the NWDI system logs there could be error entries like the below. May be if you try this out , this will also work.

The following error message is the root cause for the issue:
"com.tssap.dtr.pvc.versionmg.SystemTimeMovedToPastException: The
progression of time as shown by the database timestamps was in reverse
direction. See the integration 2 into the target versionset
f71c309d8c8a11e2900700000078ddfe that occured at was 2013-03-14
12:46:08.857. Current timestamp is 2010-04-12 04:30:46.0. This was
detected when integrating source version set
e0b88d7345e611df88178631dd538404 into the target versionset
f71c309d8c8a11e2900700000078ddfe"

This is because of new automatic integration requests created during thereplication.

To solve this please set the following DTR property to 'false' :
com.tssap.dtr.pvc.versionmg.DefaultIntegrator.failOnWrongSystemClock

See note:
1001509 - How to change a DTR repository property

The mentioned DTR property should be reset to 'true' after the
successful replication.

Best regards,
Manoj K

[Soumya]

Hi Ervin,

The manual creation of tracks instead of "Save As.." was really helpful. Replication for the track was fine too.

Thanks,

... -.-.

[ErvinSzolke]

Hello Soumya,

I am glad to hear that I could help. 😉

Best Regards,

Ervin

[Soumya]

Hi Ervin,

Using the same user id and password, we were successful in "Save As.." function. Then the script for replicating was also run successfully. But this track is not showing up in CMS. We have tried "Update CMS" button and have even restarted the entire system. Are we missing any step??

Thanks,

... -.-

[Soumya]

Hi,

I have tried to create a track with same ID as the already replicated track. This results in an error: The Track ID is already used in an other CMS server. Use an other DTR server or an other track ID to solve the problem. Please help...

Thanks,

... -.-.

[ErvinSzolke]

Hi,

- Update CMS is only syncing the SLD content with CMS, that won't help from this point of view.

- You can't create the same track name in the same CMS.

You said you created the CMS track using CMS (instead of save as). Where did you do it exactly?

Did you create the same trackname in the target CMS (which is allowed since it is a different CMS and so it won't conflict regarding tracknames) or did you create a different Trackname in the source? Could you please describe step by step how exatly you dealt with the track creation and then the replication afterwards? Please describe an example scenario for better understanding.

I would like to understand it since:

- if you created it in target CMS, then it should be available there of course.

- if you created in source CMS (using different track name of course) then there it should show up as well.

So I am uncertain what exactly you are missing at this moment.

Thank you and Regards,

Ervin

[Soumya]

Thanks for the response. Kinda stuck currently.

I have created tracks via 2 methods:

Method 1:

a> Use the same cms user id and password as old NWDI [Say NWDI 1] in the new NWDI cms [Say NWDI 2]

b> Performed the "Save As.." on track [say ABCDTRK] to new id [say ABCDCPY] as instructions, from CMS of NWDI 1. [Replacing the DTR url of the track to DTR url of NWDI 2, as explained in the link for replicating]

c> Renamed the webfolder in DTR of NWDI 2 [ABCDCPY] of the "Save As.." track to original trackname ABCDTRK [As mentioned in the article]. Here we missed the step of deleting the new track ABCDCPY in CMS of NWDI 1 as per the article.

d> Run the script [Without any errors]

e> Track not appearing in CMS of NWDI 2.

f>  Restarted the NWDI but no success. Track still not appearing.

g> Found note: http://service.sap.com/sap/support/notes/1525841. Tried to create track in CMS of NWDI 2 with name ABCDTRK. This resulted in the error as mentioned earlier. "The Track ID is already used in an other CMS server. Use an other DTR server or an other track ID to solve the problem"

Is it due to the missed step of deleting the ABCDCPY entry in CMS of NWDI 1??

Method 2:

a> Manually create track [say DEFGTRK] with same id as NWDI 1, in CMS of NWDI 2

b> Tracks getting saved and appearing in CMS of NWDI 2.

c> Running script for replicating. No issues.

d> In CBS DCs not appearing. Still to be connected via NWDS. I think the build variable is still to be set. Still not aware of the next step to verify whether this steps yeild better result than 1st method.

Stuck currently because not sure whether to delete the 2 tracks from DTR of NWDI 2 replicated via Method 1. Came across some discussions that it is not that safe. We NEED to use same track ID [ABCDTRK].

Please feel free to ask if you need any more information.

Thanks,

... -.-.

[ErvinSzolke]

Hi,

let me point out some facts before I reflect to your post.

1. a cms track will be visible there where you create it.

2. replication has nothing to do with track creation anywhere. It only replicates DTR workspaces. Consequently, replication won't create cbs builspaces either.

3. creating a track in cms webui in NWDI1 creates the cms track in NWDI1 and CBS buildspaces and DTR workspaces on the server you defined in the given track configuration.

b> Performed the "Save As.." on track [say ABCDTRK] to new id [say ABCDCPY] as instructions, from CMS of NWDI 1. [Replacing the DTR url of the track to DTR url of NWDI 2, as explained in the link for replicating]

Ok, so this case Save as created the DTR workspace in NWDI2, and created CMS Track in NWDI1.

This is why you won't see any track in NWDI2's CMS. At this stage Track ABCDTRK and ABCDCPY is available in CMS of NWDI1 and DTR workspace ABCDCPY available in NWDI2. For this see again the facts above that helps to connect the dots.

Method 2:

I like this approach better perhaps.

This case the same trackname DEFGTRK is available in both the CMS (NWDI1 and NWDI2) and this is also true for the existence of DTR workspaces and CBS buildspaces.

d> In CBS DCs not appearing. Still to be connected via NWDS. I think the build variable is still to be set. Still not aware of the next step to verify whether this steps yeild better result than 1st method.

DTR replication replicates the custom DCs of your software. In other words the Sources.

The archives are not replicated obviously and they doesn't need to be. So at this point everything is normal. What you need to do is that you have to go to the CMS webui, check-in the Archives, and import them into the corresponding CBS buildspaces (dev & cons). Under archives I meant the build plugins, or in other words the dependent software specified as Build time SC dependency for your custom SC (like SAP_BUILDT to mention an example).

Stuck currently because not sure whether to delete the 2 tracks from DTR of NWDI 2 replicated via Method 1. Came across some discussions that it is not that safe. We NEED to use same track ID [ABCDTRK].

If you need the same track  ID like ABCDTRK then why don't you go for Method 2 in which you use this Track ID ? That would be the simplest solution in your case. ABCDTRK was not created so far in NWDI2's CMS if I understood right, so it should not complain either that this track already exists. And if it does, you can just simply adjust the replication script and replicate into NWDI2's ABCDTRK.

I hope this helps a bit, let me know if you need more clarification.

Best Regards,

Ervin

[Former Member]

Hello Ervin,

I have some similar problem.

I would like to replicate some DC and SC from our old NWDI 7.0 to the new one in 7.3.

I have created a new track in our new NWDI.

From the dtr tool I have lanuched :

>connect targetserver:port username password JDI

Created session "JDI"

JDI:/>connect sourceserver:port username password JDI

Created session "JDI"

JDI:/>replicate -r /ws/sourcetrack/SC/dev/active JDI /ws/targettrack/SC/dev/active

Here is the error :

Error: Received "404 Not Found" response for the request: MKWORKSPACE /dtr/ws/targettrack/SC/dev/active

I have verified that the path was created correctly in the target dtr.

It was fine.

Could you help us on this error ?

Thank

JY

[Soumya]

Can you please change the ids to JD2 for Source ID and JD1 for Target ID, instead of putting same "JDI" for both the systems and try again ...

Hope it helps...

[Former Member]

Hello Soumya,

But our both NWDI have JDI as SID.

[Soumya]

Well, I am not sure, but I think one can use anything else also other than SIDs in SourceID and TargetID

[Former Member]

Soumya,

I have tried your solution.

But I have this message :

Found 0 integrations in source workspace

Replicating version set groups of /ws/PESPERSO

Found 0 version set groups in source workspace

Found 0 version set groups in target workspace

The replication does not work.

I have compare some folders and some files are missing

for example is the source dtr :

We have 4 files :

In the target only two :

What should I do ?

[Soumya]

So now you are able to run the script properly ?? (with different IDs.)

As far as .dcref files, I only know that they are reference pointers used in assignment of the DCs to their corresponding SCs. They are stored alongside the configuration directory. This file normally has no content, but the name reflects the hierarchial path of DC location.

Experts please help...