Skip to Content
Technical Articles

Feature switch framework in ABAP

Hi all,

 

I’m currently working on a site where we have about 120.000 users on our system. This means that our changes carries very big impact and risks whenever we do anything. To minimize this I’ve come up with a concept of a feature switch framework.

I know that you are probably thinking, well that’s nothing new. But please hear me out.

So most frameworks I’ve seen in the past is normally based on a global switch to turn on or off an enhancement or maybe have a user table to control who should get the enhancement.

My plan is to develop a quite flexible framework that could be used in different scenarios.

Here’s what I had in mind so far:

  • Enable global switches to quickly turn on or off an enhancement
  • Enable beta testing capabilities to limit the risk of go lives and also to get early feedback on changes
  • Be able to control the beta testing either via a custom authorization object or a user table
  • Enable the feature switch to quickly append to the application log if desired
  • Transaction where you can maintain the switches with a tree like menu structure for the various maintenance steps with documentation

 

For now I’ve build the concept to work with a custom auth object and a maintenance table for the global switch. More will come in the future.

I’ve put the source code on github and it can be cloned via abapgit.

Please comment with ideas or even better help me build this thing 😀

 

11 Comments
You must be Logged on to comment or reply to a post.
  • I’ve thought about something similar in the past. Some notes:

    1. The framework have to be used – someone could implement an enhancement without using the framework. I had no idea besides an organizational rule. Perhaps it would be to have a scan if an implementation is implemented but not controlled by the framework.
    2. If you have a central framework in all enhancements then you have a certain chance to bring all enhancement implementations down if it’s buggy.

    What’s your opinion?

    Best regards, Michael

    • Hi Michael,

      That’s some interesting thoughts. My idea was at least internally now to have it as part of the QA and code review process. But you are right with your second comment that it would be able to bring it all down with buggy code. Hence why unit testing is essential 😉

      I’ve just seen to much in the past changes going in and breaking existing stuff and then no way to quickly revert the changes. With a switch you could simply turn off the new changes and move back to the old. The practice is nothing new in many parts of the software industry, but SAP is still a special snowflake

       

      • Hi Jakob, as I’ve read your lines I thought on a technique I’ve recently seen by Achim Toeper. It’s the possibility to undo transports in the “Change and Transport System”. The keyword here is “Continuous Integration/Delivery”. Maybe worth a look.

  • I don’t understand the concept. I don’t understand if your concept relies on the Switch Framework or not. Could you create another blog post to clarify what the requirements are and how you currently plan to address them? Note that switching off a feature is not really a requirement according to me, companies don’t need to switch them off (apart troubleshooting).

    • I’ll write another blog soon explaining the concept. In my mind the SFW5 switch framework is not flexible enough and doesn’t allow you to quickly turn off enhancement if they are proven buggy.

  • You could also just use the features toggles available in SAP standard if you have a recent release.

    Class CL_FEATURE_TOGGLE

    Transaction FTGL

  • I think maybe we’ve all done something similar in the past.  Getting it into a nice neat framework would be good.

    I had a project that effected many different areas.   Enhancement points, user exits, badis – yes it had them all.  That was the first time I did something similar.  It tested out fine on our QAS system, but I had a way to turn it off if needed.  Sadly, I did need it as it broke a non-related SAP feature.  I was able to quickly switch it off.  (via a custom table)   For this project I also had predefined break-points that I was able to switch on.  Funny because I was ready, I only needed to do one quick fix.  If I wasn’t able to switch it all on and off there might have been more.

    In the case above switchframe work would not have worked.  Although I wonder if it would have depending on how I wrote my code.

    And toggle customizing.   Cool.  I’ll have to look into that a bit more.