What is NWDI? What is the Version? What is done in NWDI?

What is NWDI? What is the Version? What is done in NWDI? 
What CBS, DTR, CMS and SLD? Briefly explain? 
How can we transport webdynpro components from development server to product serve?
About Version Management?

NWDI:

CBS, CMS, DTR these are the parts of NWDI

We can create track using CMS

The 3 Pillars of NWDI

Design Time Repository (DTR)

A central storage for all kind of source files in various formats. It provides source code management and version control for development based on the SAP NetWeaver platform.

Component Build Service (CBS)

The CBS is the central build environment in the development infrastructure also taking care of the management of the archives needed in each development project.

Change Management Service (CMS)

The Change Management Service (CMS) represents the part of Software Life-Cycle Management in the SAP NetWeaver Java Development Infrastructure.

The Change Management Service is the central administration UI for development landscape definition and transport management.

 Workspaces & Buildspaces

For every NWDI track two configurations (_Dev and _Cons) are created. Each of these configurations in turn contains 3 compartments each, namely Active and Inactive DTR Workspaces, plus one CBS Buildspace.
So your Track consists of totally...

4 DTR Workspaces:

Work-spaces belong to DTR

1. Inactive Development workspace of your track in DTR Server.
   (http://<host>:<port>/dtr/ws/<Track_Name>/<SC_Name>/dev/inactive)
2. Active Development workspace of your track in DTR Server.
   (http://<host>:<port>/dtr/ws/<Track_Name>/<SC_Name>/dev/active)
3. Inactive Consolidation workspace of your track in DTR Server.
   (http://<host>:<port>/dtr/ws/<Track_Name>/<SC_Name>/cons/inactive)
4. Active Consolidation workspace of your track in DTR Server.
   (http://<host>:<port>/dtr/ws/<Track_Name>/<SC_Name>/cons/active)

 2 CBS Buildspaces:

Build-spaces belong to CBS.Go to Component Build Services (CBS) Web UI >> (Build spaces >>)

1. Development Buildspace
   "<SID>_<Track-ID>_D" build space.
2. Consolidation Build`space
   "<SID>_<Track-ID>_C" build space.

All your Source code is stored inside the DTR Workspaces 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 and built archives from CBS build spaces.

The Source Code Journey

 

 

Note: Above Diagram covers the various building blocks that infrastructure comprises. The diagram explains How the journey of your source code (Passenger), takes place in the form of Activities (Train) on the different stations (Stations could be basically the runtime systems that you define in your track) of the NWDI.

Sequence of Operations:

Now let's get some more clarity on what happens under the hood step-by-step, 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 (Checkout) 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" the 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". Modifications present specific to closed activities will now be available to other developers.
3. When you "Activate" this activity, the CBS triggers a central 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".
   (Important Note: If you have maintained a development runtime system in your track, then CMS will trigger a central deployment operation of your source code on the J2EE engine of that system).
4. It is also very important not to forget that after a successful activation process, a compiled (built) version of your source code modification specific to that activity is also incorporated into "Development Build-Space" of your track.
   Note: 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.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. 
5. In the 1st operation, CBS triggers a central build operation to be performed on the source code modification specific to your 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".
6. In the 2nd operation, your source code will now be copied to the "Active Consolidation workspace of your track in DTR Server".
7. It’s also very important not to forget that after a successful build process explained in point 5, a compiled (built) version of your source code modification specific to that activity is also incorporated into "Consolidation Build-Space" of your track.
   (Important Note: If you have maintained a consolidation runtime system in your track, then CMS will trigger a central deployment operation of your source code on the J2EE engine of that system).

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-5.
In the Assembly Tab you perform the Assembly operation. In this operation a .SCA file will be generated by scanning the Consolidation Build-space. Assembly fails if during assembly operation any Broken or Dirty DC are found in the Consolidation Build-space.
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 next runtime systems like TEST server for further testing and then to the actual production system.

DTR Purpose:

Purpose of DTR for storing track id, development components of type webdynpro under tracks, versioning of projects and provides effective team work among developers distributed over different location.DTR stands for design time repoistroy.

CMS Purpose:

Change management service contains all “RUN TIME SYSTEMS” like

DEV J2EE Engine, TEST J2EE Engine, CONS J2EE Engine, PROD J2EE Engine.

CBS  Purpose:

Component build service provides ready-to-use libraries that are required for running various applications.

 The common libraries are

SAP-JEE

SAP-JTECHS

SAP-BUILDT

CBS contains the Total no. of DC’s, Broken DC’s and Dirty DC’s.