The following program runs fine, however, the SELECT..ENDSELECT part runs only once, whereas it should be calling the class method lcl_util multiple times once for each rows in the table? Why is this due to?
*&---------------------------------------------------------------------*
*& Report ZDYNAMIC_PROG2
*&
*&---------------------------------------------------------------------*
*&
*&
*&---------------------------------------------------------------------*
REPORT ZDYNAMIC_PROG2.
PARAMETER:
p_from(30) TYPE c DEFAULT 'T001L',
p_where(255) TYPE c
DEFAULT 'WERKS = ''PL01'' AND LGORT = ''SL01'' '.
* ----------------------------------------------------------------------*
* CLASS lcl_util DEFINITION
* ----------------------------------------------------------------------*
*
* ----------------------------------------------------------------------*
CLASS lcl_util DEFINITION.
PUBLIC SECTION.
CLASS-METHODS:
write_struct IMPORTING p_struct TYPE any.
ENDCLASS. "lcl_util DEFINITION
* ----------------------------------------------------------------------*
* CLASS lcl_util IMPLEMENTATION
* ----------------------------------------------------------------------*
*
* ----------------------------------------------------------------------*
CLASS lcl_util IMPLEMENTATION.
METHOD write_struct.
FIELD-SYMBOLS:
<field> TYPE any.
WRITE / '('.
DO.
ASSIGN COMPONENT sy-index OF STRUCTURE p_struct TO <field>.
IF sy-subrc <> 0.
EXIT.
ENDIF.
WRITE /4 <field>.
ENDDO.
WRITE / ')'.
ENDMETHOD. "write_struct
ENDCLASS. "lcl_util IMPLEMENTATION
DATA:
data_ref TYPE REF TO data,
where_tab LIKE TABLE OF p_where.
FIELD-SYMBOLS:
<line> TYPE any.
START-OF-SELECTION.
CREATE DATA data_ref TYPE (p_from).
ASSIGN data_ref->* TO <line>.
* APPEND p_where TO where_tab.
SELECT * FROM (p_from) INTO <line> WHERE (p_where).
CALL METHOD lcl_util=>write_struct
EXPORTING
p_struct = <line>.
ENDSELECT.
That SELECT-ENDSELECT structure is dependent on the selection criteria, so if there is no match, the call to the class is skipped or it will only execute based on how many rows are returned.
From the structure of the logic, at execution time, its hard to know how many times the loop will execute.
Typically, SELECT-ENDSELECT structures should be avoided as they can affect performance and in this case make it difficult knowing how many rows matched the selection criteria.
My suggestion would be to: (1) Select the entries into an internal table. (2) Then loop on that internal table, calling your method to write the table entries out.
Here is a good blog post regarding performance tips.
Here is a good blog post regarding SELECT INTO vs. SELECT-ENDSELECT
Related
I know when I need to pass an internal table to a subroutine, I need to declare a type so I can use it in the FORM statement.
What happens if the internal table is an inline declaration table from a SELECT statement like this:
SELECT * FROM KNA1 INTO TABLE #DATA(LT_KNA1)
Is there any way to pass this table to a subroutine?
Thank you.
The subroutines are obsolete since ABAP 7.02 (2009), so I use a method in my example.
Inline declarations are an easy way of declaring types implicitly, but the limit of this solution is that you can type the parameter of a method only generically (types STANDARD TABLE, INDEX TABLE, ANY TABLE, ANY) which prevents you from stating the component names statically in your code.
But inline declarations of type DATA(...) are always based on a complete "bound" data type, so you can declare the type explicitly with TYPES and use it to type both your parameter and your data object.
If you use the ABAP Development Tools (Eclipse), you may use the Quick Fix "Declare local variable ... explicitly" to simplify the task:
which gives this code:
REPORT.
CLASS lcl_app DEFINITION.
PUBLIC SECTION.
CLASS-METHODS main.
ENDCLASS.
CLASS lcl_app IMPLEMENTATION.
METHOD main.
TYPES: BEGIN OF helper_type, " <=== automatically generated
carrid TYPE scarr-carrid,
carrname TYPE scarr-carrname,
END OF helper_type.
DATA: lt_scarr TYPE STANDARD TABLE OF helper_type. " <=== automatically generated
SELECT carrid, carrname FROM scarr
INTO TABLE #lt_scarr. " <=== automatically changed
ENDMETHOD.
ENDCLASS.
Now, declare manually the table type, use it to type a parameter of a method (a new one here):
REPORT.
CLASS lcl_app DEFINITION.
PUBLIC SECTION.
TYPES: BEGIN OF helper_type,
carrid TYPE scarr-carrid,
carrname TYPE scarr-carrname,
END OF helper_type.
TYPES: tt_scarr TYPE STANDARD TABLE OF helper_type. " <=== declare the type
CLASS-METHODS main.
CLASS-METHODS process_table " <=== new method with this type
IMPORTING table TYPE tt_scarr.
ENDCLASS.
CLASS lcl_app IMPLEMENTATION.
METHOD main.
DATA: lt_scarr TYPE STANDARD TABLE OF helper_type.
SELECT carrid, carrname FROM scarr
INTO TABLE #lt_scarr.
ENDMETHOD.
METHOD process_table. " <=== new method
LOOP AT table REFERENCE INTO DATA(line).
DATA(carrid) = line->carrid.
ENDLOOP.
ENDMETHOD.
ENDCLASS.
Use TYPE ANY or generic table type for parameters, TABLE parameters are obsolete:
FORM fill_table USING tab TYPE any
CHANGING ptab TYPE INDEX TABLE.
APPEND LINES OF tab TO ptab.
ENDFORM.
And yes, subroutines are obsolete themselves, use them only if you absolutely must do this, e.g. in legacy environment.
You don't need to indicate structure type for perform variable table. But you can get error on runtime if any field name change which are used in perform. Two working example below.
SELECT * FROM kna1 INTO TABLE #DATA(lt_kna1).
PERFORM test TABLES lt_kna1.
FORM test TABLES pt_kna1 STRUCTURE kna1.
*
ENDFORM.
Risky one:
FORM test TABLES pt_kna1.
*
ENDFORM.
So I need to use the INCLUDES rpcblo00 and rpcbdt00 to get the type of infotype change (create, update, delete). Beforehand I used a subroutine that had no problem with the includes, but I cannot get them into a class for the life of me.
If I try to put the include into the method as described here (it's even about the same HR include), I get the following error (because of the minus in lo-key):
Syntax error: Names may only consist of the characters "A-Z", "0-9"
and "_". In addition, they may not begin with a number.
minimal reproducible example:
CLASS lcl_infotypaenderungen DEFINITION.
PUBLIC SECTION.
TYPES: tty_aenderungs_operationen TYPE STANDARD TABLE OF pc403.
METHODS:
constructor
IMPORTING is_aenderungs_kopf TYPE pldoc_key,
get_aenderungs_operationen
RETURNING value(rt_aenderungs_operationen) TYPE tty_aenderungs_operationen.
PRIVATE SECTION.
DATA: s_aenderungs_kopf TYPE pldoc_key,
t_aenderungs_operationen TYPE tty_aenderungs_operationen.
METHODS:
select_aenderungs_operationen.
ENDCLASS. "lcl_infotypaenderungen DEFINITION
*----------------------------------------------------------------------*
TYPE-POOLS: abap.
DATA: lo_infotypaenderungen TYPE REF TO lcl_infotypaenderungen,
lv_fehler TYPE sy-subrc,
lt_log_kopf TYPE pldoc_key_tab WITH HEADER LINE,
lt_log_felder TYPE TABLE OF hrinftylog_fields,
lt_infotyp_vorher TYPE prelp_tab,
lt_infotyp_nachher TYPE prelp_tab,
lt_aenderungs_operationen TYPE STANDARD TABLE OF pc403.
FIELD-SYMBOLS: <log_kopfzeile> TYPE pldoc_key.
*----------------------------------------------------------------------*
CALL FUNCTION 'HR_INFOTYPE_LOG_GET_LIST'
EXPORTING
tclas = 'A'
begda = '20190315'
endda = '20190315'
IMPORTING
subrc = lv_fehler
TABLES
infty_logg_key_tab = lt_log_kopf.
CLEAR lv_fehler.
SORT lt_log_kopf DESCENDING BY infty bdate btime pernr.
LOOP AT lt_log_kopf ASSIGNING <log_kopfzeile>.
CALL FUNCTION 'HR_INFOTYPE_LOG_GET_DETAIL'
EXPORTING
logged_infotype = <log_kopfzeile>
IMPORTING
subrc = lv_fehler
TABLES
infty_tab_before = lt_infotyp_vorher
infty_tab_after = lt_infotyp_nachher
fields = lt_log_felder.
CREATE OBJECT lo_infotypaenderungen
EXPORTING
is_aenderungs_kopf = <log_kopfzeile>.
REFRESH lt_aenderungs_operationen.
lt_aenderungs_operationen = lo_infotypaenderungen->get_aenderungs_operationen( ).
ENDLOOP.
*----------------------------------------------------------------------*
CLASS lcl_infotypaenderungen IMPLEMENTATION.
METHOD constructor.
me->s_aenderungs_kopf = is_aenderungs_kopf.
me->select_aenderungs_operationen( ).
ENDMETHOD. "constructor
METHOD select_aenderungs_operationen.
INCLUDE rpcblo00. """ <---
INCLUDE rpcbdt00. """ <---
lo-key-tclas = me->s_aenderungs_kopf-tclas.
lo-key-pernr = me->s_aenderungs_kopf-pernr.
lo-key-infty = me->s_aenderungs_kopf-infty.
lo-key-bdate = me->s_aenderungs_kopf-bdate.
lo-key-btime = me->s_aenderungs_kopf-btime.
lo-key-seqnr = me->s_aenderungs_kopf-seqnr.
IMPORT header TO me->t_aenderungs_operationen FROM DATABASE pcl4(la) ID lo-key.
ENDMETHOD. "select_aenderungs_operationen
METHOD get_aenderungs_operationen.
rt_aenderungs_operationen = me->t_aenderungs_operationen.
ENDMETHOD. "get_aenderungs_operationen
ENDCLASS. "lcl_infotypaenderungen IMPLEMENTATION
Anyone know a good solution? Thanks in advance
Edit: The includes have some declarations and a makro reading from a data cluster. Of course I could just put those directly into the method, but I would like to avoid that (for now I did that).
Alternatively, does someone know of a different way to get the change operation per infotype line?
If you use your class as a local one then the only way to use these includes is to put them at the very beginning of the program. The downside is of course that the variables there become global but unfortunately there is no other way to do that and for sure not if you want to use a global class after all (not sure if your minimal working example is just simplified to use a local class instead of global or not).
REPORT ZZZ.
INCLUDE rpcblo00. """ <---
INCLUDE rpcbdt00. """ <---
CLASS lcl_infotypaenderungen DEFINITION.
" ...
Thanks to Jagger I can make it work with a local class, but in case anyone later wonders how you need to change the include code to be able to use it in a global method, you basically just need to get rid of INCLUDE STRUCTURE declarations and exchange tables with a header line.
So
DATA BEGIN OF LO-KEY.
INCLUDE STRUCTURE PC400.
DATA END OF LO-KEY.
becomes
DATA: lo_key TYPE pc400.
And
DATA BEGIN OF BELEGE_00 OCCURS 100.
DATA:
SPLKZ(01) TYPE X,
FIELD(10) TYPE C,
FTYPE(04) TYPE C,
FLENG(03) TYPE N,
DECIM(02) TYPE N,
OLDDT(50) TYPE C,
NEWDT(50) TYPE C.
DATA END OF BELEGE_00.
becomes
TYPES: BEGIN OF ty_belege,
splkz(01) TYPE x,
field(10) TYPE c,
ftype(04) TYPE c,
fleng(03) TYPE n,
decim(02) TYPE n,
olddt(50) TYPE c,
newdt(50) TYPE c,
END OF ty_belege.
DATA: belege_00 TYPE STANDARD TABLE OF ty_belege.
The macro can stay the same (or I guess you could rewrite it).
I created structure with three components, one of which is type ref to data and a table type of this structure. The problem is, how do I add data to this table?
It always has three components, but only one of them is discovered during processing, I always know two of them. Thus I always use the entire table type ref to data and then determine the type of this structure and create the table on it.
The issue here is that by doing this, even though I know two of the components, the whole itab will be dynamic, so I must use it in methods exporting/importing a type ref to data, which is inconvenient.
The method below will always return a table type ref to data, which is completely dynamic (type ref to data), but the structure of the table will always be like this:
component 1 -> type pc261.
component 2 -> type pay99_international.
compoment 3 -> well this is always a mistery hehe
methods get_payroll
importing it_rgdir type hrpy_tt_rgdir
returning value(rt_value) type ref to data.
method get_payroll.
field-symbols: <lt_payroll> type standard table.
create data rt_value type standard table of (mv_py_struct_type).
assign rt_value->* to <lt_payroll>.
...
endmethod.
My intention was to have the returning value with another type, a known type, with which I can use the two known components more easily. The idea I had was to create a type with only the unknown field as ref to data, than have a table of it.
This way, I would be able to use it inside methods without having to work so "dynamicaly", which altough works perfectly, is kind of difficult to understand only by reading the code.
types begin of gty_s_generic_payroll.
types evp type pc261.
types inter type pay99_international.
types nat type ref to data.
types end of gty_s_generic_payroll.
types gty_t_generic_payroll type table of gty_s_generic_payroll.
The problem is, how to use an itab of type gty_t_generic_payroll as declared above?
I must somehow create the component 3, but I have no idea how to do it...
At the end, I have a generic field-symbol, that is type table, that has the two known components + the third one that was discovered during processing time.
So how can I pass the content of this field symbol to a table type gty_t_generic_payroll?
data lt_payroll type ref to data.
field-symbols <lt_payroll> type any table.
lt_payroll = mo_payroll->get_payroll( lt_rgdir ). "this will return type ref to data
assign lt_payroll->* to <lt_payroll>.
After executing this code <lt_payroll> has all the values, but it is a dynamic table where I cannot use components <lt_payroll>[1]-inter.
So how to pass to gty_t_generic_payroll-typed variable, so that I can access components without much dynamics?
Given your target structure and table like this:
TYPES:
BEGIN OF payroll_row_type,
known_first_component TYPE something_we_know,
known_second_component TYPE something_else_we_know,
discovered_component TYPE REF TO data,
END OF payroll_row_type.
TYPES payroll_table_type TYPE STANDARD TABLE OF payroll_row WITH EMPTY KEY.
If you now have another table, whose type at runtime is:
TYPES:
BEGIN OF discovered_row_type,
known_first_component TYPE something_we_know,
known_second_component TYPE something_else_we_know,
known_third_component TYPE some_data_type,
END OF discovered_row_type.
TYPES discovered_table_type TYPE STANDARD TABLE OF discovered_row WITH EMPTY KEY.
You can move one to the other with
DATA source TYPE discovered_table_type.
DATA target TYPE payroll_table_type.
DATA resolved_component TYPE REF TO DATA.
DATA(descriptor) =
cl_abap_elemdescr=>describe_by_data( source_row-known_third_component ).
LOOP AT source INTO DATA(source_row).
DATA(target_row) =
VALUE payroll_row_type(
known_first_component = source_row-known_first_component
known_second_component = source_row-known_second_component ).
CREATE DATA target_row-discovered_component TYPE descriptor.
ASSIGN source_row-known_third_component TO FIELD-SYMBOL(<source_component>).
ASSIGN target_row-discovered_component TO FIELD-SYMBOL(<target_component>).
<target_component> = <source_component>.
INSERT target_row INTO TABLE target.
ENDLOOP.
The question and answers may look confusing for future visitors (what is the actual question?), so here is my two cents.
Summary of the question :
You call an external code (1) which gives you an internal table generated dynamically, but you know that all the components are always the same except one which varies but is at the same position, so you'd like to refer to its components statically, except for the one which varies.
(1) so, you can't adapt it.
Your workaround is to define an equivalent internal table statically and the component which varies will be defined as a data reference type (pointer to any data object), then to initialize it by copying the data from the dynamic internal table.
You ask for another better solution because yours consumes extra memory (two internal tables) and decreases the performance (copy process).
Answer :
No better solution
It looks like I was able to pass the values from the fully generic table (type ref to data) to another table that is 1/3 generic (type gty_t_generic_payroll):
methods get_payroll
importing it_rgdir type hrpy_tt_rgdir
returning value(rt_value) type gty_t_generic_payroll.
method get_payroll.
data lt_payroll type gty_t_generic_payroll.
data lt_payroll_aux type ref to data.
field-symbols: <lt_payroll_aux> type standard table.
create data lt_payroll_aux type standard table of (mv_py_struct_type).
assign lt_payroll_aux->* to <lt_payroll_aux> .
call function ' '.
call function ' '
exporting
= mv_relid
= mv_pernr
= xsdbool( gs_parm-use_natio <> abap_true )
tables
= it_rgdir
= <lt_payroll_aux> "table with the values I need
exceptions
= 0.
if sy-subrc <> 0.
return.
endif.
loop at <lt_payroll_aux> assigning field-symbol(<ls_payroll_aux>).
assign component 1 of structure <ls_payroll_aux> to field-symbol(<evp>).
assign component 2 of structure <ls_payroll_aux> to field-symbol(<inter>).
assign component 3 of structure <ls_payroll_aux> to field-symbol(<nat>).
data(ls_value) = value gty_s_generic_payroll(
evp = <evp>
inter = <inter>
).
get reference of <nat> into ls_value-nat.
append ls_value to rt_value. "returning table, with values I need and
"now with 2/3 known types
endloop.
endmethod.
At the end of the day, I acomplished what I needed, but unfortunately I do loose a lot of performance, since I must loop twice in the results now.
to populate the not-so-dynamic-table
to do the actual process of the report (at least it gets pretier lol)
This is the only way because I can't simply use insert lines of dynamic_itab to not_so_dynamic_itab, since the third component is reference .
i'm new in abap (OO) but developed before in java and wrote a class abap "cl_caretaker" which should handle the operations on database table and the local copy (intern table) of it.
I want to make the following method call:
caretaker->show_table( caretaker->get_users( ) ) .
with:
caretaker = cl_caretaker=>get_instance( ). "singleton instance
METHODS:
"! get a list of all user which registrated for FCP
"!
"! #parameter rt_users | users which are registrated for FCP
get_users
RETURNING value(rt_users) TYPE itty_users,
"! shows the content of a table
"!
"! #parameter it_table | the table we want to visualize
show_table
IMPORTING
value(it_table) TYPE ANY TABLE.
if I split the call in two and store the result of get_users in a tmp variable it works.
DATA:
gt_tmp_users TYPE caretaker->itty_users.
gt_tmp_users = caretaker->get_users( ).
caretaker->show_table( gt_tmp_users ).
So my questions are:
1) is a call like: caretaker->show_table( caretaker->get_users( ) ).
possible and if how?
2) I also tried to create a generic variable, which stores all kind of tables.
Because i don't want to create for each table kind i use a tmp/help variable.
But i got the information that only (german: Formalparameter) dummy parameters of method definitions are allowed to of generic type (eg. TYPE any TABLE ).
Here some stuff I already tried:
DATA:
* tmpanytable TYPE TABLE OF any.
* tmpAnyTable TYPE any.
tmpanytable TYPE REF TO data.
" needed to store a temporal table
FIELD-SYMBOLS: <tmpanytable> TYPE ANY TABLE.
* ASSIGN caretaker->get_users( ) TO <tmpAnyTable>.
* <tmpAnyTable> = caretaker->get_users( ).
* caretaker->get_users( ).
*caretaker->show_table( <tmpAnyTable> ).
*caretaker->show_table( caretaker->get_users( ) ).
*CALL METHOD: caretaker->show_table( IMPORTING it_table = caretaker->get_users ).
*CALL METHOD: caretaker->show_table( it_table = caretaker->get_users( ) ).
*COMPUTE caretaker->show_table( it_table = caretaker->get_users( ) ).
*ASSIGN caretaker->get_users() ->* to <tmpAnyTable>.
*Caretaker->show_table( <tmpAnyTable> ).
*call METHOD caretaker->show_table
* Exporting It_table = caretaker->get_users( ).
* CREATE DATA tmpanytable TYPE STANDARD TABLE OF (dbtab)
* WITH NON-UNIQUE DEFAULT KEY.
* ASSIGN tmpanytable->* TO <tmpanytable>.
* CREATE DATA tmpanytable TYPE tabkind OF any Table .
* ASSIGN tmpanytable->* TO <tmpanytable>.
*GET REFERENCE OF caretaker->get_users() INTO tmpAnyTable.
*caretaker->show_table( tmpAnyTable ) .
Method chaining is possible, and methods in operand positions are possible as well, but you need at least SAP_ABA 702 for that.
You can use generic types to pass a table around without knowing its type at runtime. However, you can't create a table without knowing its type. Comparing it to OO principles, you can handle references to an abstract superclass and pass them along between components, but you can't instantiate the abstract superclass.
The CREATE DATA statement needs a "concrete data type" to work on, not the "abstract super type STANDARD TABLE". The hard part here is deciding who will know about the type and create the data object.
BTW, you may want to take a look at the built-in Object Services - maybe there's no need to reinvent the database access layer wheel yet again.
Before starting development I'm looking for a standard way of doing something like that: I need to implement user-friendly way for ordering table rows in standard Dynpro ALV grid. I think it should look like a form where filter columns are defined, like it implemented, for example, in standard function module LVC_FILTER.
No, there is no standard functionality for this. However you can do this (manual table sort by drag-and-drop) programmatically by inserting/deleting itab rows in runtime. This can be be implemented using standard ALV events: ondrag, ondrop, and ondropcomplete.
Try these code samples for implementing methods:
method handle_grid_ondrag.
data: data_object type ref to drag_drop_object,
help_row like line of gt_outtab. "#EC NEEDED
read table gt_outtab_2 into help_row index es_row_no-row_id.
create object data_object.
move es_row_no-row_id to data_object->index.
read table gt_outtab_2 into data_object->wa_test index
es_row_no-row_id.
e_dragdropobj->object = data_object.
endmethod.
_
method handle_grid_ondrop.
data: data_object type ref to drag_drop_object,
drop_index type i,
help_row like line of gt_outtab. "#EC NEEDED
delete gt_outtab_2 index data_object->index.
insert data_object->wa_test into gt_outtab_2 index e_row-index
endmethod.
_
method handle_grid_ondropcomplete.
if data_cel = ' '.
call method grid->refresh_table_display.
endif.
endmethod.
Refer to sample program BCALV_TEST_DRAG_DROP_02 if you have difficulties.