Upgrading to SAP R/3 Enterprise: Technical Point of View SAP BASIS


The following sections will cover those upgrade tools and procedures that have to do with the technical part of the upgrade project, which is intrinsically a very important part of the upgrade.

Factors Influencing the Technical Upgrade

Several factors may influence the upgrade and they all may be different for your situation, depending on what you consider the technical part of an upgrade project. Downtime influences the length of time necessary to complete the upgrade. Downtime is defined differently by different customers, but a common definition is the elapsed time that the systems are not serving the purpose for which they were designed and implemented. The hardware configuration and power of such hardware and the sizing of the systems may affect the speed of the upgrade. The database size may affect the time before the upgrade is running.

However, there are other factors that influence the upgrade technically and that we tend to forget or put aside, such as the number of modifications in a system and the number of customizations. SAP repository objects that have been modified must be reconciled and custom-developed programs must be tested, especially when they use SAP objects. These and other postupgrade activities, such as creating new authorizations, or moving additional transports to production, add time to the actual upgrade.

Depending on your front-end rollout strategy, you may need to upgrade the front end all across. In the near future, when all the SAP user interfaces are Web based, this will not be a real consideration. The network bandwidth will likely be much higher than in your source release, especially if you are upgrading from an older release, such as R/3 4.5 and below. Planning very carefully the timing on each and every action in a detailed project plan and upgrade script and extensively testing the upgrade process are the real keys to a successful upgrade.

Appropriate planning will also help you to invest where it is necessary (for example, you may need additional testing time) and to save wherever possible (i.e., you may not need additional hardware). A common and constant question is, "How long does the upgrade last?" Often we are just thinking about the actual time that it takes to insert the CDs and upgrade the software and that is all. Try to plan the project and all the factors that may influence implementation, based on previous experience, customer references, SAP's assistance, and so on. The more prepared you are, the better. It is essential to become familiar with all the SAP Notes that help in troubleshooting the upgrade.

Other customers that have previously upgraded and run into issues may have reported them to SAP, and a collection of available SAP Notes to upgrade to SAP R/3 Enterprise is available in the SAP Service Marketplace. Early fixes to certain bugs, necessary versions of the executables to run, necessary downloads, specific SAP Notes related to your database and operating system platform, additions to the documentations, and so on are included in such SAP Notes. Study carefully the SAP Upgrade Guide that you can download from the SAP Service Marketplace. Familiarize yourself with all the service offerings that are included in your maintenance and how SAP can further assist you, and find all the documentation available under the alias/upgrade.

The Upgrade Process

Technically, at the time of upgrading to SAP R/3 Enterprise, there are two major parts of this process: the upgrade preparation executing PREPARE and the upgrade itself executing R3UP.exe. Each part of the upgrade, PREPARE and R3UP.exe, goes through several different phases, and every phase must be successful.

Prepare before PREPARE

Without being redundant, we need to emphasize that preparation is key for a successful upgrade. In this section you will find a few tips and reminders that will help you prepare more efficiently for your upgrade. For the upgrade preparation and execution, you need to create a directory in the file system of the server that contains the central instance named "usrsapput" (note that in this example the naming convention used was UNIX back slashes and it is different in Windows platforms, where forward slashes are used). The upgrade directory must have sufficient free space configured in order to avoid errors and must be empty before starting any phase of PREPARE. The SAP system administrator <sapsid>adm must be the owner of the upgrade directly and all subdirectories.

Ensure that you have blocked a timeframe to upgrade the front-end software before the upgrade runs, because once the new system is up and you need to log on to perform postupgrade activities, you need to log on with the new front-end release! Check whether you have enough hardware resources to handle the upgrade and production operations in SAP R/3 Enterprise. See the next section for a more detailed explanation and tips to estimate your hardware requirements.

Back up your database and operating system completely before starting the upgrade. This way you will ensure that you can always go back to your previous stable state if a disaster occurs. Also, back up your database and logs whenever it makes sense, essentially, before and after the upgrade. But if you choose a different strategy, just make sure that such times are added according to the project plan.If you have SAP Add-Ons, make sure that their release is in synch with SAP R/3 Enterprise and if you need to upgrade them or not. Search for SAP Notes to gather the necessary information and for consulting assistance, if you need to.

Tip When searching for SAP Notes that relate to your SAP Add-On while upgrading, use a combination of strings that include the name of your add on and upgrade, for example. In addition, if you have third-party add-ons, check with your software vendor for dependencies and if an upgrade of such add-on is necessary. R/3 Plug-Ins are essential to connect to other SAP systems, such as SAP CRM or SAP APO. R/3 Plug-Ins must be upgraded during the upgrade as well and R3UP will prompt you for the Upgrade Plug In CD. Check the alias /r3plug-in in the SAP Service Marketplace for the most up-to-date information about R/3 Plug-Ins and their availability, as well as Support Packages.

Hardware Requirements

Very early in the upgrade process, it is essential that you check whether your current hardware configuration can handle the upgrade and the production operations in SAP R/3 Enterprise.The main hardware components that you must check are the CPU, physical memory, and disk space of your servers, as well as your network capacity and infrastructure. SAP can assist you greatly figuring out whether you need to upgrade your hardware or not. In addition, there are several SAP Notes that can also be of great help, because they provide information on the increase in hardware resource consumption from your target release to SAP R/3 Enterprise. These SAP Notes are as follows:

• 517085 (resource requirements upgrading from SAP R/3 4.6C to SAP R/3 Enterprise)
• 323263 (upgrading from 4.5B to 4.6C)
• 113795 (upgrading from 4.0B to 4.5B)
• 89305 (upgrading from 3.x to 4.0B)

Depending on your source release, you may need to add the increases that each SAP Note reveals one by one. For example, if your source release is SAP R/3 4.0B and you are upgrading to SAP R/3 Enterprise, following the aforementioned SAP Notes, you would need to add 20% more CPU from 4.0B to 4.5B, 10% more CPU from 4.5B to 4.6C, and 5% more CPU from 4.6C to 4.7. This results in expecting a total of a 35% increase in CPU consumption in each application server.

If your central instance and database server are installed in the same physical server, add an extra 10% from release to release to handle the database processes. This would result in our example of expecting a 65% increase in CPU consumption in such a server with a SAP Instance and a database. The SAP Notes also help to figure out the increase consumption in physical memory and in disk space. These SAP Notes are built upon experience from the SAP installed base and are averages that are supposed to assist you figuring out roughly the resource consumption increase in your servers. Depending on your functionality and many other factors, these figures will vary more or less.

In addition, it has been noticed that if you upgrade to a 64-bit environment, an additional 5% of resource consumption in CPU and memory may also apply. This is the case if you are upgrading SAP to a core Unicode system. Remember that these are rough estimates and that you should contact your hardware partner to size your system according to your needs. SAP can also assist with the services that are part of your maintenance or additional offerings, if available.

Upgrade Strategy and System Switch

The new features of and upgrade to SAP R/3 Enterprise include a new way to substitute the repository that replaces the old A_on, A_off, A_Switch strategy. A new "shadow system" is installed in the central instance of your system. You may choose to install this system in a different application server as well and run in parallel. The resources that you need are basically those of your central instance. During this process, a SAP Web Application Server 6.20 or above is installed (created) and runs in parallel to your production system in whichever release it is. The database of the new release is imported and all the shadow objects point to the original objects in the production database. Import of SAP Support Packages is also included.

Next, you must run a modification adjustment of the dictionary objects executing transaction SPDD. You can do this, again, while the system is up. You can also choose to convert tables using transaction ICNV (Incremental Conversion). At this point, though, you cannot transport anything else; the system must be completely locked. Then the system must be shut down and the shadow system takes over. The kernel and the repository are switched, the central instance restarts, and afterward, all the dialog instances restart.

When performing an upgrade process using SAP tools, there are different upgrade strategies available that will affect the total downtime of the process. These strategies are based on the system switch as introduced previously. The upgrade strategy determines whether the substitution set is imported into the shadow tables during production operation of the system. The Repository Switch procedure can be divided into two parts:

  • The database tables that make up the substitution set include almost the complete SAP repository. This substitution set is imported into the shadow tables. The substitution set does not influence and is not recognized by the productive SAP system, and therefore the substitution set part of the upgrade can be performed during the operation of the SAP systems.
  • At a certain important point of the upgrade, the repository is switched by deleting the old repository and renaming the shadow tables. When this upgrade phase is going to occur, users cannot use the system productively. There are two available upgrade strategies:
  • Downtime minimized. Most upgrade phases and actions are performed to reduce the downtime it will take to finalize the upgrade. With this strategy, systems require the use of more memory and CPU. Although the total productive downtime is reduced, the total runtime of the upgrade is longer.
  • Resource minimized. Using this upgrade strategy, the shadow repository system is not started in parallel to the productive system. The production system and operations will have to be stopped before the shadow system can be started.

The decision between the strategies is mainly based on the maximum possible downtime, which must take into consideration the time needed for a recovery of the system in case serious problems arise. Note If you choose the strategy "downtime minimized," the system switch happens as mentioned previously, but if you choose the strategy "resource minimized" the production system is down for all the steps mentioned. Choose wisely one strategy or another depending on your resources and how long you can afford to have your system down. Check SAP Note 398100 for more information about the shadow system.

Upgrade Preparation: PREPARE Program

Because extensive checks are required for the upgrade, SAP provides the PREPARE program as a collection of checks to support the preparation of the upgrade without affecting productive operation, because the program can be run while the systems are running. It's an independent program that can and must be used previous to the actual upgrade. The PREPARE program automatically checks all the requirements for the upgrade, provides information for further steps, and imports several tools in the database. PREPARE has four different levels of execution:

  • Level 1 can be started at any time.
  • Level 2 is performed only once.
  • Level 3 performs all the checks requiring short runtimes.
  • Level 4 includes long-running jobs, such as the estimation of the modification adjustments, an extended space check, or the repository transfer.

You can execute PREPARE as many times as you want and as early in the upgrade process as you want or need. PREPARE checks the disk space that is necessary for the upgrade to run, if there are open modifications and transports in your system, and if you need to upgrade your database or operating system versions, among other checks. The Product Availability Matrix is published in the SAP Service Marketplace under the alias /PAM or you can also check the alias /platforms, which can redirect you to the Product Availability Matrix. This way you can check whether your operating system and database versions can be a possible combination for your target SAP R/3 release, SAP R/3 Enterprise.

If a database or an operating system upgrade is necessary, plan ahead the necessary steps to take and to consider, such as technical platform upgrade, testing, short production downtime, and so on.The number of clients and your database size may influence the disk space that you need to have free for the upgrade to execute without running out of space. If there are many tables that need conversion (the structure changed from release to release), this may add additional space requirements as well. If you are a global organization that has several languages installed, ditto.

Finally, if you need to, a Unicode conversion requires quite some time in preparation and execution. In addition, during the PREPARE execution, you are prompted the switch the new SAP R/3 Kernel, if necessary. Ensure, though, that you have the minimum necessary patch level specified in the SAP Notes, which you should have checked before starting PREPARE.Check that you have the latest SPAM update for the application of SAP Support Packages. Search for SAP Notes that may reflect problems encountered related to the SPAM updates.

During PREPARE the necessary tools are imported to the system. You can also configure the upgrade phases in which the SAP Support Packages that you need to import can be bound (bundled together) and the strategy to install multiple languages. As introduced in the previous section, a new feature coming with SAP R/3 Enterprise is the system switch upgrade. This new feature consists of installing a new SAP Instance and a database with the target release that will help in running the upgrade operations. You can choose where to install this Instance (e.g., a parallel server, or the same server as the central instance). This is called a shadow system and will run completely in parallel with the production system.

While the production system's database contains all the repository objects, so-called shadow objects will be created in the shadow system that point to the actual objects in the production repository. In the last phase of the upgrade, these shadows are activated and the old repository eliminated. This process can be performed during regular production operation, if you choose the strategy downtime minimized. If you choose the strategy runtime minimized, this switch will happen during system downtime.

During PREPARE you can decide whether to use one strategy or another during the actual system switch. This is a very important step in the upgrade and you must choose carefully your options. As stated in the previous section, the strategy downtime minimized allows you to run production operation for a longer period of time, because you can log on the shadow system and perform postupgrade activities in it. However, it will demand more resources out of the system and performance for the users will be impaired, as you can imagine.

The actual system switch, though, requires the system to be shut down. If you choose this strategy, you can run the modification of adjustments, activate the dictionary objects, import transports and SAP Support Packages, as well as use the Incremental Table Conversion functions in the shadow system while the old production system is still up. Runtime minimized is more similar to the old upgrade strategy in which the system is down during the switch and therefore there is less resource consumption. However, production cannot go on until the system is up again.

You may execute PREPARE from the Upgrade Assistant (see the brief explanation later on) or from the command prompt. You need to enter data to start the phases of PREPARE, such as the language in which the tests from R3UP must appear; for example, in English-E or German-D. Databasespecific entries must be made as well, such as necessary passwords, profiles, and other specifications related to your database platform. You must enter the mount points of the CDs with the software and whether they are directories in the local file system or CD drives (you may have to change CDs, as prompted).

Specify the number of background processes to run in parallel and the number of parallel import processes. The hardware capacity of the machine influences greatly these decisions. The defaults are fairly conservative.Ensure that you have downloaded all the necessary SAP Support Packages (of all types that you need for your applications and SAP Add-Ons) and that they are uncompressed into the correct directory (usr sap transEPSin). You can bundle them together to import them, which saves great time. This is a new feature with SAP R/3 Enterprise. In addition, binding SAP Support Packages together ensures that you do not miss important fixes that come with the corresponding level.

These are the most important phases of PREPARE. Ensure that all phases are completed successfully. The results of PREPARE are written in a file called CHECKS.LOG in the upgrade directory. You can repeat each PREPARE phase until it successfully completes, but you may not skip PREPARE before running R3UP.

Additional Upgrade Tools

There are some additional upgrade tools, besides PREPARE and R3UP, that are basic to control and monitor the upgrade. Additionally, there are standard transactions and utilities within the SAP system that are also used in upgrade runs. The following sections discuss the Upgrade Assistant and the Upgrade Monitor, as well as the ICNV transaction. Other key transactions required for the Modification Adjustment phases, such as SPDD and SPAU, are introduced later in this chapter.

The Upgrade Assistant is a Java tool that can help you to control and execute all the phases of PREPARE and R3UP and monitor their status. It can be started in SCROLL mode or in SERVER mode (this is the default and also recommended mode). This tool is meant to provide support to run the upgrade remotely. The advantage of using the Upgrade Assistant is that the front-end and the upgrade processes are separated so that the entire upgrade does not terminate abnormally if a connection fails. To run the Upgrade Assistant, you need to install and start up the Upgrade Assistant server. In order to do this, at the operating system level, you need to execute the command jview /cp <your upgrade directory>UAua.jar UaServer.

Afterward, you can start the Upgrade Assistant GUI from a Web browser (recommended) executing you can start it up from the command prompt with Java commands. Log on using the default user and password (Administrator/admin) and you are ready to go.

You will be prompted to start (initialize) each phase of the PREPARE and once PREPARE has been executed successfully and you have done everything you need to start R3UP, you can start this program with the Upgrade Assistant and, as before, control the upgrade phases and progress.

The Upgrade Monitor

From the Upgrade Assistant, you can start the Upgrade Monitor, which can assist you to monitor the different phases of the upgrade, their runtimes, their activity, if there are processes hanging, and other system conditions. The Upgrade Monitor estimates when the upgrade and important phases of the upgrade will be finished. These estimates are based on SAP reference timings as well as on the duration of previously run phases. The runtime statistics are refreshed once every minute only and they can be used as reference to what the upgrade is supposed to last. However, do not take these times for granted or totally "by the book," because they will vary greatly from system to system and environment to environment, depending on all the factors previously discussed. You may see green bars all the time or red bars, and this may or may not mean a problem all the time.

Additionally, you can start the Upgrade Monitor from the operating system calling "R3UP.exe monitor." Use this monitor to check whether processes are stopped and the upgrade is "not moving" while you are executing the phases of the upgrade. An animated graphic displays the activity of the upgrade processes. If the graphic is not moving, one of the upgrade processes is stopped. The upgrade processes that are running appear under Current activities. The monitor does not recognize any subprocesses of these processes, and therefore cannot display them.

Incremental Conversion (ICNV)

The structure of the tables in the SAP database might change with each new release, and therefore one of the activities performed by some of the upgrade phases is to convert these tables. Traditionally these table conversions happened only during the upgrade downtime, which usually was one of the longest processes to run. However, by using incremental conversion, you can convert many of the tables before the upgrade, using the transaction ICNV.With this mechanism, you can clearly have some advantages, such as a reduced downtime during the upgrade, because a large number of tables are converted while the productive system is still running.

With transaction ICNV you have the following functions:

• Display tables flagged for conversion as determined by the PREPARE tool.
• Select the tables you want to convert incrementally.
• Execute and monitor the conversion process.
• Estimate the runtime of the conversion.

ICNV provides users with information about the progress of the conversion and estimates finish runtime.

The Software Upgrade: R3UP

R3UP.exe is the program that upgrades the SAP software, performs the actual system switch according to your chosen strategy, and shuts down the system when it is time. You may execute R3UP from the command prompt or from the Upgrade Assistant. Ensure that you run it, though, in the central instance. R3UP can also be stopped at the end of each phase before starting executing the next using the Upgrade Assistant or the command prompt. You may need to do stop and restart R3UP, if a SAP Note tells you so to correct a situation or if you encounter a problem that must be solved before continuing. Afterward, the upgrade can be restarted. The R3UP phases leave their logs in the directory usr sap putlogs. Check these logs to analyze errors. The program's TP also leaves logs in this directory; look for the "SLOG" logs.

R3UP needs input, as PREPARE needed, and you will be prompted to enter the necessary data for the phases to run. You can use the Upgrade Assistant and the Upgrade Monitor to check the progress of the upgrade. In each phase you will be prompted to enter the necessary data and at the end of each phase you should check the success. You must enter the chosen upgrade strategy, downtime minimized or runtime minimized. Execute a complete backup, if you choose the strategy resource minimized, so you can ensure that you can come back to this point, in case of a disaster.

Certain phases are critical. For example, the upgrade program checks whether the necessary SAP Support Packages are ready to be imported in the correct order. If you still have SAP Support Packages from the old release to confirm, release the open repairs and lock transports to avoid conflicts.

After R3UP

Certain activities must be performed once R3UP has successfully finished. Of course, to start, a database backup cannot be missed. Many parameter settings will need to be changed, especially those for memory management, for example, or those related to the new components, such as the ICM, the SAP J2EE Engine, and so on. Database-specific actions, such as updating statistics, must also be performed at this time. Run transaction SGEN to generate ABAP loads of programs that don't exist and to generate BPS applications.

New authorizations and changes in the existing profiles for the users must be done at this point so the users are ready to log on in the new system and perform their transactions. Imports of transports with new developments can be done now as well and some new SAP Support Packages, if necessary, as well. All the adjustments from SPDD and SPAU run before and marked for transport can be imported to production as well.

ABAP Load Generation with SGEN

SGEN is the SAP transaction that is used to generate the ABAP loads and that replaced the report RDDGENLD, found in SAP R/3 releases before 4.6. Due to the fact that SAP systems are based on a concept of integration and activation of structures and programs, when in an upgrade, many ABAP loads for transactions and business application are not automatically generated during the upgrade. This happens automatically as soon as a program, transaction, or menu function is selected, but if the loads are not previously generated, this will impact system performance the first time users enter the specific transaction or application. Load generation requires a large amount of system resources.

This may, however, reduce production system performance, and to avoid this, you can use transaction SGEN to generate the missing loads. One of the advantages of the new SGEN transaction with SAP Web Application Server is that it allows users to generate loads in parallel. With the new release, SGEN can not only generate ABAP reports and programs, but also BSPs (business server page applications) or function groups. It is recommended that users generate the ABAP loads immediately after running the upgrade.

Modification Adjustment

When you upgrade a SAP system, the standard process will make you lose any modifications made to objects that conflict with SAP modifications in the new release. You must modify your code to Unicode. The modification adjustment process lets you make your modifications to the appropriate new objects in the upgrade. The normal order in which you upgrade a SAP environment starts upgrading the development system, which contains the version management, the utility that keeps track of all changes to all the objects in the SAP repository. Thanks to the version management and the utilities SPDD and SPAU, the modification adjustment can be performed to avoid conflicts and ease the risk of losing important customer functionality. You can find five different types of changes or modification within SAP systems:

  • Local customer developments. These are programs or other repository objects that customers create or develop, by using the proper naming conventions, such as starting with Y or Z, or by reserving a name space. Refer to Chapter 6 for more information on the transport system.
  • Customizing. This is the process of setting and defining system parameters using the Customizing transactions within the IMG. Customizing is a basic and mandatory process of any SAP system implementation. Typically it does not affect directly repository objects.
  • Modifications to SAP standard. These are customer-specific changes to SAP repository objects. When standard SAP objects are changed during an upgrade process (also during the installation of Support Packages), the customer version has to be modified to match the new SAP version.
  • Enhancements. These are customer changes to SAP repository objects without the need for modifications to the standard. The most common enhancements are are the advantages of the new Business Add-In technology that replaces the user exists.
  • Advanced corrections. These corrections are meant for applying fixes to programs or other repository objects from SAP directly to the customer SAP system. The corrections are provided from the SAP Service Marketplace in the form of Support Packages, which avoids customers having to modify those SAP objects manually.

If you have modified objects in the SAP standard software, such as programs and objects in the dictionary, you must run an adjustment to compare if the new release is bringing over those objects that you needed to modify in the past. Maybe you performed that modification because the standard did not provide with such functionality or object in the previous release and now it is included. You can choose to go back to the standard or to keep your modification.

When you choose either to return to the SAP standard object or to keep your modification, those objects are included in a transport request that you will import to the test system later on and to the production system finally. To perform this adjustment, you must execute transaction SPDD to adjust objects in the SAP dictionary and SPAU to adjust programs in the repository. If you choose the strategy downtime minimized, you can do this while the system is up, but in the strategy resource minimized it is done during actual downtime of the system. Adjustments with SPAU must be performed at the end of the upgrade, after the switch has finished and the new programs have been actually imported. SAP includes two main modification adjustment transactions, SPDD and SPAU, that are used for adjusting dictionary and program objects that could have been modified on customer systems before the upgrade.

In good upgrade projects the adjustments are performed only on development systems to be later transported to QAS (quality assurance system) and PRD (production system). The adjustment of modifications is performed first during the actual upgrade, where the tool will stop so that developers and consultants can analyze the differences between modified objects and new objects. When doing this process, customers can decide to keep the old modifications and adjust them to new objects, or can just decide to keep new objects, overwriting previous ones. The SPDD and SPAU transactions show a list of the modified SAP objects.

Especially in those installations with complex modifications, the adjustment process can be one of the more time-consuming activities of the upgrade projects. Therefore, it is very important to perform adjustments in the development system so that these objects can be automatically transported to the production system. Sometimes landscapes are different in each system, so the process has to be reviewed after finishing the upgrade phase. Usually the upgrade is limited to maintain the operation and business processes as they were before the upgrade. The main problems are the locally developed transactions, especially those that were first copied from standard and then modified and enhanced. After the upgrade, the company might decide to perform additional customizing.

The objects list that must be adjusted in your SAP system will be determined in the ADJUSTPRP phase of the upgrade. This phase is included within the PREPARE and runs in the upgrade between the import of the substitution set and the end of the production. To perform the adjustments correctly, it is very important that the original authors review the modifications. The original authors of those changes can be found in the log file UMODPROT.<SID>, located in the log subdirectory of the upgrade directory. The ABAP dictionary objects (tables, data elements, domains, and so on) are adjusted during downtime before the activation of the ABAP dictionary. The adjusted objects are collected in a transport request, but you cannot release this transport request; instead it must be flagged for export in transaction SPDD.

In one of the last phases of the upgrade, the upgrade program R3UP exports this transport request into the transport directory (/usr/sap/trans) and registers the request for transport in the file umodauto.lst. Repository objects (reports, screens, and so on) are adjusted toward the end of the upgrade. At this stage, the import of SAP objects has already been completed. However, the old, modified version is still available in the versions database. As with ABAP dictionary objects, all adjustments are released to a transport request that is noted and then exported and registered by R3UP. Activation will be carried out automatically after the adjustment.

After you have completed the upgrade, you have a maximum of 14 days to execute transaction SPAU without a key check (SAP Software Change Registration) for the objects that you changed.


SPDD and SPAU are the two main transactions and utilities to complete the process of adjusting modifications so that the upgrade process does not overwrite any important customer objects.

  • SPDD is used to adjust dictionary objects (table structures, domains, data elements, and so on).
  • SPAU is used to adjust all other repository objects that are not dictionary (reports, function modules and so on).

At the start of the adjustment process, SAP R/3 repository objects from the preupgrade repository are compared with objects from the repository of the new release. For each object, transactions SPDD and SPAU guide users through the adjustment process by offering the options of performing the modification adjustment or returning to the SAP standard. Normally, as team members work through the list of objects flagged for adjustment, they should mark each object once they finish with the adjustment. The adjusted objects will be collected in a change request. However, notice that there can be only one transportable change request for SPDD adjustments and only another one for SPAU adjustments.

Once all modified objects are marked as processed, the change request is ready for export. By transporting the change request, you avoid needing to make the same adjustments again in each system. It might happen, however, that the repository of the systems in the landscape is not completely identical; for instance, some modifications made in the development system were not transported onto subsequent systems in the landscape. Therefore, and unfortunately, the final adjustments will have to be verified after the completion of the upgrade.

There are several ways of adopting and adjusting modifications:

  • Automatic modifications. Using this option, the customer modification can be automatically adopted.
  • Semiautomatic adjustment. Semiautomatic means that each tool will individually offer you support during the adjustment process. When adjusting programs, the splitscreen editor is called, whereas in the other tools any entries made in the collision dialog box lead to the necessary adjustments being made automatically. As with the green traffic light, the semiautomatic adjustment icon only appears in the with Modification Assistant category.
  • Manual adjustment. Objects in the "Without Modification Assistant" subtree can only be postprocessed manually after the adjustment process. Manual adjustment means that you must make modifications without any special support from the system. Use the log as a help. Using Version Management, you can retrieve old versions or use your recordings to process the newly imported objects. In rare cases, the red traffic light may also appear in the With Modification Assistantcategory.
  • Unknown adjustment mode. The adjustment mode (manual, semiautomatic, automatic) for at least one of the objects in question could not be determined for modification adjustment with the Modification Assistant. If this is the case and you start transaction SPAU, a dialog box informs you that you can start a background process by choosing the appropriate pushbutton that determines the adjustment modes for all objects.
  • Reset to original If you choose Reset to original for an object displayed in the overview, no modifications are adopted for this object. The original is the version that was last imported into the SAP R/3 system during an upgrade or the application of a Support Package.

To adjust objects without the Modification Assistant, use version management wherever possible. When modifying objects where version management cannot be used, carefully document any changes that you make. This documentation can be of great assistance the next time the object needs to be adjusted. Choose Change from the maintenance transactions of the individual ABAP Workbench tools to adjust objects without the Modification Assistant.

All rights reserved © 2018 Wisdom IT Services India Pvt. Ltd DMCA.com Protection Status