SAP Upgrade - Tips and Tricks
Author : Abilasha Kulkarni
Performing an SAP upgrade from 4.7 R/3 to ECC 6.0 can sometimes be tricky. Compiled below is a list of items that should be performed when doing the upgrade.
1. Pre-Upgrade analysis
Study the existing landscape & the To-Be Landscape
Plan the soft freeze & Hard freeze transport strategy
Run the pre-upgrade tool to identify the number of programs which would be reflected for UCCHECK, Upgrade fixes etc. If you do not have an in-house tool, then you may consider developing one. This tool would have details of Obsolete FM's, search for CALL TRANSACTOIN statement, obsolete ABAP statements etc. Based on such details the tool will search for all the programs which have such FMs/Statements etc. & then it will provide a list of impacted objects
Number of cloned objects (Copy of Standard programs which are modified to meet additional requirements)
Number of Standard Objects modified (Core Code Modification done by Customer in standard objects)
Number of objects which would be impacted due to updating of Unicode flag
Number of BDC programs
Based on the number of objects reflected, you can plan the technical team size/duration etc. This will help during project planning
The Functional consultants can go through the configuration settings / level of customization etc. This will help to identify any specific test scenarios & amount of testing required.
Identify the number of interfaces/ 3rd party systems interacting with the SAP system
Identify the printer/Barcode scanner etc. compatibility with the new system
Basis consultant may go through the system & identify the need for additional hardware/sizing etc.
Based on the inputs from Technical/Functional/Basis consultants you may prepare a draft Project Plan
Prepare a landscape document (AS IS & TO BE)
Also prepare the Technical & Functional analysis document which can be shared with the team
2. Project Plan/Resource planning
In consultation with Customer finalize the timelines for each phase including the number of mock runs etc.
Finalize the project plan & share the same with Customer
Identify the POC from both sides for each phase/task/activity and assign resources
Start the offshore connectivity setup & onboarding of team members
3. SPDD phase
During this phase execute the SPDD transaction. The SPDD transaction would return All the Standard Data Dictionary objects viz Data Elements/Domains/ Structures/ Tables/ Append structures etc., which have been modified by Customer.
The technical team has to decide whether they want to RESET TO ORIGINAL or ADOPT MODIFICATION. These two options are available to fix the objects reflected in SPDD transaction. Here the Technical team has to do a Version comparison of the object & analyze whether they require the custom change. If the custom change is required in ECC 6.0, then select ADOPT MODIFICATION else select RESET TO ORIGINAL (i.e. you do not require the custom change which was done in the old system. Instead you want the standard version of the object in ECC 6.0 system).
Ensure that you put all the objects in the correct SPDD TR
To avoid doing SPDD again in the subsequent systems, you have to release the SPDD TR in a different way
Go to SPDD Tcode & click on "Select for Transport", place the cursor on the task of the Main TR & then release the Task. Similarly place the cursor on the main TR & then click on 'Select for Transport'. This will ensure that the SPDD fixes done in DEV are automatically imported at OS level in the subsequent system. Provide the TR number to the BASIS team & they would ensure to import the SPDD TR at OS level.
SPDD activity has to be done only in 000 client. Ensure that you do not do it in any other client.
Since the system would be completely open & it won’t ask for access keys to modify standard objects, we have to be careful while fixing SPDD objects & ensure that we do not touch any other object, which is not part of SPDD.
SPAU is performed in the normal client i.e. DEV client.
Tcode SPAU is executed once everything is ready to go.
That will generate a list of affected programs.
The programs are standard objects which are modified by customer with some custom changes
Development team has to analyze the changes & identify whether the custom changes are needed (Adopt modification) or discard custom changes (Reset to Original)
Ensure that all the fixes are included in a Transport Request - SPAU
The TR is imported into subsequent systems
SPAU generally reflects Programs/Includes/Screens/FM's/BADI's/Messages/Classes etc.
Execute Tcode UCCHECK
This will provide a list of impacted objects.
Ensure that all the fixes are included under a single UCCHECK TR
Testing of the fixed objects have to be done by developer & functional consultants
Mod logs & documentation to be maintained in the programs which are modified/fixed
6. Custom objects remediation
Apart from UCCHECK objects you need to check custom programs which are reflected by the upgrade tool
Fix the programs & include it either in UCCHECK TR or another TR which would be imported after UCCHECK TR
All the custom program fixes have to be tested
Ensure that the documentation/commenting/Mod log etc. is properly maintained
Unit testing to be done as per the Test scripts
UAT to be done as per the test scripts
If Solution Manager is used, then the Tcodes have to be executed from SolMan
Results to be documented wherever applicable
PDF outputs/Print/Barcode scanning/ Background Jobs/ Workflows / Interfaces etc. has to be tested thoroughly
8. Post Upgrade activities
There are some activities, which can’t be included in a Transport request. Such activities have to be manually executed in each system after upgrade. These activities are called as Post upgrade activities. Ex. Regenerating ABAP Queries after upgrade - This can’t be captured in a TR, hence has to be done in each system
Prepare a list of Post Upgrade activities & update the details along with Primary/Secondary Contact, Task details, System against which you can update whether the task is completed or pending. This tracker would help to monitor the status
Down time has this activity as well. So ensure that you have documented all the post upgrade activity detail so that you spend less amount of time during PRD post-upgrade activities. Try to automate wherever possible.
9. Different trackers required
Cloned program modification tracker
Custom Changes in Standard program moved to Implicit Enhancements
Access key request tracker
Post Upgrade activities tracker
OSS message tracker
Unit Testing/UAT tracker
Test script preparation tracker
10. Common issues faced during Upgrade
Workflows Q :Check if the upgrade affect open work items A : It is perfectly fine to have open work items when upgrading. Any open work items of old version can be executed in the upgraded ECC 6.0 version. Ensure that all the associated notes listed in Note 1068627 are applied in your system. [1068627 - Composite note about workflow upgrade].
Spool – SP01 Q : Check if there is any impact on spools created in the old version A : Yes. All the old spools which are reflected in SP01 in the old version can’t be retrieved post upgrade + Unicode conversion to ECC 6.0. Hence the old spools, which are required post upgrade, have to be either archived/converted to PDF/printed before the upgrade. Please refer note 842767 for additional details.
Obsolete Tables Q : Some tables were made obsolete in ECC 6.0 as compared to R/3 4.7 A : Table TVARV is replaced with TVARVC & table TTXER is replaced with TTXERN. Table TVARV is replaced with TVARVC Ø Check if any entries are read from table TVARV in any of the custom programs. If yes then all those custom programs have to be changed to read data from TVARVC. Refer note 557314. Ø Execute program “RSTVARVCLIENTDEPENDENT”. This program transfers entries of table TVARV to TVARVC (program doesn’t have selection screen. Check the number of entries in both the tables before & after executing the program). Table TTXER is replaced with TTXERN Ø Check if any entries are read from table TTXER in any of the custom programs. If yes then all those custom programs have to be changed to read data from TTXERN. Ø Execute program “SDTXT1AID” to copy entries from table TTXER to table TTXERN. Check the number of entries in both the tables before & after executing the program. Refer note 900607. Ø Output of program “SDTXT1AID”. There could be some entries, which won’t get copied from TTXER to TTXERN. They either would be duplicate or incorrect entries, which you can ignore.
Program Variants Q : Check if any program variants were affected by to upgrade. A : Variants are affected after upgrade. After Upgrade, run program RSVCHECK which will list down all the variants which are affected. Run program RSVARDOC_610 with necessary values to adjust those variants. However if a selection screen field has become mandatory for a Tcode due to upgrade it has to be addressed by assigning a value to it manually.
ABAP Queries Q : Check if any query dumps when executed A : ABAP Queries are affected due to upgrade. We need to regenerate the queries post upgrade. We can re-generate the queries using FM “RSAQ_GENERATE_PROGRAM” which uses work area, query name and user group as input. If the queries are more in number we can write a small program using above FM and table AQGQCAT- for global query and table AQLQCAT- for local/client specific query
Q : ALV layouts previously created from SAP queries no longer function correctly after upgrade A : Refer note 725468
SPDD Q : There are many objects reflected under “DELETED OBJECTS” node. How do we fix this? A : Objects reflected under “DELETED OBJECTS” should be ignored & need not be fixed.
Q : How to handle the transport of SPDD as BASIS wants the SPDD TR to be imported at OS level A : Ensure that all the fixes with respect to SPDD are captured in a single Transport. Multiple transports are not acceptable for SPDD fixes. While releasing the task of your SPDD TR, click on “SELECT FOR TRANSPORT” button which is in SPDD Tcode – 2nd screen. System will prompt to confirm the TR for subsequent system. Confirm the TR number & proceed. The SELECT FOR TRANSPORT step is extremely important else your BASIS team won’t be able to import the SPDD TR at OS level in the subsequent system.
SPAU/ fixing core code modifications Q : Enhancement framework can be used to fix SPAU objects A : SAP has introduced Enhancement framework along with ECC 6.0. For all the core code mods reflected in SPAU, check if there exists a possibility of moving the core code mod to an implicit enhancement. If yes, then remove the core code mod & paste it in the new enhancement. Custom code which is inserted at the start and end of a INCLUDE or a SUBROUTINE can be moved to implicit enhancements. This will help during subsequent upgrades & will save an object from core code mod.
Third Party objects Q : How to handle 3rd party SAP programs A : Check with the 3rd party vendor for the programs of ECC 6.0 version. Normally all the 3rd party SAP certified vendors maintain the set of programs for each version. So once you upgrade to ECC 6.0, you need to contact your vendor & ask him to provide the set of programs for ECC 6.0 version. Vendor would have a team which would take care of making the 3rd party objects in your system Unicode compatible for ECC 6.0.
Obsolete Transactions Q : Are there any obsolete transactions in ECC 6.0 A : Yes. E.g. VOTX is replaced by VOTXN in ECC 6.0. Go to table PRGN_CORR2 & checklist of old & corresponding new Tcodes against your SAP Version.
Obsolete FM’s Q : How do I know if any of the custom programs are using obsolete FMs? A : Table TFTIT would reflect obsolete FM’s. Please use following steps to get the list of obsoletes FM’s. You may create a small program to check all your custom programs for usage of obsolete FM’s. Such FM calls should be replaced with appropriate replacement FM.
Usage of Internal SAP FM’s in Custom programs Q : What if my system has some custom programs using FM’s which are not released to customer? A : As per SAP, any objects which are not released to customer can be changed by SAP at any point of time. Such objects need not be backward compatible. The output of programs using such FM can vary. SAP won’t be taking any responsibility nor will provide any note/solution if customer has used a non-released (internal SAP) object. Any kind of data loss or any other impact would be sole responsibility of customer. E.g. FM “SO_OBJECT_SEND” is internally released for SAP use & should not be used in any custom programs. If it’s used by customer, then they need to replace the call to this FM with another FM “SO_DOCUMENT_SEND_API1”. PDF files created using ‘SO_OBJECT_SEND’ can’t be opened in ECC 6.0 as the FM has undergone some changes in ECC 6.0. Hence all the custom programs, which are using “SO_OBJECT_SEND”, should be replaced with appropriate FM. Customers should create a tool to identify a list of custom programs where non-released (Internal SAP) FM’s are being used. Programs, which are calling such FM’s, should be modified to point to suitable replacement FM. If a FM was released to customer in old version (say 4.7) & later on was changed to “Internal SAP only”, then in such case SAP would provide a note.
Post Upgrade Activities Q : Will there be any manual activities involved post Unicode conversion A : While doing the upgrade on Development system, you would come across few fixes, which can’t be captured in a transport request. Such task has to be documented in a “Post Upgrade Activity Tracker” & such activities have to be carried out in all the subsequent system post Unicode conversion. E.g. 1. Execute program “SDTXT1AID” as per note 900607 2. Execute FM "RSAQ_GENERATE_PROGRAM" for all the queries to regenerate them
Ensure that you get authorization to necessary Tcodes before hand as there would be a very small window to perform Post Upgrade activities on Production system. In order to reduce the entire downtime, documenting the post upgrade activity tasks & providing necessary authorization, keeping the related notes handy would definitely help.
Cloned Programs Q : Do we need to fix cloned programs as well? A : There would be some cloned programs which have few standard includes & few Z Includes which are copy of standard includes. If these standard includes have undergone some change / deletion / modification etc. then there is a possibility of the cloned program giving dump/error. Hence as a preventive step, all the cloned programs should be validated (syntax check) & tested. There is a possibility of the Main program undergoing lot of changes due to upgrade. Customer has to take a call to decide if they want to create a clone program of the upgraded version of std. program or would like to continue with the old version of the cloned program.
Objects to be ignored for UCCHECK Q : Which objects can be ignored for UCCHECK? A : Following objects can be ignored for UCCHECK:- · All the $TMP Objects · Objects which exist in development system but not yet transported to Quality. If you fix these objects, you might end up including it in the UCCHECK transport, which would be forwarding such type of objects to subsequent systems without testing/UAT/sign-off from customer. · Objects under Local Workbench TR · Inactive Objects/Objects having error in old system (E.g. A custom program which is having error in R/3 4.7 system need not be fixed in ECC 6.0 for UCCHECK)
Checkbox declaration to be changed Q : Do we need to change parameter declaration of “TYPE CHECKBOX “ A : Yes. In SAP 4.6c version “TYPE CHECKBOX” used to create a checkbox on the left hand side with the corresponding text on the right hand side. But after upgrade the same code is creating Checkbox on the right hand side with the text on the L.H.S. Few users prefer to have the same selection screen, the way it was in the earlier version. Hence modify the custom programs to replace “TYPE CHECKBOX” with “AS CHECKBOX”. You may identify all the programs using “TYPE CHECKBOX” with the help of search string program “RPR_ABAP_SOURCE_SCAN”.
EDIFCT custom table entries Q : While upgrading to ECC 6.0, custom entries in table EDIFCT are deleted A : The upgrade deletes the custom entries from EDIFCT table. Before upgrade take a backup of EDIFCT table entries as per note 865142
Replacing ‘WS_DOWNLOAD’ FM Q : ‘WS_DOWNLOAD’ FM should be replaced with ‘GUI_DOWNLOAD’ FM? A : The new replacement is FM ‘GUI_DOWNLOAD’. While replacing check if the “MODE” parameter is passed with value “A” in the program. If yes then you need to ensure that for FM ‘GUI_DOWNLOAD’ APPEND parameter is set to ‘X’. Similarly check if the “FIELDNAMES” is assigned to any internal table. If yes, then in ‘GUI_DOWNLOAD’ pass the same internal table to “FIELDNAMES”.
Do we need Unicode conversion?
A Unicode conversion is only necessary for those using MDMP or blended code pages. Some organizations may want to perform a Unicode conversion to provide future support for languages with different code pages - for example, for users in Asian or eastern European countries. Converting or not converting depends on various factors. The following graphic shows the recommended upgrade paths for Unicode conversion: