Show TOC

Upgrade Using SAPJupLocate this document in the navigation structure

Context

Note

Software Update Manager (SUM) replaces SAPJup for upgrades to SAP NetWeaver 7.3 and higher.

SUM is part of the Software Logistics Toolset delivery and available for download at: http://service.sap.com/swdcInformation published on SAP site.

You can find its documentation on the SAP Service Marketplace at: http://service.sap.com/sltoolsetInformation published on SAP site.

If you use SAPJup to update a Java runtime system, SAPJup interrupts the import process and queries whether the runtime system is integrated into a NWDI landscape. Using SAPJup you can import only the unmodified SCs to the runtime system and copy all SCA files from the inbox directory to the following directory:

$(TRANSDIR)/EPS/in/CMS$(HOSTNAME)$(SYSTEMNAME)

From this directory, you check these SCs into the NWDI, import them into the development system for the track, and adjust the modifications.

Transport the adjusted modifications through the track and perform the assembly step. After the SC has been assembled successfully, a new SCA is available as a replacement component for the SAP standard in directory $(TRANSDIR)/EPS/in/assemble d

If replacement components are found for all modified SCs, SAPJup deploys the modified SCs, together with their dependent SCs for the test and production system.

When upgrading to SAP NetWeaver 7.0 Enhancement Package 1 versions SAPJup handles the NWDI systems Development and Consolidation differently from the Test and Production systems.

For Development and Consolidation , SAPJup keeps the modified version of the SCs and deploys only the successors of SCs that are not modified, and SAPJup copies the modified SCs to the appropriate directories; for Test and Production , however, SAPJup refuses to deploy until replacement components are made available.

As of SAP NetWeaver 7.1 EHP1 it is no longer allowed to configure a Runtime system on the same host as Change Management Service (CMS). For more information about the CMS restrictions, see SAP Note 754143 Information published on SAP site.

Follow-On Tracks

If you have modified SAP software components in track A and created new modified replacement components as described, you must copy these replacement components from the directory $(TRANSDIR)/EPS/in/assembled to the directory $(TRANSDIR)/EPS/in. This enables SUM (or JSPM in previous releases) and SAPJup to include these replacement components in follow-on tracks. If these replacement components are not modified further in follow-on tracks, SUM (or JSPM in previous releases) and SAPJup can perform the deployment directly.

Note

Modified software components can be detected and replaced both for individual Support Packages and for Support Package stacks, as well as for upgrades.

Prerequisites

During a standard upgrade, the SAP-delivered SCs would overwrite any modifications that you have made to those SCs. If you have developed modifications and want to keep them with the upgrade, NWDI and SAPJup need to work together to ensure a consistent Java runtime system after the upgrade. This means you need to perform the following actions, in addition to the deployment of the SCs in the runtime systems with the NWDI:

  • Import the source code files of the SCs into the Design Time Repository (DTR).

  • Start the required builds in the Component Build Service (CBS).

  • Deploy the modified development components in the relevant runtime systems.

  • Update the information about the modified SCs in the relevant runtime systems.

Procedure

  1. Create a new version of your developed SCs in SLD with new dependencies. For example, if an SC Application version 1.00 depends on DI BUILD TOOL 6.40, create a version 2.00 of Application that depends on DI BUILD TOOL 7.00). Your SC might also require new SC dependencies (EPBC, KM, BASETABLES). See the documentation for the specific applications for details.

    Note that the Software Component Name must not change for version 1.00 and version 2.00. Otherwise, the track connection will prevent the import into the new track. In our example, Application must stay Application and cannot change its name from one version to the next.

  2. Update CMS.
  3. Define a new track in CMS using the newer versions.
  4. Create a track connection of type Transport from the old track to the new track.

    Note that the package type for your software components needs to be set to Source or Source and Archive . This setting defines that the source code for your developed SCs is packed into the SCA during assembly. Otherwise, you shall not be able to change the sources in the new track. If you do not want your customers to receive the source code for your SCs, you need to define an additional track with package type Archive through which you can route your deliveries, so that the source code is separated from your delivered product. For more information, see Package Types .

  5. Assemble your version 1 in the old track and approve it for delivery to the next track.
  6. Transport all sources from your old track to the new track.
  7. Import new archives to trigger the rebuild.

Next Steps

Starting the Upgrade Process

Adjusting Modifications with the NWDI

Upgrading Follow-On Systems