Multiple-Use BAdI 

Multiple-Use BAdI

You use a multiple-use BAdI with static methods if no data is kept and many implementations make sense. For example, you can write results specified in the interface to different destinations.

badi_additional_export

Export the book entry to additional destination(s) at the end of a book entry.

*Some_Code

*End of program

CALL BADI badi_additional->export

The result of this example is:

●        Implementation 1: Export to XML file

●        Implementation 2: Export to sequential file

●        Implementation 3: Export to external file

BAdI With Optional Functionality

In the example figure below, the methods method_a and method_b have to be put into one BAdI. All the optional methods are put in another BAdI:

Never put mandatory and optional methods for a given solution or customer in one BAdI.

A large number of empty implementations indicates that your BAdI is too large.

·        If there are many empty methods that are often not implemented, divide the BAdI.

·        A design which leads to empty implementations of methods is a poor design: you will have unnecessary work with empty methods if there are any changes to the BAdI.

·        Instead of leaving optional methods empty, define them in different BAdIs.

·        Adding new smaller BAdIs instead of modifying large BAdIs to reduce the effort for implementation during import or upgrade.

Encapsulating Data for Two BAdIs Within One Class

Sometimes you have two BAdIs that have to work on the same encapsulated data. An example can be a BAdI that manages some data and writes it to the database and a BAdI that reads this data.

If you have a class that implements the interfaces of both BAdIs, this class is selected as the implementation for both selections. If you pass the same context object in both cases, you get the same implementation because the class mentioned implements both interfaces. Because of the same context object, you get also the same the same instance.

GET BADI bd1 CONTEXT me

CALL METHOD bd1->meth

and

GET BADI bd2 CONTEXT me

CALL METHOD bd2->meth

If the BAdIs are instantiated from within the same context-object (which implements the interface if_badi_context), you work with the same implementation and the same instance. This implementation implements the interfaces of both BAdIs.

Encapsulating Data for Two BAdIs Within Several Compilation Units

If you want to encapsulate data for two BAdIs that are called in different compilation units, you need an additional context object which is accessible from both compilation units.

GET BADI bd1 CONTEXT mycontext  "(some context given by a global factory class)

CALL METHOD bd1->meth

and

GET BADI bd2 CONTEXT mycontext  "(some context given by a global factory class)

CALL METHOD bd2->meth

In this case you need a separate context object. Both positions where the GET BADI occurs must be able to reach the same factory class. Both BAdI calls will yield calls to the same instance of class X. In addition, it is possible to share data between BAdIs.

This technique allows small and simple BAdI definitions.

Inheriting from a Default Class

When you define a default class also as an example class, the one who implements the BAdI can easily inherit from this class. This is a very comfortable way of redefining just the methods that must be different from the example or the default class in your implementation.