source code of a track nwdi

[Former Member]

Hi Gurus

My issue is i need to compare the source codes of old and new tracks as we are going for upgrade.

but i donot know where we find this source code and how to compare them so please help me out, thanks inadvance

Regards,

siva

[Former Member]

Hello Biswa,

To compare the code between two tracks and merging sorce code from old track to new track, the best tool is Meta data comparision tool.

This tool real easy enough to dientify the deltas and merge.

Here is the link for more details:

http://help.sap.com/saphelp_nw70/helpdata/en/c4/2910411db1d349e10000000a1550b0/frameset.htm

Thanks

Krishna

[ErvinSzolke]

Hi bsivasap,

use the track connections concept.

/people/marion.schlotte/blog/2006/03/30/best-practices-for-nwdi-track-design-for-ongoing-development

Create a forward connection from the old track to the new one (you do it in CMS's Landscape Configurator -- Track Data -- Track connections) and after you approve the changes on the "Approval" tab of the CMS's transport studio, in the old track, the changes will show up for import in the new track's 2Development" tab.

Best Regards,

Ervin

[Former Member]

Hi Ervin,

thanks for your reply,

but my scenerio is as my client is going to upgrade:

he wants initially to create a track with upgraded ess and mss sc's(with upgraded patches) and check the functionalities of upgraded ess and mss.

then after checking the functionalities, he wants me to move the customized ess and mss dc's, from old track to new track.

how do we approach this scenerio, please help me!

According to my understanding:

i would import both old track and new track into NWDS, open the customized dc of old track and open the standard dc of ess and mss of new track in webdynpro perspective.

compare both the code(implementation) and iview ui elements and make changes manually in the new standard dc, am i correct! help me if i am wrong! thanks in advance!

Regards,

Siva

[shreyas_pandya]

...Continued from the Last reply...

Now let's get some more clarity on what happens under the hood, when you perform the Check-In, Activate, Release & finally import your source code changes (wrapped inside the activities that you create for modifications) into Consolidation.

1) When an activity gets created as a result of any modification it's called "Open Activity". Open Activities are always associated with DTR-Client. Open activities are not available to other developers, not even for the same developer on other machine. To be more precise, Open Activities are strictly specific to the Local Machine's NWDS DTR-Client (their birthplace).

2) When you "Check-In" this activity, it implies that, all your source code modifications present in that Open Activity are copied from your Local Machine's NWDS DTR-Client to the "Inactive Development workspace of your track in DTR Server". Now that activity becomes a "Closed Activity". Closed activities become available to other developers.

3) When you "Activate" this activity, the CBS triggers a build operation to be performed on the source code modification specific to that activity present in the "Inactive Development workspace of your track in DTR Server". On successful activation, your source code will be copied to the "Active Development workspace of your track in DTR Server".

4) Itu2019s also very important not to forget that after a successful activation process, a compiled (built) form of your source code modification specific to that activity is also incorporated into "Development Build-Space" of your track.

5) When you "Release" this activity, it implies that this activity will now be available in the import queue of the Consolidation run-time system of your track.

6) When you "Import" this activity in the import queue of the Consolidation runtime system of your track, there are 2 main operations that are performed automatically,

7) In the 1st operation, CBS triggers a build operation to be performed on the source code modification specific to that activity present in the "Active Development workspace of your track in DTR Server". If the central build is successful then only the same source code will be copied to the "Inactive Consolidation workspace of your track in DTR Server" otherwise the import status will show "Import Failed"

😎 In the 2nd operation, your source code will be now copied to the "Active Consolidation workspace of your track in DTR Server".

9) Itu2019s also very important not to forget that after a successful build process explained in point 7, a compiled (built) form of your source code modification specific to that activity is also incorporated into "Consolidation Build-Space" of your track.

One main advantages of the _Cons workspace is that it never allows any inconsistent source code to be imported in it, as explained in point number-7.

In the Assembly Tab you perform the Assembly operation. In this operation a .SCA file will be generated by scanning the Consolidation active workspace. Assembly fails if during assembly operation any Broken or Dirty DC are found.

So by this mechanism, we have to be rest assured that the .SCA file that will be assembled by incorporating the modifications present in the _cons workspace will always be consistent. And the same .SCA file is transported to the TEST server for further testing.

Please revert if you need any clarifications.

Regards,

Shreyas Pandya

[Former Member]

Hi Shreyas,

your reply, has been very helpful to me.

But i have an issue, as we are going for upgrade of portal, so i am required to create a new track with ess/mss sc'c.

but my issue is after creating new track with ess and mss sc's , how do i move the customized standard ess and mss dc's from old track to this created new track. please help me! thanks inadvance,

Regards,

Siva

[shreyas_pandya]

Hi,

First of all you need to be clear about SAP's Component Model.

Please refer to the following blog to get a clear understand between NWDI and Non-NWDI scenarios.

/people/shreyas.pandya/blog/2011/01/06/nwdi-empowered-landscape-vs-landscape-without-nwdi-setup

Software Products & Software Components are defined in SLD.

Once the software component is defined. A track needs to be created for it. A Track acts a container that holds your Software Component (SC) which in turn is comprised of variety of Development Components (DC). This very Track you import into your developer studio for modifications.

For every NWDI track two development configurations (_dev and _Cons) are created and not only that, each of these configurations contain in turn 2 compartments namely active and inactive workspaces.

So your Track consists of totally...

4 DTR Work-spaces.

i) Inactive Development workspace of your track in DTR Server.

(http://<host>:<port>/dtr/ws/<Track_Name>/<SC_Name>/dev/Inctive)

ii) Active Development workspace of your track in DTR Server.

(http://<host>:<port>/dtr/ws/<Track_Name>/<SC_Name>/dev/Active)

iii) Inactive Consolidation workspace of your track in DTR Server.

(http://<host>:<port>/dtr/ws/<Track_Name>/<SC_Name>/cons/Inactive)

iv) Active Consolidation workspace of your track in DTR Server.

(http://<host>:<port>/dtr/ws/<Track_Name>/<SC_Name>/cons/Active)

+ 2 Build-spaces.

Goto Component Build Services (CBS) Web UI >> (Buildspaces >>)

i) Development Buildspace

"<SID>_<Track-ID>_D" build space.

ii) Development Buildspace

"<SID>_<Track-ID>_C" build space.

All your Source code is stored inside the DTR Workspace and the compiled version (Built version) of that source code is stored inside the CBS Build-spaces.

So, when you import your development configurations in developer studio it brings the code from DTR-Workspaces.

To be Continued...

Regards,

Shreyas