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:

1. Note A, Correction 1
2. Note B, Correction 1
3. 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.