SAP SpecialTables

I came across this topic "SAP Special Tables" upon reading my SAP ABAP Certification ebook. SAP Special Tables are very common table types of SAP that we as ABAPERs encounter from our day to day ABAP development. SAP Special Tables are very common in ABAP and very important as far as SAP technology is concerned. They are simply tables that contain the business data needed by everyone using SAP technology. 

These special tables are called Transparent, Cluster, and Pooled tables. You may find various definitions and comparisons in the internet if you like but, I noticed that those definitions are described commonly based on textbook type of explanations which for me I found it difficult to understand quickly esp. by the newbies. So, I decided to write this down immediately after compiling my own understanding and figuring out how I am going to plot and describe it here through my blog.

First, I will explain one by one the definition and how these tables are used and how to create one of them in SAP. Let's start with Transparent table:

Transparent table - is a type of table in SAP with a direct relation to the database itself. meaning every time you create a transparent table, there should always a corresponding instance as one to one physical relationship in a database table. The below picture shows how ABAP tables relate to the database tables from dictionary logical view relationship.

 

Creating transparent table can be done in SE11. Changing the type can be done by clicking extras and Change Table Category.

Cluster table - is a special table contains many cluster tables and grouped them into one table by combining each of their keys whichever is identical otherwise create a new key field. As you can see on the above picture, cluster table is composed of various cluster tables in dictionary logical view but it is made of only one physical database table.

Pooled table - simply a combination of various tables regardless of the key combination. Meaning keys are not combined but rather treated them independently for each table being pooled.

The below picture how pooled and cluster table differentiate to each other by means of UNION.

The letter shows the keys, if you noticed, in cluster same keys are combined to produced only one key in the database table while in pooled keys are treated independently.

Alv events for real time scenario

It has been so long that I have not been able to update my blog. I was quite busy with left to right projects to one of our clients.

Today, I want to share with you on how to handle oop alv using events specifically if front-end data has been changed. I.e sorted, deleted or filtered. On the following scenario below, I am going to present to you my own approach on how to deal with issues regarding alv front-end changes.

Steps:

1. Create a wrapper class for " set_table_for_first_display " method of cl_gui_alv_grid to handle "changing" internal table - meaning every time there are changes on the alv front-end, we will be able to capture and to read the appropriate record or data being clicked (hotpost_click event), changed (user_command event), etc.

2. Create a constructor (class' method called during creation of an object - typically for initialization of attributes) for your wrapper class for us to be able to send the cl_gui_alv_grid object coming from our main program. Our main program should act as a caller for the wrapper class by passing the appropriate parameters for "set_table_for_first_display_ method as shown below:

  variant-report = sy-repid. "to save the alv layout
  variant-username = sy-uname. "to save the alv layout
  variant-variant = alv_var. "layout name

  CREATE OBJECT obj_alv_pir01
    EXPORTING
      i_object = grid1
      .

  CALL METHOD obj_alv_pir01->set_table_for_first_display
    EXPORTING
      is_layout       = wa_alv_layout
      is_variant      = variant "to show the alv layout button
      i_save          = 'A' "to show the alv layout button
    CHANGING
      it_outtab       =   tb_final
      it_fieldcatalog = tb_fieldcat


 3. In our wrapper class, declare a static attribute for our internal table that will handle the it_outtab of "set_table_for_first_display" method. Note: parameter "changing" means that changes of an it_table inside the called method will reflect also to the it_table of the calling program.

4. Inside our event, let us take event USER_COMMAND, we should do the below code in ordfer for us to capture the appropriate line of records being selected from the ALV front-end. "NO matter what happens to the front-end data will also reflect to our static table as shown below":

  DATA lt_selected_rows TYPE lvc_t_roid .
  DATA ls_selected_row TYPE lvc_s_roid .

  CALL METHOD grid_object->get_selected_rows
  IMPORTING
  et_row_no = lt_selected_rows .
  READ TABLE lt_selected_rows INTO ls_selected_row INDEX 1 .

  IF sy-subrc ne 0 .
    MESSAGE s000(su) WITH 'Select a row!'(203) .
    EXIT.
  ENDIF .

  READ TABLE ZCL_ALV_PIR01=>tb_final INDEX ls_selected_row-row_id INTO l_wa_final.

That's it! If you have any clarification, please don't hesitate to post a comment.

Have a nice day!

TAW review season 1

Hello Guys, hope you are doing well this coming holiday season.

I would like to let you know that I will be posting some topic with regards to TAW reviewer in this coming days. TAW reviewer helped me a lot in passing my ABAP certification as well as helps me in my day to day ABAP job.

If you have any suggestions or topic that want to discuss I would be happy to cover them up!

Until next time. Please don't forget to check out my posts soon.

Happy Holidays everyone!

(For a complete copy of TAW reviewers, please email me at awesome_nope@yahoo.com)

Adding standard ALV toolbar button in OOP

Below are the simple steps in adding a standard ALV button using OOP.

1. Create a class that will handle the TOOLBAR event and insert the code for the particular button













2. Include the event in your main program:

 SET HANDLER obj_EH_ALV_FORECAST->HANDLE_TOOLBAR FOR grid1.