BADIs

Las BADIs (Bussiness Add-ins) son las nuevas tcnicas de ampliacin del cdigo estndar de SAP basadas en
programacin ABAP orientada a objetos
Las BADIs tienen las siguientes caractersticas:
Se pueden implementar ms de una vez, a diferencia de los user-exit, que slo tienen una implementacin.
Las BADIs contienen dos vistas: la definicin y la implementacin.
La definicin se realiza mediante la transaccin SE18. En ella se deben especificar los siguientes puntos:

Definicin de la interfaz: mtodos y parmetros.

Tipo de implementacin: simple (slo una implementacin activa) o mltiple (ms de una implementacin
activa).

Para implementar o ver las distintas implementaciones de una BADI dada, utilizar la transaccin SE19.
Cmo encontrar la BADI que necesitamos?
CL_EXITHANDLER is the class and GET_INSTANCE is the method to find the list of the badis for transaction.
Desde la transaccin SE24 (Class Builder) colocar un break-point en el CALL METHOD
cl_exithandler=>get_class_name_by_interface que est dentro del mtodo GET_INSTANCE de la clase CL_EXITHANDLER
.

 GO TO SE24

Find the suitable/roughly decide BADI name

and method by reading the description and
checking the signature.

Give the class name as CL_EXIT HANDLER

Then create implementation

STEP 1:Find the list of the BADIS for TCODE XKO2.

Click on display
Double click on the method GET_INSTANCE
Put a break point
Execute the TCODE XKO2
Give the vender no as 1
Select all the check boxes
Press enter
Give the country as DE and click on save
The debugger will start and note down the list
of the BADIS

Go to se18
Give the BADI NAME
And check all the methods

Step 2 : Creating implementation for the BADI

Go to SE19
give your standard BADI name :
vender_add_data.
Give the implementation name as
ZVENDER_ADD_DATA
Click on create
Give the description
Double click on the method check_all_data
Put a static or dynamic break point inside the
method and activate the class method
Click on back
Activate the implementation

BAPIS
BAPIs are part of Business Objects which are used to communicate with other BAPIs, events, Interfaces, attributes, Key
fields etc., with in a single B.O..
BAPIS are used in 3 scenarios.
1)Report generation using BAPIS
2)Using standard or custom BAPI to communicate between SAP & NONSAP
3)Using BAPIs for uploading data into SAP instead of BDC.
RULES FOR BAPIS:

Every BAPI should start with BAPI or ZBAPI.

All the Importing and Exporting parameters should be of Type structures, not the direct Data Types.
All the structures must start with BAPI or ZBAPI.
All the Parameters must be pass by Value because BAPIS doesnt support pass by reference.
Every BAPI should have a returning Parameter by Name RETURN or BAPIRET2, to display success or error
messages.
If BAPI is Success, we have to use another BAPI BAPI_TRANSACTION_COMMIT to Save the Data into Database
Tables.
If the BAPI has error, use another BAPI BAPI_TRANSACTION_ROLLBACK to revert back the changes made to the
Database Tables.

ALE Batch Data Communication

It is the technique of transferring in data from legacy system (NON-SAP) to SAP is called BDC.
There are two techniques available for transferring data.
Outbound process
Inbound process
OUTBOUND PROCESS:

The process of transferring the data from SAP to NON-SAP or another SAP server is called Outbound
Process.

INBOUND PROCESS

The process of receiving the data from NON-SAP to SAP server is called as Inbound Process. BDC is an
Inbound Process.

DIFFERENT METHODS OF BDC:

Call transaction (Screen Level Processing)

Session method (Screen Level Processing)
Direct input method->(Standard SAP Programs)
LSMW -> (A tool)
BAPI method -> (Advanced Technique, which is very Good)

LSMW (Legacy System Migration Workbench):

The LSM Workbench is an R/3-based tool that supports you when transferring data from

Non-SAP systems ("Legacy Systems") to R/3

Once or Periodically.

The tool supports conversion of data

The data can be imported into the R/3 system via

Batch Input
Direct Input
BAPIs
IDocs.

Communication between SAP to SAP:

ALE is a technology which is used to communicate between SAP to SAP server.
The data transfer is always in the form of a document called as IDOC(Intermediate Document).
Communication between SAP to Non-SAP:
EDI (Electronic Data Interchange) is the technology which is used to communicate between SAP server to NonSAP server.
Since IDOC is an SAP tool . The Non-SAP system cannot understand the format of IDOCs.

IDOCS
It is an intermediate document which contains the data.
Technically IDOC is a group of segments.
Each segment is group of fields.
Segments are like structures.
All the standard SAP segments will start with letter E1.
All the custom segments must start with the letter Z1.
WE31 Es la transaccin para la definicin de Segmentos
WE30 Es la ransaccin ppara el tipo de IDOC.
Runtime components of IDOC: Whenever an IDOC is transmitted at runtime, there are 3 components which are added automatically to the
IDOC.
Control record.(contiene quien enva, quien recibe, solo contiene 1 record, se almacena en la tabla EDIDC)
Data record. (contiene Business data LIKE KNA,KB1,KBK., solo contiene 1 record, se almacena en la tabla
EDIDD)
Status record. (contiene el estatus del IDOC success or error., contiene n records, se almacena en la tabla
EDIDS).
Steps to create an IDOC:Step1: First create the required segment in WE31 with some fields.
Step2: Create an IDOC in WE30 by inserting all the above segments.
Step1: Steps to create a segment.

Go to WE31.
Give the segment type as Z1KNA1.
Click on the button create.
Give short description.
Give the list of the fields junto a su data element.
Click on save and back.
Click on edit from menu barset release.

Step2: Create IDOC from T-CODE WE30.

Go to WE30 and give IDOC name as ZDEBMAS05

Click on the button create.
Give description and press enter.
Click on the button create segment
A pop-up is raised.
Give the segment name as Z1KNA1.
Give the minimum and maximum no. as 1, because customer
master will have single record.
Select the check box if we want to make the segment as
mandatory segment.
Press enter
Now, Put the cursor on Z1KNA1, click on the button create.
A pop-up is raised.
Select the first radio button and press enter.

Give the segment type Z1KNBK.

Give the minimum no. as 1, maximum no. as 99999 because each customer will have more than 1 bank
account.
Press enter.
Finally, the hierarchy should look as below.

Custom IDocs:
Custom IDocs are generally copied from the standard IDoc by adding OR removing extra segments.
We have two concepts available under custom IDocs.

Steps :
1)Create segments with fields in WE31 tcode.
2)Create an Extended IDOC by inserting the above segments.

 USER EXITS:

Go to transaction code va03

A pop up is displayed .
Double click on the program name.
Click on the binoculars button..
Give the string as userexit.
Select the redio button in main program and press enter.
Give the main program name and press enter.
Continue the process until you find out the user exits.
Ex:- perform userexit_save_doccument_prepare.
Ex:- perform userexit_save_doccument.

Customer exit:
Customer exit: These are zinclude programs which are available inside a function module.
Each function module is called as customer exit.
Technically these are called as enhancement; we dont require any access key.
Customer exits are available in all modules.
There are four types of customer exits.
Function module exit
Menu exit
Screen exit
Field exit (absolete now).

Project:
A project is group of enhancements but each enhancement cannot be linked to more than one project.
CMOD is the transaction to create a project.
SMOD is the transaction for searching the enhancement exits.
Each enhancement is group of exits i.e. function module exit, screen exit, menu exit.
A project must be created so that the enhancements which are available under a project will move into active state
and then our coding will be executed.

Search an Exit
Using SMOD transaction
Step1:- First we have to find out the package name for transaction.
Step2:- Go to SMOD transaction and find the enhancements using the package name.
Step3:- sometimes we can find the enhancements using the description, application component also in smod
transaction.
Step1 in detail :

Go to se93
Give a tcode name
Ex:-xd01.
Click on display.
Note down the package name. Ex:- FBD

Step2 in detail
Go to smod transaction
Click on utilities find
A pop up is displayed.
Give the package name as FBD.
Click on execute.
The list of the enhancements will be displayed.

Finding the exact or correct exit

After finding the list of the enhancementS or function module exit, put a break point in all the function
module exit.
First create project in cmod transaction.
Put a break point in fm exits.
Execute the transaction.
Now you can find easily which is correct exit based on your requirement.

ALVS

Most commonly used classes are :

CL_GUI_ALV_Grid
CL_GUI_CUSTOM_CONTAINER
CL_dd_document
CL_GUI_ALV_tree_simple
CL_GUI_container
CL_GUI_splitter_container.
The most commonly used method to display ALV grid data is, SET_TABLE_FOR_FIRST_DISPLAY.

TYPE-POOLS: slis. " SLIS contains all the ALV data types
STEP1: Create data declarations for ALV/custom
container.
TYPES : BEGIN OF ty_mara,
matnr TYPE mara-matnr,
mtart TYPE mara-mtart,
mbrsh TYPE mara-mbrsh,
meins TYPE mara-meins,
END OF ty_mara.
DATA : i_mara TYPE TABLE OF ty_mara .
DATA : wa_mara TYPE ty_mara .
DATA : alv_cont TYPE REF TO cl_gui_custom_container.
DATA : alv_grid TYPE REF TO cl_gui_alv_grid .
DATA : i_fcat TYPE lvc_t_fcat .
DATA : wa_fcat LIKE LINE OF i_fcat .
STEP2 : Create screen 100.
STEP3: Design screen with custom container
STEP4:Click on flow-logic and create the PBO Module and
write below code
MODULE STATUS_0100 OUTPUT.
PERFORM CREATE_OBJECTS.
PERFORM GET_DATA.
PERFORM create_fcat .
PERFORM DISPLAY_ALV .
ENDMODULE.
STEP5 : Define each subroutine as below:
FORM CREATE_OBJECTS .
CREATE OBJECT ALV_CONT
EXPORTING
CONTAINER_NAME = 'ALV_CONT'.
CREATE OBJECT ALV_GRID

EXPORTING
I_PARENT = ALV_CONT.
Endform.

FORM GET_DATA .
SELECT * FROM MARA
INTO TABLE I_MARA UP TO 100 ROWS
ENDFORM.
FORM DISPLAY_ALV .
CALL METHOD ALV_GRID>SET_TABLE_FOR_FIRST_DISPLAY
EXPORTING
I_STRUCTURE_NAME = 'MARA'
CHANGING
IT_OUTTAB
= I_MARA.
ENDFORM.
FORM create_fcat .
CLEAR wa_fcat .
wa_fcat-col_pos = '1' .
wa_fcat-fieldname = 'MATNR' .
wa_fcat-tabname = 'I_MARA' .
wa_fcat-SCRTEXT_M = 'Material No' .
APPEND wa_fcat TO i_fcat .
ENDFORM
*Finally display ALV with fieldcatelog instead of structure.
FORM display_alv .
CALL METHOD alv_grid->set_table_for_first_display
CHANGING
it_outtab
= i_mara
it_fieldcatalog = i_fcat.
ENDFORM

Steps involved in creating a simple ALV report

1. Define field catalogue internal table which is of type slis_t_fieldcat_alv. This table contains the field
attributes.
2. Define Layout structure which is of type slis_layout_alv
3. Define Events internal table which is of type slis_alv_event. This internal table contains all the
possible events of ALV.
4. Populating these tables into the Function Module as parameters. These Function Modules are used
in displaying the output data.
5. All the definitions of internal tables, structures, and constants are declared in type-pool called SLIS.

A. REUSE_ALV_LIST_DISPLAY: This is the function module which prints the data.

The important parameters are:
1. Export:
a. I_callback_program : report id
b. I_callback_pf_status_set
: routine where a user can set his own pf status
or change the functionality of the existing pf
c. I_callback_user_command : routine where the function codes are
handled.

status.

B. REUSE_ALV_FIELDCATALOG_MERGE:
This function module is used to populate a fieldcatalog which is essential to display the data in ALV. If the output data is
from a single dictionary table and all the columns are selected, then we need not exclusively create the field catalog. Its
enough to mention the table name as a parameter(I_structure_name) in the REUSE_ALV_LIST_DISPLAY. But in other
cases we need to create it.
The important parameters are:
1. Export:
a. I_program_name
: report id
b. I_internal_tabname
: the internal output table
c. I_inclname
: include or the report name where all the dynamic
forms are handled.
2. Changing
ct_fieldcat : an internal table with the type SLIS_T_FIELDCAT_ALV
which is declared in the type pool SLIS.
C . REUSE_ALV_EVENTS_GET: Returns table of possible events for a a list type
1. Import:
Et_Events : The event table is returned with all possible
CALLBACK events for the specified list type
(column NAME). For events to be processed by
the Callback, their FORM field must be filled. If
the field is initialized, the event is ignored. The
entry can be read from the event table, the field
FORM filled and the entry modified using
constants from the type pool SLIS.
2. Export:
I_list_type:
0 = simple list
1 = hierarchical-sequential list
2 = simple block list
3 = hierarchical-sequential block list

D. REUSE_ALV_COMMENTARY_WRITE : This is used in the Top-of-page event to print the headings and other
comments for the list.
1. It_list_commentary : Internal table with the headings of the type slis_t_listheader.
This internal table has three fields:
Typ : H - header, S - selection, A - action
Key : only when typ is S.
Info : the text to be printed
E. REUSE_ALV_GRID_DISPLAY: A function to display the results in grid rather than as a list.
Parameters : same as reuse_alv_list_display

SMART FORM
Smart form is a GUI Tool which is used to design the business legal documents such as Delivery note,Purchase
order,Invoice etc.
The transcation code is SMARTFORMS
Smartforms are client independent
It is advanced version of scripts
It is basically a GUI tool for user friendly maintenance