After some time, we're back with "SAP OSS Notes Series" - a series of blog posts which aims to cover everything you need to know about SAP OSS Notes.

If you haven't read the previous episodes, check out:

SAP OSS Notes Series - Part 1 - SAP Versioning and Five Ws about OSS Notes

SAP OSS Notes Series - Part 2 - Discovering and reading notes

In this episode we are not going to cook blue sky meth or escape from a prison filled with zombies but I hope you get pretty excited about learning how to apply SAP Notes. Being honest, cooking meth, escaping from "walkers" or applying SAP OSS notes are activities with a similar degree of risk. I'd say the last is the riskiest one.

There are mainly two ways of implementing or applying SAP OSS Notes in your company's system: via support package or manually.

Support Package

You might remember the concept of support packages described in the first episode of this blog series. They are just a bunch of corrections or very small improvements (technically speaking) delivered all together related to the same SAP component.

In other words, a support package (or SP) is a collection of SAP OSS Notes for a single SAP Component. As SAP software is composed by many components, SP are delivered in "blocks". These blocks are referred to Support Packages Stacks if you log into SAP Marketplace. To make things easier, let's just stick with the term "Support Package" to represent a set of SAP OSS Notes.

As each system version (product + EHP) is different than each other, each support packages also diverse. It means that SAP OSS notes contained in Support Package 1 from ECC 6.00 are completely different from the OSS Notes contained in Support Package 1 from ECC 6.07.

Usually, the older the system version, the highest is the number of Support Packages for it. At the moment this blog post is written, the last SP (stack) for SAP ECC 6.00 is SP24, which was released on October 2013. On the other hand, the most recent SP (stack) for SAP ECC 6.07 is SP 3, which was released on the end of last January (2014). It's also possible to check a planned schedule for the next support packages on SAP Marketplace.

So if SAP finds a bug present in all EHP versions of SAP ECC 6, it will (or at least should) fix it in every system version. Then, SAP delivers this fix in the next SP for each system version (for example SP 25 for ECC 6.00 and SP 4 of ECC 6.07). By the way, this fix is described by a single SAP OSS Note (that you know how to read from part 2).

SAP recommends its customers to upgrade their systems to a newer SP at least once a year. As fixes are delivered all at once, there is no need to test every single stuff and the upgrade process is almost automatic, this should be followed as it represents a lower risk for IT departments.

BASIS professionals are the ones mainly involved during SP upgrades. Of course you might want to test if your business processes are still working before upgrading production SP and you might have automated integrated tests or not, but this is a different topic.

Manual Implementation

There are many situations on which you cannot wait until your company upgrade the SP level or even the EHP of the system. These situations are often involved with a present or future issue in production environment.

Having already discovered a SAP OSS Note which fixes an issue, it's time to apply it. As you already know, an OSS note which change repository objects and/or customizing data, meaning it will generate change requests to be transported.

Please read with attention how notes are applied. You will realize that this activity should not be performed by anyone. Risks of causing a system damage are high if no caution is taken.

Pre-implementation steps

Mainly, the implementation of a SAP OSS Note is done automatically by transaction SNOTE. However sometimes there are a few steps you must follow before you implement the note itself. These steps are called pre-implementation steps.

How do I know if there is any pre-implementation step inside a SAP OSS Note?

The answer is simple: you have to read it. When there is any pre-implementation step, it will be said inside the note body. The steps you have to take vary a lot according to the note. Common examples include

• Creation/Change of DDIC Objects (Domains, Data Element, Tables, Structures, Table Types, Views etc)
• Creation/Change of other workbench objects as screens, table maintenance dialogs, PF-STATUS, Titlebars, etc
• Validation of specific data in the database

Normally, pre-implementation steps involve stuff that SAP cannot do it automatically. So they are always done manually.

Keep calm and apply the note successfully.

Who is the responsible for doing pre-implementation steps?

In most cases, an ABAP developer. Occasionally (then customizing stuff have to be checked of changed), a functional professional might be involved as well. There is also the possibility to have a pre-implementation step which involves the import of a change request directly into the system from a kind of .zip file. These files are always attached to the SAP Note in SAP Martketplace. Tell your BASIS friend to help you on such cases as you probably have no access to import a change request directly in the environment.

Things to remember when doing pre-implementation steps

As SAP tells you to create/change stuff under their name range (non-Z objects), you must register each object to be changed in SAP Marketplace one by one. If you as an ABAP developer have no access to SAP Marketplace, tell your BASIS friend to register the objects for you so will be able to apply SAP OSS Note accordingly. DO NOT change any standard object without registering it and don't register any object in SAP Marketplace if you don't have a SAP Note telling you to change it.

SAP OSS Notes are usually done by SAP using the English language as the original language of workbench objects. To avoid any problems, be logged in English when applying a SAP Note

If you have to translate any object to your language, write that down. SAP Notes almost never tell you to do so but you really should to (specially then the changes have an impact in the UI as data element texts).

If there are any pre-implementation steps and once they are all done, you will have a change request. Don't release it in the first moment. You will have other changes to be done and you can (and should) use the same change request to avoid missing objects in quality and production systems.

Note implementation

To implement changes contained inside a SAP OSS Note, you just have to open it using SNOTE transaction and push "Implement note" button. If all pre-implementation steps are done, all pre-requisites (topic of the next blog post) are done and sun is shining to you this process will change some objects and ask you to activate them and include inside a change request. Remember: use the same if you have done pre-implementation steps.

Open SNOTE transaction code

If you have downloaded a SAP Note, click on note browser and insert note(s) number(s)

Double click on it to open or click on execute button to implement directly (always open and read the note before applying it).

If note implementation is done successfully, its status will turn to "completely implemented". If not, something is missing and there are hundreds of reasons for that happen. This will be covered in the next episode.

Post-implementation steps

In the same way you might have pre-implementation steps, you might have post-implementation steps as well. The last is not as frequent but you should know it is always done manually too. Below are some common post-implementation steps:

• Run a specific report to do something
• Translate something to other language
• Activate objects or configurations

Code Search and Replacement

It's very important to understand how SNOTE transaction replaces broken source code by a fixed one. If a specific report or include must be updated, SNOTE transaction does NOT replace the whole source code by a new one. Instead, it replaces JUST the part of the source code which needs to be replaced.

What if there are more than one occurrences of this piece of code and not all must be replaced?

Great question and here is the answer.

Context Insert Delete sections

Once you have an OSS Note opened in SNOTE transaction, you will have a tree on the left side of the screen. Basically it organizes each fix by each product version. You can expand the tree node according to your system version and see which workbench objects are adjusted by this SAP Note. In the example below, 5 reports (Including LGUSLDTT) are adjusted. Clicking on "Change to Source Code" on the left tree, all changes are displayed in the main area separated by three sections: Context, Insert and Delete.

You might correctly guess that what is under "insert" section is the source code which will be inserted once you click on "Implement note" button. The same applies to "Delete" section. So what is the purpose of "Context" section? It's to identify a unique piece of code inside the workbench object (report, include, function, method). The source code inside context section is untouched. However what it comes next will be changed according to the other two sections. This is what makes the OSS Note implementation be automated (when there are no manual steps).

Conclusion

Well, now you should be very confident to implement many SAP notes. However be aware that most OSS notes are dependent between each other. This will be the topic of the next and final episode of SAP OSS Notes Series on AMC SCN.

SAP Team responsible for applying SAP OSS Notes: the one in the left usually is not in charge of applying notes with pre-implementation steps.