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.
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.
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.
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.
https://blogs.sap.com/2013/10/14/technical-upgrade-spdd-spau-phase/
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.
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).
https://blogs.sap.com/2013/10/14/technical-upgrade-spdd-spau-phase/
Note: A functional overview of the upgrade process could be found in the following blog, which has been posted by n.palanisami , which I found very interesting and important in grabbing the above said knowledge and experience from a functional perspective.
https://blogs.sap.com/2012/11/16/sap-technical-upgrade-and-sap-ehp-a-functional-overview/
I hope the above experience gained through the system upgrades, would be helpful for anyone who is involved in a SAP upgrade. I know for a fact, it is not easy to do a proper SAP upgrade if you are not familiar with the above steps. And getting familiar with it is not an easy task as SAP technical upgrades are not carried out frequently, for the same system.
Keep me posted with any questions you have with regards to the above mentioned content, I will be adding more such experiences in near future.
Thank You!
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.
- Extraction
- Configuration
- Checks
- Preprocessing
- Execution
- 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.
- Removing duplicate table indexes.
- Activation and adjustments of search helps that contains errors.
- 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
- A detailed guideline on how to carry out the SPDD phase could be found in the following blog, which has been posted by arjun.pawar .The information given in the blog is really helpful for a consultant to understand the entire SPDD phase.
https://blogs.sap.com/2013/10/14/technical-upgrade-spdd-spau-phase/
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
- A detailed guideline on how to carry out corrections and modifications under the SPAU transaction could be found in the following blog, which is the same blog as mentioned in the SPDD phase.
https://blogs.sap.com/2013/10/14/technical-upgrade-spdd-spau-phase/
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.
Note: A functional overview of the upgrade process could be found in the following blog, which has been posted by n.palanisami , which I found very interesting and important in grabbing the above said knowledge and experience from a functional perspective.
https://blogs.sap.com/2012/11/16/sap-technical-upgrade-and-sap-ehp-a-functional-overview/
I hope the above experience gained through the system upgrades, would be helpful for anyone who is involved in a SAP upgrade. I know for a fact, it is not easy to do a proper SAP upgrade if you are not familiar with the above steps. And getting familiar with it is not an easy task as SAP technical upgrades are not carried out frequently, for the same system.
Keep me posted with any questions you have with regards to the above mentioned content, I will be adding more such experiences in near future.
Thank You!
- SAP Managed Tags:
2 Comments
