Application Development Blog Posts
Learn and share on deeper, cross technology development topics such as integration and connectivity, automation, cloud extensibility, developing at scale, and security.
Showing results for 
Search instead for 
Did you mean: 
Active Contributor
After a while of experience following this approach, considering also your comments here I discarded this approach for me. I leave the original text as it is in order to archive the discussion. 

As I promised in my last post, today I come back writing about my experiences with the "use simple types" approach I mentioned there.

The approach

  • Avoid references to DDIC types (i.e. structures, data elements, table types) as long as is it is not necessary. A necessity for a DDIC type reference could be:

    • A field shows up on the screen (conversion exits and labels are needed)

    • You are calling a function module and have to match the types used here

  • Use simple, base types for attributes, locals and parameters such as:

    • string

    • integer

    • date

    • time

    • float

    • abap_bool

    • string_table (in fact, this is a DDIC type, but it is very basic and very useful when working on arrays)

  • Use range of strings in case of the need of selection ranges. Put a type definition for this in some central class of your code base. DB selections will work fine with this

  • Use clear, descriptive names for the variables in order to not create confusion about their semantics


When I first thought of this, I was afraid, I missed something and the approach could bring more harms than blessings. So I decided to "try it out" for a while.

After having created a number of applications following the approach, I must say that it comes in very handy. I'd like to share some snippets:
    methods pbo.

methods set_conf_number
importing in type string.

methods set_work_station
importing in type string.

methods set_test_purpose
importing in type string.

methods set_remarks
importing in type string.

methods exit_command
importing in type string.

methods user_command
importing in type string.

This is part of the declaration of a front end class that communicates with a function group that carries a dynpro. Imagine how easy it was to create those declarations using copy and paste!

The dynpro logic calls those methods on each event that happens on it:
module conf_number_input input.
g_controller->set_conf_number( conv #( zst_pp39_qcheck_strip_screen-conf_number ) ).

module work_station_input input.
g_controller->set_work_station( conv #( zst_pp39_qcheck_strip_screen-work_station ) ).

module test_purpose_input input.
g_controller->set_test_purpose( conv #( zst_pp39_qcheck_strip_screen-test_purpose ) ).

module remarks_input input.
g_controller->set_remarks( conv #( zst_pp39_qcheck_strip_screen-remark ) ).

module exit_0001 input.
g_controller->exit_command( conv #( user_command ) ).

module user_command_0001 input.
g_controller->user_command( conv #( user_command ) ).

Since I am on the front end representation layer here, all my data is typed by referring DDIC. So I have to do a conversion when passing them to my simple-typed class.
  private section.
constants function_preview type string value '1'.
constants function_print type string value '2'.
constants info_structure_name type string value `ZST_PP39_CONFIRM_INFO`.
constants work_station_parameter type memoryid value 'ZPP24_WSTAT'.
constants confirm_number_parameter type memoryid value 'RCK'.
constants info_value_width type i value 12.
constants info_description_width type i value 30.

constants (and data) declarations are dominated by simple types. However, some ABAP statements (as for instance get parameter id) require non-string parameters so I had to make some exceptions to my rule.
* <SIGNATURE>---------------------------------------------------------------------------------------+
* +-------------------------------------------------------------------------------------------------+
* +--------------------------------------------------------------------------------------</SIGNATURE>
method fill_print_data.
result =
value #(
order_id = |{ order_operation-order_id alpha = out }|
material_number = zcl_ca03_conversions=>matn1_output( order_operation-material_number )
work_center_id = work_center_id
work_center_text = work_center_text
material_description = material_description
test_purpose_text = test_purpose_text
remark = remark ).

This is a mapping method for a communication structure that is used in a smart form. Since the smart form is called via function module, I had to create a DDIC structure for the data that is to be printed. However, the fields of the structures are all simple strings (see below).

Note the conversions I do for the first two fields. For printing, I need the external representation. Here, one could say that using a DDIC field in the communication structure would have done the job of conversion (and I would agree - maybe I will change this).

class ZCL_PP39_QCHECK_STRIP_TYPES definition
final abstract
create public .

public section.
begin of ty_order_operation,
conf_number type string,
order_id type string,
activity type string,
material_number type string,
work_center_id type string,
end of ty_order_operation.

This is a class where I declare complex types for use within the application. As you see, the components are all strings.
    select single
afvc~rueck as conf_number,
afvc~vornr as activity,
afvc~arbid as work_center_id,
afpo~aufnr as order_id,
afpo~matnr as material_number
from afvc join afko on afko~aufpl = afvc~aufpl
join afpo on afpo~aufnr = afko~aufnr
where afvc~rueck = @in
into corresponding fields of @result.

Here we have a select that fills the structure declared above. Obviously the import parameter in is a string. Using into corresponding fields does the job of converting everything to strings.
    data confirm_info type zst_pp39_confirm_info.

This is a structure I use for screen output. Of course, every field in this structure has its DDIC type.


Coding in this way seems more lightweight to me. I like the easy way I can create new parts in my coding doubling a row or region and then changing the essential, while the type references are often identical (referring to a string).

To me, the code remains readable and clean. To understand the purpose of coding logic, normally it is sufficient to understand if I am dealing with a text, a flag or a number. The rest of the semantic comes with clear names.

Labels in this area