Skip to Content

This blog describes the meaning of the commented header of a function module.


*” Local Interface:

*” [IMPORTING style=’mso-bidi-font-style:normal’>parameters
]
*” [EXPORTING parameters]

*” [CHANGING  Parameters]
*” [TABLES   table_parameters]
*” [{RAISING|EXCEPTIONS} exc1 exc2 …]

Where the syntax of parameters is:

… { VALUE(p1) | p1 } 
{TYPE  type} | {LIKE struc-comp} | {STRUCTURE struc}
[OPTIONAL|{DEFAULT def1}]

{ VALUE(p2) | p2 }
{TYPE  type} | {LIKE struc-comp} | {STRUCTURE struc}
OPTIONAL …

and the syntax of table_parameters is:

  … p1  {TYPE  itab_type} | {STRUCTURE struc}
p2  {TYPE itab_type}| {STRUCTURE struc}   …

Quite familiar from defining local methods, isn’t it? But there are some differences …

Interface parameters

The interface parameters are defined on the relevant tab pages in the Function Builder.

    • IMPORTING
      parameters are input parameters. When the function module is called, a suitable actual parameter must be specified for every non-optional input parameter. The content of the actual parameter is passed to the input parameter when the call is made. The content of an input parameter for which ‘pass by reference’ is defined cannot be changed in the function module. This is the same as for methods.
    • EXPORTING
      parameters are output  parameters. When the function module is called, a suitable actual parameter can be specified for every output parameter. The content of an  output parameter that is defined for ‘pass by value’ is transferred to the actual parameter if the function module is completed without errors. An output parameter that is defined for pass by reference is not initialized when the function module is called. This is the same as for methods.
    • CHANGING
      parameters are input and output parameters. When the function module is called, a
      suitable actual parameter must be specified for every non-optional  input/output parameter. When the function module is called, the content of  the actual parameter is passed to the input/output parameter, and when the  function module is completed, the content of the input/output parameter is  passed to the actual parameter. This is the same as for methods.
    • TABLES
      parameters are table parameters. Table parameters are obsolete CHANGING parameters that are typed as Standard tables with a header line. If an internal table without a header line or a table body is passed as an actual parameter to a formal  parameter of this type, an empty local header line is generated in the function module. If an internal table with a header line is used as an actual parameter, both the table body and the header line are passed to the function module. Pass by value is not possible in formal Parameters defined using TABLES. Table parameters are not allowed in methods and you should not define them for function modules any more.
      Formal parameters defined with TABLES can be replaced by formal parameters defined with CHANGING. A local work area can easily be created for the internal table in the function module by using the addition  LIKE LINE OF itab of the DATA statement.

Type of Parameter Passing

There are two ways in which parameters can be passed: pass by reference and pass by value. Pass by value is selected in the Function Builder by selecting pass by value, and in the above syntax, differs from pass by reference by the specification of  VALUE( ) .

    1. With pass  by reference, the formal parameter points directly to the actual parameter, so that changes to the formal parameters have an immediate  effect on the actual parameter.
    2. With pass by value, when the function module is called, the formal parameter is created as a copy of the actual parameter (for IMPORTING and CHANGING parameters), or  initial (for EXPORTING parameters). For CHANGING  and  EXPORTING parameters,  the formal parameter is copied to the actual parameter when returning from the function module via  ENDFUNCTION or RETURN  or  EXIT CHEC .

Note the following for the different types of parameter:

    1. In IMPORTING, EXPORTING, and  CHANGING  parameters, pass by reference and pass by value are possible, in  TABLES parameters, only pass by reference is possible.
    2. IMPORTING parameters passed by reference  cannot be overwritten in the function  module.
    3. EXPORTING  parameters passed by reference  are not initialized when the function module is called. For this reason, no read access to these parameters should be carried out before the first write access.

Typing of Interface Parameters

The parameter interface of a function module is public across the system. Interface parameters can therefore only be typed with reference to data types from the ABAP Dictionary or from the public section of global classes. In the Function Builder, interface parameters  can be typed by the selection of either TYPE, TYPE REF TO or LIKE.  While typing with TYPE is also displayed as TYPE  in the above syntax, typing with LIKE  is not only represented by LIKE, but also by STRUCTURE !

    1. Typing with TYPE  is  the recommended typing for interface parameters of function modules. It takes place when TYPE or TYPE REF TO is selected in the Function Builder. For IMPORTING , EXPORTING, and CHANGING parameters, any predefined ABAP type (complete or generic), or any data type from the ABAP Dictionary or from the public section of a global class can be specified after TYPE . After
      TYPE REF TO
      , the generic data type data, a non-generic data type, or an object type can be specified. Then, the interface parameter is typed as a reference variable. In TABLES parameters, only a table type itab_type  can be specified, where itab_type
      is a ‘standard table’ with a flat line type from the ABAP Dictionary. When calling the function module, the typing check is performed in the same way as for methods.
    2. Typing with LIKE is obsolete. It takes place if an elementary component of a flat structure (or database table) struc-comp from the ABAP Dictionary is specified after LIKE in the Function Builder. The typing check is the same as for the specification of
      components after TYPE, with the exception that the fractional portion is not taken into account for packed numbers. And some more weird stuff: If a component of a global program structure in the function group of a function module has exactly the same identity (structure name struc and component comp) as the component of a structure in the ABAP Dictionary specified after LIKE LIKE  refers to the component of the structure defined in the function group! Fortunately, this leads to a warning during syntax check. In contrast, TYPE  always refers to types in the ABAP Dictionary.
    3. Typing with STRUCTURE is obsolete. It takes place if a flat structure (or database table) struc  from the ABAP Dictionary is specified after LIKE in the Function Builder. The formal parameter is then casted with this structure, and it is possible to access the individual components. For a formal parameter typed with STRUCTURE, a connected actual parameter must be a structure. In non-Unicode programs, the actual parameter must be suitably aligned (for pass by reference) and its length must exactly match the length of the structure struc, with the exception of table parameters. For table parameters, the length of the actual parameter must only be at least the length of the structure. In Unicode programs, the Unicode fragment view of a structured actual parameter must match that of  struc. For an elementary actual parameter this must be character-type and flat. Everything clear now? Seems better not to use that …
From the  last two points you see that choosing LIKE in the Function Builder is by far not the same as using the language element LIKE with DATA or for typing method parameters or field symbols. Good reasons, not to use LIKE any more!

Optional parameters

IMPORTING , CHANGING, and TABLES parameters can be made optional by the selection of optional in the Function Builder. EXPORTING parameters are always optional. IMPORTING and CHANGING  parameters can be assigned a replacement parameter (default value in the Function Builder). In the above syntax, this is expressed using the additions OPTIONAL or DEFAULT. For an optional parameter, no actual parameter must be entered when the function module is called. While a
formal parameter with the addition OPTIONAL is then initialized according to its type, a formal arameter with the addition DEFAULT takes over the value and type of the replacement parameter def1 def2 . Within a function module, the logical expression IS SUPPLIED can be used to check if an optional formal parameter was assigned an actual parameter when the module was called.

Exceptions

The exceptions of a function module are defined on the Exceptions tab page in the Function Builder. Here you can select exception classes to define whether class-based exceptions are declared or non-class-based exceptions are defined. Class-based exceptions are represented in the above syntax by  RAISING , and non-class-based exceptions are represented by EXCEPTIONS. This is the same as for methods.

    1. The addition RAISING is used to denote class-based exceptions that can be propagated from the function module to the caller. Exceptions in the categories CX_STATIC_CHECK and CX_DYNAMIC_CHECK must be explicitly declared, otherwise a propagation can lead to an interface violation. A violation of the interface leads to the treatable exception CX_SY_NO_HANDLER. Exceptions of the category CX_NO_CHECK are implicitly always declared. The declaration of exceptions of the category CX_STATIC_CHECK is statically checked in the syntax check. For exceptions of the category CX_DYNAMIC_CHECK, the check is not performed until runtime. In a function module in which class-based exceptions are declared with the RAISING addition, the Statement  CATCH SYSTEM-EXCEPTIONS cannot be used. Instead, the relevant exceptions should be handled in a TRY control structure.
    2. The addition EXCEPTIONS is used to define a list of non-class-based exceptions that can be triggered in the function module using the statements RAISE or MESSAGE
      RAISING
      . Exceptions defined in this way – as with formal parameters – are bound to the function module and cannot be propagated. If an exception of this type is triggered in a function module, and no return value has been assigned to it with the homonymous addition EXCEPTIONS of the CALL FUNCTION statement where the call was made, this leads to a runtime error.

For newdevelopments after release 6.10, I strongly recommend that you work withclass-based exceptions that are independent of the function module.

Global Parameters

Finally, as another relict of ABAP’s long history, you might find the attribute Global checked for older function modules. What the heck is this?

The parameters of a function module can be declared as “global” by choosing   Edit → Interface → Globalize Parameters in the Function Builder. Then the parameters are treated as follows:

    1. All parameters, that are completely typed and defined for pass by value, are handled in a way as they were declared as global data objects in the top include of the function group: They are visible throughout the function group and their values are preserved when the function module is left. When calling a function module the global parameters are initialized or a replacement parameter (default) is assigned.
    2. All other parameters are handled in a way as they were declared as global data objects in the top include of the function group, that can be used only during the execution of the function module: They are visible throughout the function group but you can access them only while the function module is active. If you access such a parameter and the respective function module is not executed, you get the runtime error GETWA_NOT_ASSIGNED (Why? Well, technically thos guys are represented via field symbols which are valid only during the runtime of the function module).

In a function group you cannot declare global data objects that have the same namesas global parameters. If a parameter name occurs in several function modules with global interfaces, the parameter must be defined with exactly the same properties.

Needless to say, that you never define such global parameters in new function modules …

 

To report this post you need to login first.

51 Comments

You must be Logged on to comment or reply to a post.

  1. Peter Inotai
    Hi Horst,

    Thanks for this weblog, it’s interesting to read all of this nicely collected small details here.

    I really LIKEd….no….TYPEd you weblog;-)))))

    Regards,
    Peter

    (0) 
  2. Peter Inotai
    Hi Horst,

    Thanks for this weblog, it’s interesting to read all of this nicely collected small details here.

    I really LIKEd….no….TYPEd you weblog;-)))))

    Regards,
    Peter

    (0) 
  3. Peter Inotai
    Hi Horst,

    Thanks for this weblog, it’s interesting to read all of this nicely collected small details here.

    I really LIKEd….no….TYPEd you weblog;-)))))

    Regards,
    Peter

    (0) 
  4. Former Member
    Hi Horst,

    I must have been sleeping when everybody agreed that tables with a header line were bad.

    I know this is an old issue, but why exactly? 

    Brad

    (0) 
    1. Horst Keller Post author
      Well, a header line is a data object which has exactly the same name as the internal table. This simply breaks the rule of an unique name space for data objects!

      If at an operand position of an ABAP statement, you specify the name of internal table itab with header line, it depends on the statement whether the table body or the header line are used. As a rule (with many exceptions!), all table-specific statements such as SORT or LOOP use the internal table, while all other statements use the header line. As a workaround, you can denote the table body explicitly with itab[].

      Therfore, you should not use this outdated possibility, because then two data objects with the same name exist in the ABAP program.
      The table name should signify the table unambiguously. This makes programs much easier to read and – speaking from own miserable experience – much less error prone. Think about using a CLEAR on a table parameter in a function module – everybody would think that you clear the table parameter, but you clear the header line!

      Tables with headers do not offer any performance advantages. Instead of a header line, you can simply create an explicit work area using the addition LINE OF of the statements TYPES, DATA etc.

      Cheers,

      Horst

      (0) 
      1. Former Member
        > This simply breaks the rule of an
        > unique name space for data objects!

        What, so no real reason then?  🙂

        As I said, I know its not a new topic, just never understood why they went out of fashion.  I saw that sad face when you mentioned them, so I thought I’d jump in with the question.  I’ll just fly back off to Alpha Centauri or wherever I came from now… (not sure I got that one Thomas?)

        (0) 
        1. Thomas Jung
          Sorry. I thought Hitchhiker’s Guide to the Galaxy was required reading before anyone got their ABAP Developer’s Key. 

          That’s what the Vogon’s told the people of Earth as they were about to destroy it to make way for a new Hyperspace route.

          No offense intended – just a (failed) attempt at humor on a Friday morning.

          (0) 
          1. Former Member
            None taken.  I’ve read the book, but its been a while…  Also, its late Friday afternoon here, minds not as sharp as it could be.  I think humour is lacking a little on the site, however, so please don’t be discouraged by my dim wittedness (is that a word?).
            (0) 
          2. Former Member
            I got it, but maybe that’s because I’ve worked with a guy here who has an uncanny resemblance to Ford Prefect (BBC series, not the new movie).

            Or maybe it’s because I grew up in Dubbo and there just isn’t a heck of a lot to do besides watching BBC repeats.  (this is a reference for the Aussies like me and Brad).

            (0) 
      2. So is it cool to define Field-symbols for accessing the internal table data?  I generally do this instead of a work area.  

        Any comments on using a field-symbol vs. a work area data structure?

        Thanks!

        Great work

        (0) 
        1. Horst Keller Post author
          Hi Kenneth,

          You are right. I just forgot to mention it. Instead of working with worka areas, you can also acces table lines via field symbols or reference variables set by additions ASSIGNING and REFERENCE INTO of APPEND, COLLECT, LOOP, MODIFY, and READ. This is for most cases preferable, since copy free.

          Regards

          Horst

          (0) 
    2. Thomas Jung
      >I must have been sleeping when everybody agreed
      >that tables with a header line were bad.

      What do you mean?
      The plans have been on display at your local planning department in Alpha Centauri for fifty of your Earth years, so you can’t start making a big fuss about it now!

      (0) 
  5. Former Member
    Hi Horst,

    I must have been sleeping when everybody agreed that tables with a header line were bad.

    I know this is an old issue, but why exactly? 

    Brad

    (0) 
    1. Horst Keller Post author
      Well, a header line is a data object which has exactly the same name as the internal table. This simply breaks the rule of an unique name space for data objects!

      If at an operand position of an ABAP statement, you specify the name of internal table itab with header line, it depends on the statement whether the table body or the header line are used. As a rule (with many exceptions!), all table-specific statements such as SORT or LOOP use the internal table, while all other statements use the header line. As a workaround, you can denote the table body explicitly with itab[].

      Therfore, you should not use this outdated possibility, because then two data objects with the same name exist in the ABAP program.
      The table name should signify the table unambiguously. This makes programs much easier to read and – speaking from own miserable experience – much less error prone. Think about using a CLEAR on a table parameter in a function module – everybody would think that you clear the table parameter, but you clear the header line!

      Tables with headers do not offer any performance advantages. Instead of a header line, you can simply create an explicit work area using the addition LINE OF of the statements TYPES, DATA etc.

      Cheers,

      Horst

      (0) 
      1. Former Member
        > This simply breaks the rule of an
        > unique name space for data objects!

        What, so no real reason then?  🙂

        As I said, I know its not a new topic, just never understood why they went out of fashion.  I saw that sad face when you mentioned them, so I thought I’d jump in with the question.  I’ll just fly back off to Alpha Centauri or wherever I came from now… (not sure I got that one Thomas?)

        (0) 
        1. Thomas Jung
          Sorry. I thought Hitchhiker’s Guide to the Galaxy was required reading before anyone got their ABAP Developer’s Key. 

          That’s what the Vogon’s told the people of Earth as they were about to destroy it to make way for a new Hyperspace route.

          No offense intended – just a (failed) attempt at humor on a Friday morning.

          (0) 
          1. Former Member
            None taken.  I’ve read the book, but its been a while…  Also, its late Friday afternoon here, minds not as sharp as it could be.  I think humour is lacking a little on the site, however, so please don’t be discouraged by my dim wittedness (is that a word?).
            (0) 
          2. Former Member
            I got it, but maybe that’s because I’ve worked with a guy here who has an uncanny resemblance to Ford Prefect (BBC series, not the new movie).

            Or maybe it’s because I grew up in Dubbo and there just isn’t a heck of a lot to do besides watching BBC repeats.  (this is a reference for the Aussies like me and Brad).

            (0) 
      2. So is it cool to define Field-symbols for accessing the internal table data?  I generally do this instead of a work area.  

        Any comments on using a field-symbol vs. a work area data structure?

        Thanks!

        Great work

        (0) 
        1. Horst Keller Post author
          Hi Kenneth,

          You are right. I just forgot to mention it. Instead of working with worka areas, you can also acces table lines via field symbols or reference variables set by additions ASSIGNING and REFERENCE INTO of APPEND, COLLECT, LOOP, MODIFY, and READ. This is for most cases preferable, since copy free.

          Regards

          Horst

          (0) 
    2. Thomas Jung
      >I must have been sleeping when everybody agreed
      >that tables with a header line were bad.

      What do you mean?
      The plans have been on display at your local planning department in Alpha Centauri for fifty of your Earth years, so you can’t start making a big fuss about it now!

      (0) 
  6. Former Member
    Hi Horst,

    I must have been sleeping when everybody agreed that tables with a header line were bad.

    I know this is an old issue, but why exactly? 

    Brad

    (0) 
    1. Horst Keller Post author
      Well, a header line is a data object which has exactly the same name as the internal table. This simply breaks the rule of an unique name space for data objects!

      If at an operand position of an ABAP statement, you specify the name of internal table itab with header line, it depends on the statement whether the table body or the header line are used. As a rule (with many exceptions!), all table-specific statements such as SORT or LOOP use the internal table, while all other statements use the header line. As a workaround, you can denote the table body explicitly with itab[].

      Therfore, you should not use this outdated possibility, because then two data objects with the same name exist in the ABAP program.
      The table name should signify the table unambiguously. This makes programs much easier to read and – speaking from own miserable experience – much less error prone. Think about using a CLEAR on a table parameter in a function module – everybody would think that you clear the table parameter, but you clear the header line!

      Tables with headers do not offer any performance advantages. Instead of a header line, you can simply create an explicit work area using the addition LINE OF of the statements TYPES, DATA etc.

      Cheers,

      Horst

      (0) 
      1. Former Member
        > This simply breaks the rule of an
        > unique name space for data objects!

        What, so no real reason then?  🙂

        As I said, I know its not a new topic, just never understood why they went out of fashion.  I saw that sad face when you mentioned them, so I thought I’d jump in with the question.  I’ll just fly back off to Alpha Centauri or wherever I came from now… (not sure I got that one Thomas?)

        (0) 
        1. Thomas Jung
          Sorry. I thought Hitchhiker’s Guide to the Galaxy was required reading before anyone got their ABAP Developer’s Key. 

          That’s what the Vogon’s told the people of Earth as they were about to destroy it to make way for a new Hyperspace route.

          No offense intended – just a (failed) attempt at humor on a Friday morning.

          (0) 
          1. Former Member
            None taken.  I’ve read the book, but its been a while…  Also, its late Friday afternoon here, minds not as sharp as it could be.  I think humour is lacking a little on the site, however, so please don’t be discouraged by my dim wittedness (is that a word?).
            (0) 
          2. Former Member
            I got it, but maybe that’s because I’ve worked with a guy here who has an uncanny resemblance to Ford Prefect (BBC series, not the new movie).

            Or maybe it’s because I grew up in Dubbo and there just isn’t a heck of a lot to do besides watching BBC repeats.  (this is a reference for the Aussies like me and Brad).

            (0) 
      2. So is it cool to define Field-symbols for accessing the internal table data?  I generally do this instead of a work area.  

        Any comments on using a field-symbol vs. a work area data structure?

        Thanks!

        Great work

        (0) 
        1. Horst Keller Post author
          Hi Kenneth,

          You are right. I just forgot to mention it. Instead of working with worka areas, you can also acces table lines via field symbols or reference variables set by additions ASSIGNING and REFERENCE INTO of APPEND, COLLECT, LOOP, MODIFY, and READ. This is for most cases preferable, since copy free.

          Regards

          Horst

          (0) 
    2. Thomas Jung
      >I must have been sleeping when everybody agreed
      >that tables with a header line were bad.

      What do you mean?
      The plans have been on display at your local planning department in Alpha Centauri for fifty of your Earth years, so you can’t start making a big fuss about it now!

      (0) 
  7. Former Member
    Hi Horst –

    Thanks for all the informative weblogs, there is always something new to learn.
    I am a keen user of explicit header lines and table types. I do, however, occasionally have the need to create a “select-options” table to be used in a select statement when no values should return a full hit-list. Obviously this can be done with the now obsolete “Ranges” statement which creates a table with header line and those annoying “append itab to itab” statements. Is there an efficient replacement for this or is it best to declare your internal table with the “Types” and “Standard table of Types” syntax and structure? 

    Thanks
    AJC

    (0) 
    1. Horst Keller Post author
      Hi,

      this is easy to answer! Use

      TYPES|DATA rtab {TYPE RANGE OF type}|{LIKE RANGE OF dobj} …

      This defines a ranges table meaning a standard table, with a standard key and a structured line type of components sign  TYPE c LENGTH 1, option TYPE c LENGTH 2, low {TYPE type}|{LIKE dobj}, high {TYPE type}|{LIKE dobj}.
            
      Regards

      Horst

      (0) 
        1. Horst Keller Post author
          Hi Clemens,

          you point out a nuisance, that is really on of the little thorns in the flesh of modern ABAP programming. I complained about that for several years but unfortunately SELECT-OPTIONS is very historical stuff and the relvant developers do not want to touch this any more 🙁

          Sorry

          Horst

          (0) 
  8. Former Member
    Hi Horst –

    Thanks for all the informative weblogs, there is always something new to learn.
    I am a keen user of explicit header lines and table types. I do, however, occasionally have the need to create a “select-options” table to be used in a select statement when no values should return a full hit-list. Obviously this can be done with the now obsolete “Ranges” statement which creates a table with header line and those annoying “append itab to itab” statements. Is there an efficient replacement for this or is it best to declare your internal table with the “Types” and “Standard table of Types” syntax and structure? 

    Thanks
    AJC

    (0) 
    1. Horst Keller Post author
      Hi,

      this is easy to answer! Use

      TYPES|DATA rtab {TYPE RANGE OF type}|{LIKE RANGE OF dobj} …

      This defines a ranges table meaning a standard table, with a standard key and a structured line type of components sign  TYPE c LENGTH 1, option TYPE c LENGTH 2, low {TYPE type}|{LIKE dobj}, high {TYPE type}|{LIKE dobj}.
            
      Regards

      Horst

      (0) 
        1. Horst Keller Post author
          Hi Clemens,

          you point out a nuisance, that is really on of the little thorns in the flesh of modern ABAP programming. I complained about that for several years but unfortunately SELECT-OPTIONS is very historical stuff and the relvant developers do not want to touch this any more 🙁

          Sorry

          Horst

          (0) 
  9. Former Member
    Hi Horst –

    Thanks for all the informative weblogs, there is always something new to learn.
    I am a keen user of explicit header lines and table types. I do, however, occasionally have the need to create a “select-options” table to be used in a select statement when no values should return a full hit-list. Obviously this can be done with the now obsolete “Ranges” statement which creates a table with header line and those annoying “append itab to itab” statements. Is there an efficient replacement for this or is it best to declare your internal table with the “Types” and “Standard table of Types” syntax and structure? 

    Thanks
    AJC

    (0) 
    1. Horst Keller Post author
      Hi,

      this is easy to answer! Use

      TYPES|DATA rtab {TYPE RANGE OF type}|{LIKE RANGE OF dobj} …

      This defines a ranges table meaning a standard table, with a standard key and a structured line type of components sign  TYPE c LENGTH 1, option TYPE c LENGTH 2, low {TYPE type}|{LIKE dobj}, high {TYPE type}|{LIKE dobj}.
            
      Regards

      Horst

      (0) 
        1. Horst Keller Post author
          Hi Clemens,

          you point out a nuisance, that is really on of the little thorns in the flesh of modern ABAP programming. I complained about that for several years but unfortunately SELECT-OPTIONS is very historical stuff and the relvant developers do not want to touch this any more 🙁

          Sorry

          Horst

          (0) 

Leave a Reply