PUBLIC

Landscape Setup for Ongoing Java Development with CM Services in CTS+

Applicable Releases:

SAP NetWeaver 7.30

SAP Solution Manager 7.01 SP08 and higher

Topic Area:

SAP NetWeaver Development Infrastructure with CM Services

Version 1.0

April 2012

2

TABLE OF CONTENTS

THE ISSUE ........................................................................................................................................................ 3

1.1 Assumptions .................................................................................................................................... 3

1.2 The System Requirements .............................................................................................................. 3

1.3 The Landscape ................................................................................................................................. 3

1.4 The Process ..................................................................................................................................... 4

1.5 Integrating a Bug Fix from Maintenance to Development ........................................................... 4

1.5.1 Integrating a Bug Fix from Maintenance (DM1) to Development (DD1) with NWDS ................. 5

1.5.2 Integrating a Bug Fix from Maintenance to Development with DTR Command Line Tool or DTR Console ..................................................................................................................................... 8

1.6 Hints and References / FAQ ........................................................................................................... 9

3

THE ISSUE Assume the following scenario: You started using CM Services for developing your own application running on SAP NetWeaver AS Java. To start with a basic landscape, you might have set up a system DM1 for developing your application, a system QM1 for testing it and finally a system named PP1 where your end users use your application productively. So, your landscape in TMS (Transport Management System) might look like the following:

Each of these systems is representing a separate runtime system on SAP NetWeaver AS Java. After having finalized your application and having provided it to your end users, you were only asked to do bug fixing and small changes that could be transported to the PP1 immediately. Now management discovered that your application is of high value and should be extended with several additional features. Realizing all of them would take a while. Nevertheless, your end users expect that you continue fixing bugs for the productive version while you develop the newly required functionality. So how can you make sure that bug fixes can be transported through the landscape but the new functionality that you maybe did not finish, yet, is not? The blog Best Practices for NWDI: Track design for ongoing development describes how this can be handled with Change Management Service (CMS) of SAP NetWeaver Development Infrastructure (NWDI). In here, we would now like to give you some hints, how this can be done if you used CM Services. Read through the whole guide before you start setting up any landscape!

1.1 Assumptions

For this article, we assume

• that you are using an NWDI (and CM Services) on SAP NetWeaver 7.3

• That you are using an SAP Solution Manager (CTS+ System) which is at least on enhancement package 1 SP8 for SAP NetWeaver 7.0 or on enhancement package 2 SP7 for SAP NetWeaver 7.0.

• that you are using the Synchronize Service to fill your workspaces and buildspaces.

• that you are using the activity-based SDA transport (and not the transport of activities / sources)

• that you use one Design Time Repository (DTR) and one Component Build Service (CBS) (usually one NWDI system) for one landscape.

1.2 The System Requirements

To be able to handle new development and bug fixing in parallel, you need two additional systems. One system – let’s call it DD1 – is needed to develop the new functionality and a second one – e.g. QD1 – to test the newly developed functionality. This requires setting up two new runtime systems and configuring the landscape in TMS.

1.3 The Landscape

The simplest solution to set up a landscape fulfilling your needs is the following:

You first have to create representations for your new development and test system DD1 and QD1in TMS. Then connect these two systems using a consolidation route. New development should at some point in time become part of the maintenance landscape as well – therefore a delivery route is needed to connect the test system QD1 with the development system DM1 of your maintenance landscape. We suggest moving new development through the complete maintenance landscape before deploying it to the productive system). This ensures that your new development can also be tested together with the existing functionality. Both DD1 and DM1 have to be set up as source systems so that you can create transport requests for these systems. They both have to have a Development Configuration. The landscape that you were using before you were asked to do new development can remain as it is with one small exception: you need an additional delivery route between DM1 and QM1 to be able to transport the requests generated in DD1 through your maintenance landscape as well. Details are explained in the following section.

4

1.4 The Process

So how would you now handle changes and new development? You can start with developing new software in DD1 at any point in time after having set up the landscape. Transport it to QD1 using activity-based SDA transport to test the software. As an import into QD1 will forward the requests to DM1, you should not execute imports to DM1 as long as you are developing the new version in DD1. But as DM1 is a development system as well, imports into this system should not be executed on a regular basis, e.g. by a scheduler, so this should not be an issue. You could use additional measures like QA approval or project specific import to make sure that imports are only executed when you would really like to do so. After having tested the new software extensively in QD1, it would be ready to go to PP1. As soon as you would like to make your software available productively, you can import the transport requests created in DD1 into DM1 (and resolve conflicts if necessary – should not happen if you integrated all changes from DM1 into DD1 – covered later. If you have to change the SP and patch level, you should think about transporting the complete SCA. Export of the complete Software Component(s) from DD1 using the Export Web UI. If you decide to use SCA transport: Create a transport request containing the SCA(s) for your new functionality and transport this request through the complete landscape until it reaches PP1. You should do additional testing in QM1 to make sure that all the new development works fine maybe also in combination with other SCs that you might only have in the maintenance landscape as there is no new development done for this functionality in the moment. Keep in mind that you cannot provide any fixes for PP1 anymore after you imported your new development into DM1. So, you should try to keep the time between importing the requests coming from DD1 in DM1 and importing them in PP1 as short as possible. The main reason why you set up the landscape as it is was that you expected that changes (bug fixing) in DM1 might be required during the development phase. So how can you handle these fixes in parallel? Assuming that you do new development for the same SCs and DCs that are also in maintenance mode, you would have to make sure that the changes that you do in DM1 are done in DD1 as well. Otherwise the old – already fixed – bugs will come up again as soon as you transport the new development with the new functionality through your landscape to PP1. There is no automatism available which can do this for you. You would have to integrate the activities that were created for DM1 into DD1 otherwise you will get conflicts in DTR. When you integrate the activities that where created while fixing in DM1 into DD1, warnings will come up if there are conflicts which will be the case if you fixed a file in DM1 that was also further developed in DD1. You have to resolve the conflicts. Ignoring them will most probably result in new bugs. You can decide to keep one or the other version. Another option is to merge the conflicting versions. In some cases, conflicts can be merged automatically. Note that if you are developing Web Dynpro Java UIs, an automated conflict resolution is not possible. In this case, you have to first integrate the activity(ies) in DD1, then accept the active version and finally re-do your changes again manually in DD1. We suggest that this step of integrating the activities and resolving the conflicts is done by the developers themselves immediately after they have finished their fix. To integrate activities, they should use the SAP NetWeaver Developer Studio (NWDS) to integrate the activities and resolve the conflicts if possible. They cannot use this option, if you use different DTRs for DM1 and DD1 – see later for details. To learn more about conflicts, why they come up and how they can be solved, refer also to http://help.sap.com/saphelp_nw73/helpdata/en/4c/1f9762c4cb57d8e10000000a42189c/frameset.htm

1.5 Integrating a Bug Fix from Maintenance to Development

The following two sections describe first how integrating activities and resolving conflicts can be done with the NWDS and then how the command line tool supports this. Note that the NWDS can only be used for integrating activities if the workspaces for DD1 and DM1 are located in the same DTR. If you use different DTRs for DD1 and DM1, you have to use the DTR Command Line tool. You would have to export the activity from the DTR of workspace of DM1, import it into DTR of DD1 and integrate into the inactive (!) workspace of DD1. In the CMS blog, the set-up suggested in here for CM Services scenario was not recommended because of required rebuilds in the DEV and CONS system in the maintenance track (which corresponds to DM1 and QM1 in the scenario described in this document). This limitation does not apply in here as the results of the rebuild in DM1 only have to be transported if there were conflicts. Otherwise, you can simply continue with the transport requests that were created in DD1. You should only import the requests coming from DD1 into QM1 after the import in DM1 finished successfully. If there are warnings (which could be the result of non-resolved conflicts), the request will nevertheless be forwarded to QM1 which can lead to bugs that you might already have resolved earlier. To resolve this situation, you would have to do a re-export in DM1 after having solved the conflicts. But if you follow the rules described in this guide, you should not get warnings because of conflicts for imports in DM1.

5

Limitations

• after having imported the SDAs coming from DD1 into DM1, you cannot create bug fixes for the version that you have in PP1 – this is possible again after you transported your new development into PP1 as well.

• SP and patch level are metadata of SCAs only. Thus, SP and patch level can only be set if you transport SCAs using the Export Web UI. Take this into account if you would like to create a new version in DD1.

1.5.1 Integrating a Bug Fix from Maintenance (DM1) to Development (DD1) with NWDS ...

1. Preparing the integration in NWDS

a. Create a new DTR Client to see workspaces of different development configurations Design Time Repository Perspective → DTR → Create Client

b. Enable Admin Mode in NWDS to be able to integrate from Workspace a to Workspace b Window → Preferences → Development Infrastructure → Design Time Repository and choose Enable administrative functionality.

6

c. Set Workspaces for Closed Activities

Go to Window → Preferences → Development Infrastructure → Design Time Repository and click on Select Workspaces behind Set Workspace Filter for Closed Activities. In the new window coming up, select the Workspaces to be viewed (Make sure that the before created DTR Client is selected). First deselect all and then select the inactive workspaces of the source development configuration(s). Usually this should be the development configuration of your maintenance system because you would like to integrate from maintenance system to development system.

d. Set Workspaces for Integration Dialog

Go to Window → Preferences → Development Infrastructure → Design Time Repository and click on Select Workspaces behind Set Workspace Filter for Integration Dialog (Make sure that the before created DTR Client is selected).

First deselect all and then select the inactive workspaces of the target development configuration(s).Usually this should be the development configuration of your development

7

system because you would like to integrate from maintenance system to development system.

2. Integrating

a. In NWDS in Design Time Repository Perspective select the previously created client.

b. Open view “Closed Activities” if you do not see it yet, open it using the following path: Window → Show View → Closed Activities.

There you should see all closed activities for the workspaces you specified earlier in the step

“Set Workspaces for Closed Activities”.

(If you do not see your activities check the settings of the User Filter and Date Filter in the Closed Activities view using the triangle in the top right of the view)

8

c. Select your activities to be integrated into development and then choose “Integrate to…” from the context menu. The following popup appears:

Make sure to select the correct target workspace, containing development configuration ID of your development configuration for your current development and the software component name of the workspace where you did the fix.

d. After having clicked OK the integration will be executed. If there was also development done in the target workspace (in the development configuration of your current development) you would probably get another popup indicating that an Integration Conflict occurred as shown here:

e. Click Yes to open Integration Conflicts View in order to resolve the conflict.

In here you can see the differences and resolve the conflict by either accepting the active version (latest version of development) or by accepting the colliding version (your fixed version from maintenance) or by merging both versions. (see also http://help.sap.com/saphelp_nw73/helpdata/en/49/1cf4e8096d16b8e10000000a42189d/frameset.htm )

f. After having done the conflict resolution, check in the activity.

g. Activate the integrated activity(ies) and if collisions occurred also the conflict resolution activity(ies).

h. Finally, you should release the activities to minimize the risk of a conflict in following systems when you transport your new development without the fix.

1.5.2 Integrating a Bug Fix from Maintenance to Development with DTR Command Line Tool or DTR Console

Instead of using the NWDS for taking over the fix from maintenance to development you can also use the DTR Command Line Tool or DTR Console to do this. If you need more information about the Command Line Tool and how to start it, take a look at the SAP Help Portal at http://help.sap.com/saphelp_nw73/helpdata/en/49/11ef1ecf292810e10000000a42189c/frameset.htm For our example the integrate command in DTR Console would look like this: “integrate /act/default_w_DM1_cust_2e_com_CUSTOMSC1_inactive_u_nwdi_dev_t_2011_10_05_11_34_

9

44_GMT_05fc8e3a-ef46-11e0-aa38-00216a767d61

/ws/DD1/cust.com_CUSTOMSC1/inactive/”.

The activity is specified by its path which can be retrieved from DTR Web UI (for details, refer to http://help.sap.com/saphelp_nw73/helpdata/en/49/2689bdc2071903e10000000a42189c/frameset.htm ) or from NWDS. In NWDS, the path of an activity is shown in the Activity Properties in the context menu. Retrieve the path from the property Actual Name:

After the integration is done, you also need to execute steps 2.5 to 2.8 from the section “Integrating a bug fix from Maintenance to Development with NWDS”. Additional Information is available on the SAP Help Portal: DTR Command Line Client http://help.sap.com/saphelp_nw73/helpdata/en/49/0ff10817d92633e10000000a42189d/frameset.htm http://help.sap.com/saphelp_nw73/helpdata/en/49/101be83d9d132ee10000000a421937/frameset.htm http://help.sap.com/saphelp_nw73/helpdata/en/49/101bd63d9d132ee10000000a421937/frameset.htm DTR Console http://help.sap.com/saphelp_nw73/helpdata/en/49/12b42a9ba4105ee10000000a42189d/frameset.htm

1.6 Hints and References / FAQ

Recommendation for Web Dynpro Java Bug Fixes

If you are doing a Web Dynpro Java fix which affects not only source code but also UI changes and you get conflicts during integration into development we recommend that you accept the active versions of all files and then redo the fix manually in the development configuration of your development system. BUT you should always integrate the activity with the bug fixes into the development configuration of your development system because otherwise you will get conflicts in future when the development version and the fixed version meet each other in any following system.

How can I do maintenance if my NWDI / CM services are on enhancement package 2 for SAP NetWeaver 7.0 or SAP NetWeaver Composition Environment 7.2?

You can also set up the same scenario if you are using CM Services on enhancement package 2 for SAP NetWeaver 7.0 or SAP NetWeaver Composition Environment 7.2. There is only a small change for your landscape: you would have to create two upload systems – one that is used to fill the buildspace of DM1 and another one for DD1. With SAP NetWeaver 7.3, upload systems are not needed any more. You should use the Synchronize Service to import the SCAs into NWDI (fill the buildspaces). If you are using upload systems, your landscape could look like the following:

10

Note that there is no delivery route between DM1 and QM1. This leads to the limitation that for these releases, you have to do a re-export of the SCA(s) in DM1 using the Export Web UI. With CM Services on SAP NetWeaver 7.0 it is not possible to set SP and patch level for SCAs. Note that the whole guide only deals with the activity-based SDA transport. Transport of sources (activities) is not taken into consideration. Therefore, this FAQ only describes what can be done with enhancement package 2 for SAP NetWeaver 7.0 or SAP NetWeaver Composition Environment 7.2. The activity-based SDA transport is not provided for enhancement package 1 for SAP NetWeaver 7.0.

How to minimize the amount of requests in the queue of PP1?

If you think that your queue for PP1 (and QM1) is too big and you would not like to see all of the transport requests containing activities for each and every small change in the queue of PP1, you could think about deleting the delivery route from DM1 to QM1 – see previous FAQ. This would mean that you cannot transport activities from DD1 to PP1 anymore but that you have to transport SCAs. These SCAs have to be exported from DM1 using Export Web UI. For bug fixing, you could still transport activities from DM1 to PP1.

What are the differences compared to using CMS?

If you used CMS and the scenario as described in the blog Best Practices for NWDI: Track design for ongoing development, you might realize that there is no back-transport available or suggested for CM Services in here. As a consequence, in CM Services you have to remember to integrate the activities containing bug fixes into DD1 manually as described earlier via NWDS or DTR Command Line Tool. In both cases (CM Services and CMS) integrating fixes into development requires manual steps. In case of CMS you have to do the import in development system manually and you have to resolve the conflicts there. In CM Services, you integrate the activities manually and resolve the conflicts. Both with CMS and CM Services, a bug that you already fixed in DM1 will come up again if you exported a new release of your software from DD1 which does not have the activities containing the fixes integrated. If you compared what’s described above with the blog dealing with this scenario for CMS, you will find out that the scenario suggested in here differs from the one recommended for CMS. The difference is that with CMS, a re-build is required more often. In here, a re-build is only needed when you import the newly developed functionality into DM1. For the rest, you can use the transport of deployables – be it SCA or activity-based SDA transport.

Do I really need five SAP NetWeaver AS Java Systems?

No, you don’t have to set up QD1 and QM1. We recommend using separate systems for testing, but it is not a must and you could also transport changes directly from development to the productive system or only use QM1 but not QD1.

How can I make sure that only transport requests containing tested functionality will become part of the queue of PP1? What does CTS offer to support me in here?

Usually, a transport request will become part of the queue of the following system directly after the import for the previous system had been executed. TMS offers options to make sure that transport requests can only be imported into e.g. the productive system after they had been approved. Another thing that you can do is to import only transport requests into the productive system that are assigned to a certain project – e.g. one project for maintenance requests and another one for new development. In SAP Solution Manager, you can also find tools like Change Request Management or Quality Gate Management that support you with change control processes and project specific transports.

11

Where can I find more information on setting up CM Services?

Guide for setting up CM Services in enhancement package 2 for SAP NetWeaver 7.0: http://www.sdn.sap.com/irj/sdn/cts?rid=/library/uuid/90b89739-c236-2e10-f69d-eed4adc40983 Information on CM Services in SAP NetWeaver 7.3: http://www.sdn.sap.com/irj/sdn/cts?rid=/library/uuid/9076d36e-2540-2e10-3fbe-ea462491aa5d

I used CM Services with upload systems in enhancement package 1 or 2 for SAP NetWeaver 7.0. Do I have to re-configure my landscape after an upgrade to NetWeaver 7.3 to be able to use the maintenance scenario described in here?

If you already used CM Services e.g. with enhancement package 2 for SAP NetWeaver 7.0 and set up the landscape with upload systems, you could also continue using this landscape for the maintenance scenario. Prerequisite is that you were using the activity-based SDA transport. This option was not provided with enhancement package 1 for SAP NetWeaver 7.0. If this was the release that you came from, then you have to do some re-configuration: at least switch to activity-based SDA transport. Details, how this switch is done can be found in the guide ‘How to switch from CMS to CM Services’: http://www.sdn.sap.com/irj/sdn/cts?rid=/library/uuid/40941f5c-087a-2d10-95b3-8be402af3358 Please check FAQ ‘How can I do maintenance if my NWDI / CM services are on enhancement package 2 for SAP NetWeaver 7.0 or SAP NetWeaver Composition Environment 7.2?’ as well in this case. Another option would be to switch to the main scenario recommended in this document. To do so, you would have to delete the upload systems and add a delivery route from DM1 to QM1.

Are there any recommendations concerning SP updates?

We recommend that you keep all the systems involved in the maintenance landscape on the same SP level. Otherwise you would have to make sure that all the coding that you use is compatible between the different SPs - especially if e.g. your productive system is on a lower SP level than the development systems (DD1 or DM1). Only exception is that you could use a newer SP level for DD1 and QD1 while developing new functionality. If you did so, you should update PP1, DM1 and QM1 before executing any import of the new functionality into these systems.

What to do if I transport a new SCA?

This guide up to now assumed that you changed the same SCA both in DM1 and DD1. If you create new SCA(s) in DD1, then you would also have to adapt the development configuration DM1 (add the new SCA(s) as ‘to be developed’) right before you import the newly developed parts in there.

After import in DM1 conflicts are reported. Why?

Conflicts in DM1 occur if the same source was changed in DM1 and in DD1. Make sure you integrated the fix from DM1 to DD1 and also transported the conflict resolution done in DD1 to DM1. See section ‘Integrating a Bug Fix from Maintenance to Development with NWDS’. More information about conflicts can be found on the SAP Help Portal: http://help.sap.com/saphelp_nw73/helpdata/en/4c/1f9762c4cb57d8e10000000a42189c/frameset.htm

www.sap.com/contactsap

© 2020 SAP SE or an SAP affiliate company. All rights reserved. No part of this publication may be reproduced or transmitted in any form or for any purpose without the express permission of SAP SE or an SAP affiliate company. The information contained herein may be changed without prior notice. Some software products marketed by SAP SE and its distributors contain proprietary software components of other software vendors. National product specifications may vary. These materials are provided by SAP SE or an SAP affiliate company for informational purposes only, without representation or warranty of any kind, and SAP or its affiliated companies shall not be liable for errors or omissions with respect to the materials. The only warranties for SAP or SAP affiliate company products and services are those that are set forth in the express warranty statements accompanying such products and services, if any. Nothing herein should be construed as constituting an additional warranty. In particular, SAP SE or its affiliated companies have no obligation to pursue any course of business outlined in this document or any related presentation, or to develop or release any functionality mentioned therein. This document, or any related presentation, and SAP SE’s or its affiliated companies’ strategy and possible future developments, products, and/or platform directions and functionality are all subject to change and may be changed by SAP SE or its affiliated companies at any time for any reason without notice. The information in this document is not a commitment, promise, or legal obligation to deliver any material, code, or functionality. All forward-looking statements are subject to various risks and uncertainties that could cause actual results to differ materially from expectations. Readers are cautioned not to place undue reliance on these forward-looking statements, and they should not be relied upon in making purchasing decisions. SAP and other SAP products and services mentioned herein as well as their respective logos are trademarks or registered trademarks of SAP SE (or an SAP affiliate company) in Germany and other countries. All other product and service names mentioned are the trademarks of their respective companies. See www.sap.com/copyright for additional trademark information and notices.