Sappress Sap Change and Transport Management

2564.book Seite 3 Mittwoch, 8.
März 2006 9:04 09
Achim Kösegi, Rainer Nerding
SAP® Change and

Transport Management
2564.book Seite 5 Mittwoch, 8. März 2006 9:04 09
Foreword to the series of books

At SAP AG, our first priority is to ensure that the SAP software solutions in
your enterprise run successfully and at a minimal cost. This “Lowest Cost of
Ownership“ is achieved with fast and efficient implementation, together with
optimal and dependable operation. SAP Active Global Support is actively and
consistently there to help you, with the new SAP Solution Management strat-
egy. Throughout the entire lifecycle of a solution, SAP offers customers all
necessary services, first-class support, a suitable infrastructure, and the rele-
vant know-how. The new strategy is backed up by three powerful support
programs: Safeguarding, or, in other words, risk management; Solution Man-
agement Optimization, which aims to optimize the customer's IT solution; and
Empowering, which ensures a targeted, effective transfer of knowledge from
SAP to the customer.
The imparting of knowledge is also one of the key aims of this book—part of
the line of SAP Technical Support Guides. This series gives you a detailed over-
view of technical aspects and concepts for managing SAP software solutions.
The topics dealt with in these books range from a technical implementation
project to running a software system and the relevant database system.
Whether you are new to SAP system management or wish to gain further
qualifications, you will benefit from the wealth of practical experience and
first-hand information contained in these books. With this line of books, SAP
also endeavors to help prepare you for qualification as a “Certified Technical
Consultant“. Please note, however: These books cannot replace, nor do they
attempt to replace, personal experience gained from working with the various
SAP solutions! Rather, the authors offer suggestions to help in your day-to-
day work with the software. Innovation in SAP solutions always brings with it
new challenges and solutions for system management. The demands made
on the customer's own or external support organizations also increase. The
expertise and knowledge of these organizations can be a great help in avoid-
ing problems when using the software. Therefore, one of the core tasks of this
series of books is to teach problem-solving skills.
Even in this Internet age, books prove to be an ideal medium for imparting
knowledge in a compact form. Furthermore, their content complements the
new service and support platform, the SAP Solution Manager, and other new
Foreword to the series of books 5

services offered by SAP. The series provides background knowledge on the oper-
ation and functioning of new SAP solutions and contributes to customer satisfac-
tion.
Gerhard Oswald
Member of the executive board of SAP AG
Dr. Uwe Hommel

Senior Vice President at SAP AG
SAP Active Global Support
Rot, March 2006

Contents
Foreword to the series of books 5
Introduction 17
How This Book Is Organized 21
Part 1 The Big Picture
1 SAP ECC Architecture and Data Components 25
1.1 Client/Server Architecture in Brief ................................................................ 26

1.2 The SAP ECC Database ................................................................................... 28
1.2.1 The Repository ................................................................................... 29
1.2.2 Customer Data ................................................................................... 29
1.2.3 Technical Implementation ................................................................ 30
1.3 SAP ECC Clients ............................................................................................... 30
1.3.1 Technical Implementation ................................................................ 31
1.3.2 Data Components ............................................................................. 32
1.3.3 Standard SAP ECC Clients ................................................................ 34
1.4 Questions .......................................................................................................... 35
2 Realizing Business Processes in SAP ECC 37
2.1 Customizing ...................................................................................................... 38

2.1.1 SAP ECC Reference Model ............................................................... 39
2.1.2 Implementation Guide (IMG) .......................................................... 40
2.2 Development .................................................................................................... 44
2.2.1 ABAP Workbench .............................................................................. 44
2.2.2 Customer-Developed Repository Objects ..................................... 45
2.2.3 Enhancements .................................................................................... 46
2.2.4 Modifications ..................................................................................... 48
2.3 Questions .......................................................................................................... 51
Contents 7
3 The mySAP ERP System Landscape 53
3.1 SAP ECC Client Roles ...................................................................................... 53

3.1.1 Critical Client Roles ........................................................................... 54
3.1.2 Additional Client Roles ..................................................................... 56
3.2 Defining an SAP Client .................................................................................... 59
3.2.1 Client-Dependent Change Options ................................................. 60
3.2.2 Client-Independent Change Options .............................................. 61
3.3 Multiple Clients in an SAP ECC System ....................................................... 63
3.3.1 Functional Limitations ....................................................................... 63
3.3.2 Technical Limitations ......................................................................... 64
3.3.3 Protective Measures for Multiple-Client Operations .................... 65
3.4 The SAP Three-System Landscape ................................................................. 65
3.4.1 Standard SAP Systems ....................................................................... 66
3.4.2 Distribution of Client Roles .............................................................. 66
3.5 Alternative System Landscapes ..................................................................... 68
3.5.1 One-System Landscape ..................................................................... 69
3.5.2 Two-System Landscape ..................................................................... 70
3.5.3 Four-System Landscape .................................................................... 71
3.6 Complex System Landscapes ......................................................................... 72
3.6.1 Multiple Production System Landscape .......................................... 72
3.6.2 Phased System Landscape ................................................................ 76
3.6.3 Global System Landscape ................................................................. 81
3.7 Questions .......................................................................................................... 84
4 Managing Changes and Data in a mySAP ERP

System Landscape 87
4.1 Transporting Customizing and Development Changes ............................. 87

4.1.1 Change Requests and Tasks .............................................................. 88
4.1.2 Promoting Changes ........................................................................... 91
4.1.3 Importing Changes ............................................................................ 94
4.1.4 Change and Transport System (CTS) ............................................... 98
4.2 Transferring Data .............................................................................................. 99
4.2.1 Master Data ........................................................................................ 101
4.2.2 Transaction Data ................................................................................ 103
4.2.3 User Master Data ............................................................................... 106
4.3 Copying SAP ECC Systems and Clients ........................................................ 107
4.3.1 System Copy ....................................................................................... 108
4.3.2 Client Copy ......................................................................................... 109
4.4 Questions .......................................................................................................... 109
8 Contents
5 Setting Up a System Landscape 111
5.1 Setting Up the Development System ........................................................... 111

5.1.1 Post-Installation Processing .............................................................. 111
5.1.2 Setting Up the Transport Management System (TMS) ................. 112
5.1.3 Creating Clients ................................................................................. 113
5.2 Setting Up the Quality Assurance and Production Systems .................... 117
5.2.1 After Installing the New SAP System .............................................. 117
5.2.2 Change Request Strategy .................................................................. 119
5.2.3 Quality Assurance Procedure of the TMS ....................................... 121
5.2.4 Client Copy Strategy ......................................................................... 123
5.3 System Copy Strategy ..................................................................................... 127
5.3.1 System Copy of Quality Assurance ................................................. 128
5.4 Release Considerations ................................................................................... 131
5.5 Questions .......................................................................................................... 134
6 Maintaining a System Landscape 135
6.1 Implementation Plan ....................................................................................... 135

6.2 Managing Implementation Projects ............................................................. 137
6.2.1 Implementation Phases .................................................................... 137
6.2.2 Managing Change Requests ............................................................. 139
6.2.3 Unit Testing ........................................................................................ 142
6.2.4 Releasing and Exporting Change Requests .................................... 144
6.3 Transport Management ................................................................................... 145
6.3.1 Exporting Change Requests ............................................................. 146
6.3.2 Importing Change Requests ............................................................. 146
6.3.3 Post-Import Issues ............................................................................. 153
6.3.4 Importing into the Production System ........................................... 155
6.4 Business Validation .......................................................................................... 161
6.4.1 Testing Procedures ............................................................................ 162
6.4.2 SAP Testing Tools .............................................................................. 164
6.5 Support for the SAP Standard ........................................................................ 165
6.5.1 Support for an SAP Release .............................................................. 166
6.5.2 Release Upgrades .............................................................................. 169
6.6 Questions .......................................................................................................... 171
Contents 9
Part 2 Technical Tasks
7 Transport Setup Activities at Installation 175
7.1 Specifying the System ID (SID) ...................................................................... 175

7.2 Setting Up the Transport Directory .............................................................. 176
7.2.1 One or Many Transport Directories? .............................................. 177
7.2.2 Transport Directory Structure .......................................................... 179
7.2.3 Procedure ........................................................................................... 180
7.3 Configuring the Transport Profile .................................................................. 185
7.3.1 Transport Profile in R/3 Release 4.0 ................................................ 186
7.3.2 Transport Profile in R/3 Release 4.5 ................................................ 187
7.3.3 Profile Syntax ...................................................................................... 189
7.3.4 Required Parameters ......................................................................... 192
7.4 Activities within SAP ECC ............................................................................... 198
7.4.1 Initializing the Change and Transport Organizer ........................... 199
7.4.2 Setting the Global System Change Option ..................................... 200
7.4.3 Verifying Required Background Jobs ............................................... 203
7.4.4 Verifying Background Work Processes ............................................ 204
7.5 Questions .......................................................................................................... 204
8 Setting Up the TMS 207
8.1 TMS Terminology and Concepts .................................................................... 207

8.1.1 Transport Domain .............................................................................. 208
8.1.2 Transport Routes ................................................................................ 211
8.2 Setting Up the Transport Domain ................................................................. 213
8.2.1 Setting Up the Domain Controller .................................................. 214
8.2.2 Extending the Transport Domain .................................................... 216
8.2.3 Backup Domain Controller ............................................................... 223
8.2.4 Verifying the Transport Domain ...................................................... 224
8.2.5 Technical Aspects of the Configuration Process ............................ 228
8.3 Configuring Transport Routes ........................................................................ 233
8.3.1 Procedure ........................................................................................... 234
8.3.2 Extending and Changing a Transport Route Configuration .......... 237
8.3.3 Extended Transport Control ............................................................. 244
8.4 Verifying the System Landscape Setup ........................................................ 249
8.4.1 Verifying the TMS Setup ................................................................... 250
8.4.2 Verifying the Transport Route Configuration ................................. 250
8.4.3 The Alert Monitor .............................................................................. 251
8.5 Questions .......................................................................................................... 253
10 Contents
9 Client Tools 255
9.1 Creating a Client ............................................................................................... 255

9.1.1 Client Entries ...................................................................................... 256
9.1.2 Client Settings .................................................................................... 257
9.2 Providing a Client with Data .......................................................................... 261
9.2.1 Selecting a Client Copy Tool ............................................................ 261
9.2.2 Using Client Copy Profiles to Select Data ...................................... 263
9.2.3 Local and Remote Client Copy ........................................................ 266
9.2.4 Client Transport ................................................................................. 267
9.2.5 Monitoring and Verifying a Client Copy ......................................... 274
9.2.6 Considerations for a Client Copy .................................................... 278
9.3 Deleting a Client .............................................................................................. 282
9.4 Table Logging for a Client ............................................................................... 283
9.4.1 Resource Constraints ........................................................................ 284
9.4.2 Activating Table Logging ................................................................... 284
9.4.3 Viewing Table Logs ............................................................................ 286
9.4.4 Removing Change Documents ........................................................ 289
9.5 Authorization Profiles for Client Tools ......................................................... 290
9.6 Questions .......................................................................................................... 292
Part 3 Tools
10 Managing Development Changes 295
10.1 Development Prerequisites ............................................................................ 295

10.1.1 SSCR Registration of Developers ..................................................... 295
10.1.2 Packages ............................................................................................. 296
10.2 Workbench Change Requests ........................................................................ 307
10.2.1 Transportable Change Request ........................................................ 308
10.2.2 Local Change Request ....................................................................... 308
10.2.3 Tasks .................................................................................................... 309
10.2.4 Viewing Workbench Change Requests ........................................... 310
10.2.5 Creating a Workbench Change Request ......................................... 311
10.2.6 Recording Repository Objects to Change Requests ...................... 314
10.2.7 Object List of Change Requests and Tasks ..................................... 316
10.3 Repairs and Modifications .............................................................................. 321
10.3.1 Setting a Repair Flag .......................................................................... 321
10.3.2 Modification Assistant ...................................................................... 322
10.3.3 Modification Browser ........................................................................ 323
10.3.4 Modifications ..................................................................................... 324
10.4 The Object Directory ....................................................................................... 326
10.4.1 Object Attributes ............................................................................... 328
Contents 11
10.4.2 Displaying or Changing an Object Directory Entry ....................... 328

10.4.3 Transporting Objects Using the Transport Organizer
(Extended View) ................................................................................ 330
10.5 Questions .......................................................................................................... 333
11 Managing Customizing Changes 335
11.1 Customizing Prerequisites .............................................................................. 335

11.1.1 Setting Up Project IMGs ................................................................... 336
11.2 Customizing Change Requests ...................................................................... 338
11.2.1 Viewing Customizing Change Requests .......................................... 338
11.2.2 Creating Customizing Change Requests ......................................... 340
11.2.3 Customizing in Project IMGs ............................................................ 342
11.2.4 Recording Customizing Changes ..................................................... 344
11.2.5 Object Lists for Customizing Change Requests ............................. 347
11.2.6 Identifying Change Requests with the Same Object ..................... 350
11.3 Nonstandard Customizing Activities ............................................................ 351
11.3.1 Client-Independent Customizing Activities .................................... 352
11.3.2 Manual Transports and Other Transport Types ............................. 355
11.3.3 Customizing in a Production Client ................................................. 357
11.4 Support Tools for Customizing ...................................................................... 358
11.4.1 Comparing Customizing in Two Clients .......................................... 359
11.4.2 Single Comparison with Transaction SCMP ................................... 366
11.4.3 Business Configuration Sets .............................................................. 368
11.4.4 Customizing Transfer Assistant ........................................................ 369
11.5 Questions .......................................................................................................... 371
12 Promoting Change Requests 373
12.1 Documenting Change Requests and Tasks .................................................. 373

12.1.1 Creating and Changing Documentation ......................................... 374
12.1.2 Action Logs for Change Requests .................................................... 374
12.2 Unit Testing ....................................................................................................... 375
12.2.1 Client-Dependent Customizing ....................................................... 375
12.2.2 SAPscript Styl............................................................................ es
and Forms ........................................................................................... 377
12.2.3 Report Variants .................................................................................. 378
12.3 Releasing a Task ............................................................................................... 378
12.3.1 Release Errors ..................................................................................... 379
12.3.2 Impact on the Change Request ....................................................... 380
12.4 Releasing a Change Request .......................................................................... 381
12.4.1 Merging Change Requests ................................................................ 382
12.4.2 Procedure for Releasing a Change Request .................................... 383
12.4.3 The Export Process ............................................................................ 387
12.4.4 Authorizations .................................................................................... 390
12 Contents
12.5 Transport Logs .................................................................................................. 391

12.5.1 Managing Transport Logs ................................................................. 392
12.5.2 Displaying Transport Errors at Logon .............................................. 393
12.6 Versioning for Repository Objects ................................................................ 394
12.6.1 Version Management ........................................................................ 395
12.6.2 Versions in Nondevelopment Systems ........................................... 396
12.7 Questions .......................................................................................................... 397
13 Importing Change Requests 399
13.1 Understanding Import Queues ...................................................................... 399

13.1.1 Import Overview ............................................................................... 399
13.1.2 Import Queue .................................................................................... 401
13.2 Performing Imports .......................................................................................... 405
13.2.1 Before Performing Imports ............................................................... 406
13.2.2 Import All ........................................................................................... 408
13.2.3 Preliminary Imports ........................................................................... 409
13.3 Managing Import Queues .............................................................................. 412
13.3.1 Forwarding a Change Request ......................................................... 412
13.3.2 Deleting a Change Request from an Import Queue ..................... 413
13.3.3 Adding a Change Request to an Import Queue ............................ 414
13.3.4 Moving an End Mark ........................................................................ 414
13.3.5 Performing Checks ............................................................................ 415
13.4 Scheduling Imports .......................................................................................... 418
13.4.1 Importing into Multiple Clients ....................................................... 418
13.5 Monitoring Imports ......................................................................................... 422
13.5.1 Import Monitor .................................................................................. 422
13.5.2 TP System Log .................................................................................... 423
13.5.3 Action Log File ................................................................................... 423
13.5.4 Single Step Log Files .......................................................................... 423
13.6 Transporting between Transport Groups ..................................................... 423
13.6.1 Adjusting Transports ......................................................................... 424
13.7 Transporting between Transport Domains .................................................. 425
13.7.1 Configuration ..................................................................................... 426
13.7.2 Transport ............................................................................................ 428
13.7.3 Linking Domains Using Domain Links ............................................ 430
13.8 TMS Authorization ........................................................................................... 430
13.9 Questions .......................................................................................................... 431
14 Technical Insight—the Import Process 433
14.1 The Transport Control Program tp ................................................................ 433

14.1.1 Prerequisites ....................................................................................... 434
14.1.2 Command Syntax .............................................................................. 434
Contents 13
14.1.3 Import Queues and Import Buffers ................................................. 435

14.1.4 Performing Imports Using tp ............................................................ 438
14.1.5 tp Processing Sequence .................................................................... 442
14.2 Using Log Files for Troubleshooting ............................................................. 446
14.2.1 Generic Log Files ............................................................................... 446
14.2.2 Single Step Log Files .......................................................................... 447
14.2.3 Return Codes ...................................................................................... 449
14.2.4 Troubleshooting Techniques ............................................................ 451
14.3 R/3 Buffer Synchronization ............................................................................. 457
14.4 Naming Conventions in the Transport Directory ........................................ 459
14.4.1 Removing Files from the Transport Directory ................................ 461
14.5 Understanding Transport Tools ..................................................................... 462
14.5.1 The Transport Program R3trans ....................................................... 463
14.5.2 ABAP Programs .................................................................................. 464
14.6 Questions .......................................................................................................... 471
15 Maintaining SAP Software 473
15.1 Making Manual Corrections on the Basis of SAP Notes ........................... 473
15.1.1 SAP HotNews ..................................................................................... 474
15.1.2 SAP TopNotes .................................................................................... 475
15.2 Implementing Notes with the SAP Note Assistant .................................... 475
15.2.1 Registering Manually-implemented Notes ..................................... 477
15.2.2 Processing Notes ................................................................................ 477
15.2.3 Implementation Status and Processing Status of Notes ............... 493
15.3 SAP Support Packages ..................................................................................... 495
15.3.1 Importing SAP Support Packages .................................................... 498
15.3.2 Modification Comparison ................................................................. 521
15.4 Support Package Stacks .................................................................................. 522
15.4.1 SP Stack Strategy with the Usual Import Procedure ..................... 524
15.4.2 Details of the Components in SAP Support Package Stacks ........ 526
15.4.3 SP Stack Calendar .............................................................................. 527
15.5 Side Effects ........................................................................................................ 527
15.6 Questions .......................................................................................................... 529
16 Change of SAP Release 531
16.1 Life Cycle of a Productive SAP System ......................................................... 531

16.1.1 SAP Release and Maintenance Strategy .......................................... 531
16.1.2 Upgrade Motivation .......................................................................... 533
16.2 Change of Release Process ............................................................................. 534
16.2.1 Overview ............................................................................................. 534
16.2.2 System Switch Upgrade Procedure ................................................. 536
16.2.3 System Switch Upgrade in Detail .................................................... 537
14 Contents
16.3 Modification Adjustment ................................................................................ 542

16.3.1 Modification Adjustment During Release Changes ....................... 546
16.3.2 Modification Adjustment During the Import of
Support Packages .............................................................................. 548
16.3.3 Modification Assistant ...................................................................... 551
16.4 Upgrade Strategies for a Transport Landscape ........................................... 552
16.4.1 Change of Release in a Three-System Landscape .......................... 553
16.4.2 Change of Release with Additional Development System ........... 554
16.4.3 Change of Release with Five Systems ............................................. 555
16.5 Further Recommendations for a Change of Release .................................. 558
16.5.1 Upgrade Tools and SAP Upgrade Service Offers ........................... 558
16.5.2 Other Recommendations ................................................................. 566
16.6 Questions .......................................................................................................... 569
17 SAP Solution Manager 571
17.1 Customizing Synchronization ......................................................................... 573

17.1.1 Customizing Distribution .................................................................. 574
17.1.2 Customizing Scout ............................................................................. 579
17.1.3 Creating and Loading Synchronization Objects ............................. 585
17.2 Change Request Management ....................................................................... 588
17.2.1 Configuring and Setting Up Change Management ....................... 590
17.2.2 Change Tracking ................................................................................ 592
17.2.3 Change Processes .............................................................................. 595
17.2.4 Change Process Steps ....................................................................... 601
17.3 Questions .......................................................................................................... 607
18 SAP NetWeaver Development

Infrastructure 609
18.1 Structure of the SAP Web Application Server ............................................ 609

18.2 Overview of the Java Development Process ............................................... 611
18.3 Parts of the SAP NetWeaver Development Infrastructure ....................... 615
18.3.1 The SAP Development Environment .............................................. 615
18.4 Configuration of the SAP NetWeaver Development Infrastructure ........ 618
18.4.1 Local Development Environment .................................................... 618
18.4.2 Overview of the Different Development Scenarios ...................... 619
18.5 Configuration of the SAP NetWeaver Development Infrastructure ........ 626
18.5.1 Configuration of the System Landscape Directory ........................ 626
18.5.2 Setting Up Users and Authorizations .............................................. 629
18.5.3 Setting Up the SAP NetWeaver Developer Studios ...................... 632
18.5.4 Creating Products and Software Components ............................... 632
18.5.5 Creating a Domain and a Track in the
Change Management Service .......................................................... 634
18.5.6 Creating a Development Component ............................................. 636
Contents 15
18.6 Developing in the SAP NetWeaver Development Infrastructure ............ 637

18.6.1 Creating a J2EE Application .............................................................. 638
18.7 Transporting Java Projects .............................................................................. 642
18.8 Summary ............................................................................................................ 644
18.9 Questions .......................................................................................................... 645
A Creating RFC Destinations 647
B Transport Profile Parameters 649
C Selected Transaction Codes 663
D Glossary 669
E Literature 683
E.1 R/3 Online Help ................................................................................................ 683

E.2 R/3 Training Courses ........................................................................................ 683
E.3 SAP on the Internet ......................................................................................... 683
E.3.1 SAP TechNet ....................................................................................... 684
E.4 Select Bibliography .......................................................................................... 684
F Questions and Answers 685
G The Authors 713
Index 715
16 Contents
15 Maintaining SAP Software

In this chapter, you will learn about the software maintenance strategies and tools
that SAP provides, and in particular, about Support Packages and SAP Notes. Sup-
port Packages correct all the errors in a system that have been identified within a
specific time period, while SAP Notes correct individual errors as they occur. This
chapter also explains the modification adjustment steps you need to take when
importing Support Packages.
The tools dealt with in this chapter are as follows.
왘 The Note Assistant (Transaction SNOTE) is used to import Notes with code cor-
rections.
왘 The SAP Patch Manager (Transaction SPAM) is used to import Support Pack-
ages.
왘 The Note Assistant (Transaction SNOTE) is used to import Notes with code cor-
rections.
This chapter is primarily intended for system administrators and technical consult-
ants who are responsible for maintaining and updating an SAP system landscape.
Nonetheless, project leaders and strategic consultants will also benefit from this
information, because it's helpful for planning package upgrades and for estimat-
ing the time and staff costs involved. Experience shows us that the main factors
that cause difficulties in Support Package implementation projects are the neces-
sary downtime, the time and effort required for testing, and the indispensable
code freeze. Section 15.3 addresses these aspects, and also describes the benefits
gained from importing Support Packages.
15.1 Making Manual Corrections on the Basis of SAP

Notes
If a specific problem occurs with the mySAP Enterprise Resource Planning (ERP)
software and this problem is corrected, details of the correction are published in
an SAP Note. The correction is also included in the next Support Package.
But, if the problem is particularly urgent, you may not be able to wait for the Sup-
port Package. In that case, you will have to manually make the correction with the
help of a SAP Note.
SAP provides the SAP Note Assistant to enable customers to import SAP Notes
containing corrections in ABAP. This tool considerably reduces the amount of
manual work required to implement the Note and to make modification adjust-
ments later on.
Maintaining SAP Software 473

Particularly important Notes—like those about faults with serious consequences

such as system breakdown or data inconsistencies—are classified as HotNews and
are published on the SAP Service Marketplace.
15.1.1 SAP HotNews

SAP HotNews items are SAP customer Notes with Priority 1 (very high). These
Notes contain the solutions to problems that could cause a system breakdown or
data loss in the SAP system. Therefore, if one of these Notes applies to your sys-
tem, it is very important that you take it seriously.
The new SAP HotNews process enables you, the user, to display only HotNews
items that are relevant to your area(s). The shared personalization interface for
SAP HotNews and SAP TopNotes (see below) allows you to create multiple filters
for the applications that you use (such as SAP R/3 or SAP CRM). Using the filter
maintenance functions, you can select the products (such as SAP R/3), product
versions (such as SAP R/3 4.6C), software components (such as SAP Basis 4.6C),
and Support Packages that are relevant to you, and the system returns only the
HotNews items that are relevant to your criteria.
SAP HotNews items are located in the SAP Service Marketplace under the /notes
Quick Link: http://service.sap.com/notes. (You need a Service Marketplace user to
be able to view this content.)
You can also have the SAP HotNews you are interested in emailed to you in the
SAP Service Marketplace newsletter. To subscribe to the topic area News for
Administrators (incl. SAP HotNews) of the SAP Service Marketplace newsletter,
make the required settings in the SAP Service Marketplace under My Profile.
Once you have done this, you will be informed automatically as soon as there is
a new SAP HotNews item that is relevant to your settings.
If you receive a SAP HotNews item that contains information that is extremely
important for the operation of your SAP system, you should confirm receipt of
this item in the SAP Service Marketplace. When you confirm receipt of this item,
this Note is no longer displayed to you. SAP is notified that you have read the
Note and that you have taken the recommended measures.
As an SAP system administrator, you should regularly review all SAP HotNews
items or ensure that this is done, and if necessary, proactively implement them in
your system.

Figure 15.1 SAP HotNews browser in the SAP Service Marketplace
15.1.2 SAP TopNotes

SAP TopNotes are the most important Notes in a component or sub-component
(such as FI). These are the Notes that are most frequently appended to customer
problem messages. Every month, the system identifies the 10 most common
messages for the component in question. Then, the TopNotes are checked man-
ually, and other important SAP Notes can be added to them or replace them. This
concept is described in detail in Note 557703.
SAP TopNotes are also located in the SAP Service Marketplace under the /notes
Quick Link (http://service.sap.com/notes). As with SAP HotNews, you can also be
notified of new SAP TopNotes by email.
15.2 Implementing Notes with the SAP Note Assistant

The SAP Note Assistant can automatically implement Notes that contain correc-
tions to source code. Other changes, such as Customizing changes or changes to
a table, cannot be automatically implemented. Always make sure to read the
Note carefully before implementing it using the Note Assistant, since it may con-
tain information about prerequisites, interdependencies, and references to clean-
up steps that you'll need to consider in the implementation process.
Implementing Notes with the SAP Note Assistant 475

The Note Assistant is available as an add-on from Release 4.5B, and is included as
standard from Basis Release 6.10.
The functions of the Note Assistant are as follows:
왘 Reporting
Provides an overview of the Notes existing in a system, their processing status
and of all the source-code corrections that have been implemented to date.
왘 Project administration
Allows you to assign Notes to processors. These processors can then set the
processing status. The system notifies you if a Note has an inconsistent status.
왘 Retraceability
The system automatically logs the processing steps.
왘 Error correction
You can automatically implement source-code corrections (correction instruc-
tions) that are described in Notes.
왘 Integration
When Support Packages are imported or upgrades are performed, the system
automatically identifies the Notes that the Support Package or upgrade
resolves and which correction instructions have to be re-implemented.
Figure 15.2 SAP Note Assistant

15.2.1 Registering Manually-Implemented Notes

If you implemented corrections from Notes into your SAP system before installing
the Note Assistant, you can retroactively 'tell' this to the Note Assistant. Because
the Note Assistant cannot automatically determine whether a Note correction
was implemented in your system manually (that is, without the use of the Note
Assistant), this is important to do. Proceed as follows:
1. In the ABAP Editor (Transaction SE38), call the program SCWN_REGISTER_NOTES.

2. In the program's input screen, enter the numbers of the Notes you want to reg-
ister and that have been fully implemented.
3. This can cause the following situations to occur:
왘 If you created a Remote Function Call (RFC) connection to the SAPNet-R/3
frontend, the program automatically loads the Notes to be registered into
your system's database.
왘 If you did not create an RFC connection, first load the Notes to be registered
from the SAP Service Marketplace. Then, upload the Notes in the Note
Assistant.
4. The program checks whether the Notes are valid for your release and Support
Package level. It also verifies whether the Notes are already registered as having
been implemented in the Note Assistant. The system then outputs the results
of these checks to a list.
5. To register the Note, select Execute.
Note To be able to register the Note as implemented, the system has to enter
the details of the Note and the objects that it corrected in a change request.
When you transport this request, you are registering the Note as implemented,
even in your follow-on systems. If it is not possible to include the Note and its
objects in one request—because, for example, some objects have already been
locked in other requests—the system will reject the registration.
15.2.2 Processing Notes

To correct an error in a program using the Note Assistant, proceed as follows:
1. Load the Note into your system. In the loading process, the Note Assistant
checks whether the characteristics of the Note (software component, release
level, and Support Package level) match those of your system. It then states
whether the corrections can be implemented.
Only Notes with source-code corrections (correction instructions) can be auto-
matically implemented.

2. Read the Note description carefully.
Note The Note description may contain information about prerequisites and
interdependencies, and references to post-processing steps (for example,
changes that need to be made to a table), which the Note Assistant does not
automatically recognize. If you do not read and, if required, act upon this infor-
mation, serious problems can result. It is therefore absolutely imperative that
you read the Note before you start the implementation.
3. Determine whether the Note is relevant to you. Classify the Note in accordance
with the processing status.
4. Implement the correction.
5. Carry out any post-processing steps that may be specified in the Note.
6. Test whether the error has been successfully corrected.
7. Set the processing status to Completed.
8. Release the transport request and import the corrections into the follow-on
systems in your system landscape.
Search for Note
The Note Browser enables you to search through all the SAP Notes in your sys-
tem. It also displays Notes that are assigned to another processor and Notes that
have already been implemented.
1. Select a search criterion for the Note:

왘 Note number
왘 Application component
왘 Processing status
왘 Implementation status
왘 Processor
2. Select which option you require:

왘 Restrict the selection process to certain software components and their
releases.
왘 Sort the Notes according to their number or the application component to
which they belong.
3. Confirm your selection.

The Note Browser then displays a list of the Notes that match your criteria, and
their Note number, short text, component, processing status, implementation
status, and user. You can also implement Notes directly from the Note Browser.
Figure 15.3 The note browser displays all notes that have been implemented using the SAP note
assistant
Load Note
You can load SAP Notes into your system from the SAP Service Marketplace or
the SAPNet-R/3 frontend, using either a direct RFC connection (Note download)
or by file transfer (Note upload). Note download has the following benefits:
1. You can transfer the Note in the Note Assistant from the SAPNet-R/3 frontend
directly to your system.
2. If the Note in question specifies other Notes as prerequisites, the
Note Assistant automatically downloads these in the implementation process.
3. You can download updated versions of the Notes at the touch of a button.
To download a Note, you have to create an RFC connection to the SAPNet-R/3

frontend. To upload a Note, on the other hand, a permanent RFC connection to
the SAPNet-R/3 frontend is not necessary. Instead, first load the required Note

from the SAP Service Marketplace and save it locally on your PC. Then, upload the
Note from inside the Note Assistant.
1. Select Note Download in the Note Assistant.

2. Enter the numbers of the Notes that you want to download. You can use the
selection function to select individual Notes or a list of Notes.
3. Confirm your selection. The system then loads the matching Notes from the
SAPNet-R/3 frontend into your database.
For Note Upload to be available, the SAP Download Manager must be installed
on your computer. Notes can then be downloaded from the SAP Service Market-
place. For more information on the SAP Download Manager, see the SAP Service
Marketplace at service.sap.com/swcenter.
1. Select the Note in question from the SAP Service Marketplace under service.
sap.com/notes.
2. Select Download. The Note is then added to your Download Basket. Repeat
this process as many times as required.
3. To save the selected Notes to your local PC, start the SAP Download Manager.
Select Download. The Notes are then saved as files to the local directory you
specified.
4. In the Note Assistant, load the Note files into your system using the Note
Upload function (Goto • Note Upload).
After you have successfully downloaded or uploaded a Note that was not previ-
ously in your system, it is listed with the processing status New.
Classify Note
This function allows you to specify the relevance or processing status of a Note.
Read the Note carefully and decide whether its content is relevant to the situation
in your system. Then proceed as follows:
1. If the Note is relevant to your system, set its status to In Processing. This
informs other users that you are already processing this Note.
2. Closely follow the recommendations given in the Note. If the Note contains a
correction instruction, implement this in your system.
3. If you want to assign the Note to another processor, enter the user name of the
processor.
All your actions are recorded in the log file for the Note. You can also enter addi-
tional comments in the log file, such as information you may want to pass on to
another user.

If the Note is not relevant to you, set the processing status to Not Relevant. This
signals to you and to all other users that this Note can be disregarded.
Figure 15.4 Processing statuses for implementing notes
Implement Correction Instruction
There is a function that implements the correction instruction contained in a

Note. If you have previously modified the object that is the subject of a correction
instruction, you can also adapt the correction to your modifications.
Figure 15.5 Additional manual action required in note implementation
1. To implement the correction instruction of a Note in your system, place your

cursor on the title of the Note in the initial screen of the Note Assistant and
select Implement Note. First, the system checks which correction instruction
from the Note is appropriate for your release level and Support Package level.
It then checks whether any corrections from other Notes are a prerequisite to
the implementation of this correction. If there are prerequisite Notes, the sys-
tem displays these in a dialog field.
왘 If you have an RFC connection to the SAPNet-R/3 frontend, you can auto-
matically download these Notes by confirming the dialog field.
왘 Otherwise, load them from the SAP Service Marketplace and then upload
them using the Note Assistant.

If the prerequisite Notes are relevant to your system, they are then displayed in
the order in which they are to be implemented. If possible, the system imple-
ments all prerequisite Notes in one step.
Read the prerequisite Notes as carefully as you would any other Notes.
Note If any prerequisite Notes are not relevant (for example, because they
have already been imported in a Support Package), the Note Assistant auto-
matically assigns the relevant status to them and does not display them in the
list. To view these Notes, call the Notes Browser and select the Not Relevant
processing status.
Before the system corrects the objects, it opens a dialog window in which you
can select the change request.
Figure 15.6 Prerequisite notes
2. Either select a suitable change request, or create a new one.

The Note (R3TR NOTE), including all correction instructions (R3TR CINS) and
all changed objects, is entered into the request. The transport request then
transports all corrections to the follow-on systems.
Note that all objects to be corrected, plus details of the Note, must be entered
in a request. This is the only way to ensure that the corrections are transported
in their entirety to the follow-on systems.
Note No SSCR key is required for automatically implementing Note correc-

tions.

3. A dialog window opens that lists all the objects to be changed. A traffic light
icon shows whether the system can automatically implement the correction.
Click on the object name to open an editor. The editor shows you the changes
in detail.
If you previously modified the objects to be corrected, the Note will have an
amber light. You can then adapt the corrections to suit your modifications (also
see: Split-Screen Editor).
If you make manual changes when implementing Notes, the system cannot
judge whether the corrections have been implemented properly. Therefore,
you must confirm in a separate dialog window that the corrections can be clas-
sified in the system as fully implemented.
Note If the system cannot automatically implement a correction, even though

the objects in question were not previously modified, you should first attempt
to import the Note using the split-screen editor. In many cases, minor differ-
ences in the source code cause the automatic implementation to fail. If the
implementation still does not work, it is probably because the Note contains
an error of some sort. If this happens, contact SAP Support by creating a prob-
lem message under the component of the Note (for example, FI-AR-CR).
4. Check that the corrected objects do not contain any syntax errors. This is par-
ticularly important if the corrected objects also contain customer-specific mod-
ifications. Note that currently the system can automatically implement only
source-text changes. If any other changes are required (changes to Dictionary
objects, for example), they are described in the Note text and must be manually
implemented in your system.
5. After implementing the corrections, test the function in question to ensure that
it has been fully corrected by the Note.
You can display all objects that were corrected by the Note; simply select Cor-
rected objects to call the modification browser.
6. Set the processing status to Completed.
Note In exceptional cases, you can remove correction instructions that you
have implemented. This undoes all implemented changes. The Note in ques-
tion remains in your system and is reset to the status it had prior to it being
implemented. To remove certain correction instructions, select Reset SAP
Note Implementation.

7. Once you have solved your problem via the Note, release the change request
that was created when you implemented the correction instruction. This trans-
ports the corrections and the Note data to the follow-on systems in your sys-
tem landscape.
If a particular Note has prerequisite Notes, the Note Assistant identifies the pre-
requisite Notes when the Note is being implemented and instructs you to load
the prerequisite Notes into your system. As soon as the prerequisite Notes are
available, the Note Assistant displays the Note you selected plus all additional
Notes in a dialog field called the Note queue. The Notes have to be implemented
in the order shown in the Note queue. Before you start the implementation proc-
ess, read the prerequisite Notes as carefully as you would any other Notes.
Figure 15.7 Implementing a note queue
You have the following options:
왘 Implement multiple Notes in one step

If you select this option, the system implements as many of the specified Notes
as possible, in one step and in sequence. The Notes that can be implemented
at the same time are highlighted in color.
The system can implement multiple Notes in one step only if all corrections can
be transferred in unmodified form from the Notes. If you have made your own
modifications to the includes in question, the system may be unable to insert
individual changes. The system always implements such Notes individually, so
that you can adapt your modifications.
왘 Implement all Notes individually
The system implements the specified Notes individually. This option allows you
to review in detail what source-code changes belong to which of the specified
Notes, and to modify the changed source code, if necessary.

왘 Cancel SAP Note implementation

The system does not make any changes to the source code.
The Confirm Changes dialog field shows you which objects will be changed by
the implementation of the Note, and whether the Note Assistant can copy in the
changes. If you confirm this dialog field, the system implements the corrections
into the specified objects. If you select Cancel here, the system does not make
any corrections.
Figure 15.8 Display of objects to be changed
The traffic light icons show you whether the corrections in a Note can be imple-
mented. The different colors have the following meanings:
왘 Green light: The corrections can be implemented without any changes.

왘 Amber light: Some of the corrections can be implemented.
Before you confirm the implementation, you should adapt the corrections in
such a way that the object changes can be imported correctly. To do this, click
on the object name or on the traffic light icon. The split-screen editor opens,
enabling you to edit the source code here.
왘 Red light: The object changes cannot be implemented.
This can occur for a variety of causes; for example, the object has to be created
from scratch, or is locked by another change request.
There is a corresponding message text for every object (for example, “Correc-
tions have not been included completely“). If you click on the text, the system
displays the appropriate long text with detailed information.
To implement the corrections, select all the objects for which you want to imple-
ment corrections, and select Continue.
Tip Note that only those objects that you selected will be changed.
This editor provides a detailed display of all corrections in an object. You can use
this editor to adapt the corrections to your own modifications, if necessary.

Figure 15.9 Split-screen editor
The split-screen editor is divided into two areas:
왘 On the left-hand side of the screen, you see the source code as it looks after
the changes have been implemented. The changes are highlighted in color. You
can edit the source code in this part of the screen.
왘 On the right-hand side of the screen, you see the parts of the program that
have been deleted, and corrections that the Note Assistant cannot implement
automatically. These deletions and corrections are displayed in the form of
context blocks, delete blocks, and insert blocks.
You can do the following on the left-hand side of the screen:
왘 Manually edit the program
왘 Select, cut, copy and paste blocks
Note To select a block that is highlighted in color, simply place your cursor on
the header line and choose Select. You can also select multiple lines. To do
this, place your cursor on the first line of the block that you want to select and
choose Select. Then place your cursor on the last line and choose Select again.

왘 Select Undo to undo all changes, step by step, that you made in the split-
screen editor.
왘 Select Redo to restore all changes that you undid.
왘 Use the arrow buttons to go to the next or last change.
왘 Select Concatenate to attach two lines to each other.
If a block has been inserted or deleted, the Undo/Redo button appears between
the left-hand and the right-hand side of the editor. You can use it to undo or redo
individual changes. The technical function of the undo and redo buttons is to
exchange individual delete and insert blocks.
Technical Details of Correction Instructions
Technical details of correction instructions contains information on the following

topics:
왘 Format of correction instructions
왘 Validity of correction instructions
왘 Prerequisites of correction instructions
Correction instructions describe how the source code of ABAP programs has to be
changed in order to resolve an error. These correction instructions are located at
the end of each SAP Note. You use correction instructions to automatically cor-
rect the source code of ABAP programs, ABAP includes, function modules,
method implementations, Dynpro flow logic, and type groups.
Every change contains information about the object (for example, the include or
the function module) and the modularization unit (such as FORM routine) in
which it is to be made. The location of the change is identified by the unique
number of the unchanged lines that directly precede the lines to be changed
(context block). The lines to be deleted are then listed (delete block), followed by
the lines to be inserted (insert block). A correction instruction can consist of mul-
tiple contexts, delete blocks, and insert blocks.
When automatically implementing a correction instruction, the system finds the

context blocks in the include or function module to be corrected, checks whether
the context blocks follow the lines to be deleted, and replaces these lines with the
lines to be inserted.
If the include or function module to be corrected contains customer modifica-

tions, sometimes the system can't find the context blocks specified in the correc-
tion instruction, or in the lines to be deleted. In other words, the system cannot
fully implement the correction. In this case, you can use the split-screen editor to
adapt the corrections in the Note to your modifications.

Since 1998, correction instructions have been formalized to such a degree that
they can be implemented automatically. However, older Notes may still be in a
non-standardized format, and the Note Assistant will be unable to automatically
implement these Notes completely. However, as before, you can manually edit
the source code, using the split-screen editor. We recommend that you do this to
ensure that the Note Assistant can register the Note in your system.
Every correction instruction specifies the release levels and Support Package lev-
els in which you can implement the correction instruction. These release and Sup-
port Package levels are known as the area of validity of the correction instruction.
For example: if an error is detected in Release 4.6C, and Support Package 5 cor-
rects this error, the validity period of the correction instruction in question will be
specified as “4.6C Support Packages 1–4.“
A Note can also specify that a correction instruction may not be implemented if
the system contains a specific software component (such as an add-on). This may
be the case if, for example, a correction makes changes to a part of a program that
is required in its unmodified form by another software component.
If such a condition exists, it is displayed in the header area of the correction

instruction under Not valid for <software component, release, Support Package
level>.
The Note Assistant automatically checks the validity and implements a correction
instruction only if the status of the system is included in the specified validity
area.
In certain cases, correction instructions can be implemented only if other correc-

tion instructions have already been implemented. This is due to interdependent
changes made to the same points in the source code, or to semantic dependen-
cies.
These dependencies are described in the header area of the correction instruc-
tions. If there are dependencies, you will have to implement not just one Note,
but also a series of Notes.
Log File
A log file is created when you download a Note. A log file contains information
about the main processing steps and the date, time, system and user in question.
It therefore allows you to trace the steps that have already been taken.
You can also save your own notes or remarks in the log file, provided that you are
entered as a processor for this Note.

The information in the log file cannot be deleted.
Figure 15.10 Log file
Update Note
This function enables you to compare the version of a Note in your system with
the current version in the SAPNet-R/3 frontend. You can thus check at any time
whether the Notes in your system are up to date. If necessary, the system down-
loads the latest version.
You have the following options:
왘 Compare an individual Note from within the Notes display
왘 Compare all the Notes listed in your work list
왘 Compare all the Notes listed in the Notes browser
Note Notes can be automatically updated only if you have set up an RFC con-
nection to the SAPNet-R/3 frontend.

To update a Note, proceed as follows:
1. Choose Download Latest SAP Note Version.

The system checks whether your system contains the latest versions of the
Notes listed on the screen.
It also displays in a dialog box the Notes that SAP has changed since the last
time you downloaded them.
2. To download the latest versions of these Notes, click on OK in the dialog box.
If the current Note was changed, and therefore has to be re-implemented, the
Note Assistant displays this Note in your work list under the Inconsistent head-
ing. In this case, all you have to do is re-implement the Note.
Post-processing Support Packages
A Support Package contains a collection of error corrections. Support Packages

can be imported only in their entirety and only in the specified order. Every cor-
rection in a Support Package is documented in a Note.
Figure 15.11 Post-processing support packages in transaction SPAU

Figure 15.12 Color legend in transaction SPAU
After you import a Support Package, you should execute the modification adjust-
ment using Transaction SPAU. The cases that can arise are as follows.
1. When a Support Package is imported, the system automatically checks whether

you have previously implemented individual corrections from this Support
Package in the form of Notes. In the modification adjustment function (Trans-
action SPAU), these Notes are displayed with a traffic light icon with no colors
and are therefore marked as obsolete.
You must reset the objects they contain to their original SAP status. You can do
this in one of the following ways:
왘 Click on the traffic-light icon.
왘 Position the cursor on the Note number. Choose Reset to Original.

A dialog box opens. In this box, confirm that you want to reset the Note cor-
rection to the original status.
If you have selected multiple Notes corrections, you can choose Reset All, and
the dialog box does not open.
2. The system checks whether corrections, which you have previously imple-
mented via a Note, have been overwritten by a Support Package that did not
contain these corrections. If this is the case, you will then have to reimplement
these Note corrections. The system displays these Notes in the modification
comparison function (Transaction SPAU) with an amber traffic light.
Click on the traffic light to start the reimplement process for the Note.
These Notes are also displayed in your work list with the status Inconsistent,
that is, they have to be reimplemented. To start the reimport, choose Imple-
ment SAP Note.
3. The system checks whether you have previously implemented individual cor-
rections from the Support Package into your system via Notes. If the Note ver-
sion in the Support Package is more current than the Note that was imple-
mented in your system using the Note Assistant, the modification comparison
function cannot reset the objects in the Note to their original status. The system
displays this Note with an amber traffic light.
In this case, proceed as follows:
왘 Open the Note Assistant.
왘 Download the latest version of all Notes.
왘 Recalculate the adjustment modes in the modification adjustment. Then

choose Goto • Determine Adjustment Modes.
If SAP has not changed the Note, its traffic light icon has no colors. You can re-
set it to its original status as described in Step 1.
If SAP has changed the Note, its traffic light icon is amber. In this case, proceed
as described in Step 2.
4. An example of this case would be a Note that contains several correction
instructions, each of which has a different validity period. This can have the fol-
lowing effect: When a Support Package is imported; one correction instruction
may become obsolete, while another may still be valid. In such cases (which
are, admittedly, rare), the Note has a green traffic light icon.
If you click on the icon, correction instructions that are no longer relevant are
reset to their original status.
5. The adjustment modes for Notes corrections are calculated in a background
process after a Support Package is imported. However, if this process is not
started for some reason, or if errors occur, a green question mark is displayed in

front of the object in the hierarchy display. Click on the question mark to restart
the process. This process can take a few minutes.
Note If an object contains your own modifications and Note corrections, first
you must process the Note corrections in the modification adjustment func-
tion (SPAU), and then adjust your own modifications.
The system does not support modification adjustments in the With Modification
Assistant subtree if the object is contained in Note corrections that have not yet
been adjusted, or that have not yet been reset to their original status.
In all cases, in a modification adjustment or when correction instructions are reset
to their original status, the objects contained in the Note are placed into transport
requests. This ensures that they are transported to the follow-on systems.
15.2.3 Implementation Status and Processing Status of Notes

The Note display in the Note Assistant contains two statuses: implementation
status and processing status. The implementation status of a Note is determined
by the system, based on existing information. The processing status, on the other
hand, is specified by the user.
You should note that the system checks whether the processing status you specify
is consistent with the implementation status of the correction instructions.
For example, you may set the processing status to Completed only if all the rele-
vant corrections have been implemented (implementation status Completely
implemented or Cannot be implemented).
If the implementation status changes afterwards and if it is no longer consistent
with the processing status (for example, after a Support Package is imported), the
system marks this Note as “inconsistent” in the Note overview.
Implementation Status
If a Note contains correction instructions, the implementation status indicates

whether all relevant correction instructions of the Note have been implemented
in the system.
The system automatically sets the implementation status. The possible values are
as follows.
왘 Incompletely implemented
Not all relevant correction instructions have been implemented, or a particular
correction instruction has not been completely implemented. The objects in

question are therefore considered to be in an inconsistent state, and you

should re-implement the relevant Note.
왘 Obsolete version implemented
SAP has corrected a Note that contained errors. Re-implement the Note into
your system.
왘 Can be implemented
The Note contains correction instructions that you can implement in your sys-
tem, if necessary.
왘 Undefined Implementation State
The implementation state is undefined.
왘 Completely implemented
The corrections in the Note have been fully implemented in your system. In
this case, you don't have to take any action.
왘 Cannot be implemented
The Note does not contain any correction instructions that you can implement
in your system. In this case, you don't have to take any action.
왘 Obsolete
After you implemented the corrections in the Note, you then imported a Sup-
port Package that also contains these corrections. The error has therefore been
completely resolved.
Figure 15.13 Possible implementation statuses of a note
Processing Status
The processor of a Note sets its processing status. This status tells other users and
the system whether this Note has already been processed and if so, to what
extent. This status is set in the Note Assistant and can be one of the following:

왘 New
The Note has been loaded into your system but has not yet been processed.
왘 In processing
The Note is being processed.
왘 Completed
The instructions in the Note have been executed; any corrections have been
implemented in the system. Consequently, processing is completed.
왘 Not relevant
The Note has been read and classified as not relevant. A possible reason for this
is that it pertains to a function that you don't use.
15.3 SAP Support Packages

SAP regularly publishes Support Packages for different types of program correc-
tion and updates, both for ABAP and Java.
Support Packages can be downloaded from the SAP Service Marketplace under
the Quick Link /swdc (http://service.sap.com/swdc). SAP also provides collections
of Support Packages on CD-ROM. You can order these Support Packages from the
SAP Software Shop at http://service.sap.com/softwarecat.
SAP provides a range of tools that make it easy and convenient for you to obtain
Support Packages and to import them automatically.
The new reporting tool called Side Effects of SAP Notes helps you to avoid any
undesirable side effects of Support Packages after you import them. This tool dis-
covers whether the SAP Notes in a Support Package could have side effects on
other areas of your SAP system, and outputs a list of additional SAP Notes that
you can implement to prevent these side effects from occurring.
Support Packages provide the following benefits:
1. Proactive solution of known problems

Support Packages solve known problems that have occurred in other SAP cus-
tomers' systems, and thus proactively remove potential problems. This in turn
leads to better system stability.
2. Prerequisite to problem-solving
In rare cases, a problem can be solved only if a certain Support Package has
been imported. In such cases, it is not possible to solve the problem with a
series of Notes. If the problem in question occurs, the required Support Pack-
age will be have to be imported at short notice.
SAP Support Packages 495

3. Improved repair and maintenance

If a problem occurs, it is easier to find a solution if the latest Support Package
has been imported. This is because you can exclude from the possible solutions
all Notes that are contained in the Support Packages that have already been
imported.
4. Reduced repair and maintenance
If you import the Support Packages for your system, there is no need to import
all the individual Notes. If the kind of error occurs that necessitates the imple-
mentation of a Note, this Note may have several prerequisite Notes that also
have to be implemented. If you don't have the latest Support Packages, the list
of prerequisite Notes may be very long, thus increasing the amount of time and
effort required for error correction.
5. Prerequisite for implementation projects
An up-to-date Support Package is often a prerequisite for the implementation
of new functionality in a system. In such cases, if the Support Package level is
not current, the implementation process will have to be put on hold until the
appropriate Support Package is imported.
6. Prerequisite for interfaces to other SAP systems
In some cases, it is necessary to import the latest Support Packages so that
other SAP systems with newer Support Packages can use interfaces to your sys-
tem.
7. Statutory changes
Support Packages comply with the latest statutory requirements. This is espe-
cially relevant to the HR area, but also to statutory changes in the FI/CO area.
Support Packages contain quality improvements to the SAP system and make any
adjustments that may be necessary (due to statutory changes, for example). They
do this by replacing the affected objects in your system.
Every Support Package is valid for one specific release level (but for all databases
and operating systems) and has a prerequisite number of predecessors. An
upgrade of the next release level or correction level contains all Support Packages
for the preceding levels that were available when the upgrade was delivered.
The Support Package Manager ensures that Support Packages are imported only
in the correct order.
To prevent problems from occurring, import Support Packages at regular intervals.

This is the best way to keep your system landscape up to date.

The following types of Support Packages are available:
왘 SPAM/SAINT update
A SPAM/SAINT update (PAT) contains updates and improvements to the Sup-
port Package Manager and the SAP Add-On Installation Tool.
왘 Component Support Packages
A Component Support Package (COP) applies to a particular software compo-
nent (such as SAP_BASIS, SAP_HR, and SAP_APPL) and contains quality
improvements to Repository and Dictionary objects in this specific compo-
nent.
Support Packages for the SAP_HR component also contain changes made in
response to statutory changes, as well as the usual improvements.
왘 Add-on Support Package
An add-on Support Package (AOP) always applies to an add-on with a specific
release. It contains quality improvements to this add-on.
왘 Conflict Resolution Transport
A Conflict Resolution Transport (CRT) is used exclusively for add-ons, such as
IS-IS or IS-OIL. Its purpose is to adapt a Support Package to an add-on.
Tip Note that a CRT that applies to a specific add-on release also contains all
changes made for earlier releases of this add-on. A CRT may also contain other
quality improvements for the relevant add-on. Thus, a CRT can also be a special
add-on Support Package.
The naming convention for Support Packages is as follows:
Software component Name
SAP_APPL SAP ERP Support Package
SAP_BASIS Basis Support Package
SAP_ABA Application Interface Support Package
SAP_HR SAP HR Support Package
SAP_APO APO Support Package
SAP_BW BW Support Package
BBPCRM BBP/EBP and CRM Support Package
Java Support Packages contain corrections and updates to Java components. They
are delivered in the form of software component archives (SCAs). Unlike ABAP Sup-

port Packages, Java Support Packages always contain the full version of the devel-
opment component in question. It is therefore sufficient to import only the latest
one. If there are dependencies between the current Java Support Package and
other Java Support Packages, these dependencies are described in an SAP Note.
Java Support Packages have been delivered since SAP Web Application Server
(SAP Web AS) 6.20 and are imported using the Software Delivery Manager
(SDM). The SDM is delivered with the SAP Web AS from Version 6.20. SAP Note
544244 contains more detailed information on this topic.
15.3.1 Importing SAP Support Packages
Support Package Manager
The Support Package Manager (Transaction SPAM) enables you to import SAP
Support Packages into your system simply and efficiently.
You can open the SPM in one of the following ways:
왘 Choose SAP Menu • Tools • ABAP Workbench • Utilities • Maintenance •

Support Package Manager.
왘 Enter the transaction code SPAM.
Figure 15.14 Initial screen of transaction SPAM

The Support Package Manager has the following features:
왘 Support Package loading

You can load Support Packages into your system from the SAP Service Market-
place, the SAPNet-R/3 frontend, or from collection CDs.
왘 Restartability
When the Support Package Manager imports a Support Package into your sys-
tem, it adheres to a fixed order of steps.
If the import process has to be canceled for any reason, you can then resume
processing at a later stage from the point that had been reached.
왘 Display import status
You can use the Support Package Manager to find out the current import status
of your system at any time.
왘 Special import procedure
A special import procedure minimizes downtime.
왘 Start time control
The individual phases of the Support Package Manager are grouped into mod-
ules. This allows you to set the start time of the modules to any time you like.
왘 Background processing
You can also schedule the modules to run in background processing, with pre-
defined start times.
You need the following authorizations to be able to use all the functions of the
Support Package Manager:
왘 S_TRANSPRT
왘 S_CTS_ADMIN
Both authorizations are contained in the S_A.SYSTEM authorization profile.
If you log on to client 000 and your user master contains the relevant authoriza-
tion profile, you can use all the functions of the Support Package Manager. If you
log on to another client, or if you don't have the required user profile, you can use
only the display functions.
You should only assign this authorization profile to the system administrator. Also,
only the system administrator should have authorization for the following actions:
왘 Download Support Packages
왘 Import Support Packages
왘 Confirm successfully imported Support Packages
왘 Reset the status of a Support Package

Choose Extras • Settings to open a dialog box in which you can make general set-
tings for the Support Package Manager. These settings affect the behavior of the
system when loading and importing all types of Support Packages. One exception
is SPAM/SAINT updates, which have special predefined settings.
You only have to make the settings once, since they're saved and used every time
the Support Package Manager is called. Note that these settings also apply to the
SAP Add-On Installation Tool.
An exception to this is the settings for the Downtime-minimized import mode:

This does not automatically apply to the SAP Add-On Installation Tool.
Figure 15.15 Load packages tab page
You can change or check the following properties:
왘 Load CAR/SAR archive from frontend
왘 Transmission Monitor
The Transmission Monitor is a graphical monitor that enables you to monitor
the loading of Support Packages from the SAPNet-R/3 frontend. Otherwise,
the progress of the load process is indicated in the status bar.
왘 RFC destination
Displays the name of the RFC destination, which is used for the connection
to the SAPNet-R/3 frontend. You do not usually need to change the standard
setting SAPOSS. Transaction OSS1 is used to set up the SAPOSS destination.

왘 Directory at the application server

Shows you the application server directory in which the Support Packages are
stored.
왘 Load CAR/SAR archives from the frontend
왘 Display content before decompressing

Allows you to specify whether you want to view a dialog box containing the
archive content before the CAR/SAR archive is decompressed. This is
checked by default.
왘 Delete archive after decompressing
Allows you to specify whether the CAR/SAR archive that was transferred to
the application server should be deleted after it is successfully decom-
pressed. This is checked by default.
왘 Save last upload directory
Allows you to specify whether the most recently used upload directory on
your front-end computer should be saved. If you select this option, this
directory is then automatically displayed as the start directory in the archive
selection dialog box the next time you use this transaction. This is checked
by default.
You can also enter an upload directory of your choice in the Upload Direc-
tory field. This upload directory is then displayed as the start directory in the
archive selection dialog box.
Figure 15.16 Import queue tab page

왘 Scenario
By selecting a scenario, you are specifying which actions will be carried out
during the import of the Support Package.
왘 Standard
Select the standard scenario if you want to fully import Support Packages
and to execute all the steps involved.
왘 Import mode: downtime-minimized
If you select the standard scenario, you can also select downtime-minimized
import mode to reduce the length of the downtime. This is not selected by
default, which means that if you don't select this option, the packages are
imported by the conventional method. For more information on this import
mode, see the relevant section below.
왘 Test
The test scenario allows you to determine whether you need to carry out a
modification adjustment, or whether there are conflicts that need to be
removed before the import, that is, before the Support Package itself is
imported. No data or objects are imported into your system in the test sce-
nario. There is no test scenario for SPAM/SAINT updates. Therefore, if you
select this option when importing a SPAM/SAINT update, it is simply ignored.
왘 Create new data file
This option allows you to specify whether the data files in the EPS packages
should be decompressed with every attempted import. This is checked by
default.
If you have a multisystem landscape with a shared transport directory, we rec-
ommend that you switch on this option only in the first system into which you
import Support Packages, and to switch off this option in the follow-on sys-
tems. This saves time in the import process, because the data files don't need
to be re-created in the follow-on systems.
왘 Delete data file after import
This option allows you to specify whether the data files should be deleted after
a Support Package is imported. This helps to save disk space and is activated by
default.
If you have a multisystem landscape with a shared transport directory, we rec-
ommend that you switch on this option, because the data files don't need to
be recreated in the other system (see “Create new data file“ above).
왘 Create object versions during import
This option does not apply to SPAM/SAINT updates.

It allows you to specify whether versions should be created of the objects of

the Support Packages in the import process. This option is deactivated by
default. This is because versioning makes sense only if it is activated for all
imports, and also because it increases the run time and takes up additional
space in the database.
Note If you activate the versioning option, note that when configuring the
transport tools in the Transport Management System (Transaction STMS), you
must set the VERS_AT_IMP parameter to ALWAYS.
왘 ABAP/screen generation
These options allow you to specify whether the programs and screens that
come with the Support Package should be generated during the import.
They have no effect with SPAM/SAINT updates.
왘 Never
If you select this option, the programs and screens are generated only when
they are first called.
왘 Always
If you select this option, the programs and screens are always generated.
Note that the generation process can take a very long time and may cause
errors to occur.
왘 According to SAP instructions
If you select this option, the programs and screens are always generated if
the generation option is activated during the import process for these Sup-
port Packages.
The Support Package Manager has the following basic settings:
Option SPAM basic setting
Transmission Monitor Off
RFC destination SAPOSS
Display content before decompressing On
Delete archive after decompressing On
Save last upload directory On
Scenario Standard
Downtime-minimized import mode Off

Option SPAM basic setting
Recreate data file On
Delete data file after import On
Create object versions during import Off
ABAP/screen generation Never
All actions that the import tools perform run in phases. These phases, in turn, are
grouped into modules. The modules have the following properties:
왘 You can run them individually.
왘 You can start them in a background process.
왘 You can set the start time of the modules to any time you like.
The import process is subdivided into the following modules:
왘 Preparation module
This module carries out all the preparation and testing steps (such as a test
import and add-on conflict checking). It can run during live operation.
After you have run the Preparation module, you can reset the queue if, for
example, you find that you have to import a different number of Support Pack-
ages. If you proceed to the Import 1 module, the data is changed in the data-
base and you won't be able to reset or delete the queue from this point on.
왘 Import 1 module
This module imports and activates Dictionary objects (and carries out a modi-
fication comparison of Dictionary objects, if necessary). Any changes that are
made in the process of importing and activating the Dictionary are still in an inac-
tive state in the system. This means that the runtime system cannot yet “see“
these changes. If you are sure that there are no manual changes to be made and
that no transports will be imported into the system, this module can also run
during live operation. This is usually the standard in production systems.
왘 Import 2 module
This module carries out the remaining import steps, including the activation of
inactive Dictionary name tabs. To avoid inconsistencies, this module cannot
run simultaneously with live operations, since it imports changes to various
development objects.
왘 Clean-Up module
This module handles all post-import (“clean-up“) steps, especially modification
comparison for the Repository objects. Live operations can resume once all
modifications have been compared.

Because the package import process can be stopped after every module, it is possi-
ble to run the Preparation and Import 1 modules during live operations, if no mod-
ifications have been made to Dictionary objects. Once the system is transferred to
non-live operations, the Import 2 module and, if necessary, the modification com-
parison can then be carried out, after which live operations can resume.
Tip Note that no company-specific transports, apart from modification com-

parison transports, can occur during the time between the Preparation and
Import 2 modules (or during the time up to the modification comparison), and
that no manual changes can be made to Repository objects (ABAP programs and
Dictionary objects) in the same period. The time between Import 1 and Import
2 should be as short as possible.
The Support Package Manager uses the status bar to indicate which phase is cur-
rently being executed. If you want to know which phases are executed for which
scenario (test or standard scenario), run program RSSPAM10.
The following list provides an overview of all the modules and phases in the order
in which they are executed by the Support Package Manager:
왘 PROLOGUE
This phase checks whether you're authorized to import Support Packages.
왘 CHECK_REQUIREMENTS
This phase checks various import prerequisites, such as whether the trans-
port control program tp can log on to your system.
왘 DISASSEMBLE
This phase extracts the data files from the relevant EPS packages and stores
them in the transport directory.
왘 ADD_TO_BUFFER
This phase adds the queue to the transport buffer of your system.
왘 MODIFY_BUFFER
This phase modifies the transport buffer so that it can process the next
import phases correctly.
왘 TEST_IMPORT
This phase carries out a test import using the transport control program tp
for the current queue. In doing so, it checks whether any objects are cur-
rently in repair and will be overwritten during the import, and whether
there are any other factors that will prevent an object from being imported.

왘 IMPORT_OBJECT_LIST
This phase imports into the system the object lists for the Support Packages
in the queue.
왘 OBJECTS_LOCKED_?
This phase checks whether there are any objects that will be overwritten in
the import and that are contained in requests that have not yet been
released.
왘 ADDON_CONFLICTS_?
This phase checks whether there are any conflicts between objects in the
queue and installed add-ons.
왘 SCHEDULE_RDDIMPDP
This phase schedules the transport demon (program RDDIMPDP).
왘 Import 1 module
왘 CREATE_VERS_BEFORE
If this option is selected, this phase creates versions of the objects of the
Support Packages in the queue.
왘 SPDD_SPAU_CHECK
This phase checks whether a modification comparison (transactions
SPDD/SPAU) is required.
왘 DDIC_IMPORT
This phase imports all ABAP Dictionary objects in the queue.
왘 AUTO_MOD_SPDD
This phase checks whether modifications to ABAP Dictionary objects can be
automatically compared.
왘 RUN_SPDD_?
This phase instructs you to compare your ABAP Dictionary object modifica-
tions by calling Transaction SPDD.
왘 LOCK_EU (only in Downtime-minimized import mode)
This phase locks the development environment.
왘 DDIC_ACTIVATION
This phase activates the imported ABAP Dictionary objects.
왘 INACTIVE_IMPORT (only in Downtime-minimized import mode)
This phase imports program code and texts in an inactive state.
왘 Import 2 module
왘 IMPORT_PROPER
This phase imports all Repository objects and table entries that were not
imported in the INACTIVE_IMPORT phase. Actions such as table conver-
sions and name-tab activation are carried out beforehand.

왘 PREPARE_XPRA
This phase prepares the execution of the XPRAs and after-import methods.
왘 UNLOCK_EU (only in Downtime-minimized import mode)
This phase unlocks the development environment.
왘 AUTO_MOD_SPAU
This phase checks whether modifications can be automatically compared.
왘 XPRA_EXECUTION
This phase executes the XPRAs and after-import methods.
왘 ABAP_GENERATION
This phase generates the runtime objects for imported Repository objects
(ABAP source code, screens).
왘 RUN_SPAU_?
This phase instructs you to compare your Repository object modifications by
calling Transaction SPAU.
왘 CLEAR_OLD_REPORTS (only in Downtime-minimized import mode)
This phase deletes obsolete versions of program code and program texts
from the database.
왘 EPILOGUE
This phase closes the import. The system also checks whether the queue has
been fully processed.
Import SPAM/SAINT Update
SPAM/SAINT updates (known as SPAM updates for short) provide you with
updates and improvements to the Support Package Manager and the SAP Add-On
Installation tool. Every release comes with a SPAM update, which is then updated
as necessary over time. It is stored in the following locations in the system:
왘 In the short description; for example, SPAM/SAINT update version <REL>/0001
왘 In the package name; for example, SAPKD<REL>01
A SPAM update is always first in the list of Support Packages in the SAPNet-R/3
frontend. You can also find the latest SPAM update in the SAP Services Market-
place under http://service.sap.com/patches.
Note We recommend that you always import the latest version of a SPAM
update before importing Support Packages or Installation Packages.

A SPAM update can be successfully imported only if the system does not contain
any canceled packages. If the system does contain such packages, a dialog box
informs you of this, in which case, you can do one of two things:
왘 First, you can fully import the queue and then import the SPAM update.
왘 Delete the queue, import the SPAM update, and then import the queue.
You can delete the queue only if the Import 1 module has not yet been started
(up to phase SCHEDULE_RDDIMPDP).
To import a SPAM update, proceed as follows:
1. Open the Support Package Manager (Transaction SPAM).

2. Check that the SPAM update in question is more up-to-date than the version
that is currently in your system. (The latest version is displayed in the title bar
of the Support Package Manager.)
3. Once you're satisfied that the update you will be importing is the latest one,
choose Support Package • Import SPAM update. SPAM updates are automat-
ically confirmed after they have been successfully imported.
Loading Support Packages
Before you can import a Support Package, you first have to load it. SAP makes its
Support Packages available via the following channels:
왘 The SAPNet-R/3 frontend

왘 The SAP Service Marketplace
왘 Collection CDs
Proceed as follows to load Support Packages from the SAPNet-R/3 frontend so

that you can import the Support Packages in question with the Support Package
Manager:
1. Request the Support Packages you require in the SAPNet-R/3 frontend. To do

this, see Note 97621.
2. Load the Support Packages from the SAPNet-R/3 frontend to your SAP system
by choosing Support Package • Load Packages • From SAPNet-R/3 Front End.
The system displays a list of Support Packages. You can select the Support Pack-
ages you require before loading them.
The size of the uncompressed Support Packages is shown in bytes. This figure
gives you a rough idea of the time needed for the Support Package to load.
3. The status bar indicates whether the load process was successful.
4. Choose Goto • Back to return to the Support Package Manager.
5. Define the queue.

Note Before loading a Support Package from the SAPNet-R/3 frontend, make
sure that the network parameters for logging on to the SAPNet-R/3 frontend
are correct. You do this by using Transaction OSS1.
Figure 15.17 Loading support packages from the SAP Service Marketplace
Support Packages in the SAP Service Marketplace and on Collection CDs come in
a compressed format. You therefore have to decompress them before using them.
If the archives are located on your front-end computer, you can transfer these directly
to the application server from within the Support Package Manager and decompress
them there. However, if the archives are larger than 10 MB, proceed as follows:
1. Load the Support Packages from the SAP Service Marketplace or mount the rel-
evant CD.
2. Log on with the following user:
Operating system User
Unix <sid>adm
IBM eServer iSeries <SID>OFR
Windows <SID>adm

3. Switch to the following subdirectory in your system:
Operating system Subdirectory
Unix and IBM eServer iSeries trans
Windows TRANS
4. Use the following command to decompress the archive that contains the Sup-
port Packages:
Operating system Command
Unix SAPCAR -xvf /<CD_DIR>/<PATH>/<ARCHIVE>.CAR
IBM eServer iSeries SAPCAR '-xvf /QOPT/<VOLID>/<PATH>/<ARCHIVE>.CAR'
Windows SAPCAR –xvf <CD_DRIVE>:\<PATH>\<ARCHIVE>.CAR
The decompressed Support Packages are then automatically placed in the EPS
Inbox of your transport directory (Unix and IBM eServer iSeries:
/usr/sap/trans/EPS/in; Windows: <DRIVE>:\usr\sap\trans\EPS\in).
5. Now load the Support Packages into your system using Support Package •
Load Package • From Application Server.
A list is displayed of the Support Packages that you just uploaded, which are now
known to the SAP system with all their attributes and can be dealt with correctly
by the Support Package Manager.
1. Choose Back to return to the initial screen of the Support Package Manager.
If you want to load the archives (*.CAR/*.SAR) from the frontend to the applica-
tion server, and if the archives are smaller than 10 MB, proceed as described
below. If the archives are greater than 10 MB, the procedure described below will
not be efficient. Therefore, in this case, first transfer the Support Packages to the
application server by FTP, for example, and then load them from there.
1. Open the Support Package Manager (Transaction SPAM).

2. Choose Support Package • Load Packages • From Front End. The dialog box
for archive selection opens.
3. Select the relevant archive. This archive is transferred to the application server.
The archive's table of contents is then read and displayed in a dialog box.
4. Select Decompress to transfer the archive to the application server and decom-
press it. If you select the New Support Packages option and choose Display

under Directory in the initial screen, the corresponding package is displayed in

the Support Package Manager after the archive has been decompressed.
5. Choose Goto • Back to return to the Support Package Manager.
Define Queue
The queue determines which Support Packages are imported into your system by
the Support Package Manager, and in what order. If the queue has not yet been
fully defined, you now have to define the queue, making your selection from the
available Support Packages. If the queue has been fully defined, it is simply dis-
played, and you cannot change it. However, you can delete the queue entirely, if
required, by choosing Delete Queue.
Note You can delete the queue only if the Import 1 module has not yet been
started (up to phase SCHEDULE_RDDIMPDP).
The Support Package Manager ensures that only Support Packages that are suita-
ble for your system are displayed in the queue. Support Packages that are
intended for another release, or for an add-on that you have not installed, don't
appear in the queue, even if you loaded them into your SAP system.
You can define the queue on the basis of either the software components in your
system or a target Support Package.
Figure 15.18 Defining the import queue

1. To define a queue on the basis of software components, click on Dis-

play/Define in the initial screen of the Support Package Manager.
The Component Selection dialog box opens, and the list of installed software
components is displayed (such as SAP_BASIS, SAP_HR, SAP_BW).
2. Select the component you want. Alternatively, you can calculate a common
source for all software components in the system by selecting All Components.
3. The available queue is then displayed. The queue contains the Support Pack-
ages that are available for the selected component(s) in your system, and pos-
sibly also any Support Packages required for other components, Conflict Reso-
lution Transports (CRT), and any associated add-on Support Packages.
If you want to define the queue for another software component, select New
Component.
4. You now have the following options:
왘 If you're happy with the queue as displayed, choose Confirm Queue to con-
firm and close the dialog box.
왘 You also have the option to reduce the queue selection. To do this, select
the Support Package that you want to be the last in the queue. The queue is
then recalculated. You can also explicitly re-calculate the queue by selecting
Recalculate Queue.
To define the queue on the basis of a target Support Package, proceed as follows:
1. In the initial screen of the Support Package Manager, choose the New Support
Packages option under Directory.
2. Click on Display. The system displays a list of the Support Packages in the sys-
tem.
3. Place your cursor on the Support Package you require and click on Calculate
Queue. The queue is then displayed. This queue contains the Support Packages
that are available in your system for the target Support Package, and possibly
also any Support Packages required for other components, Conflict Resolution
Transport (CRT), and any associated add-on Support Packages.
4. Proceed as described under Step 4 in the section Defining queue on the basis of
software components above.
The following rules apply when you're creating a queue:
왘 Support Packages for a selected component are placed in the queue in

sequence.
왘 If Support Packages in the queue are linked to Support Packages of another
component (such as another predecessor relationship or a required CRT), other

Support Packages are added to the queue until all predecessor relationships are
accounted for.
Note The Support Package Manager takes into account the configuration of
your SAP system and places in the queue only those Support Packages that
your system can accept.
Import queue
The Support Package Manager provides the following two scenarios for importing
Support Packages or the queue:
The test scenario is used to identify any conflicts or problems (for example, repairs
that have not been released) before the actual import process. The test import
creates the list of objects to be compared in transactions SPDD and SPAU, and
should therefore be run in the project preparation phase. If you want to run the
test scenario, you have to specify so explicitly.
This scenario allows you to estimate—and, if necessary, to minimize—the time

and effort required to import Support Packages. No data is imported into the sys-
tem in this scenario, and if errors occur, you can continue the import without hav-
ing to correct them.
Note After the test scenario has run, the queue is then empty again and you
will have to redefine it. You then also have to explicitly select the standard sce-
nario.
In the standard scenario, the Support Packages contained in the queue are fully
imported. If errors occur, you can continue and complete the import only once
you have removed or resolved the errors.
Once you have selected the standard scenario, you can choose between conven-
tional import mode and Downtime-minimized import mode. The latter reduces
the length of the downtime.
Proceed as follows to import the queue in the standard scenario:
1. To set the standard scenario, select Extras • Settings.

2. On the Import Queue tab page, select Standard and make the other import
settings.
3. Select the import mode that you require.

4. Select Support Package • Import Queue. You can also use this function to
resume a previous import procedure that was canceled.
5. The dialog box for selecting the start options opens. Specify the required start
options and confirm the dialog box.
The Support Package Manager then completes the import, in accordance with the
import mode and start options you selected.
If you accept the standard start options without changing them, the Support
Package Manager handles the whole import process in the dialog box. The status
bar provides you with information about the progress of the import and the cur-
rent phases of the Support Package Manager. Note that your system should no
longer be live at this point.
If you selected a start time or Continue Manually for the Import 2 module, you
can keep the system in live mode until the Import 2 module starts.
If you accepted the standard start options without changing them, you can keep
the system in live mode for the time being, as the Support Package Manager will
explicitly request you to stop live operations when the time comes.
As usual, the Support Package Manager carries out all the preparatory and check-
ing steps (Preparation module). It then imports the inactive objects (Import 1
module), during which process the system can stay live.
The development environment is locked when the Import 1 module starts, so that
objects are not unintentionally modified and therefore the consistency of the sys-
tem is not jeopardized when objects are accessed by this module.
The Support Package Manager then notifies you in a dialog box that you have to
stop live operations for the next import module (Import 2).
왘 Click on Cancel to do this in an orderly manner.
Close any background jobs that are running. Request all users to close any
transactions that they are running and to log themselves off from the SAP sys-
tem.
왘 Click on Continue to continue the import.
The Import 2 module activates the objects that were previously imported in an
inactive state and imports the remaining objects from the Support Packages in
the queue.
Once this module has finished, the Support Package Manager informs you that
you can resume live operations in the system, provided that no changes, or at
most only small changes, were made to SAP objects.

왘 If you made changes to SAP objects, the Support Package Manager instructs
you to finish the modification comparison process.
If you have to compare Dictionary objects (Transaction SPDD), you must do
this immediately, whereas with Repository objects (Transaction SPAU), you can
either compare these objects immediately or at a later point, or in parallel with
the clean-up steps after importing a Support Package. To do this, proceed as
described in Section 16.3.
왘 To complete the import process, select Import Queue again.
The clean-up steps are carried out on the next import module (Clean Up), and
the import process is completed and closed.
You can define the start options for the individual modules in accordance with the
requirements of your system. If you confirm the dialog box without making any
specific settings of your own, the import tool uses the standard settings of the
selected import mode. You can store any settings you make as a template for
future import procedures.
The tab pages in the Start options for the queue dialog box allow you to select
the options you require for every module:
왘 Start in dialog immediately

Select this option if you want this module to start running immediately in the
dialog box. If you select this option for multiple modules, they are executed
immediately one after the other. The mode remains blocked for the duration of
the import.
왘 Start in background immediately
Select this option if you want this module to start running immediately in the
background. If you select this option for multiple modules, they are executed
immediately one after the other.
왘 Start in background later
Select this option if you want this module to start running in the background at
a later time. Specify the start date and start time you require in the input fields.
The No start after option allows you to specify that this module is to run only
in the period between the Planned start time and the current time. If no back-
ground process is available in this time period, this module is not started.
왘 Manual Start/Continue Manually
Select this option if you want to manually start processing of this module. The
import tool stops the processing process once the previous module has fin-
ished.

Figure 15.19 Defining the start options
If you selected the conventional import procedure (Downtime-minimized is not

activated), the following standard settings apply:
Module Option
Preparation Start in dialog immediately
Import 1 Continue in dialog immediately
Import 2 Continue in dialog
Clean Up Continue in dialog
If you have selected Downtime-minimized import mode, the following standard

settings apply:
Module Option
Preparation Start in dialog immediately
Import 1 Continue in dialog immediately
Import 2 Continue manually
Clean Up Continue manually

Downtime-Minimized Import Mode
As a rule, the process of importing the latest OCS packages (Support Packages,
Add-on Installation Packages, add-on upgrades) requires a relatively long system
downtime due to the size and scope of these packages. Although the system is
not restarted in the import process, it should still not be used for live operations
during this process. This restriction is a distinct disadvantage in many live systems.
Thus, Downtime-minimized import mode was developed to reduce the downtime

required for package imports. This mode enables you to import the majority of
import objects while keeping the system live. The objects in question are program
code and program texts. Therefore, downtime can be reduced greatly if a package
contains a high proportion of program code and texts. (This figure is approxi-
mately 70–80 % for SAP Basis and SAP_APPL Support Packages.)
In Downtime-minimized import mode, the objects are imported into the database
in an inactive state and are mostly “invisible“ to the system. The system can con-
tinue to stay live.
This procedure contains new actions (activation of inactive objects) and more
organizational steps than the previous mode, which means that the whole import
process takes longer in this case. The efficiency and time-savings in the non-live
phase of this mode, as compared to conventional mode, depend on two things:
the proportion of inactively imported objects of the overall volume of imported
data, and the amount of time consumed by additional actions that have to be car-
ried out during the downtime (such as the handling of after-import methods and
XPRAs).
Note Import the packages in queues that are as large as possible. Ideally, put
all packages in one queue to benefit most from this method. You should note,
however, that in some cases Support Packages cannot be imported in one
queue using the Support Package Manager. Consult the relevant SAP Note in
your release for more information.
Because the inactively imported objects are stored in the database at the same
time as the active versions, more space is temporarily required in the database.
The objects are activated later by a defined process that is provided by the import
tool (Support Package Manager/SAP Add-On Installation Tool). Nevertheless,
inactive objects are not fully isolated from the system, which means that parallel
changes can cause unwanted activations and therefore system inconsistencies.

During the import, you should ensure the following:
왘 There is enough free storage space in the database
왘 There are no simultaneous imports of transport requests
왘 The development environment is not in live use
Use Downtime-minimized import mode in the following situations:
왘 In live systems
왘 In test systems, if you want to test the expected downtime in the live system
During the import process, you should treat the systems like live systems (no
manual changes to program objects, no parallel imports of other transport
requests).
Do not use Downtime-minimized import mode in the following situations:
왘 In development systems or in systems into which a lot of regular imports are

made (such as QA or test systems)
System consistency cannot be guaranteed during the import if manual changes
are made to program objects, or if other transport requests are imported at the
same time.
왘 To import Support Packages to BBP/CRM systems
The additional preparation and clean-up steps required by the special Support
Package Manager for BBP/CRM mean that the whole import process effectively
takes place during downtime.
왘 To import Preconfigured Systems (SAP Best Practices) using the Add-On Instal-
lation Tool
Importing Support Packages into a System Landscape
Support Packages can be imported in groups or individually. If you have multiple

SAP systems in a system landscape like DEV, QAS and PRD, you must import Sup-
port Packages into each of these systems.
You can use the aforementioned procedure to import Support Packages into your
landscape's development system, but the procedure is different for the other SAP
systems in your landscape, especially if you have to carry out a modification
adjustment. Figure 15.20 shows an example of how Support Packages can be dis-
tributed in a three-system landscape.

Patch Queue Patch Queue 4 Patch Queue 7

1
Run Run Run
SPDD SPDD QAS SPDD
DEV PRD
2 5 8
3
Run
SPAU 6
9
SPAU
Change
Request
Figure 15.20 Distribution of support packages in a three-system landscape
Ideally, all SAP systems have the same release level, which is the case after they
are installed, after an SAP release upgrade, or after the rollout in the implementa-
tion phase. If all SAP systems have the same release level, you can import one or
more Support Packages in the same way as you import change requests:
1. Import the Support Packages into the development system (Step 1 in Figure
15.20). The system compares all objects that were imported with the Support
Package and that have been modified by the customer:
왘 You may need to carry out a modification comparison for the Dictionary
objects using Transaction SPDD in the development system (Step 2 in Figure
15.20). The changes that result from the comparison can then be included in
a change request. However, unlike with release upgrades, this request can-
not be used for an automatic modification comparison of ABAP Dictionary
objects in follow-on R/3 systems (see below). Instead, the comparison pro-
cedure must be repeated manually in every SAP system (Steps 5 and 8).
왘 You may need to carry out a modification comparison for the SAP Reposi-
tory objects using Transaction SPAU in the development system (Step 3 in
Figure 15.20). The changes that result from the comparison can then be
included in a change request. This change request can be used to transport
the modification comparison of the SAP Repository objects to other sys-
tems. If extensions were used to make changes to the SAP system (see
Chapter 2), there is no need for a comparison, since extensions don't intro-
duce modifications.

2. Import the Support Packages into the QA system (Step 4 in Figure 15.20).
3. Import the change request with the changes from the modification comparison
(if any) into the QA system (Step 6 in Figure 15.20).
4. Verify the Support Package using operational validation tests. If changes have to
be made due to Support Package imports, make the changes in the develop-
ment system and then test them in the QA system.
5. Once you have tested and verified the Support Packages, import them into the
live system (Step 7 in Figure 15.20) along with all transport requests associated
with the Support Packages (Step 9 in Figure 15.20).
6. Once you have carried out the modification comparison of ABAP Dictionary
objects in the development system, you then have to manually repeat this
process in every follow-on SAP system, using Transaction SPDD (Steps 5 and 8
in Figure 15.20).
It is a prerequisite of this process that no change requests for the import are wait-
ing to be processed in the QA or in the live system. To put it another way, the SAP
systems—especially the QA and the live systems—must all have the same release
level. The validation process in the QA system ensures that the Support Package
and all the change requests that result from the modification comparison can be
imported into the live system.
Support Packages and Development Projects
It is more difficult to schedule Support Package imports if large development

projects are ongoing in your system landscape. This is because you're not sup-
posed to make transports between systems with different Support Package levels.
Therefore, development projects cannot be imported into the live system until
the Support Packages have been imported into all systems in the landscape.
Despite efforts to keep this “code freeze“ period as short as possible, experience
shows that one to two weeks have to be allotted for the SPAU comparison in the
development system, and then approximately two to four weeks must be sched-
uled for the integration test in the QA system. Of course, these time periods are
average values and are subject to change in different systems.
The time and effort required for the SPAU comparison increases along with the
number of modified and customer-specific objects. In addition to the objects
listed in SPAU, any customer-specific objects that access SAP standard code also
have to be checked. The SAP Code Inspector (Transaction SCI) is an automated
tool for performing this task, and enables you to carry out an extended syntax
check for all customer-specific objects.

The time and effort required for this check depends on the number of business
processes in use. The SAP system administrator has to decide whether to test only
the most important business processes, or whether more minor processes should
also be included in the test. Therefore, it is necessary to categorize the business
processes according to their importance (ABC analysis) in advance. A well-organ-
ized test management process and the ready availability of automated test cases
(eCATT tool) reduce the time and effort required for the test and thereby shorten
the duration of the code freeze period.
Before Support Packages are imported into the development system, any open
change requests should be released and imported to the follow-on systems. Once
the Support Packages have been imported into the development system and the
SPAU comparison is complete, you may be able to resume development work in
the development system. But, the danger still exists that errors detected in the
Support Package tests may be difficult to solve in the development system,
because the development system may have a more up-to-date software release.
The safer option would therefore be to resume work in the development system
only once the Support Packages have been tested and found to be error-free. In
every case, all transports in the QA system must be suspended for the duration of
the integration test.
Because of these effects on development work, the timing of Support Package

imports must be carefully planned and coordinated with the development project
teams.
Some SAP customers first test Support Package imports and the SPAU comparison
in a sandbox environment in order to minimize the code freeze period. Initial
functional tests can also be carried out in the sandbox system.
You can also use the latest Support Package level for the relevant development
projects, and then transport the changes along with the Support Packages
through the maintenance landscape. The advantage of employing this method is
that only one test is required for Support Packages and development projects.
Note that this approach requires a phase-based system landscape, as described in
Section 3.6.2.
15.3.2 Modification Comparison

The modification comparison must be run for Support Packages imports, just as it
does for a release upgrade. However, with Support Package imports, unlike with
release upgrades, the SPDD comparison must be run separately in every system.
A transport request can be imported from the development system to the follow-
on systems for the SPAU comparison only.

Because Section 16.3 deals with the topic of modification comparison in greater
detail, we won't discuss it further here.
15.4 Support Package Stacks

In 2003, SAP added 'Support Package stacks' (SP stacks) to its Support Package
strategy for some product versions. This new strategy supports the import proce-
dure of most customers and Support Packages, improves quality and service, and
thus reduces ongoing operating costs.
The increasing range and complexity of components within individual product

versions makes it necessary to improve the transparency of Support Packages and
patches, and to clearly specify the recommended or permitted combinations.
Therefore, a new SP stack is compiled for every product version that is updated
via the new strategy, usually on a quarterly basis. This stack contains the optimal
combination of Support Package and patch levels for the individual components
at the time of the stack release.
The SP stacks are therefore combinations defined by SAP for each product ver-
sion. SAP recommends that you import these SP stacks on a regular basis instead
of choosing different Support Package levels per different Software Component.
While the underlying technology of the individual Support Packages and patches
does not change with this stack approach, an SP stack is intended to be regarded
as a whole. In other words, while you should take into account any minimum
requirements of or dependencies between the individual components, the Sup-
port Packages and patches contained in the stack must be imported together to
utilize the benefits shown in the following chapter.
By reducing the range of theoretically possible combinations to practical, real-

world combinations, there are several benefits for the customer that result:
왘 The quality of the individual Support Packages is improved, as other associated

components are maintained to a known minimum level, so that corrections are
less complex and of a higher quality.
왘 Quality and compatibility within the set combinations are improved, as SAP's
own tests can focus more on these combinations.
왘 Download pages that are specially tailored to SP stacks make it easier to down-
load required Support Packages and patches.
왘 Import instructions can also be tailored for the combination to be imported,
thereby reducing the time and effort required for the import process.
왘 The general level of knowledge about any restrictions, and transparency about
side effects and their solutions, are better overall for SP stacks than for individ-

ual combinations. Potential problems can be prevented and, when they occur,
solved more effectively, which, in turn, reduces operating costs.
SP stacks support the requirements of customers with live applications for regular
Support Package and patch recommendations, plus their need for the minimum
total cost of ownership (TCO). For customers with upgrade or implementation
projects, the minimum requirements may involve other (higher) recommenda-
tions than the most recent SP stacks.
Implementing SP stacks leads to a reduction in complexity, increased quality,

improved transparency, and simplified repairs and maintenance. SP stacks further
reduce the risks to live operations and help to expedite the resolution of any
problems. They are just another step toward reducing the total cost of ownership
(TCO).
Once an SP stack is released, details of the relevant information and download

site are available from the SAP Service Marketplace via the Quick Link /sp-stacks
• SP Stack Information & Download or under the /patches alias (head of the navi-
gation hierarchy) • (Product) • <Product version>.
Additional information on specific SP stacks is available from the pertinent

Release and Information Note (RIN), which is available via a link on the aforemen-
tioned page.
Figure 15.21 Downloading support package stacks from the SAP Service Marketplace
Support Package Stacks 523

15.4.1 SP Stack Strategy with the Usual Import Procedure

It has been shown that most customers carry out planned maintenance for each
live application between one and four times a year, and that this maintenance
process usually covers all the components of each application.
In practice, the frequency of planned maintenance operations depends on many

factors. These include the following:
왘 The customer's own specific situation (projects, live status, etc.)
왘 The product in question (technical factors, statutory changes, etc.)
왘 The benefits of having the latest release when support is required
왘 The customer's own assessment of the risk of encountering known errors (and
thus of incurring unnecessary costs and having to react at short notice)
왘 The expected costs of a planned maintenance operation
There is therefore no standard rule for calculating the optimal time and frequency
of planned maintenance operations. Customers decide on the optimal conditions
for themselves, with regards to their own individual circumstances. However, SAP
recommends that customers run a planned maintenance operation at least once a
year, and preferably two to four times a year, whether or not problems have
arisen, so that the risks outlined above don't become too great. SAP assumes that
the latest SP stack will be imported as part of a planned maintenance operation,
and that the SP stacks in use in a system landscape are not retained beyond one
year. As before, if problems occur, SAP can instruct the customer to import the
latest Support Packages or patches, independently of the SP stack cycle.
Unexpected problems can occur at any time, regardless of planned maintenance

operations. They have to be fixed as quickly and as straightforwardly as possible.
A range of different mechanisms is available for this purpose, and the decision
regarding which device to use depends on the affected component and the actual
problem. These mechanisms include correction instructions for ABAP-based
tracks (which can solve problems relatively locally and in a targeted way) and ker-
nel patches (which, for technical reasons, usually contain other problem solutions
and whose effects are therefore less restricted to the local environment).
The SP stack strategy runs with this conventional combination of planned main-
tenance and interim local corrections.
왘 The quarterly frequency of SP stacks is intended to complement the frequency

of planned maintenance operations. This does not mean, however, that
planned maintenance must be carried out every quarter. Based on your assess-
ment of the aforementioned factors, you can temporarily postpone the import

of an SP stack, provided that your system does not contain any errors that
necessitate the import of up-to-date Support Packages or patches. You can
catch up with any Support Packages that you postpone when you import the
next SP stack.
왘 SP stacks contain Support Package combinations that you should change only
in exceptional cases; for example, if a problem has occurred that can be solved
only by a change. In such cases, you should keep the modification as small and
as local as possible. Of course, you can also import new Support Packages or
patches as a preventative measure, if circumstances in the system are such that
the error in question is likely to occur. But, in many cases, you will be able to
make a local correction via the correction instruction in a Note, for example.
왘 Components of an SP stack that are not in use, or not in live use, in a system
landscape don't have to be patched when an SP stack is imported, provided
that they have no technical or logical dependencies with any components that
are in active use. But you should note that the Support Package or patch levels
of components that are in use cannot be lower than the levels of the combina-
tion set in the SP stack.
If unexpected problems are identified after the release of an SP stack, these prob-
lems will be resolved by additional single notes, which will be added to the side
effect notes reporting.
A Release and Information Note (RIN) is used to inform all customers of the gen-
eral release of an SP stack and possibly also about potential problems. As before,
notice of critical errors is communicated via HotNews Notes. A special reporting
tool in the SAP Service Marketplace can be used to find out about known side
effects of all kinds of Support Packages (Quick Link /side-effects).
An SP stack thus remains valid until the next SP stack is released. Unexpected
problems are communicated to customers according to the problem's level of
severity. The focus in SP stacks on specific combinations means that potential
problems can be identified and solutions can be found earlier on in the process.
Any differences between Support Package levels or patch levels and the relevant
SP stack should be documented in Notes. This approach is used only for problems
or other special cases (such as statutory changes or for customers' project or
implementation phases). This also applies to Support Packages or patches that
have been created since the last SP stack and that will be part of subsequent SP
stacks.
It is also possible that there may be Support Packages or patches that are more
up-to-date than those contained in the last SP stack. Nevertheless, as long as your
system is not experiencing any particular problems, the general recommendation
Support Package Stacks 525

is that you use the combination contained in the latest SP stack. Any Support
Packages or patches that are created in the interim are reserved for the special
cases mentioned above.
15.4.2 Details of the Components in SAP Support Package Stacks

Based on one 'leading' application component, SP stacks represent one combina-
tion of preset or recommended Support Package levels and patch levels of the
other components of a product version. Dependencies are defined step-by-step
in a “top-down“ fashion (see the example below).
Stacks specify one level for each possible release for some components, such as
the SAP GUI. Other components may be optional; that is, the relevant Support
Package or patch level must be fulfilled only if the component in question will be
in use in a production system (for example, an R/3 Enterprise Extension).
The basic rule here is that the other components must have at least the specified
level for it to be possible to import a Support Package for the leading component.
Also, a higher level is recommended for most components only for those prob-
lems where there is no local correction (such as a correction instruction) or a
workaround.
An SP stack can consist of the following:
왘 A Support Package level of a leading application component (such as SAP_

APPL 4.6C), which serves as the name of the SP stack
왘 A Support Package level of the application basis (such as SAP ABA 4.6C) that is
a prerequisite for the aforementioned application Support Package and that
would not usually be overwritten until the next SP stack
왘 A Support Package level of the basis layer (such as SAP Basis 4.6C) that is a pre-
requisite for the aforementioned ABAP Support Package and that would not
usually be overwritten until the next SP stack
왘 A recommended kernel patch level (such as SAP KERNEL 4.6D) that would not
usually be overwritten until the next SP stack, provided that there are no prob-
lems
This kernel patch level is intended for use on the operational level and can be
higher than the level of an upgrade for the release in question (in this case, fol-
low the instructions in the upgrade documentation or the relevant Notes).
왘 A minimum patch level for every possible SAP GUI release (such as 4.6D/6.20
for Windows, 6.20/6.30 for Java)
Note that the releases in this case should initially be regarded as alternatives
and that each patch level is a minimum requirement that can be overwritten at
any time. This minimum requirement within an SP stack will be increased in

exceptional cases only. But, because the SAP GUI is a component of almost all
SAP products, the requirements of the SP stacks of various products that are
used in parallel must be coordinated with each other. In this case, the maxi-
mum required SAP GUI releasehis case, the maxoimuumthe maxoimumoducts
can be pocase, follow if problems for which thration is still that you use th with
the maximum required patch level is what is relevant. Other conditions may
arise in the context of product-specific GUI add-ons.
왘 Possibly, a minimum patch level for every possible SAP ITS release (such as
4.6D, 6.10, 6.20) could occur. The various releases should be regarded as alter-
natives, similarly to the SAP GUI.
왘 Another condition that might arise could be that other optional components
require the specified level only when the component in question is in produc-
tion use.
15.4.3 SP Stack Calendar

Either the product versions listed in the SP stack calendar are already supported
by SP stacks, or SP stacks will be introduced for them in the near future. Every SP
stack is “led“ by a particular component or Support Package track, and the rele-
vant Support Package is a central component of this. Once the first SP stack is
released, this signals the start of the new strategy for that product version.
Figure 15.22 Support package stack calendar
15.5 Side Effects

The SAP Service Marketplace contains a new reporting tool that helps you to
avoid unwanted side effects. Side effects can occur in rare cases after a Support
Package or a SAP Note is imported. The aforementioned tool enables SAP cus-
tomers to reduce their internal support costs and to increase the stability of their
SAP solution.
Side Effects 527

SAP Support Packages consist of several SAP Notes, each of which contains soft-
ware corrections. Importing Support Packages and Notes increases system stabil-
ity and protects the system from known problems. Nonetheless, it can still hap-
pen that a Note that is intended to solve one problem can actually cause another
problem. To solve this new problem, a new Note is then created that is linked to
the first Note.
The new tool is intended to make these dependencies easier to handle. If you're
importing a Support Package or a SAP Note, you can search for any known side
effects and correct these, if necessary. This tool enables you to proactively prevent
problems that could occur after an import.
Information about side effects is defined in the Note attributes. The reporting tool
identifies all the side effects that will be caused by the Notes contained in the
Support Package. Therefore, to protect your system from unwanted side effects,
import these Notes after you import the Support Package.
The Quick Link http://service.sap.com/notes in the SAP Service Marketplace con-

tains information about known side effects of individual SAP Notes.
Figure 15.23 Side effects of an individual note
To obtain a list of all the side effects of a Support Package or an SP stack, use the
reporting tool in the SAP Service Marketplace (Quick Link: http://serv-
ice.sap.com/patches • Support Packages in Detail • Side Effects of SAP Notes.)
Use this tool just before you import the Support Package in question to see the
most up-to-date list of side effects.

Side effects that have already been eliminated by other Support Packages in the
same queue are automatically removed from the results list. The results list is spe-
cially tailored to your Support Package queue. It is sorted by application compo-
nent, so that you can easily skip Notes that belong to applications that you don't
use.
Note that it can take several hours to create the results list. Therefore, the system
sends you an email when the list is complete.
SAP began its side-effect reporting activities in July 2003. There is no complete
information available on the side effects of earlier Notes.
Figure 15.24 Side effects of support package queues
15.6 Questions
1. What are the benefits of importing SAP Support Packages?
A. Proactive solution of known problems
B. Functional extensions to SAP software
C. Improved ease of maintenance and reduced time and effort for repairs and
maintenance
2. Which of the following statements are true of the SAP Note Assistant?
A. It simplifies the maintenance of programs in the customer namespace.
B. It enables you to import Notes that contain code corrections.
C. It simplifies the process of making changes to Data Dictionary objects.
Questions 529
D. It identifies dependencies between SAP Notes.

E. It can replace the process of importing Support Packages.
3. Which of the following statements are true of Support Packages?
A. They change the SAP standard of your SAP system before the next release
upgrade.
B. You can import all types of Support Packages into all SAP systems, regardless
of the components installed in the target system.
C. Support Packages are available only to customers who are taking part in the
ramp-up.
D. Different types of Support Packages may be required for SAP systems with
different components.
4. Which of the following statements are true of the SAP Patch Manager?
A. The Patch Manager ensures that Support Packages are imported in the cor-
rect order.
B. The SAP Patch Manager does not check whether the type of Support Pack-
age that you want to import is suitable for your SAP installation. You have to
determine whether you need a particular Conflict Resolution Transport, for
example.
C. The SAP Patch Manager does not allow you to protect SAP objects that you
have modified. These objects are automatically overwritten.
D. The SAP Patch Manager automatically opens transactions SPDD and SPAU
for the modification comparison process, if required.
5. Which of the following statements are true of Support Package stacks?
A. Support Package stacks are combinations of Support Packages that are rec-
ommended by SAP.
B. Support Package stacks should be imported only if an urgent problem is pre-
venting an import from being carried out.
C. Support Package stacks are Support Package combinations that have been
particularly well tested by SAP.
D. The SAPGUI version also must be upgraded to the latest level with every
Support Package stack upgrade.

Index
24-hour maintenance 178 AS/400 system 183
5-1-2 maintenance strategy 532 ASAP 670
Assembly 612, 613
A Audit history 289
ABAP 669 Authorization assignment testing 100
ABAP Dictionary 669 Authorization Object 290
ABAP Dictionary activation 467 Authorization Profile 106, 290
ABAP Dictionary Maintenance 44 Authorization technique 129
ABAP Dictionary tables 360 Authorizations 390
ABAP Editor 44, 322, 669 NWDI 629
ABAP Programs 396, 464 Automatic Display 393
ABAP Workbench 29, 37, 44, 669 Automatic Logon 648
ABAP Workbench tools 316 Automatic recording of changes 345,
abap/Ntfmode 198 670
abapntfmode 649 Automatic transport 356
Action Log File 423
Action Logs 374 B
Activating Object Checks 384 Background Job 203
Activation 669 Background processing 670
Activity 636, 639 Background Scheduling 279
Activity group 669 Background Work Processes 204
Activity Logging 287 Backup Domain Controller 209, 223,
actlog 180, 460 670
Add-On Patches 669 BAdIs 47
ADIRACCESS 325 BAPI 670
Adjusting Transports 424 Batch input 670
Adjustment transport 548 Buffer 180, 460
ADO 669 Buffreset 649
Advanced Business Application bufreftime 650
Programming 669 Build
ALE 105, 669 incremental 641
ALE Customizing Distribution 669 Build process 613
Alert Monitor 251, 669 Build space 641
alllog 649 Business Configuration Sets 84, 368,
Alternative Phased System Landscape 670
80 Business integration testing 670
API 669 Business Processes 37
Application Data 32, 34, 57, 100, 669 Business scenarios 162
Application Link Enabling (ALE) 102, Business Server Pages 609
258, 669 Business Transaction 38
Application Programming Interface Business Validation 161
669 Business validation and stabilization
Application Server 28, 670 cycles 137
ArchiveLink 670 Byte code 611
Archiving object 670
715
C Client Protection 260

c_import 650 Client Restriction 261
CA 672 Client Role 259
Canceled Client Copy 277 Client Setting 257, 671
CATT 104, 670 Client Tool 255, 290
CCMS 670 Client Transport 123, 262, 267, 276, 671
Central transport directory 185 Client/server architecture 26
Central User Administration 106 Client-dependent 671
Change and Transport Organizer (CTO) Client-Dependent Change Option 60,
98, 129, 173, 198, 670 89
Change and Transport System 87 Client-Dependent Customizing 375
Change and Transport System (CTS) Client-Dependent Data 31
98, 671 Client-independent 143, 671
Change document 289 Client-Independent Change Option
Change list 637 61, 89
Change Management 588, 671 Client-Independent Customizing 63,
configuration and setup 590 69
Change Management Service Client-Independent Customizing Acti-
domain creation 634 vities 352
track creation 634 Client-Independent Customizing
Change of release 531 changes 124
Change processes 595 Client-specific standard transport layer
Change Request Strategy 119 249
Change Requests 88, 96, 98, 120, 121, Client-Specific Transport Layer 247
139, 144, 148, 315, 338, 340, 342, 347, Client-Specific Transport Route 245,
380, 399, 413, 671 671
Change Requests and Task 90 CMS domain 634
Change requests in 401 CMS users 630
Change tracking 592 CMSuser 631
Changes 91 CO 672
Client 671 Code freeze 553
Client Change Option 60, 115, 260 cofilelifetime 650
Client compare 671 cofiles 460
Client Comparison 361 column Key field 288
Client Copy 35, 109, 143, 274, 281, 671 Command Syntax 434
Client copy according to a transp. Common objects 351
request 671 Common Programming Interface-
Client copy logs 275 Communication 672
Client Copy Profile 263, 264, 265, 275, Communication data 223
671 Company code 73
Client Copy Strategy 123 Comparison client 365
Client Copy Tool 261, 290 Comparison runs 580
Client Entries 256, 257 Complex System Landscape 72, 243
Client Export 125, 268 Compress Function 386
client export change request 271 Computer Aided Test Tool 104
Client Impact 278 Computer Aided Test Tool (CATT) 165
Client Import 269, 271 Computer Aided Test Tool see CATT
Client maintenance 114 104
716
Configuration 426 Customizing change request 341, 350,

Configuration Process 228 672
Conflict Resolution Transports 671 Customizing changes 273, 344
Consistency 79, 234, 320, 409 Customizing comparison 583
Consistency Check 415 Customizing Cross-System Viewer
Consolidation Route 211, 241, 672 359, 360, 672
Consolidation system 672 Customizing data 32, 33, 125, 282
Container (J2EE) 612 Customizing Differences 365
Control file 672 Customizing Distribution 574
Control Panel 672 procedure 577
Controlled Availability 672 requirements 575
Copy profile SAP_EXPA 269 Customizing environment 58
Copy tool 267 Customizing in Two Clients 359
Copying R/3 Systems and Client 107 Customizing object 88, 350
Correct type 315 Customizing Organizer 140, 146, 672
Correction R/3 Release 672 Customizing Organizer (CO) 350
Costs 69 Customizing Prerequisites 335
CPI-C 672 Customizing Scout 574, 579
Creating target group 247 Customizing settings 83, 114, 127, 347
Critical activities 44 Customizing Synchronization 573
Critical Client 54 Customizing task 349
Critical object check 417 Customizing Transfer Assistant 369,
Critical Objects 416, 417 370, 672
Critical Write Access 229 Customizing-and-development client
Cross-client 43, 672 (CUST) 54, 61, 119
Cross-System Tool 84
Cross-System Viewer 361, 647 D
CRT 671 Data 460
ctc 651 Data archiving 673
CTO 670 Data Component 25
CTS 87 Data file 673
CTS administration authorization 394 Database 673
CTS Project Management 142 Database copy 673
Current Settings 357, 672 Database instance 673
Customer Data 29 Database parameter 187, 192, 193
Customer Development 45, 672 Database requirement 64
Customer Development Class 46 Database Server 28, 673
Customer development class Database tables 468
create 298 datalifetime 651
Customer exit 47 DBA 673
Customer name ranges 305 dbcodepage 651
Customer Object Names 304 dbconfpath 652
Customizing 38, 55, 83, 87, 113, 115, dbhost 652
116, 126, 140, 672 dblibpath 652
Customizing activities 43, 138, 288, dblogicalname 653
357, 358 dbname 653
Customizing Activity Log 672 dbswpath 653
Customizing change 349 dbtype 653
717
Default Change Request 347 EDI 673

Default Project IMG 344 Electronic Data Interchange 673
Deleting an R/3 Client 282 Emergency fix 156
Delivery class 673 Emergency Production Fixes 158
Delivery Route 212, 242, 246, 673 End Mark 407, 414, 436, 674
Delivery system 96, 673 End-user training 68, 70, 100, 564
Delta Customizing 673 End-user training client 59
Deployment descriptor 612 Enhancement 46, 674
Design Time Repository Enqueue 674
check-in 639 Enqueue conversion 444
structure 640 Enterprise IMG 40, 336, 674
DEV 248, 333 eps 180
Development Change 87 Error 454
Development Class 306, 332, 353, 673 Error message 648
Development class $TMP 329 Error messages 251
Development Classes 296 Errors 379
Development component 632 Exchange rate 286
Development configuration 632, 635, Expert Mode 409, 410
636 Export 387, 674
Development configuration pool 632 Export process 146, 373, 387
Development namespace 202 Exported Data 388
Development object 632 Exporting Change 93
Development Prerequisites 295 Exporting data 123
Development System 77, 131, 132, 151, Extended Transport Control 244, 406,
196, 673 419
Development track 635 Extended transport control 150, 674
Development/correction 309 External System 221, 674
DEVK900383 454
Dialog box 673 F
Dialog work process 673 FCS Final Delta Patches 674
Dictionary structures 443 Field exit 47
Differences 371 Final quality assurance system (FQA)
DIR_TRANS 195 78
Display Options 403, 405 Firewall 674
Distribution process 219 First Customer Shipment (FCS) 674
Distribution Status 227 First Production Customer (FPC) 674
Documentation 374 Foreign group 424
Documentation Requirement 325 Forward 674
Documenting 373 Four-System Landscape 71
Domain Four-system phased landscape 80
creating in the CMS 634 Full Control 182
Domain Controller 214 Function Builder 45
Domain Name Server (DNS) 183 Function module exit 46
Downtime Assessment??? 566 Functional R/3 Release 674
Dummy 654 Functionality testing 100
Further Users 313
E
Eclipse 615
718
G Import time 443

General Availability (GA) 675 Importing Change 94
Generic Log Files 446 Importing Master Data 101
Global System Change Option 200 Inconsistencies 149, 413
Global System Landscape 72, 81 Individual Change Requests 438
Global Template 82 Industry Solution (IS) 112, 676
Graphical Editor 241 informix_server 654
Graphical tool 39 informix_serveralias 654
Group identification number (GID) informixdir 654
182 informixsqlhost 654
GUI 675 Initial tasks 312
Initializing the TMS 214
H Installing 117
Handling of errors 155 Instance number 184
Heterogeneous Environment 197 Integration system 676
Hierarchical display 311 Interface 104
High availability 675 Interface technology 102, 103
Host systems 196 Internet Transaction Server (ITS) 676
Hot Packages 675
J
I J2EE engine components 610
ICNV phase 539 J2EE Explorer 638
IDoc type 675 Java applets 612
IMG Customizing activities 63 Java archive 613
Implementation 17, 135 Java development process 611
Implementation Guide (IMG) 37, 40, Java development scenarios 619
675 Java Enterprise Beans 609
Implementation Phase 137, 152 Java Enterprise Runtime 609
Implementation Project 137 Java projects, transporting 642
Implementing in Phases 138 Java Server Pages 609
Import 675 Java servlets 612
Import All 408, 675 Java Software Development Kit
Import Buffers 435, 437, 675 (J2SDK) 613
Import Considerations 150 Java Virtual Machine (JVM) 611
Import dispatcher RDDIMPDP 465
Import functionality 431 K
Import Logs 153 k_import 655
Import Monitor 422
Import Options 159, 439, 675 L
Import Overview 399, 400 LAN 676
Import phases 442 Language 655
Import Problem 452 Language Transport Utility 112
Import process 147, 467 Layered development 625
Import Queue 94, 97, 146, 151, 158, Legacy system 676
271, 399, 401, 405, 412, 413, 435, 675 Legal Change Patch (LCP) 676
Import queue documentation 159 Local and Remote Client Copy 266
Import schedule 152 Local Change Request 308, 676
Import Steps 444, 446, 448 Local client copy 262
719
Local object 676 Multiple Delivery Route 242

Locking 320 Multiple Production System 74, 75,
Locks 676 105
Log 180, 460 Multiple Production System
Log Files 377, 446 Landscape 72, 73, 75
Logging 285 Multiple subsidiaries 81
Logical system 676 Multiple-client capability 63
Logical System Name 258 Multiple-Client Operation 65
loglifetime 655 MV75AFZ1 49
M N
Maintenance strategy 531 Name Range 202, 677
Managing Development Changes 295 Namespace 202, 677
Mandatory activities 44 Nametab 677
Manual modification 166 Naming Convention 306
Manual transport 355, 356, 676 Navigation area 240
Manually Recording 346 nbufform 656
Mass activator 470 NetWeaver Development Infra-
Master Data 101, 676 structure (NWDI) 609
Memory Requirement 280 New R/3 System 216
Menu exit 47 New transport route 240
Menu Painter 45 new_sapnames 657
Merging Change Requests 382 NFS (network file system) 179
Merging two change requests 382 No transport 356
Modifiable 201 Non-critical activities 44
Modifiable change request 382 Nondevelopment Systems 396
Modification 48, 168, 676 Nonstandard Customizing Activities
Modification adjustment 50, 542, 676 351
during release changes 546 Notification of Imports 154
programs 544 Number Range 282
tables 544
Modification assistant 50, 322, 551, O
676 Object Attributes 328
Modification Browser 323, 677 Object Checks 384, 386, 677
Modifications 321, 324 Object dependencies 409
Modifikation adjustment Object Directory 326, 677
during the import of Support Object Directory Entry 328, 329
Packages 548 Object list 317, 318, 347, 380, 677
Monitoring Imports 422 Object locked 379
mssql_passwd 656 Object Locking 315
mssql_user 656 Object name 326, 353
Multi-layered development 242 Object type (Obj.) 326
Multi-Layered Development Project OCS 677
241 olddata 180
Multiple Change Requests 410 olddatalifetime 657
Multiple Clients 63, 418, 440, 441 One-System Landscape 69
Multiple Customizing-and- Online Correction Support (OCS) 677
Development Client 78 Operating System 184
720
Operating System Level 173, 463 Program identification (PgmID) 326

opticonnect 658 Project IMG 141, 338, 677
Optional activities 44 Project IMG to 337
Original object 677 Project IMG views 677
OS 677 Project IMGs 42, 336
Owner 342 Project management 40
Ownership of 313 Project management capabilities 337
Project Team 42, 140
P Project team members 340
Parameter Types 190 Promoting Change Requests 373
Path-Specific Parameter 193 Protective measures 65
Performance 677
Performing Checks 415 Q
Performing Imports 405 QA Approval Process 157
Permanent Inconsistencies 458 QAS 66, 237, 248
Phased Implementation 77 Quality Assurance 66, 92, 117
Phased System Landscape 72, 76 Quality assurance activities 71
Physical transport directory 176 Quality assurance client (QTST) 55, 125
Post-Import 273 Quality assurance system 66, 95, 97,
Post-Import Issues 153 120, 128, 149, 677
Post-Import Processing 273 Quality assurance system (QAS) 176
Predefined Variables 190 Quality assurance test client (QTST)
Preliminary Import 677 118
preliminary import option 420
PREPARE phase??? 537 R
Prerequisites 434 R/3 Release 4.0 186
Presentation Server 28, 677 R3trans 98, 463, 464, 678
Primary key 349 r3transpath 658
Problem Resolution 154 R3up 543
Processing Sequence 444 Ramp-up procedure 532
Product 633 RDBMS 678
create 632 RDDIMPDP 678
Production activities 160 RDDNEWPP 466
Production client (PROD) 55, 357 recclient 658
Production data replication 100 Recording Client-Independent Custo-
Production Environment 130 mizing Changes 353
Production period 136 Recording R/3 314
Production Planning 139 Release 633, 678
Production Support 156, 370 Release and export process 145
Production support environment 79 Release change
Production support system (PSS) 78 process 534
Production system (PRD) 78, 127, 677 Release change with additional
Production system landscape 72 development system 554
Productive system Release Customizing 678
life cycle 531 Release Errors 379
Profile Generator 677 Release process 373
Profile Syntax 189, 190 Release strategy 531
Program exit 46 Releasing a Change Request 383
721
Releasing a Task 378 setup 632

Releasing Change 92 SAP NetWeaver Development Infra-
Relocation 332 structure (NWDI) 615
Relocation transports 679 configuration 618, 626
Relocations 330 SAP Note Assistant 473
Remote client copy 262 SAP Notes 50, 678
Remote Function Calls (RFCs) 123, 679 SAP Patch Manager 679
Remote logon 648 SAP Reference IMG 679
Repair 309, 679 SAP Release 166
Repair Flag 321, 389, 679 SAP Release Consideration 131
Repairs 321 SAP Release Upgrade 64, 132
repeatonerror 658 SAP Release Upgrade Phase 170
Report Variants 378 SAP report testing 100
Repository Browser 679 SAP Repository 25, 29, 30, 69, 678
Repository object 83, 394, 679 SAP runtime environment 678
Repository Object Checks 144 SAP Software Change Registration
Repository switch 536, 679 (SSCR) 45, 679
Resource Constraint 284 SAP Software Change Registration
Return Codes 449, 450, 468, 470, 679 (SSCR) key 296
RFC 679 SAP Solution Manager 571
RFC Connection 228 business process 573
RFC Destinations 647, 648 system landscape 572
RFC System Check 268 SAP Standard 165
Roles, NWDI 629 SAP standard installation 199
Runtime environment 418 SAP Support Package 67
SAP System 678
S SAP System Identifier 680
Same Primary Key 389 SAP System NET 333
Sample transaction data 103 SAP System operator 184
SAND 62 SAP System service 678
Sandbox client 59, 62 SAP System superuser 184
SAP Architecture 25 SAP System upgrade 199
SAP background processing 468 SAP TopNotes 475
SAP Buffer Synchronization 457 SAP Tutor 564
SAP Business Warehouse Patches 679 SAP Upgrade Assistant 678
SAP Business Workflow 258 SAPGUI 679
SAP Client 25 SAPMV75A 49
SAP Client Roles 53 sapnames 180, 460
SAP Client/Server Technology 27 SAPNet 679
SAP component model 632 SAPNet—R/3 Frontend 679
SAP Connection 647 SAPNet—Web Frontend 679
SAP Going Live Functional Upgrade SAProuter 679
Check 562 SAPscript Styles and Forms 377
SAP HotNews 474 SAPTRANSHOST 183, 196
SAP Installation 175 Schedule 147
SAP Instance 678 Scheduling Imports 160, 418
SAP J2EE Engine 609 Screen Painter 45
SAP NetWeaver Developer Studio 615 Sequence in Import Queues 96
722
Server 679 Structured Query Language 680

Servlets 609 Sub-Objects 327
Session 679 Support 165, 166
Session Manager 680 Support Package Collection 680
Shadow instance 535 Support Package Manager 505, 543
Shared memory 680 Support Package Stacks 522, 526
SID 680 Support Packages 50, 112, 113, 129, 168,
Side-Effects of SAP Notes 495 325, 495, 517, 520, 680
Signed-Off Change Requests 158 Support Tools 358
Sign-Off after Testing 156 Synchronization objects 575, 579, 585
Sign-off process 157 Syntax check 385
Single Comparison 363, 367 syslog 660
Single Comparison with Transaction System Change Option 89, 202, 680
SCMP 366 System check 392
Single Step Log Files 423, 447 System Copy 108, 128, 130, 680
SLD bridge 628 System ID (SID) 173, 175
Software Change Management 626 System Landscape 111, 116, 135, 680
Software Change Registration (SSCR) System Landscape Directory
51 configuration 626
Software component 633 System Landscape Setup 249
create 632 System Overview 225
Software component model 617 System performance 26
Software Component Patches 680 System Resource 279
Software Delivery Manager (SDM) System Status 225
498 System switch 536, 537
Software Lifecycle Management 627
Software logistics 680 T
Software package 28 t_import 660
Source client 264, 440 TABIM_UPG 541
Source systems 659 Table append 47
SPAM 679 Table Delivery Classes 280
SPAM Updates 680 Table Log Analysis 286
SPDD adjustment 538 Table Logging 283, 284, 680
Specialized Development Client 58 Tablespace Requirement 279
Specific Language Requirement 75 Target Client 406
SQL 680 Target Group 246, 680
SSCR 679 Target system 305, 389
SSCR Key 324 Tasks 309, 681
SSCR Registration of Developers 295 TCP/IP 681
Standard Currency 259 Technical Insight 433
Standard maintenance 531 Technical Limitation 64
Standard R/3 Clients 34 Technical upgrade 534, 565
Standard request 680 Temporary Inconsistencies 457
Standard transport layer 680 Test Imports 389
Status Possibilities 402 Test result 162
stopimmediately 659 Test systems 660
Stopmark 436, 441, 680 Test Workbench 164
stoponerror 659 testimport 660
723
Testing methodology 163 Transport Logs 153, 391, 392, 454, 681
Testing period 390 Transport Management 145
Text enhancement 47 Transport Management System (TMS)
Three-System Landscape 67, 236 91, 112, 147, 173, 175, 207, 647, 681
tmp 180 Transport object 379
TMS Authorization 430 Transport Organizer 330, 681
TMS Configuration 223, 451 Transport Organizer transports 331
TMS Editor 238 Transport parameter 397
TMS initial screen 215 Transport Process 98
TMS Setup 118, 250 Transport profile 185, 228, 682
TMS Terminology 207 Transport profile parameter 188, 461
TO 681 transport profile parameter 450
Tool 278, 293 Transport Profile TPPARAM 186
tp and ABAP Programs 467 Transport request 682
tp Commands 437 Transport requests
tp Processing Sequence 442, 443 comparison 592
tp Return Codes 449 Transport route 91, 92, 221, 233, 234,
TP System Log 423, 446, 453 239, 682
tp_version 661 Transport Route Configuration 237,
Track, creating in the CMS 634 250
Training Needs 265 Transport route requirements 418
Training session 68 Transport Routes 211
Transaction code 681 Transport Step Monitor 447, 454
Transaction Data 103, 104, 681 Transport subdirectory 461
Transaction SCC1 377 Transport Tool Check 415
Transaction SCMP 368 Transport tool interaction 463
Transaction SE06 200 Transport Tools 462
Transaction SPAU 543 Transport Types 355
transdir 195, 661 Transport volume 181
Transferring Data 99 Transportable Change Request 308,
Transferring Master Data 102 682
Transport 428, 681 Transportable Workbench 312
Java 642 TRBAT Entries 469
Transport control 406 Tree structure 343
Transport Control Program tp 433, 681 Troubleshooting 446, 452, 456
Transport Directory 176, 177, 181, 210, Troubleshooting Techniques 451
250, 459, 681 Two consolidation route 238
Transport Directory Files 387 Two-System Landscape 70
Transport Directory Structure 179
Transport domain 208, 213, 216, 222, U
229, 408, 427, 428, 681 ULOG file 447
Transport Domain Controller 208, 681 Unconditional Modes 439
Transport Domains 425 Unit Test Client 56
Transport error display 385 Unit Testing 142, 375, 682
Transport Errors 393 Unlocking 320
Transport flow 426 Upgrade 131, 132
Transport Group 178, 210, 424, 681 Upgrade Customizing 682
Transport Layer 681 Upgrade method 568
724
Upgrade project 566

Upgrade Roadmap 561
Upgrade tests 568
Upgrade Weekend Support 565
Upgrading to R/3 Release 4.5 188
User Exit 46, 49
User Management Engine (UME) 609
User Master Data 33, 34, 106, 682
Users 342
NWDI 629
Using tp 434, 438
V
Validation 169
Verifying the Transport Domain 224
vers_at_imp 661
Version Control 243
Version database 395, 682
Version Management 395
View 344, 682
Viewing Table Logs 286
Virtual System 219
Virtual system 682
W
w_import 662
WAN 682
Warnings 251
WBO 682
Work process 682
Workbench Change Request 307, 310,
314, 386, 403, 682
Workbench Organizer (Transaction
SE09) 89, 385, 682
Worklist 370
WP 682
X
XPRA 541
Z
ZDEV 237
725

Sappress Sap Change and Transport Management

Загружено:

Сведения о документе

Авторское право

Доступные форматы

Поделиться этим документом

Поделиться или встроить документ

Параметры публикации

Этот документ был вам полезен?

Это неприемлемый материал?

Авторское право:

Доступные форматы

Sappress Sap Change and Transport Management

Загружено:

Авторское право:

Доступные форматы

2564.book Seite 3 Mittwoch, 8.

März 2006 9:04 09

Achim Kösegi, Rainer Nerding

SAP® Change and

Foreword to the series of books

Foreword to the series of books 5

Dr. Uwe Hommel

Rot, March 2006

Foreword to the series of books 5

How This Book Is Organized 21

Part 1 The Big Picture

1 SAP ECC Architecture and Data Components 25

1.1 Client/Server Architecture in Brief ................................................................ 26

2 Realizing Business Processes in SAP ECC 37

2.1 Customizing ...................................................................................................... 38

3 The mySAP ERP System Landscape 53

3.1 SAP ECC Client Roles ...................................................................................... 53

4 Managing Changes and Data in a mySAP ERP

4.1 Transporting Customizing and Development Changes ............................. 87

5 Setting Up a System Landscape 111

5.1 Setting Up the Development System ........................................................... 111

6 Maintaining a System Landscape 135

6.1 Implementation Plan ....................................................................................... 135

Part 2 Technical Tasks

7 Transport Setup Activities at Installation 175

7.1 Specifying the System ID (SID) ...................................................................... 175

8 Setting Up the TMS 207

8.1 TMS Terminology and Concepts .................................................................... 207

9 Client Tools 255

9.1 Creating a Client ............................................................................................... 255

10 Managing Development Changes 295

10.1 Development Prerequisites ............................................................................ 295

10.4.2 Displaying or Changing an Object Directory Entry ....................... 328

11 Managing Customizing Changes 335

11.1 Customizing Prerequisites .............................................................................. 335

12 Promoting Change Requests 373

12.1 Documenting Change Requests and Tasks .................................................. 373

12.5 Transport Logs .................................................................................................. 391

13 Importing Change Requests 399

13.1 Understanding Import Queues ...................................................................... 399

14 Technical Insight—the Import Process 433

14.1 The Transport Control Program tp ................................................................ 433

14.1.3 Import Queues and Import Buffers ................................................. 435

15 Maintaining SAP Software 473

16 Change of SAP Release 531

16.1 Life Cycle of a Productive SAP System ......................................................... 531

16.3 Modification Adjustment ................................................................................ 542

17 SAP Solution Manager 571

17.1 Customizing Synchronization ......................................................................... 573

18 SAP NetWeaver Development

18.1 Structure of the SAP Web Application Server ............................................ 609

18.6 Developing in the SAP NetWeaver Development Infrastructure ............ 637

A Creating RFC Destinations 647

B Transport Profile Parameters 649

C Selected Transaction Codes 663

E.1 R/3 Online Help ................................................................................................ 683

F Questions and Answers 685

G The Authors 713

15 Maintaining SAP Software

The tools dealt with in this chapter are as follows.

15.1 Making Manual Corrections on the Basis of SAP

Maintaining SAP Software 473

Particularly important Notes—like those about faults with serious consequences

15.1.1 SAP HotNews