MOPZ no longer selects the latest available Java patches by default
Recently I discovered that MOPZ no longer selects the latest available Java patches for the selected Support Package. It seems that SAP has changed the default behavior in MOPZ so that it selects patch level 0 when choosing stack dependent files. SAP Solution Manager 7.1 SP12 was used as the reference system, I believe it has MOPZ 3.0.
I chose to post this blog to SAP NetWeaver Administrator instead of SAP Solution Manager or Application Lifecycle Management because I felt that this is a basis concern and most basis folks are tuned to the selected space.
Now what’s the big deal? Unless you are aware of the new default behavior you might end up with a NON-WORKING SYSTEM. Sorry SAP, your patch level 0 releases are rarely production quality. I don’t remember when was the last time our landscape would have had patch level 0 systems in it. Typically all systems have at least patch 1, some have patch 2 or 3 and we stick with it until it is time to update or upgrade again. As it was when we updated our NetWeaver 7.31 SP10 system to NetWeaver 7.31 SP16, even Portal Content Catalog wasn’t operable as demonstrated by the attached screenshot.
Portal Content Catalog broken after applying SPS16 (patch level 0) for NetWeaver 7.31
Okay, got it. Anything else I should be aware of? Unfortunately yes. Unless you use the “Add Java Patches” in the Stack-Dependent step of MOPZ while generating the stack XML, YOU WON’T BE ABLE TO APPLY PATCHES LATER ON, unless you do it manually that is. MOPZ seems to use the selected set of files to determine the available patches. If your system is already at the target level, you won’t have any files to select and thus MOPZ won’t find any patches. Basically what that meant for us is that we had to restore the system and to start over. I did go through the manual process of selecting the latest patch levels of about 15 components always taking a note of the dependencies. It is however always a gamble to manually patch any system, you don’t know for sure whether your defects will be fixed by the selected components nor will you know all possible side effects of the selected components.
Any closing words? In my opinion, although I don’t know the reasons behind the change, the new behavior is disruptive. I have been using MOPZ together with SUM (and JSPM before that) to patch Java systems for years admitted though that I haven’t been actively using them in the past couple of years. That said I have trusted MOPZ to always select the latest patches while generating the stack XML, which it no longer does. MOPZ should at least give a very visible warning that the default behavior has been changed and that Java patches are no longer selected by default.
And yes, SAP has released KBA 2022451 to address the topic although it doesn’t address/cover everything in my opinion.
Hi Samuli,
I thought MOpz had been only including the patch 0 version of Java SPs all along, unless you clicked on "Add Java Patches." I think SAP's reasoning is that the "stack" of support packages has been tested as a group, whereas the combination of all the individual patches together has not necessarily been so heavily tested. I get that.
But, like you, I always click that Add Java Patches button. I have noticed, too, in the past, that if you don't do it at the same time then it doesn't seem to properly offer them later. But, the workaround for that has been to not worry about MOpz for patches, as SUM will apply Java patches without requiring a stack.xml.
This brings me to my question/concern. As you pointed out (and as mentioned in Note 2022451), care has to be taken to ensure that cross-component dependencies between patch levels are observed. It's not obvious to me that the "Add Java Patches" function in MOpz does this (perhaps it does), so I have typically gone and manually looked in the SMP at the dependency list for each and every patch to ensure I'm not missing anything important. This can get laborious.
Do you know if MOpz is in fact checking on this?
Cheers,
Matt
I'm 99.999% sure Add Java Patches wasn't required before, it was changed in the past 2 years during which our basis admins have been doing most of the patching. Before that generating the stack XML automatically selected the latest available (*) patches for the selected stack.
(*) not sure if it was really the latest available or was there some hidden logic behind it, it used to take "almost" the latest patches.
That said I have myself never used Add Java Patches button until now.
Regarding your question about dependencies and does MOPZ consider those when selecting patches, I surely hope it does but I really don't know. Let's hope someone from the MOPZ team jumps in. Maybe Miguel Angel Arino Clarke although I think Miguel no longer is part of the MOPZ team.
Hello,
As far as I know, the standard behaviour right now is that Maintenance Optimizer selects the Support Package level defined in the stack. This may or may not include the latest patch level. It usually doesn't.
The patch level for a Support Package stack is not explicitly defined in PPMS, but it is just the patch level of the download object that corresponds to the Support Package level for each software component defined in the stack.
I am not sure if/when this behaviour was introduced, but for me it seems it was always like this. Perhaps it is just recency bias... I cannot recall any documentation that I could refer to.
Patch levels in PPMS have been problematic because originally PPMS coexisted with Java-only models (usage types and whatnot). The Java-only software logistics models are being phased-out. It occurs to me that PPMS should be improved to allow for patch levels to be defined in the stacks. In their wisdom, the PPMS developers have not deemed it necessary to do this , and it's been 7 years I have been watching closely.
Best regards,
Miguel Ariño
To add the 0.001%, I remember many times in the past when in longer running upgrade projects, where the stack XMLs weren't generated for the entire landscape in the beginning, we ran into problems with the correct patches not being selected (or even being available for download) when the stack XML was being generated for the next system in the landscape. That is probably the reason why SAP changed the default MOPZ behavior. It would be nice though to see that documented somewhere and also to know when exactly it was changed.
Ah, that makes sense. I still frequently have to create stack.xml files for dev (or sbx) systems when I haven't yet installed the qas and prd systems (in fact, I'm doing that right now with an MDM system).
There is also the stack XML copy tool, I have never used it though for QA or production systems.
I have used it, though so far only for ABAP systems, not Java systems. It worked well. I'm hoping it will continue to work well on my latest project.
Hello,
the trouble is, Maintenance Optimizer follows PPMS modelling, and PPMS does not have any patch objects. So there is no way whatsoever to detect interdependencies of patches. This is why patches cannot be calculated, and need to be added manually.
Best regards,
Miguel Ariño
Ok, so that confirms that we still need to go and manually check the interdependencies for each patch we plan to include. Thanks, Miguel, for clarifying this, and for the explanation as to why!
I am the bearer of bad tidings, when it comes to Maintenance Optimizer 🙂
I wish there were a solution for the patch interdependency, but it's still not there. I guess if it is possible to do it by hand, there must be an algorithm to do it automatically. The problem is that the data model behind MOpz does not support anything in that direction.
Best regards,
Miguel.
Thanks Miguel, I appreciate the insights, as always.
Did the maintenanceplanner solve this problem?
What is your way to patch a three-system-landscape to the latest patchlevel?
Thanks,
Mario
It's also a manual optional step in the Maintenance Planner. You have to press on Add Java Patches in the step Select Files -> Â Select Stack Dependent and Independent files. See the attached picture.