Skip to Content
Technical Articles
Author's profile photo Julian Phillips

OCC ABAP Cleaners OR How to tidy up the Core

To clean or to tidy-up?

In this blog I intend to go over what for many is perhaps old ground, over what is a dirty SAP core, and how to then tidy-up this core.


Excuse me whilst I digress a bit. One of my wife’s favourite shows on TV is a show for all of us core tweaking ABAP’ers to watch “OC-Cleaners” – it’s a fun ride where a self-confessed “OC-cleaner” is called in to solve a situation that has somehow developed at someone’s (often a “collector”) residence. Quite often the residents are mystified as to how they ended up in quite the pickle that they now find themselves in (often it’s hard to get in the front door without tripping over stuff), and the cleaners are quite frankly horrified too. There is great entertainment to be had watching the reactions of the OC-Cleaners and the collectors.

For several years now since Teched 2018 (I was lucky to attend Barcelona) and in many publications since, SAP has been repeating the refrain “Keep the core clean”, You could say SAP are the original SAP OC-Cleaners. SAP’s stated main driver for delivering S/4 HANA was simplification (that’s what the S in S/4 stands for). S/4 is essentially a clean-up of the core systems design of its code and data model. I think SAP then realized that they also need their customers to follow on this simplification journey with custom code, or all of their SAP simplification efforts were wasted. We can question how completely SAP achieved this (a topic for another day perhaps), but this lead to the mantra “Keep the core clean”.

The questions that many developers then raise is “What do SAP really mean with keeping the core clean?” AND/OR “How do we get to a clean core?” and then “How to keep it clean?”.

We will attempt to answer these questions here. The cleaning also concerns customer over how to retain all of their added value custom developments (mirroring the collectors anxiety over throwing away all of their stuff), whilst at the same time receiving all of the very latest tech that SAP are now delivering in abundance (see my other blog on Storm in an SAP BTeaP cup). As previously mentioned Wouts blog I found goes into some deep thinking around what is meant by a clean core (see Wout’s blog here “keep the core clean considered harmful) – I will describe my interpretation here; and then explain that perhaps we don’t need to be so much OC-Cleaners (which as Wout points out actually maybe harmful to us) and more perhaps SAP core tidiers (or one small step at a time).


OCC SAP Cleaner

Typically the residences at the start of the OC-Cleaners show resemble our core SAP custom code bases today, after several years of happy custom coding. Even the best customers of SAP at some point resort to very necessary changes in and around the SAP core. These changes we make parallels what happens at the OC-Cleaners (OCC) tv-show collectors’ residences, we buy new stuff (make new core changes) that we want to use ASAP, we use it, and then don’t place to much thought on placing it tidily in the right place (get the design right), then we go out and buy some more stuff (accumulating code debt), eventually all this stuff start to stack-up blocking access to the sofa… The problem is that our code bases over years of work tend to evolve organically (rather like the OCC collectors residences), and developers (often under delivery pressures) prioritize performing changes as quickly and as simply as possible (mvp-style (minimal viable product)), with a view that value can be achieved as quickly as possible, something surely every customer wants?

These kind of organic changes, usually work fine at the start and value is achieved from a customer perspective, whilst at the same time the changes begin to accumulate. What initially seemed like a small piece of isolated code and the quickest and best solution, may on reflection after a few years, have lead to a “spaghetti like” code base, after repeated changes. Essentially this is an OCC episode at the start, a nightmare scenario and a “Code Debt” situation, where we have left items of code blocking access to our needed simplifications for regular upgrade and or S/4 upgrade changes, we are in danger of tripping over the user exits, mods, implicit enhancements, before we can reach the promised hallowed simplified lands of S/4 (or the sofa).

Now at the time where many of us are getting ready to upgrade to S/4, where we have many code changes to perform, the ongoing practices of quickly performing core coding tweaks inside the “AB core” is leading to a continually more complex code conversion for us all, and additionally this journey to S/4 becomes more tricky with each new code tweak that is performed. You might think “the sooner we invite in the OC Cleaners the better!”. However in place of full-on cleaning out changes, I propose instead we tidy up the core one bit at a time.

Tidying up, in terms of ABAP, is essentially a process of code redesign and refactoring, encapsulating and separating concerns, one bit at a time.

A clean core is not so much a core without custom ABAP, but it is a core with well designed and clearly interfaced and carefully encapsulated custom code. This code is then far easier to deal with during upgrade situations, and you have more flexibility in terms of future redesigns. Its the customers code that we want to focus on here, as that’s what we can influence and customers perhaps, didn’t quite get the cleaning message, where the cleaning is really needed, and this is a result of the message I think being a little bit undefined.

A key tidy-up target is tight coupling.

Tight coupling is the enemy of agile delivery, and is really the knots in the tangled mess of the dirty core. What do we mean with tight coupling?

Wikipedia defines coupling as “In software engineering, coupling is the degree of interdependence between software modules; a measure of how closely connected two routines or modules are; the strength of the relationships between modules.”

To decouple code cleanly we must aim for a separation of concerns, together with a clear purpose and a clear interface for each code change. The good news is, that this is not a new problem to computer science, and computer science boffins have been thinking on and around this challenge for many a year. This thought process has partly lead to the principles of S.O.L.I.D. coined by Robert C. Martin (SOLID is one of the foundation stones of the Agile coding movement). Many aspects of SOLID are very relevant to our core changes and can be applied to our SAP custom development today in the effort to help us tidy up the core, and many of these principles I would argue SAP are following themselves today (just not everywhere, even for SAP is in a code tidying journey).

The primary type of code we need to really look out for is where code dependencies are not clearly respected.

So what sort of things are we considering with “Core changes”? In Wout’s recent blog he argues it is changes inside the Application Boundary (the AB).

For code within “the AB” I think about traditional user exits, function exits, changes made using the enhancement framework (Non BADI), implicit enhancements, and then straight out modifications to SAP Standard (having worked in and around SAP customers for many years, I can say most customers using ABAP have examples of almost all of these kind of changes in abundance).

The clean code movement also introduces the Boy-Scout rule, which is essentially “always leave the campsite cleaner than you found it” which I think points to the real solution. In other words, constant incremental tidies wins over a full clean-up. Incremental tidying up the core then should be the goal, and really it is a step by step exercise in code refactoring and redesign, with the aim to decouple and eliminate the tight dependencies.


To decouple core code we should be aiming to follow SOLID principles, just to list out the core principles (without fully diving into the detail):

Single responsibility – Give it a “single responsibility” (keep it simple) “A class should have one, and only one, reason to change”

Open for enhancement, closed for modification – Enhancements (think of the framework) we understand in SAP as well as modifications (direct changes to SAP code).

Liskov substitution – Liskov means to honour your contract, the behaviour of a class/interface should be consistent across its implementations.

Interface segregation – Decouple using class-interfaces

Dependency inversion – breakdown and eliminate dependencies

When first looking at a core change, ask yourself, is this code encapsulated and performing a purpose for just one responsibility? So a change requirement coming from one area of the business won’t necessarily impact another unintended area (for example). So try not to merge multiple responsibilities into a single class, try not to do too much. If you have code serving multiple responsibilities probably the best solution is to split the responsibilities to multiple classes (and avoid coding direct dependencies between classes). Document what the responsibility is that your encapsulation is performing clearly (or make it clear in the naming), also briefly document the possible impact of that responsibility not being fulfilled (if you can and to the best of your ability).
Try to keep the methods interfaces clear, clean and simple. Each method should be understandable from its naming what it is trying to achieve.

Open for enhancement, closed for modification.
With the enhancement framework SAP have kindly provided us with what is arguably a best practice way to apply core changes. That is the usage of Kernel BADIs (see a good blog on these by Joseph), a Kernel BADI (or business add-in) is a defined enhancement point that uses a class-interface definition and a class implementation of that definition, you can then apply filters to that implementation for finer control, then there should also be a default implementation for a kernel BADI. The BADI when executed, executes efficiently within the kernel. The advantage of the BADI definition is that they place a clear contract (Liskov) and interface point that any enhancement is bound to, essentially they state how they interact with standard code clearly. As such it can be simpler to lift and shift these definitions (say in an S/4 upgrade situation), than for code where the interface and scoping is less clear. BADIs come with encapsulation designed into them, although you should still follow the principle of single responsibility and try to keep them simple. Kernel BADIs are preferable (to non-kernel BADIs, now considered obsolete) as they are implemented in a fashion that means no performance penalties for the implementations. If there is no standard BADI definition provided, I would argue to place a custom kernel badi definition at the point where your enhancement is needed (even though this may be technically a modification (Yikes! OC Cleaners and Mr Martin are now coming after me) its still a modification where you are stating “I will add a controlled and well kept piece of code here”), if no clear enhancement point exists.

I usually strongly recommend against implicit enhancements, as these are very similar to open modifications, and without clear scoping. They are changes that SAP are certainly not expecting you to make, and changes that are very likely to be impacted during upgrades, and so best to avoid, but if you do need them, then encapsulate and follow SOLID principles. Avoid at all costs cloning SAP standard combined within implicit enhancements.

Some of the other principles of SOLID also apply, but those come bundled to an extent when following the kernel-BADI technique.

So what is important is that for every custom change we make in the AB core we take time to encapsulate, and then aim for singular responsibility.


The Boyscout rule (Robert C. Martin)

We can incrementally follow our journey to a tidier core by following a principal of clean code, and that is:

If we tidy the campsite, each time we camp (every time we make a change) so that we always leave the code cleaner after a change than it was before we started. Following this habit, then eventually the core will be a tidier place, and less need for the OC-Cleaners to invade our systems!

So I would argue that in place of a message “keep the core clean” instead we should be aiming for “Keep the core tidy”.

Addendum: When I asked SAP-BTP experts a little while ago over what they recommend to keep the core clean, the answer they give appears simple, although not always practical, and quite distant for customers to achieve: “take your core changes and move them to side by side solutions”.

Side by side is great in certain use cases, and certainly leads to a decoupled solution, but it is usually several giant steps away, and not always achievable even in the medium term for many SAP customers, as for instance you may need to really get under the hood of the standard solutions to really gain the advantages you as a customer need, or perhaps you need real-time access to some really big tables, there can be many reasons why you consider you need to build close to the core. So completely cleaning the Core is often not an option (sorry OC Cleaners, SAP and the misses😉).

Just remember step 1 to reach side by side is separation of concerns and encapsulation, and so the above recommendations are a small step on the way to perhaps one day reaching OCC nirvana.

Assigned Tags

      You must be Logged on to comment or reply to a post.
      Author's profile photo Abraham MD
      Abraham MD

      Dear Julian Phillips,

      Thank you for the excellent blog. How do we handle a situation where there is no API and standrad BAPI/FM available and the only option is to BDC recording. What is the recommendation?

      Author's profile photo Julian Phillips
      Julian Phillips
      Blog Post Author

      Hi Abraham,

      I am really happy to find you are reading my blog, so thank you for that. As you mentioned no API and no standard BAPI / FM, I think it really does depend on what you are trying to do.

      BDC is near obsolete now, this as it relies on a GUI, and it is quite slow to execute. I think where there really is no API provided at all by SAP - you should first ask yourself if there is an alternative way to go about what you are trying to do?

      Sometimes taking a step back is the way to proceed. In other words, do you really need to perform an update (I assume an update is what you are trying to do...) where you are trying to perform one? perhaps you can trigger an event, and perform an update from an event instead of embedding your data together with the standard. So try to decouple and take your solution out of the standard instead of placing it deeply inside it.

      I usually spend time googling around to see how others have managed this kind of situation, as if no-one on the planet has previously tried to do what you are trying to do - that should tell you that its probably not something you should do, at least its a good indicator. Then perhaps batch input is still the way - but I would be reluctant to choose it.

      Its possible there are other solutions available, for instance a web-proxy API, or perhaps a managed RAP scenario (if you are at the level supporting this on S/4).

      The more modern alternative to Batch input are automation tools that use gui-scripting, these days this is becoming more of an option, if you are gonna enable gui-scripting in production, do it on a specific scenario basis (do not open it up generally), scripting automation works similarly to BDC from a browser, and fill in the fields needed, and usually is faster and more efficient and more future proof, as scripts are fairly easy to correct.

      My main recommendation is - try to not always go for the tried and trusted 25 year old tech, but try to think on the options that are now possible instead, and check to see what others are doing (as you are doing by replying to this blog - so well done!)

      Author's profile photo Jelena Perfiljeva
      Jelena Perfiljeva

      Hey, not sure if Abraham MD saw your reply (we need to use Reply button under the comment in order for the person to get notified or use @ mention like I just did) but I hope they do get notified now.

      I want to add that in reality, too many times there is actually still no replacement for BDC. That's just hard truth. Of course, as suggested, do your diligence and research if there is a new functionality or API. But there are still not enough APIs even in S/4HANA (on premise, SAP does some stuff for Cloud but then doesn't downport it) for a lot of functionality.

      The customers should use SAP Influence website to keep requesting APIs, I think, although even that is not always possible. Developers have been talking about it for years with no visible results.

      Author's profile photo Abraham MD
      Abraham MD

      Thanks a lot Jelena Perfiljeva. You are absolutely right. There are many missing APIs in IS-OIL space which requires such BDC programs to trigger data from ERP systems. If BDC is not recommended then we need to know what is the way out for those situations considering many customers still use Business Suite and they have plan to see S/4 in few years.

      Author's profile photo Julian Phillips
      Julian Phillips
      Blog Post Author

      Hi Jelena,  Sorry for the miss in using the reply button (oops), thanks for noticing and notifying Abraham.

      I totally agree that more APIs are needed, and also that SAP Influence does seem to be the main option there to achieve that. If we are to keep the core clean, we need to have the APIs in the right places to help us to achieve that.

      Also then for industry solutions it can be even more challenging to get enough influence together to achieve this, which is why I think it is critical that we all get involved with our national user communities - like ASUG, DSAG, and where I live SAPSA, team up with other companies in your area and then if more of us ask, there is more chance we get noticed and actually influence the solution.

      Author's profile photo Abraham MD
      Abraham MD

      Hi Julian Phillips,,

      Thanks for the reply. Our situation is that there are t-codes in IS OIL which can raise such situations where you do not have any API/FM/IDoc/Proxy services option. We are still living with it. Don't know if RPA can fill-in here. We will see.

      Author's profile photo Julian Phillips
      Julian Phillips
      Blog Post Author

      Hi Abraham,

      See the response above. Try to engage with your user organisation, and with other companies using IS-Oil, and build a community, then request on the SAP influence page (that Jelena posted above). I think if there are more companies asking for it, its far more likely to get the kind of response that you need. Good luck.

      Author's profile photo Julian Phillips
      Julian Phillips
      Blog Post Author

      I have just noticed the following blog, which I post here in case others have also missed this:

      Here Jeetendra explains all of the modern extensibility options, lists the best practices and helps to prioritise and explain which is best in which situation, this is a really good blog that I would highly recommend.