Prehistoric, but still quite useful. The batch input session works much like a macro on R/3 applications, allowing screen by screen field input and menu actions...

Macro recordings

It is possible to "record" a macro for a SAP transaction, or rather: it is possible to "play" one. A Batch Input Map is a kind of macro with which screen fields can be filled and user actions (read: menu actions) can be executed. Batch input data will be entered into SAP transactions as if it were entered by the end user. Field by field, screen by screen.

Batch Input Maps can be used for:
• Calling a transaction from an application, this enables the developer to use existing transactions: it's possible to "help" the end user getting him/her through entering the necessary data (interactive reporting)
• Conversion and interfaces: executing transactions for adding or modifying SAP data, with the data from, for example, an external system. An important advantage is that the data will be entered by the transaction that was build for this purpose: data checks and integrity checks will be done automatically, as if the enduser is entering it himself (herself)

Prehistoric ? From version 4.5 onwards, SAP has build transactions that are quite difficult to handle using batch input. The main disadvantages of batch input are performance and upgradibility, so SAP has handed us BAPI's for updates that required batch input before.

A Batch Input Map is composed in an internal table within an ABAP. The actual Batch Input Map is an internal table with two possible types of lines:

1. "jump to screen nnn of program progname"
2. "fill in value xxx for screen field fieldname".

A special case in processing field values is in place for menu actions, for which field BDC_OKCODE needs to be filled in with (with the values you could type in the command box, actual menu actions) and the other less common one is BDC_CURSOR followed by the field name on which the cursor should be positioned. Note that fields which are shown as a list also require a line number to be set, thus MATNR(03) is the field for material number in row 3. 

This is all the information a Batch Input Map needs. A batch input map would handle a database "transaction", thus, whenever a program executes a COMMIT WORK, the batch input map would regard that as a "you're finished now". Make sure your information message like "Document & saved" or SETting user parameters is done before the COMMIT WORK. Just to ensure that they would be executed when your program is called in a Batch Input Map.

Compose your recording with BDCDATA

The structure of BDCDATA, the Batch Input Map table structure, can be issued with INCLUDE STRUCTURE BDCDATA. This standard structure always has to be used when using the Batch Input Map mechanism.

Fieldname	Type	Description
PROGRAM	CHAR 8	Program name of the called screen
DYNPRO	NUMC 4	Screen number
DYNBEGIN	CHAR 1	Flag: is this the first time the screen is called ? (When this flag is 'X', only the first 2 fields of the BDCDATA structure will be filled.
FNAM	CHAR 35	Name of the field within the screen
FNAM	CHAR 80	Value of the field within the screen

If you do want to use a BDC session, using this macro can result in readable coding...

Example: Macro for composing a BDC session (line by line)

Macro for composing a BDC session (line by line)

data: lt_bdcdata type standard table of bdcdata, 
      lw_bdcdata type bdcdata. 

* bdc_add 'X' 'PROGRAM_NAME' 'SCREEN NUMBER'.
* bdc_add ' ' 'FIELDNAME' 'FIELDVALUE'.
  define bdc_add.
    clear lw_bdcdata.
    lw_bdcdata-dynbegin = &1.
    if &1 eq 'X'.
      lw_bdcdata-program = &2.
      lw_bdcdata-dynpro = &3.
    else.
      lw_bdcdata-fnam = &2.
      lw_bdcdata-fval = &3.
    endif.
    append lw_bdcdata to lt_bdcdata.
  end-of-definition.

Call transaction

With a BDC session available in an internal table, the next step is to CALL TRANSACTION it. A small example - just to get the idea:

lv_mode = 'N'. 
call transaction 'XD02' USING lt_bdcdata MODE lv_mode
  MESSAGES INTO lt_BDCMSGCOLL.

The transaction here is XD02, the BDC session was set up in internal table lt_BDCDATA and the mode is set to LV_MODE, which is set to 'N' for "Blind processing". It can be altered to 'A' - show all or 'E' show errors when needed. If you pass the processing mode to your CALL TRANSACTION the way described here, you enable anyone with debugging access to change the processing mode (in the debugger) - very convenient when pin-pointing a problem.

The last bit in the call is MESSAGES INTO, which is a method to gather all messages that are "thrown" during the BDS session. The alternative is just to check the message that is on SYST just after the transaction call - but this would only hold the last message.

• Prev
• Next