How many types of Views are there?

Database View
Help View
Projection View
Maintenance View
Below are the list and sequence of events available under classical reports, each event has it`s own
importance.
Load-of-praogram
This event is used to load program into memory for execution and this is the first event in execution
sequence.
Initialization
This event is used to initialize variables, screen default values and other default actions.
At Selection-Screen output
By using this event we can manipulate dynamic selection-screen changes.
At Selection-Screen on field
This event is used to validate a single selection-screen input parameter.
Syntax: AT SELECTION-SCREEN ON <parameter name>. "Validate a input parameter
At Selection-Screen on value request
This event is used to provide value help ( field help ) for a input field.
Syntax: AT SELECTION-SCREEN ON VALUE REQUEST FOR <parameter name>. "Input search help for
a input parameters
At Selection-Screen on help request
By using this event we can provide F1 help for a input field.
Syntax: AT SELECTION-SCREEN ON HELP REQUEST FOR <parameter name>. "Input (F1) help for a
input parameters
At Selection-Screen
This event is used to validate multiple input fields
Syntax: AT SELECTION-SCREEN . "used to validate multiple input fields
Start-of-Selection
This is default event which is used to write actual business logic .

Syntax: START-OF-SELECTION . "Default event

End-of-Selection
We can use this event just to state that start-of-selection is ended, this event is used with logical
databases, logical databases are in HR ABAP only. In normal ABAP we don`t have much importance .
Syntax: END-OF-SELECTION . "Start of selection is ended
Top-of-Page
This event prints constant heading for all pages.
Syntax: TOP-OF-PAGE . "Page heading
End-of-Page
This event prints constant footer for all pages.
Before using this event, we need to reserve some lines for displaying footer .
Syntax: END-OF-PAGE . "Page footer
Example: REPORT ZPROGRAM LINE-COUNT 27(3). " Here we reserve 3 lines for footer

How many types of reports are there in ABAP and what is the difference between them?
There are 2 type of reports. They are:
- Interactive report
- Classic reports
In classic reports, we can see the output in single list where as in interactive reports we can see the
output in multiple list.
In ABAP, there are a total of 7 types of reports. They are:
- Classical
- Interactive
- Logical Database
- ABAP query
- ALV Reports (ALV stands for ABAP List Viewer)
- Report Writer/Report Painter
- Views (There are different types of views also)
Classical Reports
These are the most simple reports. Programmers learn this one first. It is just an output of data using the
Write statement inside a loop.
Classical reports are normal reports. These reports are not having any sub reports. IT IS HAVING ONLY
ONE SCREEN/LIST FOR OUTPUT.

Events In Classical Reports.

INTIALIZATION: This event triggers before selection screen display.
AT-SELECTION-SCREEN: This event triggers after processing user input still selection screen is in active
mode.
START OF SELECTION: Start of selection screen triggers after processing selection screen.
END-OF-SELECTION : It is for Logical Database Reporting.
Interactive Reports
As the name suggests, the user can Interact with the report. We can have a drill down into the report
data. For example, Column one of the report displays the material numbers, and the user feels that he
needs some more specific data about the vendor for that material, he can HIDE that data under those
material numbers.
And when the user clicks the material number, another report (actually sub report/secondary list) which
displays the vendor details will be displayed.
We can have a basic list (number starts from 0) and 20 secondary lists (1 to 21).
Events associated with Interactive Reports are:
AT LINE-SELECTION
AT USER-COMMAND
AT PF<key>
TOP-OF-PAGE DURING LINE-SELECTION.
HIDE statement holds the data to be displayed in the secondary list.
sy-lisel : contains data of the selected line.
sy-lsind : contains the level of report (from 0 to 21)

What is BDC programming?

Transferring of large/external/legacy data into SAP system using Batch Input programming. Batch input is
a automatic procedure referred to as BDC(Batch Data Communications). The central component of the
transfer is a queue file which receives the data vie a batch input programs and groups associated data
into sessions.
What are the functional modules used in sequence in BDC?
These are the 3 functional modules which are used in a sequence to perform a data transfer successfully
using BDC programming: BDC_OPEN_GROUP - Parameters like Name of the client, sessions and user
name are specified in this functional modules. BDC_INSERT - It is used to insert the data for one
transaction into a session. BDC_CLOSE_GROUP - This is used to close the batch input session.
What are internal tables?
Internal tables are a standard data type object which exists only during the runtime of the program. They
are used to perform table calculations on subsets of database tables and for re-organizing the contents of
database tables according to users need.

Difference Between BADI and User Exits

Business Add-Ins are a new SAP enhancement technique based on ABAP Objects. They can be inserted
into the SAP System to accommodate user requirements too specific to be included in the standard
delivery. Since specific industries often require special functions, SAP allows you to predefine these
points in your software.
As with customer exits two different views are available:
In the definition view, an application programmer predefines exit points in a source that allow specific
industry sectors, partners, and customers to attach additional software to standard SAP source code
without having to modify the original object.
In the implementation view, the users of Business Add-Ins can customize the logic they need or use a
standard logic if one is available.
In contrast to customer exits, Business Add-Ins no longer assume a two-level infrastructure (SAP and
customer solutions), but instead allow for a multi-level system landscape (SAP, partner, and customer
solutions, as well as country versions, industry solutions, and the like). Definitions and implementations of
Business Add-Ins can be created at each level within such a system infrastructure.
SAP guarantees the upward compatibility of all Business Add-In interfaces. Release upgrades do not
affect enhancement calls from within the standard software nor do they affect the validity of call interfaces.
You do not have to register Business Add-Ins in SSCR.
The Business Add-In enhancement technique differentiates between enhancements that can only be
implemented once and enhancements that can be used actively by any number of customers at the same
time. In addition, Business Add-Ins can be defined according to filter values. This allows you to control
add-in implementation and make it dependent on specific criteria (on a specific Country value, for
example).
All ABAP sources, screens, GUIs, and table interfaces created using this enhancement technique are
defined in a manner that allows customers to include their own enhancements in the standard. A single
Business Add-In contains all of the interfaces necessary to implement a specific task.
The actual program code is enhanced using ABAP Objects. In order to better understand the
programming techniques behind the Business Add-In enhancement concept, SAP recommends reading
the section on ABAP Objects.
What is difference between badi and user-exists?
What is difference between enhancements and user-exists? and what is the full form of BADI?
I have another doubt in BDC IN BDC WE HAVE MSEGCALL (i did not remember the > correct
name) where the error logs are stored, MSEGCALL is a table or structure.
What is the system landscape?
1) Difference between BADI and USER-EXIT.
i) BADI's can be used any number of times, where as USER-EXITS can be used only one time.
Ex:- if your assigning a USER-EXIT to a project in (CMOD), then you can not assign the same to
other project.
ii) BADI's are oops based.
2) About 'BDCMSGCOLL' it is a structure. Used for finding error records.
3) Full form of BADI 'Business addins'.
3) System land scape will be depends on your project
Ex:- 'Development server'-->'Quality server'---> 'Production server'......

User Exit

Customer Exit

User exit is implemented in the form of a Subroutine i.e. PERFORM

xxx.
PERFORM userexit_save_document_prepare.

A customer exit can be implemented as:

Function exit

Screen Exit

Menu Exit

Field Exit

Example: CALL Customer function "XXX"

INCLUDE ZXXX. ."create and add logic
In case of a PERFORM, you have access to almost all the data. So
you have better control, but more risk of making the system
unstable.

You have access only to the importing, exporting,

changing and tables parameter of the Function
Module. So you have limited access to data.

User exit is considered a modification and not an enhancement

because we are changing the existing code.

A customer exit is considered an enhancement

because we are adding additional functionality to th
existing one..not changing any thing.

You need Access Key for User Exit.

You do not need access key.

Changes are lost in case of an upgrade.

Customer exits came later and they overcome the

shortcomings of User Exit.

User Exit will be activated automatically when ever you activate the
application(program).

To activate a function exit, you need to create a pro

in CMOD and activate the project.

Different methods for finding BAdI for a given transaction

The use of object orientated concepts within SAP has lead to new method of enhancing standard SAP
code called Business Add-Ins or BAdI. BAdI are some what similar to user exits catering to the same
need.
As an ABAP developer writing code may not be problem however where to write the code is always the
point to think of.
The section below describes various ways to find the BAdI. The different ways or alternatives can help the
developer to understand which BAdI would serve the purpose/requirement right.
The BAdIs can be found in the following ways
1.

Through SPRO

2.

Through ST05 -> SQL Trace and Buffer Trace (Performance Analysis)

3.

Through SE24 -> CL_EXITHANDLER.

4.

Through function module SXV_GET_CLIF_BY_NAME.

Apart from the above mentioned methods we can also find the BAdI using the two methods below,
Though not very effective but its a GOOD-TO-KNOW information.
5.

Through SE30 Runtime analysis

6.

Through TADIR table entry.

Every method has been illustrated with screen shots and examples, hope this helps anyone for their
development.
1 Through SPRO
The most basic method is searching through SPRO.
For example here we are searching for all the BAdI for Purchasing (This includes both PR and PO in the
Material management module)
Step1. Execute Transaction SPRO-> SAP Reference IMG-> Material management (As our requirement
specific to MM module)-> Purchasing.
Navigate through this node you would find the Node Business Add-Ins for Purchasing NODE.
Read through the Documentation available and check if the BAdI satisfies your requirement and then
create an implementation. It is not mandate that the BAdI node will appear in the same manner for other
module. We need to navigate through the all the nodes and find the BAdI node. For example In
Purchasing we directly get the NODE business add-in however if we navigate through Sales and
Distribution we get under the system modification.

Though this gives us all the BAdI that we have for the given module however its not very specific to the
transaction we may be looking for.

The Next method is the one through ST05. This answers to our problem, we can find all BAdI that trigger
for a given transaction code.

2. Through ST05 -> Performance analysis

This method is based on the fact that all BAdI are registered in SAP database tables and during a
transaction execution if any BAdI is called then these tables will surely be accessed. The BAdI database
tables are SXS_INTER, SXC_EXIT, SXC_CLASS and SXC_ATTR. These tables are always accessed by
the views V_EXT_IMP and V_EXT_ACT. When we create a trace for the given transaction we can filter
the trace by these view names to get all BAdI.

Step1. Switch on the TRACE through Transaction ST05 (Performance analysis) and set the flag for
BUFFER TRACE SQL TRACE and activate the trace.

4.JPG

Step2. Execute the transaction for which we need to find the BAdI, in our case it ME52N. Navigate
through the transaction like change a data, check the document and save etc doing so the trace would
capture all BAdI that would trigger on these events.

Step3. Execute Transaction ST05 and deactivate the Trace -> display trace. This would popup the screen
Set Restriction for displaying trace. Under the field Objects fill values and hit OK.

5.JPG

6.JPG

7.JPG

Step4. Export the trace list to an excel document by hitting on the Trace list option in the MENU
OPTIONS and SAVE as LOCAL file.

8.JPG

And save in the desired location.

After the download, excel would look like below.

9.JPG

The BAdI names are in the Statement field under col K.

Delete unwanted cols and then read through the definition documentation to understand if the BAdI will
serve our purpose.

The short coming for this method is that though it lists out the BAdI called in specific transaction however
it does not specify when the BAdI was called i.e. what triggered the BAdI? Is it the SAVE event or the
ENTER or the CHECK or which navigating to any other screen. This becomes even more cumbersome if
the documentation for definition is not available in the language you are looking for. The next 2 methods
cover these short comings.

3. Through SE24 -> CL_EXITHANDLER.

This is a very simple but efficient method to find the BAdI for a give transaction.

Step1. Execute Transaction SE24 and enter the class name as CL_EXITHANDLER. There would be
numerous methods with this class but we are interested only in GET_INSTANCE method.

Step2. Double click on the method name and place a break-point on the CALL METHOD
cl_exithandler=>get_class_name_by_interface.

10.JPG

Step3. Now execute the transaction for which the BAdI is required.

The code processing would stop at the break-point we have applied, click on the EXIT_NAME in the
Changing parameter. The parameter EXIT_NAME holds the name of the BAdI. Take a note of the BAdI
and hit F8. If for instance we are looking for a BAdI while saving the document then when the SAVE
button is hit processing would stop at the breakpoint and would give the name of the BAdI that would
trigger at the SAVE event.

11.JPG

The next method is same the above only that instead of putting a breakpoint at CL_EXITHANDLER we
can place a breakpoint in the function module SXV_GET_CLIF_BY_NAME at CALL FUNCTION
'SXV_ADD_PREFIX and execute the transaction.

12.JPG

The exporting parameter NAME holds the value at the BAdI name.

13.JPG

Take a note of the BAdI that would trigger based on the requirement.

As discussed earlier, there are few methods which may not be as effective as the above mentioned
methods however it always good to know that there are other alternatives available.

5 Through SE30 Runtime Analysis.

The Runtime analysis measures the CPU time required by ABAP statements. The most important are the
database access, context statements, Modularization units like Perform Call function Call screen Call
transaction etc, Internal Table operations like append collect Insert etc, Data transfer like read dataset etc
and for our specific requirement the ABAP object statements Though there are many other statements
that Runtime Analysis measure, we may not move into details of that.

Once we have the hit list from the SE30, we can search through the HIT LIST for METHOD
cl_exithandler.

Execute Transaction SE30 and under the Current session tab enter the transaction ME52N (as used
through out this document) and execute. Flow through the transaction and save and exit. So we now have
the Runtime analysis available for the transaction we just executed, Search through the HIT LIST for
CL_EXITHANDLER. Select the line and then in the Menu bar -> Goto -> Display Source code.

This would take us to the code where either the BAdI name is directly passed in the instance or through a
variable. if its through a variable double click on the variable for the variable definition. The variable
would obviously be TYPE REF to an interface name .

IF_EX_<BAdI name>.

Any thing after the IF_EX is the BAdI name.

14.JPG

15.JPG

16.JPG

In the above case

lc_cacl_character_input type ref to if_ex_cacl_character_input.

Then cacl_character_input is the BAdI name.

Lastly we can find some of the BAdI names from the TADIR table entry. Just as we can find the user exit
from TADIR, BADI name can also be retrieved there. Though this is a good method for finding User exits
however for BAdI this is just good-to-know information, the reason being that the BAdI name is fetched
based on the Development class or the package. It may so happen that the package may contain all the
BAdI provided by SAP for that transaction or the BAdI may exist in another Package which is accessed
when the transaction is executed.

Consider the Example below.

Execute Transaction Se11 and display table TADIR. Execute TADIR for table entries.

Enter the following values.

Program ID (PGMID) : R3TR.

OBJECT : SXSD (For user exit use SMOD)

Development Class (DEVCLASS) : MEREQ (for transaction ME52N)

17.JPG

And execute.

18.JPG

Though ME52N has many other BAdI which are called however they exist in the package ME.

Every technique used here has its own advantages; however which technique is best suited depends on
the developer and the requirement.