Understanding BDC call transaction

Lets derive the BDC process...

The aim of BDC is to transfer data from flat file ( or xls ) to the appropriate database tables in SAP.

To transfer data into the DB tables , an internal table should be used in the program.

Here we go to our first step

1) Declare an internal table with relevant fields.

How do u transfer data into your internal table from the flat file.
We have a function module gui_upload for this purpose.
This is our next step

2) Upload data from flat file into the internal table.

Now we have data in our internal table , we need to transfer it to the DB tables.
SQL is an option but is not advisable because a single transaction affects more than one table.
Hence SQL is not a safe way of transferring data.

So whats the other way to accomplish the same.
We are all aware that transaction codes exist for the creation of data.
Ex xk01 is the code for creating a vendor master data.

Transactions can be called from the program using CALL TRANSACTION 'TCODE'.

Now, the above statement causes opens a new transaction and one has to manually
enter data. This defeats the whole purpose of BDC. There should be a way to automate the process of enterring data.

Well, there is a way to automate the process.

CALL TRANSACTION USING
MODE UPDATE MESSAGES INTO

is used for the same.

Dont panic .. you will understand the syntax once u understand the logic.

Since we want to automate the data entry process in the transaction, there should be some
means by which the transaction receives data t be entered.
BDCDATA holds the data and actions to be performed to complete the transaction.
For example , to comple a transaction , one might have to go through a sequence of screens , entering values in the fields.
This sequence and data is stored in BDCDATA structure.

To explain in very simple terms , BDCDATA tells the system what it should do in that transaction.
For ex. the contents of a typical BDCDATA structure for xd01 translates to

"Fill value for customer,sales organization, distribution channel ,
then move on to screen 1020.
In screen 1020 fill values for name , search term ...
Then move on to screen 1030"

Phew...

Ok now u r happy that this BDCDATA does some magic and gets the system to fill values in the transaction.
Remember in programming there is no magic , what u ask the sytem to do is what u get ...
Someone has to fill the BDCDATA structure.
In my previous blog i have explained BDCDATA in detail.

Filling the structure manually is a big pain ...
There is an easier method to do it ...

IN SAP there is a concept called "Record transaction" ..
Goto shdb , start new recording , enter the transaction code that u want to record ,
keep filling values , save the recording...
All actions that u performed throughout the entire transaction is stored.

Now goto edit , create program. This creates a program with information about the recording.
Copy the list of performs used to fill the bdc data.
This list populates the structure BDCDATA.
You dont have the headache of populating it urself ..

I guess the remaining steps will fall into place now..

3) Process itab
4) For each entry of itab create a bdcdata structure with field values from the itab.
5) CALL TRANSACTION USING
MODE UPDATE MESSAGES INTO
6) check sy-subrc and process errors.

UPLOAD data from Excel to Itab

The function module
ALSM_EXCEL_TO_INTERNAL_TABLE is used to migrate data from an excel file
into an internal table.

The internal table should be declared of type ALSMEX_TABLINE.

This structure has the following fields

ROW COL VALUE.

Each cell of the excel data is stored as a record in the table.

BDCDATA structure in depth

BDCDATA structure stores the data that needs to be transferred to the SAP system.

The structure has the following fields.

PROGRAM
Name of the program.

DYNPRO
Screen Number

DYNBEGIN
Marks the beginning of a screen in a transaction

FNAM
Field NAme

FVAL
Field value.

The records can be divided into screen records and field records.

Each screen of the transaction is assigned a row in the BDCDATA structure.
This row contains Program,Dynpro and Dynbegin fields.
Dynbegin is set to 'X' to mark the beginning of the screen.

A record is assigned for each of the values entered.
These field records have only FNAM and FVAL.

The function codes of commands entered during the transaction are
entered in the structure too.

HIDE Technique

ex.

loop at itab
write ...
hide itab.
endloop.

HIDE keyword creates a table of the form

linenumber fields.

When at line selection event is triggered, the linne number is referred in the HIDE table,
The corresponding fields are copied onto the itab header.
This can be used later in the program.

Dialog Processor and List processor

A screen sequence is handled by dialog processor.
Within a screen, list sequence is handled by list processor.

The dialog processor handles flow logic screen after screen , triggering the appropriate
ABAP modules in the module pool pgm.
One can switch between dialog processor and list processor using
leave to listprocessing , call screen commands.


The o/p of report pgm is called list.
Conceptually , the o/p comprises of a list screen.
The list screen in turn comprises of basic list+details lists.
Each of these lists is assigned a list index starting from 0 for the basic list.
The index of a particular list can be retrieved from sy-lsind system field.
The list processor handles 'at line selection' and 'at user command events'.

At the end of displaying the list , the list processor checks if the sy-lsind value is lesser than the
current list index. If so , the lists in between are deleted , the current list is set to the
number in sy-lsind.

Suppose you want to move from 3rd list to 1st list using back button ,
just decrement the sy-lsind value programatically and then press back button.

Popup box function module

POPUP_WITH_TABLE_DISPLAY is the function module to display contents
of an itab in a popup window.

It takes the name of the itab as i/p.
Displays the contents in a popup window.

On the window you can select any line.
The index of the itab corresponding to the line selected is stored in 'choice'.

In your program declare a variable say , indx like sy-tabix.
Pass this in the import parameter 'choice' during function call.

Later , use the variable in a read statement as follows
to retrieve the contents of the clicked line.

read table itab index indx.

Passing itabs to subroutines

The aim of the program is to take select-option from the main program and pass the same to a subroutine.

I was able to achieve the same with FORM <> TABLES <>

In order to pass itabs to your subroutine use tables instead of USING in both the
FORM and PERFORM statement.

My pgm was of the form.

FORM sub1 TABLES itab
.
select * from mara into <> where matnr in itab.
END FORM


declare an itab itab1

PERFORM sub1 TABLES itab1.


In my program i obtained select options in my main program and passed it using PERFORM TABLES.
The documention of FORM specifies that TABLES is obsolete , the same functionality can be obtained with USING. When i tried the same the
select * from mara into <> where matnr in itab.

in my program failed in syntax check.
Quiet obvious as SAP does not understand what type i am passing.

I also tried adding like statement in FORM.
It failed too.

Right now TABLES is the working way i know of to pass itabs to subs.