Skip to Content

Introduction

Quite often we come across such cumbersome enhancement implementations at various customer sites that are not only difficult to support but has very little or no reusability at all across the development landscape. The source code behind these enhancements continue to grow from bad to worse over time as the business continues to request changes to these objects frequently as the business itself grows and evolves; to a point where it becomes simply a nightmare to support these objects not only from the development perspective but also from the testing standpoint, for example, to perform regression testing of all the existing functionalities when a current enhancement is extended and it results in change of behaviour of the enhancement in regards to the current business processes.

The objective of this blog is to demonstrate a simplified approach to implement custom enhancements by leveraging the powerful features of the new Enhancement framework together with the Switch framework that is well integrated into each other.

The Problem

Let us take an example of a classical User Exit (UE) component in the HR module PBAS0001 and its most common implementation at customer sites. Those unfamiliar with this particular UE – Two Function/Exit Modules are provided by SAP to the customers one to default values at PBO and the other to check values at PAI at the time of HR Infotype master data maintenance via its related transactions.

A Classic UE Implementation via CMOD – Example (of a developer’s nightmare)

"The source code shell below is to demonstrate the support difficulties over time
"Developer #1 starts initial development...
CASE innnn-infty.
     WHEN '0000'.
          PERFORM do_something.
          IF var1 = constant1
             PERFORM do_something_else.
"Developer #2 starts making changes...
          ELSE.
            PERFORM read_something.
"Developer #3 starts making changes...He spends hours figuring out how to make his changes
"without interrupting any of the current functionlities
            "IF var2 = constant2.                         "del Developer #3
               IF var2 = constant2 AND var1 = constant1.     "add Developer #3
               MESSAGE e001 WITH sy-msgv1 sy-msgv2 sy-msgv3 sy-msgv4
                    RAISING errors_occured.
             ENDIF.
          ENDIF.
           IF...
             IF...
 "Developer #4 starts making changes. He is completely lost! He spends days trying to make sense of it all
                CASE...
                     IF...
                     ENDIF.
                ENDCASE.
           ENDIF.
             ENDIF.
     WHEN '0001'.
          "same story repeats here as well...
     WHEN '0002'.
          "same story continues here as well.... 
      WHEN OTHERS.
ENDCASE.

   

The Drawbacks of this Model

  • Code is procedural as a result the entire Function Group with all its global data is loaded every time into the memory at each call of the UE
  • Extremely messy to program
  • The framework does not support multiple implementations
  • A Classic BAdI definition without multiple implementation option has similar limitations to that of a Classic CMOD UE
  • Source code is cluttered everywhere as the implementation grows with time – Lots and lots of IF statements constructs
  • Implementations are not structured; they have no layers – they are extremely cumbersome to maintain
  • Business logic is not decoupled – No decoupling within this (old) framework
  • Hence no reusability across the development landscape
  • Support nightmare – Developer #4 needs to be extremely careful when changing source code as not to interfere with the functionalities of Developer#1, 2 & 3
  • Difficult to test especially in terms of regression testing – Difficult to pinpoint defects and isolate them
  • Difficult to sustain the solution in the long run
  • No flexibility over full or part of the functionality/implementation to make them active/inactive i.e. they are not Switchable

The (much) Better Approach

“Converting” classic UEs (and classic BAdIs) implementation to call custom Kernel BAdI implementations to leverage the power of the Switch Framework that is so well integrated within the new Enhancement Framework. This not only simplifies all the enhancement implementations but provides a structured development approach that is bound to add a lot of value to the SAP landscape in the long run.

The Advantages

  • Kernel BAdIs (or Enhancement Spot BAdIs or New BAdIs) are way faster than Classic BAdIs and/or the Classical UEs
  • Multiple Kernel BAdI implementations are possible where a Classic BAdI definition allows only a single implementation (Not multiple use)
  • Multiple Kernel BAdI implementations should normally be the approach for Classic UEs as they never can be marked for Multiple use
  • Multiple BAdI implementations can be done on a single Enhancement Implementation (EI) or it could be 1:1 depending on the requirement
  • Implementations are Filter dependent which means applications have control over calling specific implementations of a BAdI and not all
  • Implementations are clean, separated from each other as a result they are structured – source code is never cluttered
  • The entire business functionality (i.e. the UE) is Switchable
  • Each implementation of the UE is also Switchable by its own defined Switch
  • Business logic is decoupled
  • Hence business logic is reusable across the development landscape – for e.g. A standalone application reusing a specific business logic of a large enhancement implementation; Call the BAdI but return the business logic result for Infotype 0001 only!
  • No pain in regression testing – just turn off the Switch of a specific implementation to isolate errors
  • No more support maintenance nightmares – Developer #4 now simply creates his own new BAdI implementation on the same EI or creates a new EI

Example of a Custom Kernel BAdI with Switchable Enhancement Implementations

In our example, we will convert, simplify, integrate and structure the Classical UE/CMOD implementation PBAS0001 into the new Enhancement Framework. In our sequence of building blocks, we will first build the objects related to the Switch framework followed by the objects in the Enhancement framework to make it easier for the audience to understand the building flow and the integration between these two frameworks.

Package Hierarchy


We will start off by building a Package Hierarchy in order to structure our enhancement development – we will see later that this is very important so that we could leverage the switches to make our enhancements as flexible as possible. In any case, it is a good practice to to group development objects into the appropriate Packages and to have a meaningful Package Hierarchy in a development landscape.

Package_Hierarchy.PNG

where HR = Human Resources, PA = Personnel Administration, MD = Master Data, UE = User Exit, INFTY = Infotype followed by the infotype number.

Business Function Set, Business Function & Switches

Next, we will create a Business Function Set (BFS), an (Enterprise) Business Function (BF), link the BF with the BFS, create 5 Switches then link these Switches with our BF and finally assign appropriate Packages to our Switches (or not).

Bus_Function.PNG

Business Function ZHR_BF_PA_MD_UE consists of 5 Switches which are required to control our New custom BAdI implementations.

Bus_Func_Set.PNG

Our BF is also assigned to a Business Function Set – which does not hold much context to our current demonstration but its good to know that every BF needs an asignment to a BFS to complete the SFW hierarchy.

Linkage between Switches and Packages


The table below contains the details of the Switches along with their individual Package Assignments and activation status.

Swich ID Switch Description Package Assignment Activation Status

ZHR_SFW_PA_MD_UE_INFTY_0000

Switch for Infotype 0000 ZHR_PA_MD_UE_INFTY_0000 Standby
ZHR_SFW_PA_MD_UE_INFTY_0001 Switch for Infotype 0001 ZHR_PA_MD_UE_INFTY_0001 Active
ZHR_SFW_PA_MD_UE_INFTY_0001_01 Switch for Infotype 0001 – Seq 01 None Standby
ZHR_SFW_PA_MD_UE_INFTY_0001_02 Switch for Infotype 0001 – Seq 02 ZHR_PA_MD_UE_INFTY_0001_02 Active
ZHR_SFW_PA_MD_UE_INFTY_0001_2A Switch for Infotype 0001 – Seq 2A None Standby

Business Function Activation


Our BF is fully reversible i.e. it can be turned ON or OFF any time in the development system – we have turned our BF ON (Green traffic lights) however it contains 5 Switches some of which are turned ON (Green traffic lights) and others are on Standby (Yellow traffic lights). You can also view the Package Assignments for every Switch from the SFW hierarchy browser (see screen-shot below)

sfwb.PNG

Confirmation that the Business Function is Active

BF_Active.PNG

Custom Enhancement Spot BAdI Definition and Enhancement Implementations


In the next step we create our custom Kernel BAdI definition and mark it for Multiple Use, Reusing Instantiation for Instance creation.

Espot_Def.PNG

Our BAdI definition uses standard interface IF_EX_HRPAD00INFTY but because it is an Enhancement Spot BAdI it also requires the interface IF_BADI_INTERFACE to work with. As a result I had to create interface ZHR_IF_EX_PA_MD_UE then include the standard interfaces as above.

The BAdI defintion also defines a Filter i.e. it is Filter Dependent on the Infotype number (see screen shot below) which in effect means every implementation will be called by the framework with a match of the specific Filter value (in this case it is the infotype number) that will be defined in its BAdI implementation.

Espot_Filter.PNG

In the below screen-shot the value of the Filter has been specified in the BAdI implementation for Infotype 0000; which is bound within the rules of the Filter defined within the BAdI Definition.

Filter_value.PNG

We proceed to create our first Enhancement Implementation on this BAdI (for Infotype 0000 processing) assigning it to the Package ZHR_PA_MD_UE_INFTY_0000. This is because we had assigned this Package to Switch ZHR_SFW_PA_MD_UE_INFTY_0000 earlier therefore we would like to control this implementation of infotype 0000 with this Switch (refer table of Linkage above)

Enh_impl_0000.PNG

You will notice under Runtime Behaviour, in the field Switch Framework, the system has detected that this implementation is currently switched off by the assigned Switch ZHR_SFW_PA_MD_UE_INFTY_0000. The properties of this Enhancement Implementation also automatically is set to Standby as per the activation status of the assigned switch (see screen-shot below)

Enh_impl_0000_properties.PNG

The developer can now proceed to create a BAdI implementation on this Enhancement Implementation then write the source code in its implementing Class (in the methods of the interface that it inherits) as per normal. Note that neither the BAdI implementation nor its implementing Class are switchable by themselves – it is the Enhancement Implementation object that is connected with the Switch which then controls its BAdI implementations & their respective implementation Classes.

Next, we create 2 Enhancement implementations (EIs) for Infotype 0001 – then we create 3 BAdI implementations on top of these 2 EIs. (as per screen-shots below). Actually I did create one more EI in the prototype but let’s just ignore it as the ones explained below is exactly the same.

SnipImage.JPG

Note that the above EI is assigned to the Package  ZHR_PA_MD_UE_INFTY_0001 which in turn has been assigned to Switch ZHR_SFW_PA_MD_UE_INFTY_0001 and its activation status in ONSnipImage-1.JPG

SnipImage-7.JPG

Our final EI on (Infotype 0001) has two BAdI implementations. As stated already, the BAdI implementations themselves are not switchable but they are controlled by the Switch incorporated in their EI. The EI above is assigned to Package ZHR_PA_MD_UE_INFTY_0001_02 which in turn is assigned to the Switch ZHR_SFW_PA_MD_UE_INFTY_0001_02 and its activation status is ON. However, the second BAdI implementation 02A has its own defined Switch ZHR_SFW_PA_MD_UE_INFTY_0001_2A which has no Package assignment and it is turned OFF.

Because the Switch behind the EI is turned ON, both the BAdI implementations will be called by the system but we have deactivated the Switch of the second one and therefore we do not want to call its business logic at runtime. To achieve this requirement, we implicitly check the Switch in the implementing Class of 02A as per screen-shots below in both its Methods that are called by the system at the time of HR master data maintenance.

SnipImage-2.JPG

SnipImage-3.JPG

Implicit Switch check in the PBO Method

SnipImage-4.JPG

And the same for the PAI Method

Finally, we call our BAdI from the Function Exits of PBAS0001 – we call the Method before_output from the PBO passing the infotype number to the BAdI Filter

SnipImage-5.JPG

And the Method after_input from the PAI passing the infotype number to the BAdI Filter

zxpadu02.PNG

That’s the only source code that is ever going to be there so this is going to be pretty much static. All business logic for all the infotypes will reside separately in the BAdI implementation Classes.

Now that our model is ready, let’s revisit the SFW Browser to look at the final relationships.

sfwb_2.PNG

Let’s also revisit all the components of our Enhancement Spot and its relationships.

Espot_BAdI.PNG

     Benefits of the Enhancement Spot BAdI


  • The business logic has now been decoupled – we are now free to call it in any application by using the same source code above – we also have control over which particular infotype logic we want to call/validate in our applications taking advantage of the BAdI Filter by simply passing the infotype number to the filter. Hence this BAdI is reusable across the landscape.
  • If another object (zcl__xyz) needs access to a Private method of a specific implemention class (for e.g. to reuse a method which does a complicated calc and returns a value) – this can also be achieved by making it “Friends” with the BAdI Impl. class then simply instatiate it from zcl_xyz as normal.
  • The developers no longer have to worry about existing logic and functionalities in place as long as they implement their own business logic via a new implementation of this BAdI.
  • The entire Business Function (the UE in question) can be turned ON or OFF easily via the Switch framework.
  • Each implementation can also be turned ON or OFF via the Switch framework therefore control is available at more granular level – commenting out of source code etc. are not required.
  • Implementations are structured, layered by business logic and source code is not cluttered any more as the developers do not need to touch the old/existing implementations but focus on their own implementations.
  • Testing and regression testing is much easier now – Isolate the cause of the defects by simply turning the implementations OFF then ON one at a time as when required.

Conclusion

We have demonstrated the ease of developing enhancements by using the New Enhancement Framework leveraging the benefits of the powerful Switch framework to simplify, structure and add lots of flexibility to the enhancement builds.

To report this post you need to login first.

22 Comments

You must be Logged on to comment or reply to a post.

  1. Suhas Saha

    The good points have already been highlighted, so i would not repeat those. Just a couple of this i would like to highlight –

    • Multiple Kernel BAdI implementations are possible where a Classic BAdI definition allows only a single implementation (Not multiple use)

    I’m not sure what you mean by that, but we have “mutli-use” classical BAdIs. ‘Multi-use’ attribute is not the differentiating feature between Classical vs Kernel BAdIs.

    • Can you provide the relevant transaction codes also, for the lazy ones who don’t want to search for them? 😈 This is to ensure the completeness of the document.

    I wish we have more of such genuine content in the ABAP forums.

    Vielen Dank,

    Suhas

    PS – Sorry for being critical, it’s hard to change yourself 🙁

    (0) 
    1. Sougata Chatterjee Post author

      Suhas Saha wrote:

                             

      • Multiple Kernel BAdI implementations are possible where a Classic BAdI definition allows only a single implementation (Not multiple use)

      I’m not sure what you mean by that, but we have “mutli-use” classical BAdIs. ‘Multi-use’ attribute is not the differentiating feature between Classical vs Kernel BAdIs.

      What I meant is that it is possible to convert a Classic BAdI, which is not marked for multiple use, into a custom Kernel BAdI which can be defined as a “Multiple Use”

      • Can you provide the relevant transaction codes also, for the lazy ones who don’t want to search for them? 😈 This is to ensure the completeness of the document.

      No, you will have to find it out for yourself – the intention of this blog is to highlight the benefits of using the new Enhancement & the Switch frameworks – its definitely not a “How-to” document 😀

                         

      (0) 
  2. Suhas Saha

    Hello Sougata,

    In the UE includes where you have implemented the GET BADI call, i do not see the definition for the BAdI reference go_badi_hrpa_md_ue.

    Am i missing something?

    BR,

    Suhas

    (0) 
  3. Bruno Esperança

    Hi Sougata,

    Thanks for this blog post, very helpful information!

    I have one small question, what are the advantages of creating switches to activate/deactivate at BAdI implementation level instead of activating/deactivating the BAdI implementation itself? Is it just for coherence sake or are there any other advantages? Because in my opinion it could be confusing to have two ways to deactivate/activate a BAdI implementation.

    Thanks!

    Best,

    Bruno

    (0) 
    1. Sougata Chatterjee Post author

      Hi Bruno,

      In the New Enhancement Framework you could have n number of BAdI Implementations for a single Enhancement Implementation; it is a 1:n relationship. But each of these BAdI implementation cannot be deactivated individually – you’ll need to deactivate at its parent level i.e. at the Enhancement Implementation level; which will result in all of its BAdI Implementations being automatically deactivated. There is unfortunately no control mechanism at the granular level.

      There is however a high possibility that one might come across a requirement where you may require to retain the business logic of BAdI Implementations 1 & 3 but not 2 but all 3 belongs to Enhancement Implementation X – and in the project scenario one needs to do it quickly with a click of a button instead of commenting out source code and/or restructuring the development objects etc.

      Other advantages of keeping Switches at this granular level includes, as already pointed out in the blog:

      • Each implementation can also be turned ON or OFF via the Switch framework therefore control is available at more granular level – commenting out of source code etc. are not required.
      • Testing and regression testing is much easier now – Isolate the cause of the defects by simply turning the implementations OFF then ON one at a time as when required.

      Cheers,

      Sougata.

      (0) 
      1. Suhas Saha

        There is however a high possibility that one might come across a requirement where you may require to retain the business logic of BAdI Implementations 1 & 3 but not 2 but all 3 belongs to Enhancement Implementation X

        I think this is not possible with BAdIs linked to Enh. Spots, isn’t it?

        (0) 
      2. Bruno Esperança

        Hi Sougata,

        I’m sorry but I’m afraid that is not true.

        A BAdI implementation in an Enhancement implementation can easily be deactivated/activated using the “Implementation is active” checkbox:

        2014-02-19 09_56_13-Clipboard.png

        Am I misunderstanding something?

        BR,

        Bruno

        (0) 
        1. Sougata Chatterjee Post author

          Hi Bruno,

          I don’t have access to SAP system so am not able to check this out but I do remember at the time I was unable to deactivate at the BAdI Implementation level. I was working on ECC6.0 EhP6 SAP_ABA 7.31 – which Enhancement Pack are you on? Also did you try to debug after deactivating one of the BAdI Impl (as per the screen-shot in your post) to check that particular one is not called by the system when the Enh Impl is called?

          Cheers,

          Sougata.

          (0) 
          1. Bruno Esperança

            Hi Sougata,

            Yes I have tested, it works as intended. I’m guessing that as long as you have the new enhancement framework on your system you should have this option. Maybe you overlooked it somehow, I don’t know, but maybe this option should be mentioned in your post.

            Best regards,

            Bruno

            (0) 
        2. Sougata Chatterjee Post author

          Bruno Esperanca wrote:

          Hi Sougata,

          I’m sorry but I’m afraid that is not true.

          A BAdI implementation in an Enhancement implementation can easily be deactivated/activated using the “Implementation is active” checkbox:

          Am I misunderstanding something?

          Hi Bruno,

          I think I have figured out the cause of the confusion. In your example you are able to activate/deactivate at the BAdI implementation level because you do not have a Switch associated to its parent level i.e. at the Enhancement implementation level.

          The moment you associate a Switch at the Enhancement Impl level all its children i.e. the BAdI Implementations will be automatically controlled by the Switch of the Enhancement Impl. You’ll then notice that the checkbox “Implementation is Active” will be greyed out not allowing you to change it as the entire Enh implementation will then be controlled by the Switch Framework.

          I would suggest you build an Enhancement Spot from scratch incorporating the Switch Framework (similar design to the example that I put forward in my blog) to be able to validate this.

          Cheers,

          Sougata.

          (0) 
          1. Bruno Esperança

            Hi Sougata,

            Yes, looking back at your screenshots I noticed this! This is very poor design by SAP (imho). This will make me think twice about implementing a switch framework in my designs, as I’m not sure the added complexity will (always) be worthwhile.

            90% of the time I would say the biggest interest is to activate/deactivate a single implementation at a time. Did you get many requests to activate/deactivate entire groups of implementations?

            Thanks!

            Best,

            Bruno

            (0) 
          2. Bruno Esperança

            Hi Sougata,

            I’m trying to implement this as you suggested but I’m having a lot of trouble 🙁

            Is it possible to delete a BFS? I always get the error message that the BFS is active system-wide and I cannot deactivate it no matter how hard I try. I tried searching for how to delete this and I get nothing. I don’t think I like this framework very much 🙁

            Also, I have activated everything and assigned it like in your post, and it would seem that everything would be correct, but the switch in the enh. impl. always shows as being in the off state! I don’t understand.

            2014-02-20 12_01_34-S19(1)_077 Switch Framework Browser.png

            2014-02-20 12_04_25-S19(3)_077 Enhancement Implementation Z_ES_IMP_MV45AFZZ Display.png

            Thanks,

            Bruno

            (0) 
              1. Bruno Esperança

                I got it! I think I had a session open in edit mode somewhere, and instead of complaining about it, SAP just didn’t allow me to delete the BFS and was messing up everything. That’s the problem with SE80… if you navigate too much there’s no telling what you left behind 😛

                However, Sougata, for your information, if the switch is ON, you are able to activate/deactivate a BAdI implementation as you see fit.

                Checkbox off:

                2014-02-20 13_23_11-S19(1)_077 Enhancement Implementation Z_ES_IMP_MV45AFZZ Change.png

                Checkbox on:

                2014-02-20 13_24_11-S19(1)_077 Enhancement Implementation Z_ES_IMP_MV45AFZZ Change.png

                If the switch for the enh. impl. is OFF, then you are right, the checkbox is grayed out and there’s nothing you can do about it.

                I hope this clears out this misunderstanding.

                Cheers!

                Bruno

                (0) 

Leave a Reply