This property controls the instantiation of the object plug-ins during execution of the statement GET BADI. The following are possible specifications:
The first two specifications define context-free BAdIs. In the case of the newly created instantiation, new object plug-ins are created at each execution of the statement GET BADI . In the case of the reused instantiation, an object plug-in that was used once in the current internal mode is reused - if it is required more than once.
In the case of context-dependent instantiation, you need to specify a context for GET BADI . This context controls the instantiation. Only one object plug-in is created for each context and implementing class. Each time there is another GET BADI with the same context, it is reused. A context is an instance of a class that implements the tag interface if_badi_context . The specification takes place in the form of a reference to such an instance.
If object plug-ins are to get reusable data, only specifications 1 and 2 are allowed.
The figures below show the situation for context-free BAdIs, after two statements following each other:
GET BADI bd1.
GET BADI bd2.
The upper rectangles represent the BAdI objects. The broken-line arrows show which object plug-ins are referenced by the BAdI objects, whereby the case of two suitable BAdI implementation classes cl_imp1 and cl_imp2 is demonstrated.
Figure 1 shows the newly created instantiation. Each time a BAdI object is created, new object plug-ins are created - first imp1 and imp2 , then imp3 and imp4 .
Figure 2 shows the reused instantiation. For each BAdI implementation class, only one instance is created. All BAdI objects reference the same instance, irrespective of where (in internal mode) and how the BAdI object is called.
The instance generation mode of a BAdI can be context-dependent. If you have context-dependent BAdIs, you must specify an object reference variable to a BAdI context object (an object whose class implements the tag interface IF_BADI_CONTEXT ) in the GET BADI statement. As a result, within an internal session for the same BAdI context object, the same object plug-ins are always used. Such object plug-ins are singletons as far as their BAdI implementation class and a BAdI context object are concerned. Using a context-dependent BAdI is linked to a program is illustrated in the example below.
By using the predefined global class cl_badi_report_context you can easily couple BAdI implementations to an (executable) program (or more generally, to a compilation unit). This class implements the interface if_badi_context , has a public attribute repid , and a public static method get_instance , which creates an object and sets the attribute.
By calling the method cl_badi_report_context=>get_instance , you can create unique instances as far as the attribute, which can serve as BAdI context object is concerned.
Suppose the BAdI badi_ctx_badi is context-dependent and has no filters. The code fragment below shows how to use the cl_badi_report_context :
DATA: bd TYPE REF TO badi_ctx_badi,
ctx TYPE REF TO cl_badi_report_context.
ctx = cl_badi_report=>get_instance( repid = sy-repid ).
GET BADI bd CONTEXT ctx.
The reference variable ctx references an instance that is unique for the current program name. In this context a BAdI object is requested. If the same code fragment is executed in other programs in the same internal session, different instances of the BAdI implementation classes are always associated with the BAdI object.
The class cl_badi_report_context allows you to bind object plug-ins to compilation units. The methods of these object plug-ins can be called anywhere in the internal session by using the combinations of GET BADI and CALL BADI shown above. The state is kept in this connection, which means that the same instances are always called for the same compilation units.