Get Event

[Former Member]

HI Experts ,

What actually GET command does. Plz describe background processing behind GET.

Thanks.

Khan.

[seshatalpasai_madala]

Hi,

When ABAP runtime comes across a GET event , all the data that is associated with this node of the Logical database is made avaialable to the report.

The logical database reads all data from all nodes that are not defined for field selection using SELECTION-SCREEN FIELD SELECTION in the logical database and are located on the access path of the logical database superior to node. This is independent of whether GET event blocks have been defined for these nodes or not. However, only the data of those nodes can be accessed for which a work area was declared using the NODES (or TABLES) statement.

If for nodes on the access path of the logical database superior to node, for which no GET event blocks are defined, a field selection is defined in the logical database, then all data is read only for those nodes, for which a NODES (or TABLES) statement exists. For nodes without a NODES (or TABLES) statment, only the key fields are read, because the logical database needs the key fields to build the access path.

Regards,

Sesh

[Former Member]

Calling Executable Programs

Executable programs are only directly executable from the end user's perspective. Whenever an executable program is started using System - Services - Reporting or a report transaction, the SUBMIT statement is executed. Executable programs are the only programs that can be called using SUBMIT.

Flow of an Executable Program

The SUBMIT statement loads the called program in a separate internal session and starts a series of processes in the ABAP runtime environment that trigger events and actions in the called program in the following order:

1.Program constructor event LOAD-OF-PROGRAM


2.The start values defined using the DEFAULT addition in the statements PARAMETERS and SELECT-OPTIONS are passed to the relevant data objects. The start values of all other data objects are set before LOAD-OF-PROGRAM.


3.Reporting event INITIALIZATION


4.The selection screen specified in selscreen_options is called if it contains at least one input field or button. Complete selection screen processing is performed. Before the first event of the selection screen processing, AT SELECTION-SCREEN OUTPUT, the values specified in selscreen_options are passed.


5.Reporting event START-OF-SELECTION

6.Different GET events, if the called program is linked with a logical database.

7.Reporting event END-OF-SELECTION

8.The basic list is called.

If the basic list is empty, the program is exited..

If the basic list is a print list, it is sent to the SAP spool system and the program is exited.

If EXPORTING LIST TO MEMORY is specified in list_options, the basic list is stored in the ABAP Memory and the program is exited.

Otherwise, the basic list is a screen list and is displayed on the screen. User actions on a displayed screen list trigger list events. The program is exited when the user exits the list display.

9.If no selection screen is displayed in step 4, because processing is performed in the background or not at all, the program flow is complete.

If a selection screen id displayed in step 4, the runtime environment calls the called program again after the basic list has been exited. During this new call, the runtime environment supplies the parameters, the selection criteria, and the free selections of the selection screen between the events INITIALIZATION and AT SELECTION-SCREEN OUTPUT with the previous input values. The program call is not complete until the user exits the selection screen processing by choosing Back, Exit, or Cancel.

Read Depth and Callback Routines

When you link a logical database with an executable program, the GET statements determine the depth to which the logical database is read. When you call the function module LDB_PROCESS, you determine the depth by specifying a node name in the CALLBACK parameter. For each node for which you request data, a callback routine can be executed at two points. These correspond to the GET and GET LATE events in executable programs. In the table parameter CALLBACK, you specify the name of the callback routine and the required execution point for each node. A callback routine is a subroutine in the calling program or another program that is to be executed at the required point.

For the GET event, the callback routine is executed directly after the data has been read for the node, and before the subordinate nodes are processed. For the GET_LATE event, the callback routine is processed after the subordinate nodes have been processed.

The line type of the table parameter CALLBACK is the flat structure LDBCB from the ABAP Dictionary. It has the following components:

· LDBNODE

Name of the node of the logical database to be read.

·

   GET

A flag (contents X or SPACE), to call the corresponding callback routine at the GET event.

·

GET_LATE

A flag (contents X or SPACE), to call the corresponding callback routine at the GET LATE event.

· CB_PROG

Name of the ABAP program in which the callback routine is defined.

· CB_FORM

Name of the callback routine.

If you pass an internal table to the CALLBACK parameter, you must fill at least one of the GET or GET_LATE columns with X for each node (you may also fill both with X).

A callback routine is a subroutine that must be defined with the following parameter interface:

FORM subr USING node LIKE LDBCB-LDBNODE 
                wa   [TYPE t]
                evt
                check.

The parameters are filled by the function module LDB_PROCESS. They have the following meaning:

EXAMPLE :

REPORT demo_logical_database.

DATA wa_spfli TYPE spfli.
SELECT-OPTIONS s_carr FOR wa_spfli-carrid.

DATA: callback TYPE TABLE OF ldbcb,
      callback_wa LIKE LINE OF callback.

DATA: seltab TYPE TABLE OF rsparams,
      seltab_wa LIKE LINE OF seltab.

callback_wa-ldbnode     = 'SPFLI'.

callback_wa-get = 'X'.
callback_wa-get_late = 'X'.

callback_wa-cb_prog     = sy-repid.
callback_wa-cb_form     = 'CALLBACK_SPFLI'.
APPEND callback_wa TO callback.

CLEAR callback_wa.
callback_wa-ldbnode     = 'SFLIGHT'.

callback_wa-get = 'X'.

callback_wa-cb_prog     = sy-repid.
callback_wa-cb_form     = 'CALLBACK_SFLIGHT'.
APPEND callback_wa TO callback.

seltab_wa-kind = 'S'.
seltab_wa-selname = 'CARRID'.

LOOP AT s_carr.
  MOVE-CORRESPONDING s_carr TO seltab_wa.
  APPEND seltab_wa TO seltab.
ENDLOOP.

CALL FUNCTION 'LDB_PROCESS'
     EXPORTING
          ldbname                     = 'F1S'
          variant                     = ' '
     TABLES
          callback                    = callback
          selections                  = seltab
     EXCEPTIONS
          ldb_not_reentrant           = 1
          ldb_incorrect               = 2
          ldb_already_running         = 3
          ldb_error                   = 4
          ldb_selections_error        = 5
          ldb_selections_not_accepted = 6
          variant_not_existent        = 7
          variant_obsolete            = 8
          variant_error               = 9
          free_selections_error       = 10
          callback_no_event           = 11
          callback_node_duplicate     = 12
          OTHERS                      = 13.

IF sy-subrc <> 0.
  WRITE: 'Exception with SY-SUBRC', sy-subrc.
ENDIF.

FORM callback_spfli USING name  TYPE ldbn-ldbnode
                          wa    TYPE spfli
                          evt   TYPE c
                          check TYPE c.
  CASE evt.
    WHEN 'G'.
      WRITE: / wa-carrid, wa-connid, wa-cityfrom, wa-cityto.
      ULINE.
    WHEN 'L'.
      ULINE.
  ENDCASE.
ENDFORM.

FORM callback_sflight USING name  TYPE ldbn-ldbnode
                            wa    TYPE sflight
                            evt   TYPE c
                            check TYPE c.
  WRITE: / wa-fldate, wa-seatsocc, wa-seatsmax.
ENDFORM.

reward points if it is usefull .....

Girish

[Former Member]

Hi Khan,

SAP includes a no of events that a programmer can use to enable the processing of data from logical database. An event is a keyword that defines a block of code to be executed when system detects an appropriate occurrence. the most imp event for logical database is the GET table event.

GET isnot a command like SELECT or WRITE. Instead, It is an event. It can be confusing because ABAP/4 has no ENDGET. all code following GET keyword is considered part of the GET event until another event keyword is reached such as another different GET table or an END-OF-SELECTION.

The syntax

GET table [late].

Regards

Raghavendra.D.S

[Former Member]

Hi,

<u><b>GET</b></u>

This is the most important event for executable programs that use a logical database. It occurs

when the logical database has read a line from the node <table> and made it available to the

program in the work area declared using the statement NODES <table>.

When you define the corresponding event block in the program, you can specify a field list if the

logical database supports field selection for this node:

GET <table> [FIELDS <f1> <f2>...].

You can process the data in the work area in this event block. For example, you can write it

directly to a list, or store it in a sequential dataset (internal table or extract) so that you can

process it later.

The logical database reads all columns from all nodes that are not designated for field selection

in the logical database and which are superior to <table> on the access path of the logical

database. This works independently of whether you have defined GET event blocks for these

nodes or not. However, you can only access the data of the nodes for which you have declared a

work area in the NODES statement.

At the end of a hierarchy level of the logical database, all of the fields in the work area <table>

are set to the value Hexadecimal 00. If you are using extracts, there is a special sort rule for

fields with the content hexadecimal 00. For further information, refer to Sorting Extract Datasets.

Performance can be much better for tables that are designated for field selection in the logical

database. If there are nodes of this type above <table> in the hierarchy of the logical database

for which there are no GET event blocks, the data for all columns is only read for the nodes for

which there is a NODES statement in the program. For nodes without a NODES statement, only

the key fields are read. The logical database needs the key fields to construct an access path.

You can use the FIELDS option to specify explicitly the columns of a node that the logical

database should read. With the FIELDS option, the logical database program reads only the

fields <f1> <f2> ... and the key fields from the database table <table>. However, the node <table>

must have been designated for field selection in the logical database.

Using FIELDS can result in much better response times than when the logical database has to

read all of the columns of the node.

All fields of the node <table> that are not key fields and are not listed after FIELDS, are not read

by the logical database. The contents of the corresponding components of the table work area

<table> are set to hexadecimal 00. This means that they are also set to hex 00 during the GET

events of the nodes below <table> in the hierarchy. You should therefore not use these fields in

your program or call subroutines that work with them. If you use the GET event block to fill an

extract dataset, remember that they have a special sort rule for fields with the contents

hexadecimal 00.

The following program is connected to the logical database F1S.

REPORT EVENT_DEMO.

NODES: SPFLI, SFLIGHT, SBOOK.

START-OF-SELECTION.

WRITE 'Test Program for GET'.

GET SPFLI.

SKIP.

WRITE: / 'From:', SPFLI-CITYFROM,

'TO :', SPFLI-CITYTO.

GET SFLIGHT.

SKIP.

WRITE: / 'Carrid:', SFLIGHT-CARRID,

'Connid:', SFLIGHT-CONNID.

ULINE.

GET SBOOK.

WRITE: / 'Fldate:', SFLIGHT-FLDATE,

'Bookid:', SBOOK-BOOKID,

'Luggweight', SBOOK-LUGGWEIGHT.

ULINE.

The table work area SFLIGHT is also used in the event block for GET SBOOK.

<u><b>GET … LATE</b></u>

This event is triggered when all of the data records for a node of the logical database have been

read.

When you define the corresponding event block in the program, you can, as with GET, specify a field list if the logical database supports field selection for this node:

GET <table> LATE [FIELDS <f1> <f2>...].

You can use the event block for processing steps that should occur at the end of the block, like,

for example, calculating statistics.

The following program is connected to the logical database F1S.

REPORT EVENT_DEMO.

NODES: SPFLI, SFLIGHT, SBOOK.

DATA WEIGHT TYPE I VALUE 0.

START-OF-SELECTION.

WRITE 'Test Program for GET <table> LATE'.

GET SPFLI.

SKIP.

WRITE: / 'Carrid:', SPFLI-CARRID,

'Connid:', SPFLI-CONNID,

/ 'From: ', SPFLI-CITYFROM,

'To: ', SPFLI-CITYTO.

ULINE.

GET SFLIGHT.

SKIP.

WRITE: / 'Date:', SFLIGHT-FLDATE.

GET SBOOK.

WEIGHT = WEIGHT + SBOOK-LUGGWEIGHT.

GET SFLIGHT LATE.

WRITE: / 'Total luggage weight =', WEIGHT.

ULINE.

WEIGHT = 0.

The total luggage weight is calculated for each flight in the event GET SBOOK, and

then displayed in the list and reset in the event GET SFLIGHT LATE.

Regards,

Bhaskar

[Former Member]

self ansered