cancel
Showing results for 
Search instead for 
Did you mean: 

Is BAdI the right tool for us?

Former Member
0 Kudos

Hello,

we are building a custom component which generates postings that are later dispatched to FI.

The component's customizing defines Posting Activities in different variants/versions that create those postings.

Every Posting-Activity-Variant is implemented by a dedicated class, all implementing a common Posting-Activity interface.

Usually I would use the BAdI-technique to register the classes for each Posting-Activity-Variant using BAdI-Filters.

However, in this case I have a certain aversion to BAdI-usage:

  • 100s Posting-Activity-Variants, means 100s BAdI-Implementations and Filter-Definitions
    *additionally* to the customizing of all these Posting-Activity-Variants
  • There is customizing for every Posting-Activity-Variant, it is very tempting to add a classname-column and be done with it.
    The customizing would be concise & understandable, I don't have to deep-dive into SE80/SE19 to check registered BAdI-classes and their filter-values to guess which BAdI would be called. I immediately see if the Posting-Activity-Variant is bound to an implementing class.
  • We use OO extensively and defined interfaces irrespective of any BAdI-usage, so we don't really benefit from the BAdI's OO-approach.
    Furthermore we would actually hide the BAdI-mechanism since BAdI-references are not normal pass-around OO-references.
    So from a design perspective it doesn't matter if we use BAdI or customizing, it's hidden in some Factory anyways.
  • We lose the static-registration and where-used functionality of BAdI-classes,
    but I think that would be a price I am willing to pay to get a manageable & concise customizing.
    We would work-around that with a dedicated report that lists all used classes etc.
  • If using an old-school classname-column in the customizing, we would build a report that checks that customizing for sanity and checks the classes for the presence of certain interfaces/constructors/etc. Things which would otherwise be statically handled by the BAdI itself of course..

So what do you think, would you really *always* use the BAdI-technique to register classes?

Thanks for any advice.

Accepted Solutions (1)

Accepted Solutions (1)

custodio_deoliveira
Active Contributor
0 Kudos

Hi Kai,

Very good question you brought to us, thanks

Unfortunately I don't have an answer and actually I'm not sure there is ONE answer. But I'd still go with the BAdI approach, especially because of the static registration/where used functionality and because with BAdI it's impossible to "cheat" and call methods with a different signature.

But based on what you put here, I'm pretty sure whatever decision you make will be a good one.

Cheers,

Custodio

custodio_deoliveira
Active Contributor
0 Kudos

One thing I forgot, in favor to BAd,I is the fact that you can pair them with the Switch framework and easily activate/deactivate them.

Cheers,

Custodio

Answers (5)

Answers (5)

Former Member
0 Kudos

Hi Kai

To throw a different light on the topic...

You say that each BADI implementation/class will derive data that will later be sent to FI for processing?

How complicated is the logic within each BADI/class? Have you considered using a rules engine like BRFPlus to replace both your config table *and* the logic in your BADIs/classes?

BRFPlus might not make sense if your logic is overly complex but it's an option worth considering.


Regards

Glen

Former Member
0 Kudos

Previously SAP used to handle such kind of scenario using Business Transactional Events  ( Publish & Subscribe methods ). There also we had a customizing table with events called at specific points. Each event was mapped with a function module.

Now with new releases, SAP is going ahead with OO-  polymorphism using interfaces. POSDM integration with IS-Retail is done using BADI's . On the other hand SCM integration with ECC is done using CIF interface ( BTE + QRFC ).

There is no clear winner here. Customizing  table will give information about  all the classes under one table ,  still you have to be doubly careful about entering the correct name of the class. You need to do lot of validations - check the class name before calling the interface method.

Kernel BADI with filters will run faster and we can activate/ deactivate it as per requirement.

nabheetscn
Active Contributor
0 Kudos

Hi Kai

We recently had a very good discussion in one of the blog http://scn.sap.com/community/abap/blog/2014/02/14/a-framework-for-localregion-specific-requirements-... by Bruno about handling Local region specific developments.

Initially to me it look like a lot of work definitions to be created, interface, implementations filters etc blah blah...  The initial set up does not take not more than 30 minutes. After sometime a new change came and believe  me it did not took us much time just add a new filter and we are ready to go without affecting other designs

As Fred correctly pointed out it will be good if you can write a blog about the same and it will be fun to learn.

Thanks

Nabheet

fred_verheul
Active Contributor
0 Kudos

Hi Kai,

First: thank you for noticing this high-quality question.

Kai: To be honest, I think you've answered your own question already. Not that there's something wrong in checking your reasoning with the community (on the contrary: we're all likely to learn something from it).

But I can imagine this not being a forum question but a blog post describing the case and the design decision made. That would make an excellent blog post, from which (again) many people would learn something. It's the kind of content that's IMHO underrepresented on SCN at the moment.

So, instead of answering (which really isn't necessary: as Custodio already said, whatever you go with, I'm sure you'll be fine), I'd like you to rewrite this into a blog post. Let the community chime in using the comments and see what comes out of it.

For the record, I'd go with BAdi's. I don't think it's much extra work (implementing a class might be, but defining a BAdi implementation using a filter surely isn't), and you stay in the code realm, instead of breaking out of it (I always find that using class/function module columns in customizing makes it hard to understand the big application picture).

But I'm surely interested in what other developers have to say. And that's another advantage of the blog format: more people will likely notice it.

So: please give it a go! (Only if you're comfortable with it of course)

Thanks, Fred

Former Member
0 Kudos

As Custodio said above, there is not a single answer.

You will always fight with the workbench-based solutions (in this case BADIs) against customized solutions mostly because of the where-used list. You are aware of the SM30 / generated views for the customizing tables and its cons - in most cases it is not sufficient and you need to create a more-user-friendly solution for the customized data manipulations (mostly because of the extensive checks needed). Even SAP delivers its solutions with variety, so your pick depends on your situation.

Maybe one situation to consider - if your application needs a regular (or often) change of the classes used, then the customizing would be a better approach. It is easier to change a row in a data table than deactivate / activate a BADI. Once you use a strict interface-interface (ridiculous words), then there should be no problem implementing this and you gain all the pros (and the cons) of class-based solutions as with using BADIs.

If this was a poll, from the information you gave I would vote for the cusomized-based solution.