A typical SAP upgrade project would require technical as well as functional adjustments/modifications, which any implementation team would need to follow. The following blog discusses mainly on few technical aspects, a technical consultant (Mainly an ABAP consultant) would need to follow, which are based on experience on multiple system upgrades that I was involved in. This blog covers from the pre-implementation phase, to the post-implementation phase, where it also contains information with regards to the SPDD/SPAU corrections and modifications. Pre-implementation Basis consultants would follow a set of processes during the system preparation process, which includes data backups and many other tasks. Once these steps are completed, the basis consultant would begin the upgrade via the software upgrade manager (SUM). The typical steps in the SUM (Figure 1) would be as follows. 1. Extraction 2. Configuration 3. Checks 4. Preprocessing 5. Execution 6. Postprocessing Figure 1: Software Update Manager Open transactions in SPDD/SPAU ◉ At first, the involvement of an ABAP consultant would be required during the Preprocessing phase. Here, the system would first check for any open transactions in SPDD and SPAU, which we need to correct, in order to proceed to the next step (Figure 2). This is not a mandatory correction that we need to do as the system would prompt again with the same list of open transactions during the actual SPDD/SPAU phase. But I would recommend to correct them here as it would reduce the number of corrections that we need to do in the next steps. Figure 2 – Open Transactions in SPDD/SPAU Inactive objects ◉ Once the above corrections are made, again it would prompt a warning message if there are any inactive objects in the system (Figure 3). Figure 3 – Preprocessing Inactive Objects ◉ The ABAP consultant must either activate all these objects, or delete them from the system, in order to proceed to the next step in the software upgrade manager. Note: This error would typically come if there are any inactive objects under local objects of system users. If activating them is not possible due to any reason, I would recommend deleting them as they are anyway local objects and it can do no harm to the systems in either Quality or Production environments. If the inactive objects are in transport requests, they must be activated, and the respective requests must be released. Errors causing to repeat the above phase ◉ Once the above steps are completed, if there are any corrections yet to be made in the system, these will be populated in the ACTUPG.ELG file, which will be available in the SAP directory (AL11). This would contain a typical set of error as follows, which needs to be corrected by the ABAP consultant. 1. Removing duplicate table indexes. 2. Activation and adjustments of search helps that contains errors. 3. Removal of duplicated fields in table enhancements. ◉ Given below is an example of how the errors would be displayed in the SUM (Figure 4), where the BASIS consultant could also provide the set of errors which needs to be corrected in an extracted PDF document. Figure 4 – Repeat Phase ◉ Once the above corrections are made, the SUM should run without any errors, which would then come to the next step in doing repository modifications in the Shadow system. Note: Make sure to maintain a separate transport request for the corrections under the above steps, as the software component version for the corrections done until now would be lower, compared to the version that would be available after the system upgrade. If you miss this, there could be complications while importing the transport request to the systems that would be upgraded in quality and production environments. Repository Modifications (SPDD) ◉ The next step during the upgrade would be to do the repository modifications under transaction SPDD, where the SUM would populate a message as follows (Figure 5). Figure 5 – Repository Modifications Note: Make sure to maintain a separate transaction request for the SPDD corrections, as the software component version of the system is higher than the previous level now. You cannot import this transaction to the systems quality and production environments, as the system have not been upgraded yet and the software component over there is old. Post-implementation Once the pre-implementation steps are completed, the BASIC consultant would continue to upgrade the system via the SUM, where the next step would be to do the adjustment of modified repository objects (Figure 6). Modified Repository Objects (SPAU) Figure 6 – Adjustment of Modified Repository Objects Important thins to know while committing SPAU corrections/adjustments. ◉ Always maintain a separate transaction request for the SPAU phase. ◉ The system will be open for 14 working days, for any modifications. ◉ Make sure to confirm all obsolete notes, after having a discussion with relevant owners (Consultants who implemented the notes). Sometimes they would want to re-import the objects under the note, even though it is obsolete. ◉ Make sure to check whether the objects under the delete tab should be deleted or re-implemented. Sometimes you may require them again. As an example, if any third part packages have been imported to the system, they will be marked as deleted objects during the upgrade. I’m pretty sure you will want to have those objects even after the upgrade. ◉ Make sure to get everything tested (A full cycle test) within the given 14 days. The technical consultant does not know what processes would be impacted after the corrections are been made and it is the process owners’ responsibility to make sure that all processes used by the business runs without interruptions.
