Upgrade Using SAPJup
Use
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/assembled
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, for Development and Consolidation, SAPJup keeps the modified version of the SCs and deploys only the successors of not modified SCs, 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.
When the upgrade is to SAP NetWeaver 7.0 Enhancement Package 2, if replacement components are found for all modified SCs, SAPJup deploys these replacement components and all other successors of the not modified SAP components that are detected, in a single action. If SAPJup cannot find replacement components of the modified SCs (for example, because the SC was modified on a different NWDI server), it prompts the user to provide a valid replacement component.
For upgrades to SAP NetWeaver 7.0 Enhancement Package 2 or SAP NetWeaver 7.1 Enhancement Package 2, for Development and Consolidation systems, SAPJup deploys the new SAP version of the modified SCs it copies the modified SCs to the appropriate directories; for Test und Production, however, SAPJup gives the user (customer) the option to deploy the new SAP version of modified components or to choose to deploy the new modified SCs version which are successors of the detected modified SCs.
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 directory $(TRANSDIR)/EPS/in/assembled to directory $(TRANSDIR)/EPS/in. This enables JSPM and SAPJup to include these replacement components in follow-on tracks. If these replacement components are not modified further in follow-on tracks, JSPM and SAPJup can perform the deployment directly.
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 in 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 remain Application and cannot change its name from one version to the next.
2. Update your SLD with the current content that contains the software definition to which you want to upgrade.
3. Update CMS.
4. Define a new track with the software component versions you are going to upgrade to.
5. 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 will 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.
6. Assemble your version 1 in the old track and approve it for delivery to the next track.
7. Transport all sources from your old track to the new track.
8. Import the upgraded software component version(s) coming from SAP.
9. Perform the modification adjustment.
10. Upgrade the runtime system in the planned sequence.
More Information: