I have been working for a few customers now to implement NWDI and later also CTS+, during this projects I found out that there were a lot of confusions of how it all works. With this Blog I am trying to explain how the different components work together. It is not the intention to explain how to configure it. If there is some interest for the activity based configuration as well then let me know so that I can create a blog about that as well.
Introduction
A while ago SAP started with CTS+ (enhanced CTS) with this tool you can transport also portal (non-ABAP) content via the stable CTS application. This way you can streamline your change management process for both ABAP and non-ABAP applications. This worked great for portal content (iViews, Roles, Pages, etc) but when you were using NWDI developments then you still had to attach full SCA files and use the CMS tool with tracks as well.
Now with activity based transports you can transport just the code that was changed (captured in DIP files). This way you only use the DTR and CBS components of NWDI but the CMS component is not used anymore. All configuration is done from the STMS transaction of the CTS+ server in a similar way on how you setup CTS for ABAP systems.
Prerequisites
In order to implement this feature you have to met the following prerequisites:
- Dual Stack Enhanced Change and transport System on enhancement pack 1 for SAP NetWeaver 7.0 or higher (Solution Manager recommended)
- SAP NWDI system on enhancement pack 1 for sap NetWeaver 7.0 or higher
- NWDS (Developer Studio) on enhancement pack 1 for 7.0 or higher (only version that enables the developer to release their activities into ABAP transports
- Runtime (portal) systems must be on the same version as NWDS when you develop Web Dynpro applications
In total you need to define three destinations from the CTS server, CTSCONFIG and CTSDEPLOY_DI point both to the NWDI system. CTSCONFIG is used to create development configurations and CTSDEPLOY_DI is used to connect to the deploy proxy for NWDI changes (which should run on NWDI based on SAP recommendations).
The third connection is the CTSDEPLOY and should connect to the deploy proxy running on the java stack of the CTS+ system. This proxy is used for transporting portal content (epa files). Both the CTSDEPLOY and CTSDEPLOY_DI are the same web service. But SAP recommends to use the approach defined above. The SLD for storing the software components will run on the NWDI system.
When you set up activity based transports then the developer will have to use the enhancement pack 1 version of NWDS, this version enables the developer to release their activities into an ABAP transport.
How does it work
The developer logs on to NWDI with its developer studio and downloads the source code of a specific application to its local pc (1). He can then change some code of the application which is captured into activities (2). The changes are only visible locally on his pc. Then the developer will check in his code to the DTR (3) and activate the code which will build the application (4). If the build was successful it will copy the code to the active part of the workspace (5) deploy to the development portal (6).
So far there are no differences between a regular NWDI development, but when the developer is finished with its development then it will release all its activities into an ABAP transport. During this process all the activities (code changes) are put into an ‘DIP’ (Development Infrastructure Package) and this file is attached to the ABAP transport (7). Finally the released ABAP transports are placed into the import queue of STMS and from there you can now import the changes in the same way as how you transport regular ABAP changes.
When you now open the transport then you can see that a ’dip’ file is attached to the transport.
This also gives the advantage that you can look at the log files in the same way that you’re used to with the ABAP changes. So you can see for example how often a transport had failed import for a specific system.
When you click on an import log you will see the SDM log so these are now right available with the ABAP transports. This way it is not only easy to track if a transport went wrong before but also why.
Due to the fact that you only transport code changes it would be impossible to transport them directly to the portal. Therfore for each portal in your landscape a separate area in the DTR (workspace) and CBS (buildspace) is reserved.
So with each import you will copy the contents of the ‘dip’ file into the DTR workspace of the destination portal. Then the build server will take this newly copied code and tries to build it on the CBS build space of the portal and if all is successful the application that was build will be deployed to the portal via SDM.
2 Comments
