- SAP Managed Tags:
Sometimes I worry that SAP are in danger of leaving us all behind. It seems that they are on a starship shooting off at light speed to the stars of Generative AI and cloud everything. SAP customers meanwhile are still trying to get their on premiss SAP ECC biplanes off the ground. I know that SAP have to do this, as they have to stay ahead of the game, to compete, and they currently do this through focussing on BTP, and all the goodies around this, and then incorporating generative AI is all the buzz at the moment. Yet the majority of SAP customers are mostly wrestling with how they will upgrade to S/4 before the deadline of 2027. I understand that SAP must be innovation focussed and so it often falls to SAP tech architects working for customers or SAP partners to ensure that customers can stay on track with their vision to someday catchup to where SAP are at (by which point in time SAP will be somewhere else probably in a far away galaxy😉).
“Keep the core clean” has been the SAP mantra now for at least 6 years and probably for a lot longer, I personally first remember it from Teched 2018 in Barcelona. As a software engineer I read “keep the core clean” instead as “decouple your custom code from the standard solution”, admittedly its not as catchy...
As many SAP customers are still preparing for S/4 upgrades, then many customers are still in the stages where cleaning up the core is very much a key focus area.
What you as an SAP customer can do to prepare for cleaning the core varies a bit depending on where you are in your SAP journey.
Keeping the core clean does not have to be done pre-S/4 – but it should make life simpler, the sooner you start, and what you are essentially doing is cleaning up your technical code debt.
If you are pre S/4 upgrade, I would begin with the quick wins, and this is by focussing on enhancement code that is often simply not encapsulated at all, and so not coded using ABAP Objects, and called from within SAP enhancement points, BADIs or user exits.
Probably the best approach is to focus on encapsulating all your enhancements, ensuring that it is relatively simple to relocate them when the need arises, ensuring there is a clear, well scoped boundary from where standard code ends and custom code begins. Following clean code principles and using SOLID OOPs design techniques enables you to begin to decouple your deeply embedded custom code, in preparation for a future redesign, and or relocation to BTP.
My own experience with custom code from various SAP customers over the years, means that I suspect that many enhancements are just loosely coded ABAP code placed directly wherever the functionality is needed, often with little thought to encapsulation, this kind of code is essentially code debt. Cleaning this code up will help to make your S4 upgrade journey smoother and simpler, or if you are on S/4 it could make your future journeys considerably smoother.
So the main principles are quite simple object oriented principles, that Robert C Martin is famous for defining.
Aim for Single responsibility in the classes that you introduce. Think carefully about their interfaces, their contract to the places that call them, exposing the bare minimum as public, but enough to allow for long term requirements. Try to unknit your spaghetti code, into purposeful methods that don’t do too much. Aim to keep code simple. Don’t be afraid to create additional classes if a class is doing too much work, if its losing its singular responsibilities.
Its often useful to define interfaces that the classes then implement, the interface is then defining a public contract, and can also be useful for unit testing purposes, and the creation of test-doubles. Using interfaces creates a layer of decoupling, and definition, that introduces future flexibility into your solution.
We need to take a methodical approach to all of our enhancements, and slowly redesign them by these simple decoupling techniques.
One of the purposes of this blog is to point out an approach to decoupling that I only fairly recently stumbled upon. This is through using events via ABAP message channels, together with ABAP Daemons, something which Olga has described in a blog back in 2015 and then again in 2018, and also gets a passing mention in ABAP to the Future (Paul Hardy SAPPress) Olga’s blogs are here:
This approach only becomes relevant when you are on an S/4 system, as it requires 7.52 as well as 1809. With this approach, you can for example, raise an event in an enhancement point, and then subscribe to the event from a custom class that is then triggered by an ABAP Daemon process. The daemon processes are considered robust by SAP from 1809 onwards – in that they get restarted if the system is restarted, and events are not at risk of being lost. So switching your enhancements to an event driven programming model really takes another step towards decoupling your custom code to the standard SAP code.
This kind of design means the enhancement is solely used to raise an event and pass the necessary information onto the subscribing class. This means your implementing class for your enhancement is almost fully decoupled. Ready to be migrated to the possibility of a BTP solution or alternative solution. I was quite surprised to find this great possibility was there and I simply hadn’t realised it was there, so I mention it here in the hope to spread the news a little further. Further down this road we have Event mesh and the possibility then to use events for external interfaces, I think many are aware of the event mesh approach, but perhaps less aware that events can be built straight into regular ABAP (this at least was the case for me and a few colleagues that I have talked with).
As always there are pros and cons to this approach. The pros I think are as mentioned, the looser coupling, tied then to all the advantages loose coupling brings (increased future flexibility), one of the cons comes down to the need for atomicity. If you for instance need to update a custom table within the same logical unit of work as the SAP code, then this approach will not allow for that, but I would argue that you probably should not need to be this tightly coupled to SAPs updates, this kind of thinking is what we need to move away from to keep the core clean. The other con being what if the event handling fails. Well we are told that this approach is quite robust now with 1809 support for ABAP Daemons, and so most of the negatives of this approach I think are laid to rest.
In my next blog (probably a month or two away) I want to focus on the enhancement options that SAP are providing for cleaning the core in S/4, and their defined methodologies that are there for helping customers decide for what solution is best for them, and how this fits in with your decoupling efforts.
