NWDI Cookbook for XSS.pdf

SAP® HORIZON

© 2007 SAP AGDietmar-Hopp-Allee 16D-69190 Walldorf

Title: NWDI Cookbook for XSSVersion: 1.2Date: 3/22/2007

of 27

Release: 1.0

NWDI Cookbook for XSSCustomersModification guide for XSS

History

Version Status Date1.1 Released to Cus-

tomers21-12-2006

1.2 Released to Cus-tomers

23-03-2007

Storage location of this document:

SAP®

© 2007 SAP AG Title: NWDI Cookbook for XSSVersion: 1.1Date: 3/22/2007

of 27

Contents1 Introduction.......................................................................................... 3

1.1 Motivation: why this guide? ........................................................................... 31.2 External documentation ................................................................................ 3

2 Overview of process............................................................................ 43 Initial Configuration of NWDI.............................................................. 7

3.1 Pre-requisites................................................................................................ 73.2 Step by step process .................................................................................... 7

3.2.1 Create a new Track using the CMS Landscape Configurator...................... 73.2.2 Add Software Components to track ............................................................ 83.2.3 Configure Runtime Systems in the track................................................... 123.2.4 Import Software Components into this track ............................................. 143.2.5 Keep a copy of this SP in a new track....................................................... 163.2.6 Import the Development Configuration...................................................... 17

4 Preparing for the first Support Package.......................................... 194.1 Close development in current track............................................................. 194.2 Create two copies of current track............................................................... 194.3 Apply new Support Package ....................................................................... 20

4.3.1 Switch runtime systems from old to new track .......................................... 204.3.2 Update Runtime Systems ......................................................................... 204.3.3 Download SP archives from service marketplace ..................................... 244.3.4 Check-In and import archives into new Tracks.......................................... 24

4.4 Import new Development Configuration ...................................................... 244.5 Re-Implement modifications in new Track................................................... 254.6 Close the old track ...................................................................................... 26

5 Importing subsequent Support Packages....................................... 27

SAP®


of 27

1 IntroductionBefore you start, make sure you have the latest version of this document. You can find the latestversion as attachment of note 872892. Furthermore please consider the related notes of thatnote.

This document describes the process of configuring the NetWeaver Development Infrastructure(NWDI) in a way that it supports the modification of sources delivered by XSS. XSS allows cus-tomer modifications for the following Software Components

- SAP ESS 600

- SAP MSS 600

- SAP PSS 600

- SAP ASR 600

- SAP PCUI_GP

For these software components the sources are included in the shipped sca files. The SoftwareComponent SAP PCUI_GP 600 is shipped with sources as well, not for the purpose of customermodifications, but to be able to apply fixes.

1.1 Motivation: why this guide?

When XSS source-code delivered by SAP is modified by customers, the import of the next sup-port package will result in conflicts (between the modified customer versions and the new SAPversions). While NWDI supports merging of source files through text-based merge tools, theWeb Dynpro elements that are in conflict require model-based merge tools (which can mergelogical objects spanning multiple files). These model-based merge tools are not yet available.

Hence, NWDI recommends an alternative process that will help customers avoid a situationwhere un-resolvable conflicts are created after the import of a Support Package. This guidedescribes this alternate process of configuring and using the NWDI landscape.

This guide will explain the track landscape and the process how to adjust the modifications dur-ing the update/upgrade process.

1.2 External documentation

This document refers to the following official documents delivered by SAP in the help portal( http://help.sap.com ) :

Administration manual of NWDI :

o http://help.sap.com/saphelp_nw2004s/helpdata/en/01/9c4940d1ba6913e10000000a1550b0/frameset.htm

http://help.sap.com

http://help.sap.com/saphelp_nw2004s/helpdata/en/01/9c4940d1ba6913e10

SAP®


of 27

2 Overview of processThe following pictures provide an overview of the process that must be followed. InitiallyERP2005 including the needed XSS components is installed on the runtime systems (RTS) viaSAPInst. When you start the modification of one or more XSS components, create two tracksand import the initial version of XSS (say SPx ) into both tracks, one of which is used for makingcustomer modifications. The second track has no runtime systems connected and is only usedto compare the versions later on.

When the first Support Package (SP) is applied, two new tracks are created, and the new SP isimported into both these tracks. In parallel the runtime systems are switched from the “SPx +modifications” track to the new “SPx + 1 + modification” track. Furthermore the runtime systemsare updated to the new support package using JSPM. Here you have the possibility to specify,that your system is under NWDI control, so that for the TEST and PROD runtime system JSPMwill interrupt the update procedure, if modified software components are deployed to these run-time systems. Using the Web Dynpro diff tool, you now can compare the states of different DCsand get an overview of the new changes contained in this SP and the changes you made to theprevious SP. Using this information, you now can re-implement your changes in one new track.After the changes are assembled to new software component, JSPM can be restarted on theTEST and PROD RTS to install the new SP with the modifications included.

JSPM handles the NWDI systems Development and Consolidation differently from the Test andProduction systems. For Development and Consolidation, JSPM copies the modified SCs to theappropriate directories; for Test und Production, however, JSPM refuses to deploy until re-placement components are made available during the assembly step.

SAP®


of 27

For more details on how to upgrade NWDI controlled runtime systems with JSPM please have alook at the standard documentation:

http://help.sap.com/saphelp_nw2004s/helpdata/en/43/26b84d6c823f66e10000000a11466f/frameset.htm

After you have applied the first SP in this manner, your landscape should look as shown below.

http://help.sap.com/saphelp_nw2004s/helpdata/en/43/26b84d6c823f66e10000000a11466f/fram

SAP®


of 27

For the next SP (and all subsequent ones), you have to create one new track, and repeat theprocess. This is depicted in the diagram below:

To give you a better overview of the main steps a table is shown below:

1 Install ERP 2005 including XSS components on all runtime systems (RTS)

2 Make modifications and transport them through your landscape

3 Start JSPM on TEST and PROD RTS to apply new SP JSPM will stop, if modified com-ponents are deployed on these runtime systems

4 Start JSPM on DEV RTS JSPM will not deploy modified components and copy them toEPS folder

5 Create new track and import sca files of new SP (from EPS folder and/or SPM if needed)

6 Compare the versions (of all tracks) using the Web Dynpro diff tool and re-implement thechanges

7 Activate automatic deployment will deploy the re-implemented modification to the DEVRTS

8 Transport and assemble the changes new sca files are created

9 Start JSPM on TEST and PROD RTS with new assembled SCA to install new SP includingmodifications

SAP®


of 27

3 Initial Configuration of NWDIThis chapter describes how to configure the NWDI in order to start modifying the XSS softwarecomponents. The steps in this chapter are relevant immediately after an installation (the nextchapter describes the steps needed to handle a Support Package upgrade).

For the purpose of illustration, this chapter assumes you are importing XSS SP3 (SP3 is the firstSupport Package level for which customer modifications are possible).

3.1 Pre-requisites

This chapter assumes that you have met the following pre-requisites:

Usage Type DI has been installed

NWDI Post-Installation: DI Template has been executed using the Template In-staller within NetWeaver Administrator

The System Landscape Directory (SLD) has the new (delta) content (of the Soft-ware Components delivered with this release). Please download the latest CIMContent (Delta) from the Service Marketplace, import it into your SLD repository(http://<sldhost>:<port>/sld - Administration - Content: Import) and update the NWDICMS Configuration (CMS Landscape Configurator – Domain Data Tab – UpdateCMS).

3.2 Step by step process

3.2.1 Create a new Track using the CMS Landscape Configurator

On the “Track Data” tab of the Landscape Configurator, enter the general data with your TrackID, Track Name and Track Description as shown below:

SAP®


of 27

Substitute the URLs with the appropriate ones from your landscape.

In the following sections of this document, this track will be referred to as “SP3Mod” (since thiswill contain your modifications).

3.2.2 Add Software Components to track

On the same “Track Data” tab, add the Software Components as “Software Components forDevelopment” which you want to modify. The following XSS Software Components are shippedwith sources, which mean they are allowed to be modified:

SAP_ESS

SAP_MSS

SAP_PSS

SAP_ASR

(SAP PCUI_GP)

The following screenshot shows the dialog when adding a software component for develop-ment. Here the list of all components is filtered for SAP_ESS. Choose the correct release (here:600 for ERP 2005) with the Package Type “Source and Archive” and click the “Add” button.

After this step, a new entry is shown in the list of software components for development and itwill look similar as shown below. As mentioned in the beginning, if you do not plan to modify allsoftware components, you should only add the ones that you are going to change. In the exam-ple below all four XSS components are added.

SAP®


of 27

When adding a software component for development, CMS will retrieve the SLD informationand display a list of required software components as shown below. This list is usually not thelist of software component that you need to import into the track. The reason for this is that youonly need to import the SCs which are required to build the XSS SCs but CMS aldo adds theSCs which must be deployed to the runtime system. Those SCs should not be imported into thetrack, because they are deployed to the runtime system using SAPInst or JSPM. In the screen-shot below for the SAP_MSS component a list of 19 required software components is displayed.This list is much longer because in fact you need only 5 SCs within your Buildspace. The correctlist of required software components is explained in the next chapter (3.2.2.1).

Hint: In the screenshot above you see the right column “Exclude from Deployment”. This columnis part of CMS since NW 2004s SPS5 Patch1. You can check the checkboxes to exclude singlesoftware components from deployment. XSS components (like SAP MSS or SAP PCUI_GP)that are defined as required software components can be excluded from deployment in the casewhen they are already deployed (via SAPInst or JSPM). All other NetWeaver SCAs include aflag so that the deployment via NWDI is automatically switched off. That leads to the behaviourthat they will not be deployed during the NWDI transport, because they are already deployed onthe runtime systems during the NetWeaver installation.

SAP®


of 27

Hint: For some NetWeaver components (especially the PORTAL sca files) the flag is not set inthe current release. This will be fixed for the NetWeaver release SPS8. For all previous Net-Weaver releases it is recommended to check the “Exclude from Deployment” checkbox (at leastfor the Portal sca files) to avoid their deployment.

Save your changes by clicking on the “Save” button. When you are asked to perform a RestoreSystem State in the Transport Studio, choose the button “Save and Restore”.

3.2.2.1 Required Software Components

When you added the Software Components for Development, the required software componentlist is updated. This list in the Landscape Configurator shows more entries as software compo-nents are needed to be imported into the track. The list is longer because it shows all transitivedependencies.

To know which software components are direct dependencies and have to be imported into thetrack, you should have a look at the SLD software component dependencies for the specificSoftware Component that you plan to modify.

The following screenshot shows the “BuildTime Dependencies” in the SLD software componentcatalog for the software component SAP ESS 600.

SAP®


of 27

Another possibility to retrieve the list of required software components is to have a look in theXML file. Therefore click the “View/Edit XML Content” button.

Within the XML file you see a dependencies tag, which lists all used compartments. These arethe software components that are needed as required software components to build the se-lected software component later on during the modification process.

For the XSS software components (ESS, MSS, PSS, ASR) the required software componentsthat have to be checked in and imported into the track are listed below:

1) SAP ESS 600: DI BUILD TOOL 7.00 EP BUILD TOOL 7.00 SAP J2EE ENGINE 7.00 SAP JAVA TECH SERVICES 7.00 SAP PCUI GP 600

2) SAP MSS 600: DI BUILD TOOL 7.00 EP BUILD TOOL 7.00 SAP J2EE ENGINE 7.00 SAP JAVA TECH SERVICES 7.00 SAP PCUI GP 600

SAP®


of 27

3) SAP PSS 600 CAF EU 7.00 DI BUILD TOOL 7.00 EP BUILD TOOL 7.00 SAP J2EE ENGINE 7.00 SAP JAVA TECH SERVICES 7.00 SAP PCUI GP 600

4) SAP ASR 600: DI BUILD TOOL 7.00 EP BUILD TOOL 7.00 SAP J2EE ENGINE 7.00 SAP JAVA TECH SERVICES 7.00 SAP PCUI GP 600 SAP MSS 600

In the case you need to apply fixes to the software component SAP PCUI_GP, the requiredsoftware components are listed below:

5) SAP PCUI_GP 600: CAF EU 7.00 DI BUILD TOOL 7.00 EP BUILD TOOL 7.00 PORTAL 7.00 PORTAL CORE SERVICES 7.00 PORTAL FRAMEWORK 7.00 PORTAL WEB DYNPRO 7.00 SAP J2EE ENGINE 7.00 SAP JAVA TECH SERVICES 7.00

3.2.3 Configure Runtime Systems in the track

Configure your runtime systems as described in the following topic in the help portal:

http://help.sap.com/saphelp_nw2004s/helpdata/en/5a/5c9dbe413949f6ab75331c7ddc2f5a/frameset.htm

Here it is assumed, that you are using a NWDI server release NW 2004s SP5 or higher.

As of SP5, you also need to specify connection data for SAP WebAS Java for the runtime sys-tem (URL for the server, user and password) as shown in the screenshot below. Please have alook in the standard documentation for more details.

The new input fields for J2EE are needed to update the system information of the runtime sys-tem. If these fields are empty, JSPM is not able to recognize that software components havebeen modified and will overwrite these components during the next SP update.

http://help.sap.com/saphelp_nw2004s/helpdata/en/5a/5c9dbe413949f6ab75331c7ddc2f5a/fram

SAP®


of 27

When configuring the track with the J2EE Engine fields, the system information is updated (seethe example below, where the SAP_MSS component has a new Location).

The Location of the software components that are added as „Software Components for Devel-opment“ is updated when saving the track with the new Location which has the following syntax:<Domainname>_<Trackid>_D (here: XLD_MSS_D).

But please be aware of the fact, that the location update is not enough to let JSPM stop theupgrade process. A deployment of the modified DCs or SCs is needed to let JSPM recognize,that the customer has changed the coding. Therefore you can start with the track configurationas long as you do not deploy your modifications, you can upgrade your runtime systems withoutany impact.

SAP®


of 27

3.2.4 Import Software Components into this track

3.2.4.1 Download Archives

The Software Component archives (.sca files) for the corresponding Support Package levelmust be downloaded from the Service Marketplace ( http://service.sap.com/patches ) andplaced into the “inbox” folder of the CMS. (The “inbox” folder can be found under the followingpath: “<CMS Transport Directory>\CMS\inbox”, where the <CMS Transport Directory> isspecified in the “Domain Data” tab of the CMS Landscape Configurator).

The following .sca files must be placed into the CMS inbox folder. If you do not modify all 4software components (ESS, MSS; PSS; ASR), have a look at the dependencies list above andimport only the ones listed there. Please do not forget to import the sca file of the software com-ponent that you plan to modify.

http://service.sap.com/patches

SAP®


of 27

Required Software Components (without sources):o EPBUILDTXX_0-10003786.sca ( EP BUILD TOOL 7.00)o SAPBUILDTXX_1-10003479.sca ( DI BUILD TOOL 7.00)o SAPJEEXX_0-10003469.sca ( SAP J2EE ENGINE 7.00)o SAPJTECHSXX_0-10003467.sca ( SAP JAVA TECH SERVICES 7.00)o SAPEUXX_0-10003026.SCA ( CAF EU 7.00)o EPPSERVXX_0-10003474.sca ( PORATL 7.00)o EPBCXX_0-10003473.sca ( PORTAL CORE SERVICES 7.00)o EPBC2 XX_0-10003489.sca ( PORTAL FRAMEWORK 7.00)o EPWDCXX_0-10003557.sca ( PORTAL WEB DYNPRO 7.00)

XSS Software Components for Development (or Required) (including sources)o SAPESSXX_0-20000512.sca ( SAP ESS 600)o SAPPSSXX_0-20001217.sca ( SAP PSS 600)o SAPASRXX_0-20001216.sca ( SAP ASR 600)o SAPPCUIGPXX_0-20001215.sca ( SAP PCUI GP 600)o SAPMSSXX_0-20000503.sca ( SAP MSS 600)

(Note: The names of .sca files could be different – they may include version numbers, vendorname, etc )

3.2.4.2 Check-In archives

In the “Check-In” tab of the CMS Transport Studio CMS perform a “Check-In”: select the soft-ware components which you want to modify with its dependent components and click on the“Check-In” button.

SAP®


of 27

3.2.4.3 Import the checked in archives into the Development system

In the “Development” tab, select the checked-in components and click the “Import” button.

This import will run for several hours (if all the components are selected together). After theimport was successful the “State” (field on the extreme right in the picture above) will be shownas “Import Finished”. Please check the logs in any case.

3.2.4.4 Import the checked in archives into the Consolidation system

Repeat the above step in the “Consolidation” tab.

3.2.5 Keep a copy of this SP in a new track

In parallel to your development in the track created in the above steps, you must create a newtrack and import the same SCAs into that track. This new track can be created as a copy of thefirst track:

In the CMS Landscape Configurator, select your current track and choose the “Save as…” but-ton on the ‘Track Data’ tab. This will bring up the following popup:

SAP®


of 27

Give a new name (preferably denoting the Support Package number) and save the copied trackdefinition. Note that this copy only copies the track definition, and not its contents. Hence, youwill now have to import the same set of SCAs into this track.

Although this track will only be used when the next SP is imported, it is recommended to becreated earlier, due to the long duration of the import process.

At this point, your landscape should look as follows:

The track created in this step will be referred in this document as the “SP3” track.

3.2.6 Import the Development Configuration

Now that the servers in the landscape have been configured, development can begin. The firststep on the client side (using the NetWeaver Developer Studio) is to import the DevelopmentConfiguration which corresponds to the “Development” system of this track that has been cre-ated.

An example is shown below:

SAP®


of 27

Modifications to the XSS Development Components (SAP_ESS, SAP_MSS, SAP-PSS or SAP-ASR) can now proceed under this Development Configuration. The development process andthe deployment of the modifications to the RTS is describes in the NWDI documentation.

SAP® HORIZON

© 2007 SAP AGDietmar-Hopp-Allee 16D-69190 Walldorf

Title: NWDI Cookbook for XSSVersion: 1.2Date: 3/22/2007

of 27

4 Preparing for the first Support PackageThis chapter describes the steps necessary (from the landscape and infrastructure point ofview) to move to a new Support Package for XSS components delivered by SAP. For the pur-pose of illustration, the new SP is denoted as “SP4”.

4.1 Close development in current track

Before a new Support Package can be imported, it is important to close all development in thecurrent track. This involves the following steps:

Using NetWeaver Developer Studio,

o Check-in all open activities, and activate them.

o Release all unreleased activities (This will queue them for import into the Con-solidation system)

From the CMS Transport Studio, import the released activities into the Consolidationsystem

o The released activities will appear in the Import Queue on the Consolidation tabof the CMS Transport Studio.

4.2 Create two copies of current track

Create two copies of the track you are using for modification. The procedure to copy a trackdefinition is described in section 3.2.5

Name one of them “SP4” (this will be used only for comparison) and the other “SP4Mod” (thiswill contain your modifications). The names can be suitably adjusted based on the SP you areimporting.

The landscape after this step should look as shown below (note the two new tracks):

SAP®


of 27

4.3 Apply new Support Package

4.3.1 Switch runtime systems from old to new track

The runtime systems that were associated with the old track (“SP3Mod”, containing your modifi-cations) must now be connected to the new track (“SP4Mod”). For details on how to configureruntime systems, refer to the following section in the help portal:

http://help.sap.com/saphelp_nw2004s/helpdata/en/5a/5c9dbe413949f6ab75331c7ddc2f5a/frameset.htm

and

http://help.sap.com/saphelp_nw2004s/helpdata/en/43/26b84d6c823f66e10000000a11466f/frameset.htm.

4.3.2 Update Runtime Systems

4.3.2.1 Update Runtime System via JSPM

Since NetWeaver 2004s JSPM is the tool to apply a new Support Package Stack or a singleSupport Package. Therefore it is recommended to use JSPM to update the NWDI configuredRuntime Systems to a new Support Package level.

Please have a look at the XSS documentation to see if the update to a new Support Packagelevel of the XSS components requires the update of the NetWeaver stack as well.

When you followed the process so far, you will have the following situation (here in the examplewe use SP3 and SP4, but the process will be the same for all future releases). As you con-nected the runtime systems to your SP3Mod track, your modifications are deployed to this run-time systems. That means on the runtime systems SP3 with modifications is deployed.

Now you want to upgrade to the next SP level (here: SP4). To upgrade the runtime system theupgrade tool JSPM is used. Normally you would override the current SP3 with modification statewith the new SP4 release. With JSPM and NWDI you have now the possibility to track and ad-just your changes during the upgrade process. Therefore you select the option, that your run-time system is a system under NWDI control. Please have a look at the screenshot below. Inthat screenshot the NWDI system role DEV is selected, to update the runtime system that isconnected the NWDI DEV system.

http://help.sap.com/saphelp_nw2004s/helpdata/en/5a/5c9dbe413949f6ab75331c7ddc2f5a/fram

http://help.sap.com/saphelp_nw2004s/helpdata/en/43/26b84d6c823f66e10000000a11466f/fram

SAP®


of 27

Specifying that your runtime system is under NWDI control leads to the behavior that JSPM willrecognize which component is managed by the NWDI. Choosing the Target SP Level as an“NWDI controlled” level will lead to a warning (see the screenshots below).

SAP®


of 27

Here in this example MSS is recognized as modified component and will only be transported tothe EPS transport directory without deployment.

Clicking the Next button leads to the following screenshot, where SAP MSS is not deployed, butthe dependent component SAP PCUIGP (which is not modified) is deployed.

SAP®


of 27

Hint: Please be aware of the fact, that JSPM will not stop the deployment process, if the modifi-cations are not deployed to the runtime system. Pure track configuration leads to an update ofthe system information provider, but that is not enough for the JSPM upgrade tool to stop theupgrade process.

JSPM deploys only the unmodified software components to the runtime system and copies themodified SCs and their dependent SCs to the directory$(TRANSDIR)/EPS/in/CMS$(HOSTNAME)$(SYSTEMNAME) of the runtime system file system(here: D:\usr\sap\trans\EPS\in\CMSWDFN00109097ASR1) or of the shared transport directory.

If you do not work with a globally shared transport directory, copy these SCA files to your NWDIserver file system to be able to check them into the NWDI. Usually you would place them underthe “<CMS Transport Directory>\CMS\inbox” folder or you can create an additional folderhere. Within the Check-In tab of the CMS Transport Studio, you can configure the Check-Infolder.

4.3.2.2 Update Runtime System via NWDI

In the case where you plan to update only the XSS components and not the whole NetWeaverstack, you can skip the JSPM upgrade procedure and check the new sca files into the NWDItrack directly as described below.

SAP®


of 27

4.3.3 Download SP archives from service marketplace

Usually not all dependent sca files are copied via JSPM to the specified EPS folder. Thereforeplease make sure that all required sca files for the new Support Pack level are copied to theCMS inbox folder. As explained in section 3.2.4.1, you can download the .sca files released forthe new Support Package from the service marketplace and place it into the CMS inbox direc-tory.

4.3.4 Check-In and import archives into new Tracks

In the new Tracks, perform the Check-In and Import steps as described in sections 3.2.4.2 ,3.2.4.3 and 3.2.4.4

After you have copied the SCAs to the CMS inbox, you can check these SCs into the NWDI.Please make sure, that the runtime system is already configured for the DEV system beforeimporting the new SCAs into the development system for the track.

To adjust the modifications you have to import all the needed Development Configurations tocompare the coding. This is explained in the next chapter.

4.4 Import new Development Configuration

So far, the only development configuration imported was the one for the track containing theoriginal modifications (“SP3Mod”). Now, for the purpose of comparison, we need two additionaldevelopment configurations. This can be seen from the diagram below which depicts the threetracks (or states) that need to be compared:

SAP®


of 27

Further, you need an additional development configuration to re-implement you changes in thenew SP.

Thus, you need to import development configurations corresponding to the “SP3”, “SP4” and“SP4Mod” tracks.

4.5 Re-Implement modifications in new Track

The “SP4Mod” track, which now contains the latest sources from SAP (corresponding to theimported Support Package), must be used as a base for re-implementing customer modifica-tions made in the previous track (“SP3Mod”).

The following tools offer help in this re-implementation task:

Meta-Data Comparison tool for WebDynpro projects

Using this tool you can compare two WebDynpro projects and examine the differencesin the different logical entities (like Applications, Components, Models etc).

To examine the differences between a DC modified by you and the same DC deliveredby SAP, the steps given below can be followed:

o In the ‘Inactive DCs’ view of the Development Configurations perspective, se-lect your DC in the configuration corresponding to the “SP3Mod” track, andcreate a project for this DC.

o Next select the same DC in the configuration corresponding to the “SP3” track,and create a project for this DC.

o Shift to the WebDynpro Perspective, and open the ‘Navigator’ view. There youwill see two projects you just created.

o Select both projects and choose “Compare Metadata” from the context menu.This will open a dialog box that displays the differences between the two DCs.For more details about this tool, refer to the following documents on the SAPHelp Portal :

http://help.sap.com/saphelp_nw2004s/helpdata/en/c4/2910411db1d349e10000000a1550b0/frameset.htm

http://help.sap.com/saphelp_nw2004s/helpdata/en/6e/0e184188b4f16fe10000000a1550b0/frameset.htm

Repeat the above steps to examine the changes delivered by SAP in the new supportpackage by performing a “compare” operation between DCs in “SP3” and “SP4” tracks.

These two sets of comparisons will give you an overview of which modifications madeby you (in “SP3Mod” ) are still relevant in the new SP (For instance, a change made byyou to the SP3 state may have become part of the standard in SP4, and hence it neednot be a part of the re-implementation steps.)

http://help.sap.com/saphelp_nw2004s/helpdata/en/c4/29

http://help.sap.com/saphelp_nw2004s/helpdata/en/6e/0e

SAP®


of 27

Copy & Paste functionality in WebDynpro

A number of WebDynpro elements can be copied and pasted from one DC to another.So if your modifications include a new Application, Component or a Data-Type, you cancopy it from your DC (from the development configuration corresponding to the oldtrack) and paste it on to the new DC (in the development configuration corresponding tothe new track).

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

If replacement components are found for all modified SCs, JSPM deploys the modified SCs,together with their dependent SCs for the test and production system, in case they are config-ured.

4.6 Close the old track

After all the re-implementation has been completed and your tests on the runtime systems con-nected to the new track have been successful, you can close the old track (“SP3Mod”) by fol-lowing the guidelines given below:

Reset permissions such that your developers do not have edit permissions on the DTRworkspaces of the old track. This will ensure that no new modification can be attemptedin the old track.

In the NetWeaver Developer Studio, remove the Development Configuration that corre-sponds to the old track.

At this point, your landscape should like this:

SAP®


of 27

5 Importing subsequent Support PackagesImporting subsequent SPs can be done using a process similar to the one described in the pre-vious chapter. The only difference is that instead of creating two new tracks (as described insection 4.2 ), you only need one new track, as depicted in the landscape diagram below:

Thus, you can re-use one of the two older tracks containing the earlier SP to import the latestSP, as shown above.

NWDI Cookbook for XSS.pdf

Documents

Transcript of NWDI Cookbook for XSS.pdf