Skip to Content
Author's profile photo DJ Adams

Food for thought: LDBs and ABAP Objects

During part of this week I’ve been fighting with an old adversary,output determination. In the fracas, I spent some time inside RSNAST00 (the selection program for issuing output) and couldn’t help noticing, in passing, that it used FIELD-GROUPS. This relatively old area of ABAP got me thinking about logical databases (LDBs) and their use in writing reports. You know the sort of thing:


  WRITE: / ...


  WRITE: / ...

When you execute a report that uses a logical database, you’re really just hitching a ride on the back of the database program that actually reads through the logical database you’ve specified; your GET statements are reactive, event handlers almost, that do something when passed a segment (ahem, node) of data by means of the proactivePUT statements in the database program (e.g. SAPDBDDF for the DD-F logical database).

Anyway, this brings me to something that’s been floating around in the back of my mind since TechEd last month in Basel. I attended a great session on ABAP Objects, given by Stefan Bresch and Horst Keller (thanks, chaps). In a section championing the explicit nature of ABAP Objects, there was a fascinating example of an implementation of a simple LDB using a class, and using ABAP Object events (RAISE EVENT … EXPORTING) and event subscriptions to achieve the PUT / GET relationship. Here’s that example.

There’s the ‘ldb’ class that implements a simple database read program for the the single-node (SPFLI) logical database:

class ldb definition.
  public section.
    methods read_spfli.
    events spfli_ready exporting value(values) type spfli.
  private section.
    data spfli_wa type spfli.

class ldb implementation.
  method read_spfli.
    select * from spfli
             into spfli_wa.
      raise event spfli_ready exporting values = spfli_wa.

Here we have a single public method READ_SPFLI that reads the table SPFLI, raising the event SPFLI_READY for each record it finds. This is like the PUT from our traditional database program.

Then we have a report that uses that logical database. It’s also written as a class:

class rep definition.
  public section.
    methods start.
  private section.
    data spfli_tab type table of spfli.
    methods: get_spfli for event spfli_ready of ldb
                       importing values,

class rep implementation.
  method start.
    data ldb type ref to ldb.
    create object ldb.
    set handler me->get_spfli for ldb.
    ldb->read_spfli( ).
    display_spfli( ).
  method get_spfli.
    append values to spfli_tab.
  method display_spfli.
    data alv_list type ref to cl_gui_alv_grid.
    create object alv_list
           exporting i_parent = cl_gui_container=>screen0.
              exporting i_structure_name = 'SPFLI'
              changing  it_outtab        = spfli_tab ).
    call screen 100.

In the START method we effectively are declaring the use of the logical database by instantiating an ‘ldb’ object, doing the equivalent of specifying a logical database in a report program’s attributes section. Then we define the method GET_SPFLI as the handler for the events that will be raised (SPFLI_READY) when we trigger the database’s reading with the invocation of the READ_SPFLI method. This of course is the equivalent of a GET SPFLI statement. To initiate the reading of the database we invoke the READ_SPFLI method. Finally there’s a DISPLAY_SPFLI event in the ‘rep’ class using ALV to present the data on the screen.

I don’t know about you, but I was taken aback by the beauty of this. As we’re approaching the weekend, a time to unwind and reflect, I just thought I’d share it with you.

Assigned Tags

      You must be Logged on to comment or reply to a post.
      Author's profile photo Dushyant Shetty
      Dushyant Shetty
      The first thought that struck me as soon as I read this blog was that, amazing though it sounds, this was just another one of those ocassions when the most obvious thing was done in the most simplest way using the most beautiful form of programming possible and you realize it was there all the time, waiting to be used, but never was... Isn't it sad that a programming technique so fundamentally revolutionary has never been given it's due and has always seemed underused.

      Commendations for bringing this up so nicely !

      Author's profile photo Former Member
      Former Member
      It is also a great demontration of how to abstract the 'data provider' from the business object.

      Lovely stuff.

      Author's profile photo Priyesh Shah
      Priyesh Shah

      Great One........ Almost Coding in Parallel Universe 😎

      Author's profile photo Sandra Rossi
      Sandra Rossi

      Note that SAP has also seen the beauty of this, and it was possible to generate automatically an ABAP Objects class for reading the logical databases, with a generic event GET. I don't know if it's one GET event, or several GET_* events. Transaction SLDB -> menu Edit -> Generate -> Wrapper class.

      Author's profile photo DJ Adams
      DJ Adams

      Gosh, interesting, thanks for bringing this to my attention, Sandra. Cheers!