FAQs 

When do I use a context-dependent BAdI? When do I select instance reuse?

It makes sense to bind a BAdI to a context only if the same BAdI is called several times and has instance methods. The context guarantees that an already instantiated implementation class is reused provided that the same context is transferred. If the implementation uses local data, it is kept.

·        If a BAdI interface contains only static methods, you have to, for performance reasons, always use a non-context-dependent BAdI with instance reuse.

·        If a BAdI is used only once in an internal session, you should again, for performance reasons, always use a non-context-dependent BAdI with instance reuse.

·        In all other cases, you must use a non-context-dependent BAdI without instance reuse.

 

When do I use the default BAdI implementation class in the BAdI definition and when do I create a default BAdI implementation?

The default BAdI implementation class in the BAdI definition is called whenever no other valid implementation has been found. It must always be used if you do not need several default implementations with different filter conditions. Otherwise, you have to create default implementations with the respective filter conditions. You can also combine these two techniques.

A BAdI defines the filter language. You create one default implementation for German and one for English, and for all other languages you create a default BAdI implementation class.

 

Can I change a BAdI after the delivery and what are the consequences?

The BAdIs of the enhancement concept have an upgrade support. If a BAdI is imported into a system with a related implementation, the related implementations are offered for comparison. Depending on the kind of change, the comparison is simple or complex. Up to the end of the comparison operation, the BAdI can contain syntax errors (for example, due to changes to a method interface.) This is critical especially for central BAdIs. An error in a BAdI in the user management can, for example, make logons impossible. Since not all comparisons are always executed, it makes sense to perform only compatible changes, such as:

·         Adding new parameters.

·         Changing a single-use BAdI to a multiple-use BAdI.

·         Changing an SAP-internal BAdI to a non-SAP-internal BAdI.

·         Adding a screen or menu enhancement with the related default values.

 

Can I deliver a normal class, from which the BAdI implementation classes can inherit? Can I implement several BAdIs in the same BAdI implementation class?

Yes, for the BAdIs of the enhancement concept, BAdI implementation classes can be treated like normal classes. They can inherit from other classes and implement several interfaces. It also poses no problems to inherit from any BAdI implementation classes.

 

Is there a naming convention recommended by SAP for the BAdIs of the enhancement concept?

SAP recommends you start all BAdIs with the prefix BADI_. This avoids namespace conflicts with other global data types, classes, or interfaces. BAdIs must lie in their namespace so that in ABAP you can use REF TO to create a unique BAdI reference variable.