Some more technical details about SAP note
- How to use this tool
- Note building blocks
- Difference between this tool and tcode SNOTE – why I wrote it?
Although I have been working on ABAP for several years, I am not well aware of the technical design of SAP note, since most of the time as an application developer, I am responsible for the bug fixing, putting the correction instruction into the note and release it, then our customer can apply it in their system.
However recently my team has encountered some technical issue that is our customer have some trouble to apply our note in their system, which pushes me to know something more detail about SAP note design.
I use this note 2184333 which I am responsible for as an example:
In order to research the technical design of SAP note, I write a simple tool for analysis.
How to use this tool
Just run the report whose source code could be found from this link and execute the report and specify note number: 2184333
Once executed, the report will download the note as a compressed binary stream, display the size of this compressed stream and then uncompress it, allow you to view the building block of the note in detail. In the end the size of uncompressed data is displayed as well.
Take note 2184333 for example, around 137 KB is downloaded and after it is decompressed, the size inflates to around 742 KB.
Please note that this tool just gives you a draft estimation about the static size of note. The runtime overhead for memory management against deep data object such as internal table and string are not considered.
Note building blocks
The decompressed content of note is actually a xml file and could be parsed by function module SCWN_NOTE_UNPACK_XML:
Note header data. See below picture to find how the note header information is maintained in exporting parameter et_cwbnthead of FM SCWN_NOTE_UNPACK_XML.
Note tilte in multi language.
Contains note body in html format in multi language. Content for each language is stored in a single line.
Contains note body in multiple language. Content of each language is stored in a separate internal table.
Contains note validity information. In this information, component key: 16929, we can find its description from table CWBCMPNT. And 63 for BBPCRM.
And how to understand DEALEID_V 244 for BBPCRM?
From this table we can know “244” represents 713.
Contains correction instruction header information.
Support Packages & Patches information.
Note attribute like status and error category:
contains dependencies of correction instructions information.
Object List of correction instructions with TADIR key:
You can also obtain description for 63 and 16929 from this internal table.
detailed code delta change contained in variable LV_CODE_DELTA_BIN
The area below marked with blue rectangle is the code delta change our customer could see in the note browser, and the red area is part of variable lv_code_delta_bin inspected via XML Browser. The delta code change consists of two parts:
1. deletion of keyword “IMPORTING”;
2. insertion of two lines “it_customer_h = it_customer_h” and “IMPORTING”.
From the picture we can see clearly that the code fragment for insertion or deletion has corresponding XML tag ( I prefer to call it as “directive” ) maintained so that the node tool can know WHAT operation should be performed on these fragment. Meanwhile the context ( line number 38 ) is also known so that node tool can also know WHERE the delta change should be applied.
Once you download a note to a system, you can review the detail of downloaded note from transparent tables belonging to package SCWN.
Difference between this tool and tcode SNOTE – why I wrote it?
As you see most of the source code of this tool comes from tcode SNOTE, in my opinion, there are two points which make it worthy to spend some effort to write the tool:
1. One of my favorite way to investigate a topic / issue is: to write a report to deal with the topic / issue, and run the report under trace mode using tcode SAT. With the great power of SAT, there is a tab “Processing Blocks” which gives me a very clear big picture of method / function call in a tree hierarchy view.
Of course SAT also enables to directly measure tcode SNOTE, however this approach is not efficient since lots of other stuff which I am not interested ( such as transaction processing, SAPGUI related handling etc ) are also measured and contained in SAT trace file.
In a word, since I would like to only focus on download and parse functionality in tcode SNOTE, so I extract the code for these two logics into a custom report with all other stuff excluded and then concentrate on these core stuff, that’s it.
2. SNOTE does not provide the function to give user a draft estimation on the size of downloaded note. And since I have written the report, I have the full ownership on it and so I can add any feature to the report which I want to add. As a developer sometimes we will see the need to write some tool by ourselves to achieve automation to improve our daily work efficiency. If we frequently practice to extract code of standard tcode into our own custom report on purpose, our ability of code adaption will grow up in the long run.