text: 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 😀
  A bit older, but still nice.
  I’ve thought about something similar in the past. Some notes:
  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
  Thanks for the information.
  On my end FTGL / CL_FEATURE_TOGGLE is not available in 7.40- systems, but available in 7.52+ systems. (not sure about 7.50 and 7.51)
  Is there some documentation and is it released to customers?
  It’s briefly mentioned in “Agile ABAP Development”, chapter 21.6.2. Not sure about “released to customers”. It doesn’t prevent you from creating feature toggles in customer namespace though.
  Here are some screenshots:
  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.