A Deadly Embrace of SAP Note Corrections
In many ways SNOTE has been a wonderful boon to Basis admins everywhere when applying SAP Notes. It’s not just how the tool can find the right spot to insert the code corrections, nor how it can check if the Note is valid for your release and support pack level, but also how it can alert you to other conditions. Is there a known side effect to the Note that has been corrected by a later Note? SNOTE will notify you, and download the side effect correction Note for you so it’s ready to go. Is there a prerequisite Note that must be implemented first? SNOTE will download it and put it together in a queue with your original Note to be implemented together. Magic!
But all this hand-holding can come at a cost.
Not All That Glitters Is Gold
For instance, those who manage Solution Manager systems (isn’t that all of us, whether we want to or not?) are familiar with the need to apply a new “Basic Functions” Note with each new support pack, and in turn how that Note triggers the implementation of dozens (upon dozens) of other Notes, resulting in Note implementation queues so long, with Correction Instructions intertwined in such a seemingly self-referential way that you half-expect the thing to gain artificial consciousness on the spot.
In such circumstances, I’m glad to have SNOTE! I well remember the days when applying a Note meant opening SE38 and manually inserting the new code, and the opportunities for error were frequent, not to mention the process time-consuming.
Periodically, however, it happens that one has to update that Solution Manager Basic Functions Note, which typically means downloading updated versions of all the “prerequisite” Notes as well. Mostly this goes ok, but sometimes the tool gets itself into a bit of a spin, as it wants to first de-implement the old version of the Note in question, then implement the new version. Sounds logical, right? And usually this isn’t a problem for SNOTE, but sometimes you end up with…
… a list of inconsistent Notes. Why are they inconsistent? Usually it is because the tool had some problem it could not resolve during de-implementation, typically related to dependency. No, I don’t mean substance addiction, but rather that you tried to de-implement a prerequisite Note while the dependent Note is still in the system. This results in error message SCWN027: Unable to deimplement or reset to original.
The Circular Reference
Fortunately, in the long text of the error message you will find the Note (sometimes several Notes) that is dependent upon the one in question. “No problem!” you say to yourself, because the clever tool just gave you a list of what you have to do: go de-implement the dependent Note first. We’ll call this Note B, with Note A having been the one you were originally interested in updating.
So you click on down to Note B and hit Reset SAP Note Implementation. Oh oh; you got the same error message as before. “Ok,” you think, “this might be a little more involved, but I can handle this.” You check which Note is dependent upon Note B, ready to go de-implement that one first instead, and…
… it’s Note A.
That’s right. You just found that Note A is dependent upon Note B, and Note B is dependent upon Note A.
How Did That Occur????
The only way for this situation to occur is for at least one of the two Notes to have at least two different sets of Correction Instructions included. So,
- Note A, Correction 1 has no prerequisites.
- Note B, Correction 1, which came out later, is dependent upon Note A, Correction 1.
- Later still, Note A is updated to include Correction 2, which is dependent upon Note B, Correction 1.
It would be literally impossible for you to implement either of these Notes individually using SNOTE. The tool would not let you. However, as soon as you attempted to implement either one, the tool would detect the dependency, download the other Note, and then propose to implement them together as a queue:
- Note A, Correction 1
- Note B, Correction 1
- Note A, Correction 2
For a real world example, I give you Exhibit A: Notes 2066029 and 2080527. Note 2066029 has two Correction Instructions:
Correction Instruction 1443728 has no dependencies, except for a valid support pack range. Correction Instruction 1484151, on the other hand, has:
Note 2080527 has only a single Correction Instruction, 1468114, and its dependency is:
That’s right. It points back to the first Correction Instruction of the first Note.
Not All Who Wander Are Lost
Except sometimes we are. It is all well and good that SNOTE has a mechanism for implementing Notes together in a queue (oh, and by the way, you cannot manually create Note queues; the tool must create them automatically for you when dependencies are detected). What SNOTE lacks, however, is a mechanism for de-implementing Notes in a queue. It is not possible to de-implement either of the above Notes singly, because there is always a dependency in the system by the other Note. A smart queue would seem to be the only way to do it, but the tool does not allow that. I know. I’ve tried.
Another possibility would seem to be de-implementing or resetting just one Correction Instruction at a time, thus peeling back the onion bit by bit, carefully.
Sorry, Charlie.
SNOTE doesn’t do individual Correction Instructions; it’s the whole Note or nothing. Of course, this is to protect us from ourselves, and with good reason, but sometimes it can be a little frustrating.
What this means, in practice, is that not only can we not de-implement or reset Notes in such a deadlock, we cannot update them either, due to the need to de-implement old versions first.
There’s another old database term for this situation: the deadly embrace.
So Where’s The Happy Ending?
At the moment, there isn’t one. When I am able to find a solution, I’ll report back here. Meanwhile, I’m thinking of a feature request to SAP: add queue functionality to Note de-implementations.
Or better yet, don’t build circularly referential Notes.
I feel your pain and am also glad I need not experience it.
Perhaps SAP never thinks the correction needs to be backed out?
Hope this functionality is thought through or a circular reference check can be reported and resolved.
Regards
Colleen
Oh boy. ;/ Frustrating situation.
Loved the blog, though! It brought me closer to the whole topic (I don't do this kind of stuff, but I'm still interested in it... the sys-admin core in me is still going strong ^^).
So now what? Have you entered in the time-honored back-and-forth with the SAP support?
I just wonder (here comes my "I have no experience in this area." in play): Even if SNOTE can't remove the corrections one by one, can't you? I mean manually? Or is this not possible, when you've implemented them via the tool?
Yes, I could manually change the code, but that wouldn't fix the status of the Notes as reported by SNOTE, and by SPAU during support packs and upgrades, and so on. I will enter an Incident on it, but right now I'm under some considerable time pressure, so I'm seeking quick workarounds -- what does that tell you, I don't have time for official support? 😉 I'm thinking of enlisting the aid of Samuli Kaski, he has written some very interesting documents about wrangling SNOTE to do his bidding (How to force SNOTE to apply outdated SAP notes and How to force SNOTE to reset SAP notes that can't be downloaded), showing all sorts of undocumented and unsupported methods using the Debugger. Highly dangerous, use at your own risk, complete disavowal in case of failure.... just the stuff we live for! 😈
Whoa...sounds like you stepped in a big ol pile of......SAP. 😛 This kinda thing...why...I think it could just lead a man to drink! 😆 😆 😆
Hi Matt
Nice write-up.
There are definitely annoying situations which concern SAP notes.
Another spot where improvement would be nice is what happens if you "cancel" a SAP note implementation during the implementation. A total mess most of the times. I try never to use cancel 🙂 when implementing SAP notes unless it's before anything was clicked or confirmed 😛 .
I feel the pain though, what about the need to click "yes" a thousand times when you've got a SPAU list with many SAP note corrections and you want to reset big heaps of those?
I can keep going ...
That being said, in general, it's a nice system / concept to implement bug fixes into a system, loving the concept but SAP might want to look into it again and bring some updates.
Best regards
Tom
Hi Tom,
I don't have a system to screenshot at the moment, but there is an icon at the top of SPAU (at least in the newer systems) that will run reset's as a batch job, making life a little easier. I think on hover over it just says "reset obsolete notes" or something of the sort. It gets rid of a little bit of the pain of SPAU.
Hope this helps,
MM
Hi Mathew
Thanks for info, I'll have a look in one of the newer systems. I've been focusing on SAP Solution Manager mostly last couple of years, that and SAP HANA advice / technical architect so I seem to have missed out on something 😉 in the meantime.
Best regards
Tom
Yes, as Mathew mentions, the "mass reset" functionality for obsolete Notes was introduced in SPAU with Notes 1972294 and 1975910... but in SNOTE there is still no such function -- at least not as of Basis 702 sp15, and I'm pretty sure there still isn't in Basis 740 sp12.
I did think that if I could somehow use SPAU instead of SNOTE to do this that it would work, because of that "mass reset" function, but I think the only way I can get the Notes to show up in SPAU will be to import a newer support pack that then tags them. Seems a bit drastic. 😆
I hear you on the "cancel" function. I have used it more than I would like, and sometimes it works... and sometimes it leaves you with just as big a mess as whatever you were cancelling out of.
I will say, overall, I really like SNOTE and the functionality it provides. It has made the Basis admin's life much easier in general, especially as pre-existing Notes have been gradually adjusted to be "SNOTE-compliant." It just still has a few quirks.
Cheers,
Matt
Last time I ran the mass reset in SPAU, it actually fixed a lot of the inconsistent notes in SNOTE, that's why I mentioned it. Now I need to try it again to make sure that's the expected
One thing I've noticed when you're in the note "rabbit hole of death", is that if you cancel for some reason while applying a mass note (Solman composite note for instance), and then go back to it, the second round doesn't seem to implement all of the child notes with it (only the original). Again, that's something I would need to confirm, but I just don't know that I want to potentially mess up a system to satisfy my curiosity.
Blog is very nice, by the way. A good read!
The Notes "rabbit hole of death." Apt phrase!
That "Basic Functions" Note, and the need to repeat all the System Prep and Basic Config stuff, is the main reason I try to avoid Solution Manager support pack updates! It's very time-consuming, and hard to justify to management. Still, from time to time it must be done. It shall be done.
An interesting twist. I just discovered recently released Note 2264123 (Stopping deimplementation of obsolete notes). If you implement this Note, or the support pack that contains it, then instead of getting a message about deimplementation of the Note (successful or otherwise), you will get a hard error stating "Contact SAP Support." That's it. Apparently it is too easy to mess up your system with SPAU/SNOTE de-implementing obsolete Notes incorrectly (you think?) that SAP is simply going to prevent it.
I'm not sure how long this will stand, however. Methinks it will generate a great many more support calls by frustrated customers when their upgrades and support pack updates are interrupted in SPAU with a hard error because naturally obsolete Notes should be deimplemented.
SNOTE is OK when it works and terrible when it doesn't (much like most stuff in SAP, come to think of it. 🙂 ) Fortunately, I haven't encountered the "deadlock" situation, but de-implementation leaves a lot to be desired.
Just last year we had to install the whole bunch of notes for a new legal requirement and after doing Note A, B, etc., somewhere on the Note K we suddenly ran into the syntax errors. It turned out that along the way SAP decided to issue a new version of the Note B or C, which caused a ripple effect on the rest of the notes (why on earth do they do that?! just issue a new note!). Since we were applying the notes as they were released, we had an old version and for some reason didn't get prompted to update it when adding new notes on top. The SAP Support's response was: "Ugh, we don't know what to do, just remove all the notes and start from the beginning".
Oh, merry elfin Christmas! Some of those notes had other prerequisites, manual steps, even one modification thrown in the middle (long story). So here we go, set messenger to "do not disturb" and start peeling away stuff manually, note by note.
But I guess SAP is not really planning on any improvements in SNOTE because, you know, everyone should be moving to The Cloud any minute now.
Oh yeah, the "peel it back so you can update an earlier Note in the chain" syndrome. That's actually pretty much what led to this blog, indirectly.
One other thing that I forgot that may help some folks. Check out the following notes (these are actually notes to fix SNOTE, ironically enough). I found these a couple years ago when I ran into SNOTE issues. Now I try to make sure they're in all my systems.
1668882 : Note Assistant - Important Notes (NW 7.30-7.50)
875986: Note Assistant - Important Notes (up to NW 7.02, like Solman)
Matt, this may be handy up in the blog.
Thanks,
MM
Mathew, very true.Indeed, I made sure I had Note 875986 and every Note it references up-to-date before getting into this mess.
As of today (December 20th, so about nine months after I wrote this blog post), this situation still exists in SAP without resolution. There have been no updates to the problematic Notes, nor any relevant update to SNOTE functionality. I do have a Customer Incident filed with SAP, so we shall see.
It is apparently possible to de-implement one correction instruction at a time in SNOTE, but I could not do this myself. SAP Support was able to do it, from which I gather they must have access to some undocumented/hidden functionality. Given the potential for customers to dig themselves even deeper into the hole with such a tool if used less than very carefully, I can understand why they might keep it restricted to themselves.
In any case, the situation is now resolved in my own system, but the two example Notes I mentioned in the blog still contain the circular reference, so it could easily come up again for someone else.
Â