Calendar week - dynpro field with tuned search help

As always, I hope this article can save someones time as I wasted time by googling and debugging. Here I want to describe two different approaches how to work with calendar week input field on dynpro, especially two search help options.

Simple dynpro field with given search help

Calendar week itself has NUMC(6) data format. When you are working with dynpro field you need type input as CHAR(7), remember standard search help returns separating dot in between. I found suitable in my case to use standard search help /BI0/OCALWEEK. You have to add just conversion exit, here it is PERI6. Now we have nice working stuff.

Dynpro settings:

Dynpro result:

Everything is simple enough and works just as you would expected, but....  There is one big but for me. The search helps starts somewhere in the deep past. Today I have year 2017, the default value is 6 year ago. The user is forced to scroll down too much to reach current year.

Search help with prefilled input parameters

So we have nice character (7) input field, conversion routines works Ok. So what is painkiller of above example? The answer is search help input parameters, by these you can influence given range of values. I decided to work with DATEFROM, because sy-datum is easily reachable.

Search help input parameters:

How to provide the input parameters? In my case I used ABAP and own F4 screen module. I wanted to have a list of weeks starting just few weeks ago, but not years.

So the result now looks like:

This is what I was exactly looking for. Search help starts from week I wanted.

Here is the solution:

On the screen "Flow logic" tab define module event trigger for F4 as e.g. below.

PROCESS ON VALUE-REQUEST. "F4
  FIELD gs_task_schd-cw MODULE f4_cw.

Screen settings:

Just conversion exit is still present within field properties - see below, but no search help any more. It is replaced by F4 module. Conversion exit works to convert data from screen to program (from CHAR7 to NUMC6), but not from F4 module to screen, that is why I have added manual call of conversion routine to the F4 module to display data in a correct way on the screen.

The module can looks like:

*&---------------------------------------------------------------------*
*&      Module  F4_CW  INPUT
*&---------------------------------------------------------------------*
*       Calendar week search help with preset (change week list)
*----------------------------------------------------------------------*
MODULE f4_cw INPUT.

  lcl_main=>self->o_ctrl_screen->screen_300_f4_cw(
    iv_screen_field = 'GS_TASK_SCHD-CW'
  ).

ENDMODULE.                 " F4_CW  INPUT

So the miracle here is the method screen_300_f4_cw.

Method definition:

             screen_300_f4_cw
              IMPORTING
                iv_screen_field          TYPE  dynfnam.

Method implementation:

  METHOD screen_300_f4_cw.

    DATA: lt_dynpfields         TYPE STANDARD TABLE OF dynpread,
          ls_dynpfields         LIKE LINE OF lt_dynpfields,
          ls_shlp_descr         TYPE shlp_descr,
          lt_shlp_return_values TYPE STANDARD TABLE OF ddshretval,
          lt_shlp_selopt        TYPE STANDARD TABLE OF ddshselopt,
          ls_shlp_selopt        LIKE LINE OF lt_shlp_selopt,
          lv_date               TYPE sydatum.

    " Get search help description
    CALL FUNCTION 'F4IF_GET_SHLP_DESCR'
      EXPORTING
        shlpname = '/BI0/OCALWEEK' " Standard search help name
        shlptype = 'SH'
      IMPORTING
        shlp     = ls_shlp_descr.

    " Ask FM F4IF_START_VALUE_REQUEST for return values - set the sign
    FIELD-SYMBOLS: <fs_interface> LIKE LINE OF ls_shlp_descr-interface.
    LOOP AT ls_shlp_descr-interface ASSIGNING <fs_interface>.
      <fs_interface>-valfield = 'X'.
    ENDLOOP.

    " Note: There is internaly used build in function DATE_CONV_EXT_TO_INT that is later used, it accepts DDMMYYYY,
    " not other e.g. YYYYMMDD - it causes dumps. So sy-datum can not be used directly
    lv_date = sy-datum - 21. " start some weeks ago
    CONCATENATE lv_date+6(2) lv_date+4(2) lv_date+0(4) INTO ls_shlp_selopt-low.

    " Preset default week interval of initial search help screen (not to start in stone age)
    ls_shlp_selopt-shlpname  = '/BI0/OCALWEEK'.
    ls_shlp_selopt-shlpfield = 'DATEFROM'.
    ls_shlp_selopt-sign      = 'I'.
    ls_shlp_selopt-option    = 'GT'.
    " ls_shlp_selopt-high     = ''.
    APPEND ls_shlp_selopt TO lt_shlp_selopt.
    ls_shlp_descr-selopt = lt_shlp_selopt.

    " Trigger search help popup screen
    CALL FUNCTION 'F4IF_START_VALUE_REQUEST'
      EXPORTING
        shlp          = ls_shlp_descr
      TABLES
        return_values = lt_shlp_return_values.

    FIELD-SYMBOLS: <fs_return_value> LIKE LINE OF lt_shlp_return_values.
    LOOP AT lt_shlp_return_values ASSIGNING <fs_return_value>.

      " Run manually value conversion exit
      CALL FUNCTION 'CONVERSION_EXIT_PERI6_OUTPUT'
        EXPORTING
          input  = <fs_return_value>-fieldval
        IMPORTING
          output = <fs_return_value>-fieldval.

      " Fill screen field
      ls_dynpfields-fieldname  = iv_screen_field.
      ls_dynpfields-fieldvalue = <fs_return_value>-fieldval.
      APPEND ls_dynpfields TO lt_dynpfields.
      EXIT. " process just one item

    ENDLOOP.

    " Update screen
    CALL FUNCTION 'DYNP_VALUES_UPDATE'
      EXPORTING
        dyname     = '/FDSEU/HCPC'    "Program name
        dynumb     = '0220'           "Screen number
      TABLES
        dynpfields = lt_dynpfields
      EXCEPTIONS
        OTHERS     = 0.

  ENDMETHOD.                    "screen_300_f4_cw

An addition - database data type

the data type storing calendar week within database could be e.g. KWEEK or /BI0/OICALWEEK, all have type NUMC(6).

Internally the stored value looks like:

May be there are easier ways, I found this. I hope it helps someone ;-)

Trigger standard search help and fill more dynpro fields

Yes, the easist way how to get search help functionality is just to provide its name within Screen painter beside the field name.

But what about a bit more complicated case, imagine, you would need to fill more dynpro fields based on search help result. Here you are out of standard techniques. Below example solves exactly this case.

It triggers manually standard SAP search help - in this case USER_COMP. This search help offers various selection methods how to pick a desired person, in the end it returns username.

Below F4 module gets username, reads user full name and fills both values on dynpro. Comments should be self explanatory enough ;-)

Dynpro coding:

PROCESS ON VALUE-REQUEST. " F4 action
  FIELD gs_task_pool-responsible_pers MODULE f4_responsible.

Source code:

*&---------------------------------------------------------------------*
*&      Module  F4_RESPONSIBLE  INPUT
*&---------------------------------------------------------------------*
*       Transport values to dynpro/screen
*----------------------------------------------------------------------*
MODULE f4_responsible INPUT.

  DATA: lt_dynpfields         TYPE STANDARD TABLE OF dynpread,
        ls_dynpfields         LIKE LINE OF lt_dynpfields,
        ls_shlp_descr         TYPE shlp_descr,
        lt_shlp_return_values TYPE STANDARD TABLE OF ddshretval,
        lv_username           TYPE xubname.

  " Get search help description
  CALL FUNCTION 'F4IF_GET_SHLP_DESCR'
    EXPORTING
      shlpname = 'USER_COMP' " Standard SAP search help name
      shlptype = 'SH'
    IMPORTING
      shlp     = ls_shlp_descr.

  " Ask FM F4IF_START_VALUE_REQUEST for return values - set the sign
  FIELD-SYMBOLS: <fs_interface> LIKE LINE OF ls_shlp_descr-interface.
  LOOP AT ls_shlp_descr-interface ASSIGNING <fs_interface>.
    <fs_interface>-valfield = 'X'.
  ENDLOOP.

  " Trigger search help popup screen
  CALL FUNCTION 'F4IF_START_VALUE_REQUEST'
    EXPORTING
      shlp          = ls_shlp_descr
    TABLES
      return_values = lt_shlp_return_values.

  CLEAR lt_dynpfields.
  CLEAR ls_dynpfields.
  CLEAR lv_username.
  CLEAR gs_user_address.

  FIELD-SYMBOLS: <fs_return_value> LIKE LINE OF lt_shlp_return_values.
  LOOP AT lt_shlp_return_values ASSIGNING <fs_return_value>.

    " Fill 1th screen field
    ls_dynpfields-fieldname  = 'GS_TASK_POOL-RESPONSIBLE_USR'.
    ls_dynpfields-fieldvalue = <fs_return_value>-fieldval.
    APPEND ls_dynpfields TO lt_dynpfields.

    " Fill 2nd screen field
    lv_username = <fs_return_value>-fieldval.
    gs_user_address = lcl_main=>self->get_user_detail( iv_username = lv_username ).
    ls_dynpfields-fieldname  = 'GS_TASK_POOL-RESPONSIBLE_PERS'.
    ls_dynpfields-fieldvalue = gs_user_address-fullname.
    CONDENSE  ls_dynpfields-fieldvalue.
    APPEND ls_dynpfields TO lt_dynpfields.

    EXIT. " process just one item/person
  ENDLOOP.

  " Update screen fields
  CALL FUNCTION 'DYNP_VALUES_UPDATE'
    EXPORTING
      dyname     = '/FDSEU/HCPC'    "Program name
      dynumb     = '0220'           "Screen number
    TABLES
      dynpfields = lt_dynpfields
    EXCEPTIONS
      OTHERS     = 0.

ENDMODULE.                 " F4_RESPONSIBLE  INPUT

Sources on net:

• https://wiki.scn.sap.com/wiki/display/Snippets/F4+help+functionality+for+a+dynpro+screen+field+using+the+PROCESS+ON+VALUE-REQUEST+statement
• https://keremkoseoglu.wordpress.com/2009/03/25/how-to-call-a-sap-search-help-manually/
• https://stackoverflow.com/questions/17143057/can-i-call-a-search-help-programatically-with-some-parameters-already-filled-in

Repository class transport error: ‘INCLUDE REPORT CL_XY==========CO’ NOT FOUND

Repository class transport error

I have become almost mad by solving this error. I have checked everything and compared any piece of repository class between development system and following system. Everything fits, class declaration part, methods implementation and so on. I transferred declaration and implementation parts again by new transport. I still got the error...

Here is different situation comparing to local classes where comparing just includes solves everything, repository classes have their own secrets ;-)

Solution

I still do not know the exact root cause, nevertheless I found a way how to overcome the bug.

Create a new transport entry by following way:

Click right mouse button directly on the class causing the problem and follow the picture below.

Do the transport again. I hope it helps in your situation ;-)

Send email with high importance from ABAP

There is an easy to grasp function module EFG_GEN_SEND_EMAIL, which is a kind of wrapper over CL_BCS class. Unfortunately EFG_GEN_SEND_EMAIL does not support email high priority sign (nice red exclamation mark within Outlook) in any input parameter.

I have a made a custom clone of this FM supporting high importance sign. I converted the coding into static method of a custom repository class. Please, no flame war for usage of static method ;-), there is no need to have an instance.

Original call of FM:

    CALL FUNCTION 'EFG_GEN_SEND_EMAIL'
      EXPORTING
        i_title                = iv_title
        i_sender               = iv_sender
        i_recipient            = ''
        i_flg_send_immediately = 'X'
      TABLES
        i_tab_lines            = t_mail_text
        i_tab_recipients       = t_recipients
      EXCEPTIONS
        not_qualified          = 1
        failed                 = 2
        OTHERS                 = 3.
    IF sy-subrc NE 0.
      MESSAGE ID sy-msgid TYPE sy-msgty NUMBER sy-msgno WITH sy-msgv1 sy-msgv2 sy-msgv3 sy-msgv4.
    ENDIF.

Call of custom method (almost the same):

    TRY.
        CALL METHOD /yournamespace/cl_email=>send_email
          EXPORTING
            iv_title          = iv_title
            iv_sender         = iv_sender
            iv_high_priority  = abap_true
            iv_recipient      = ''
          CHANGING
            ct_tab_lines      = t_mail_text
            ct_tab_recipients = t_recipients.
      CATCH cx_root.
        MESSAGE ID sy-msgid TYPE 'E' NUMBER sy-msgno WITH sy-msgv1 sy-msgv2 sy-msgv3 sy-msgv4.
    ENDTRY.

Description of the custom repository class 

There is one static method with following input parameters:

The complete method source code:

METHOD send_email.

  DATA: lt_recipients     TYPE STANDARD TABLE OF string,
        lv_string         TYPE string,
        lo_ref_send_req   TYPE REF TO cl_bcs,
        lt_text           TYPE bcsy_text,
        lo_ref_doc        TYPE REF TO cl_document_bcs,
        lo_ref_recipient  TYPE REF TO if_recipient_bcs,
        lo_ref_sender     TYPE REF TO if_sender_bcs,
        lx_rex_bcs        TYPE REF TO cx_bcs,
        lx_rex_addr       TYPE REF TO cx_address_bcs,
        lv_smtp_addr      TYPE adr6-smtp_addr,
        lv_subject        TYPE so_obj_des,
        lt_soli           TYPE soli_tab,
        ls_soli           TYPE soli,
        lv_uname          TYPE uname,
        lv_importance     TYPE bcs_docimp.

  IF iv_sender IS INITIAL.
    RAISE EXCEPTION TYPE cx_bcs
      EXPORTING
        msgty = 'E'
        msgid = '00'
        msgno = 007
        msgv1 = 'Sender'.
  ENDIF.

  IF iv_title IS INITIAL.
    RAISE EXCEPTION TYPE cx_bcs
      EXPORTING
        msgty = 'E'
        msgid = '00'
        msgno = 007
        msgv1 = 'Title'.
  ENDIF.

  IF ct_tab_lines IS INITIAL.
    RAISE EXCEPTION TYPE cx_bcs
      EXPORTING
        msgty = 'E'
        msgid = '00'
        msgno = 007
        msgv1 = 'Content'.
  ENDIF.

  IF ( ct_tab_recipients[] IS INITIAL ) AND ( iv_recipient IS INITIAL ).
    RAISE EXCEPTION TYPE cx_bcs
      EXPORTING
        msgty = 'E'
        msgid = '00'
        msgno = 007
        msgv1 = 'Recipient'.
  ENDIF.

  IF NOT iv_sender CS '@'.
    cv_flg_sender_is_uname = 'X'.
  ENDIF.

  lt_recipients = ct_tab_recipients[].
  APPEND iv_recipient TO lt_recipients.

  DELETE lt_recipients
    WHERE table_line IS INITIAL.

  SORT lt_recipients BY table_line.
  DELETE ADJACENT DUPLICATES FROM lt_recipients.

  TRY.
      lo_ref_send_req = cl_bcs=>create_persistent( ).

*     sender
      TRY.
          IF cv_flg_sender_is_uname IS INITIAL.

            lv_smtp_addr       = iv_sender.
            lo_ref_sender      = cl_cam_address_bcs=>create_internet_address(
              i_address_string = lv_smtp_addr
              i_address_name   = lv_smtp_addr
            ).
          ELSE.
            lv_uname = iv_sender.
            lo_ref_sender = cl_sapuser_bcs=>create( i_user =  lv_uname ).
          ENDIF.

        CATCH cx_address_bcs INTO lx_rex_addr.
          RAISE EXCEPTION lx_rex_addr.
      ENDTRY.

      lo_ref_send_req->set_sender( lo_ref_sender ).

*      recipient (e-mail address)
      LOOP AT lt_recipients INTO lv_smtp_addr.
        lo_ref_recipient = cl_cam_address_bcs=>create_internet_address( lv_smtp_addr ).
*       add recipient with its respective attributes to send request
        lo_ref_send_req->add_recipient( lo_ref_recipient ).
      ENDLOOP.

*     document
      APPEND LINES OF ct_tab_lines TO lt_soli.
      lv_subject  = iv_title.

      IF iv_high_priority EQ abap_true.
        lv_importance = '1'.
      ENDIF.

      lo_ref_doc = cl_document_bcs=>create_document(
        i_type       = 'RAW'
        i_text       = lt_soli
        i_length     = '100'
        i_subject    = lv_subject
        i_importance = lv_importance
      ).

*     add document to send request
      lo_ref_send_req->set_document( lo_ref_doc ).

      IF NOT iv_flg_send_immediately IS INITIAL.
        lo_ref_send_req->set_send_immediately( 'X' ).
      ENDIF.

      lo_ref_send_req->set_status_attributes( 'N' ).
      lv_string = iv_title.
      lo_ref_send_req->set_message_subject( lv_string ).
      lo_ref_send_req->send( ).

      IF NOT iv_flg_commit IS INITIAL.
        TRY.
            COMMIT WORK.
          CATCH cx_root.
        ENDTRY.
      ENDIF.

    CATCH cx_bcs INTO lx_rex_bcs.
      RAISE EXCEPTION lx_rex_bcs.
    CATCH cx_root.
  ENDTRY.

ENDMETHOD.



The usage is very easy, you have to always provide some email body, title - subject, sender and recipient. You can do that as follows within some arbitrary class. Play with it a you want..

CLASS lcl_ctrl_email DEFINITION.

  PUBLIC SECTION.
    METHODS:
      send_email
        IMPORTING
          iv_title           TYPE clike
          iv_sender          TYPE clike.

  PRIVATE SECTION.
    DATA: t_mail_text        TYPE soli_tab,
          t_recipients       TYPE STANDARD TABLE OF ad_smtpadr.

    METHODS:
      generate_content,
      get_recipients.

ENDCLASS.                    "lcl_ctrl_email DEFINITION

CLASS lcl_ctrl_email IMPLEMENTATION.
  METHOD generate_content.

    DATA: ls_mail_text TYPE soli.

    ls_mail_text = 'Hello,'.
    APPEND ls_mail_text TO t_mail_text.

    ls_mail_text = ''.
    APPEND ls_mail_text TO t_mail_text.

    ls_mail_text = 'this is an email content example...'.
    APPEND ls_mail_text TO t_mail_text.

    ls_mail_text = ''.
    APPEND ls_mail_text TO t_mail_text.

    ls_mail_text = 'Regards,'.
    APPEND ls_mail_text TO t_mail_text.

    ls_mail_text = 'Your team'.
    APPEND ls_mail_text TO t_mail_text.

  ENDMETHOD.                    "generate_content.

  METHOD get_recipients.

    SELECT email FROM /yournamespace/email_addr
      INTO TABLE t_recipients.

  ENDMETHOD.                    "get_recipients

  METHOD send_email.

    generate_content( ).
    get_recipients( ).

    TRY.
        CALL METHOD /yournamespace/cl_email=>send_email
          EXPORTING
            iv_title          = iv_title
            iv_sender         = iv_sender
            iv_high_priority  = abap_true
            iv_recipient      = ''
          CHANGING
            ct_tab_lines      = t_mail_text
            ct_tab_recipients = t_recipients.
      CATCH cx_root.
        MESSAGE ID sy-msgid TYPE 'E' NUMBER sy-msgno WITH sy-msgv1 sy-msgv2 sy-msgv3 sy-msgv4.
    ENDTRY.

  ENDMETHOD.                    "send_email

ENDCLASS.                    "lcl_ctrl_email IMPLEMENTATION



Source:  https://archive.sap.com/discussions/thread/1953259

Convert internal table into binary Xstring (via JSON) and back

There is a lot of cases where binary data representation becomes handy. E.g. for some data transfers or saving data into database via rawstring format. No need to mention advantages of JSON over XML. The conversion within ABAP is described here.


There is a list of some conversion tools (the list is not comprehensive)

1. CALL TRANSFORMATION ID - kernel general functionality
2. CL_TREX_JSON_SERIALIZER & CL_TREX_JSON_DESERIALIZER - it seems it would be later absorbed by part of HANA = uncertain destiny
3. /UI2/CL_JSON or CL_FDT_JSON - not reachable everywhere

I explored a bit the usage of Call transformation and Trex classes. You can observe my conclusions here below.

1) CALL TRANSFORMATION

This is general way working with two patches  starting from version of ABAP 7.02 on. Here you relay on kernel functionality - some internal binary black box coding :) Nevertheless it is working well. Of course you can write down your own XSLT transformation. Because as I wanted to have it simple as possible, finally I discovered a way without a need of custom transformation for deserialization.



DATA: lo_writer           TYPE REF TO cl_sxml_string_writer,
      lv_xstring_json     TYPE xstring,
      " source itab - for serialization
      lt_flight           TYPE STANDARD TABLE OF spfli, 
      " target itab - after deserialization
      lt_flight2          TYPE STANDARD TABLE OF spfli. 



" Get data from database into itab
SELECT *
FROM spfli
UP TO 3 ROWS
INTO TABLE lt_flight.

" Serialize data - into binary JSON
lo_writer = cl_sxml_string_writer=>create( if_sxml=>co_xt_json ).
TRY.
    CALL TRANSFORMATION id
    SOURCE itab = lt_flight
    RESULT XML lo_writer.
  CATCH cx_xslt_format_error.
    MESSAGE 'Some serialization error occured.' TYPE 'E'.
ENDTRY.

" Now we have a serialized JSON data
lv_xstring_json = lo_writer->get_output( ).

The back way - get back the itab

" Deserialization of data - back into itab
TRY.
    CALL TRANSFORMATION id
    SOURCE XML lv_xstring_json
    RESULT itab = lt_flight2.
  CATCH cx_xslt_format_error.
    MESSAGE 'Some deserialization error occured.' TYPE 'E'.
ENDTRY.


" Final confirmation
ASSERT lt_flight EQ lt_flight2.

2) TREX classes

These classes are simple to use, pretty straight forward and easy to understand. The question is the future of them.

Get some data to be serialized

DATA: lo_json_serializer   TYPE REF TO cl_trex_json_serializer,
            lo_json_deserializer TYPE REF TO cl_trex_json_deserializer,
            lt_flight            TYPE STANDARD TABLE OF spfli,
            lv_json              TYPE string,
            lv_binary            TYPE xstring.

SELECT *
  FROM spfli
  UP TO 3 ROWS
  INTO TABLE lt_flight.


This is the source itab

Create JSON string out of itab

CREATE OBJECT lo_json_serializer
  EXPORTING
    data = lt_flight.
lo_json_serializer->serialize( ).
lv_json = lo_json_serializer->get_data( ).


Now we have a following JSON string.

Create a binary string out of JSON string

CALL FUNCTION 'SCMS_STRING_TO_XSTRING'
  EXPORTING
    text     = lv_json
*   MIMETYPE = ' '
*   ENCODING =
  IMPORTING
    buffer   = lv_binary
  EXCEPTIONS
    failed   = 1.


There is nice binary content ready for a journey.

And now, the back way. Get itab out of binary data.

Get JSON string out of binary string

Note: I used for purpose different target variables.


DATA: lt_flight2           TYPE STANDARD TABLE OF spfli,
            lv_json2             TYPE string. 


CALL FUNCTION 'HR_KR_XSTRING_TO_STRING'
  EXPORTING
    in_xstring = lv_binary
  IMPORTING
    out_string = lv_json2.

Get itab out of JSON string

CREATE OBJECT lo_json_deserializer.
lo_json_deserializer->deserialize(
  EXPORTING
    json   = lv_json2
  IMPORTING
    abap   = lt_flight2
 ).


" Final confirmation
ASSERT lt_flight EQ lt_flight2.



Now we are at the very beginning, holding exactly the same itab as at the beginning. Choose your own way ;-)

Useful links:

• http://www.abap-developers.com/2014/07/what-is-xstring-data-type-and-how-to-convert-it-to-various-formats/
• https://wiki.scn.sap.com/wiki/display/Snippets/One+more+ABAP+to+JSON+Serializer+and+Deserializer
• https://blogs.sap.com/2016/11/17/displaying-json/
• https://blogs.sap.com/2013/02/21/three-different-ways-to-serialize-and-deserialize-complex-abap-data/
• http://www.onsap.com/questions/212/how-to-generate-json-content-from-abap
• https://blogs.sap.com/2013/04/15/abap-2-json-and-json-2-abap-with-st/

Convert big PARID/PARVA table into big flat structure dynamically

Imagine, you can have a huge table with various keys PARID/PARVA similar to USR05 but defined for plant specific parameters (see below table structure).  There is an application working with BIG STRUCTURE receiving data from this database table. But how to do the conversion from table PAR(ID)/PAR(VAlue) into a structure? If you would do that manually, it would be huge list of IF ITAB-PARID = 'SOME_STRUCTURE_FIELD1' ELSE IF ITAB-PARID = 'SOME_STRUCTURE_FIELD2'  etc. - long list of checks made within a loop over ITAB. You would need to write down all the structure components one by one. Yes, it is nicely easily readable , but its ugly programming at all.

Let's look at the dynamic approach, it saves lots of manual coding here. The below code snippet is, I hope, well commented to grasp the idea.

Source database table structure:

Target filled flat structure:

*&---------------------------------------------------------------------*

REPORT z_dynamic_prg.

* Some huge flat target stucture receiving PARID/PARVA data from ITAB
TYPES:
  BEGIN OF tls_plant_specifics,
    delete_aufnr     TYPE abap_bool,
    use_screen_202   TYPE abap_bool,
    global_selection TYPE abap_bool,
    run_co04         TYPE abap_bool,
    not_use_opr_num  TYPE abap_bool,
    export_9_31      TYPE string,
    export_9_4       TYPE string,
    export_9_5       TYPE string,
    export_special   TYPE string,
    screen_907_clear TYPE string,
    not_use_fstau    TYPE abap_bool,
    blank_staging    TYPE abap_bool,
    filter_version   TYPE c LENGTH 1,
    export_plan_in   TYPE abap_bool,
    staging_blank    TYPE abap_bool,
    remove_routines  TYPE abap_bool,
    panning_rmw_e3   TYPE abap_bool,
    schedule_old     TYPE abap_bool,
    free_time        TYPE c LENGTH 1,
    set_subrc        TYPE abap_bool,
    zroh_1           TYPE string,
    zroh_2           TYPE abap_bool,
    fevor_set_bu     TYPE abap_bool,
    component_active TYPE abap_bool,
    sel_reservations TYPE string,
    mode_3_lgort     TYPE lgort_d,
    change_profil    TYPE abap_bool,
    set_user_attrib  TYPE abap_bool,
    import_check_lr  TYPE abap_bool,
    read_marc_as_1   TYPE werks_d,
    read_marc_as_2   TYPE werks_d,
    read_marc_as_3   TYPE werks_d,
    default_lgort    TYPE lgort_d,
    select_days      TYPE abap_bool,
    use_zmet_zroh    TYPE abap_bool,
    set_fevor_icon   TYPE string,
    read_marc_as_4   TYPE werks_d,
    set_fstad_fstau  TYPE abap_bool,
    set_okcode       TYPE string,
    set_affree       TYPE abap_bool,
    set_time         TYPE abap_bool,
    userexit_lgnum   TYPE lgnum,
    get_mto_mts_by   TYPE string,
  END OF tls_plant_specifics,

  BEGIN OF tls_plant_specifics_parva_parid,
    parid       TYPE memoryid,
    parva       TYPE xuvalue,
  END OF tls_plant_specifics_parva_parid.


DATA: lt_plant_specifics_parva_parid TYPE STANDARD TABLE OF tls_plant_specifics_parva_parid,
      ls_plant_specifics_parva_parid LIKE LINE OF lt_plant_specifics_parva_parid,
      lo_structdescr     TYPE REF TO cl_abap_structdescr,
      lt_components      TYPE cl_abap_structdescr=>component_table,
      ls_component       LIKE LINE OF lt_components,
      lv_element_name    TYPE string,
      lv_element_content TYPE string.

DATA: lv_werks       TYPE werks_d VALUE '9999', " some plant - hardcoded for test
      lv_plant_table TYPE tabname VALUE 'SOME_YOUR_PARAM_TABLE_NAME', 
      ls_plant_specifics TYPE tls_plant_specifics. " target structure

FIELD-SYMBOLS <fs_element> TYPE simple.

" Get all plant parameters into itab
SELECT parid parva FROM (lv_plant_table)
INTO TABLE lt_plant_specifics_parva_parid
WHERE werks = lv_werks.


IF ( sy-subrc EQ 0 ) AND ( lt_plant_specifics_parva_parid IS NOT INITIAL ).

  " Get the values out of table (parid/parva) into class public structure
  lo_structdescr ?= cl_abap_structdescr=>describe_by_data( ls_plant_specifics ).
  lt_components   = lo_structdescr->get_components( ).

  " Loop at parid x parva itab (comming from database)
  LOOP AT lt_plant_specifics_parva_parid INTO ls_plant_specifics_parva_parid.
 
    " Loop over components of target structure
    LOOP AT lt_components INTO ls_component.

      " Read component name out of table
      lv_element_name = ls_plant_specifics_parva_parid-parid.
   
      " If PARAM name is equal to STRUCTURE component name => assign the value to the structure for this field
      IF ls_component-name EQ lv_element_name. 

        CONCATENATE 'ls_plant_specifics-' lv_element_name INTO lv_element_name.
        ASSIGN (lv_element_name) TO <fs_element>.

        IF ( <fs_element> IS ASSIGNED ) AND ( ls_plant_specifics_parva_parid-parva IS NOT INITIAL ).
       
          " You can assign data based on its type...   
          IF ls_component-type->absolute_name CS 'ABAP_BOOL'.
            " just one char
            <fs_element> = ls_plant_specifics_parva_parid-parva+0(1).
          ELSE.
            " strings, etc.
            lv_element_content = ls_plant_specifics_parva_parid-parva.
            CONDENSE lv_element_content NO-GAPS.
            <fs_element> = lv_element_content.
          ENDIF.

        ENDIF.
      ENDIF.

    ENDLOOP.
  ENDLOOP.

  FREE lo_structdescr.

ENDIF.