Overview
By defining a build method in an ABAP class, you can ensure that before an attribute is displayed, an ABAP method (the build method) is first called to determine the value of the attribute. The S10 framework assumes that the value of the attribute depends only on the value of the import parameters of the build method. If the import values have not changed, the method is not called.

A build method can have more than one export parameter. This is useful when it is better to calculate the values of the parameters together, rather than to run a separate method for each parameter.
For all import parameters of a build method, the corresponding build method is also called first. In general, for all methods of the S10 framework in which the value of an attribute is accessed via the attribute name as a parameter, the corresponding build method is called first, for example in s10getuservalue(). In contrast, when the attribute value is accessed by ABAP statements, for example "x = x + 1", no build method is executed.

All atomic attributes of the current class are possible as import parameters, but no object references or tables. As export parameters, object references and tables are also supported.
The build mechanism can also be called explicitly for a single attribute by s10build( attrname ). After database updates, it is often useful to run the build methods again the next time the database is accessed, which can be achieved by  s10rebuild() for all attributes of the object.

When using the build methods, it is important that the import parameters map the entire functional dependency.  If, for example, the list of contact persons for the client were to depend on the particular sales area - which is not the case in the SAP system - then the sales area should be named as an import parameter of the build method in addition to the
customer number. Even if no change of sales area is currently planned in the application, you should then include it in order to be prepared for future extensions of the application.

Advantages
Instead of using the concept of build methods, you could also determine the attribute values depending on user input for the screen to be displayed through your own method calls. However, this leads to coding of the type: "If the user has entered a new client number and screen xyz is currently being displayed in which the contact persons for the client are shown, then now determine the contact persons from the database". Experience shows that dialogue programmes become more complex and error-prone with such logic. By using build methods, you achieve greater independence of the application logic from the user interface while at the same time improving performance. In the example of contact persons, these are only read when they are displayed on the current HTML page, and they are not re-read as long as the customer number does not change. Instead of a temporal dependency "user has entered clientnumber and selects screen xxx", you have a fixed functional dependency "the list of contact persons depends on the client number".

Implementation
A build method of an attribute is a public method of the object (not a class method) that has an export parameter whose name is identical to the attribute name. The method name begins with "build_" and is otherwise freely selectable. The type of the export parameter should be identical to the type of the class attribute. Public attributes with the same name must also exist for all import and export parameters.

 
Example 1 (single field)
A telephone number is to be output in such a way that clicking on it dials the number.

data:
  telf1                    type kna1-telf1,

* phone link
  telf1_html               type string.

methods:
  build_telf1_html
     importing
        telf1      type telf1
      exporting
        telf1_html type string.

* build phone link
  method build_telf1_html.

   if telf1 is initial.
      clear telf1_html.
    else.
      telf1html = '<span onclick="event.stopPropagation()">'
                      && '<a href="tel:' && telf1
                      && '" style="color:inherit; text-decoration-color: #afa9a9;">'
                      && '<span class="output">'
                      &&   telf1
                      && '</span></a></span>'.
    endif.
  endmethod.

HTML
<span class="outputhtml" name="telf1_html"> </span>

Example 2 (two single fields as input)
For a contact person, the initials of the name are to be output

data:
   lastname           type string,
   firstname          type string,
   initials           type string.

methods:
   build_initials
     importing
        firstname type string
        lastname  type string
     exporting
        initials  type string .

 * contact initials
method build_initials.

  clear initials.

  if firstname is not initial.
     initials = to_upper( firstname(1) ).
  endif.

  if lastname is not initial.
     initials = initials && to_upper( lastname(1) ).
  endif.

 endmethod.

HTML
<span class="output" name="initials"> </span>

When outputting in a table, the build method is automatically called per table row. The output then looks like this, for example:

where the colored representation of the name initials as an avatar in the HTML page is made via a CSS class and some JavaScript, which is explained in more detail elsewhere.

In HTML, in the case of the table display above, it looks like this:

<div class='outputcelldiv avatar'
   style="float:left; width: 32px;"
   name="initials">
</div>

 data:
    orderproblems type table of ref to orderproblem,

    maxrowcount type string,
    kunnr       type kunnr,
    minvalue    type string,

methods:
 build_orderproblems
      importing
          maxrowcount type string
          kunnr       type kunnr
          minvalue    type string
        exporting
          orderproblems type table,

 * order problems
method build_orderproblems.
     ...
endmethod.

HTML
<form class='table' name='orderproblems'>
  ...
</form>

 

The table is automatically re-read if one of the following has changed: input values customer number, minimum order value or maximum number of hits.
 
 
Example 4 (several output fields)
Dunning data is to be displayed as information on a customer.

 data:
     kunnr   type kunnr,

     mansp   type knb5-mansp,
     madat   type knb5-madat,
     mahns   type knb5-mahns.

methods:
  build_knb5_data
   importing
     kunnr     type kunnr
   exporting
     mansp type knb5-mansp
     madat type knb5-madat
     mahns type knb5-mahns.

 
method build_knb5_data.

  clear: mansp, madat, mahns.

  data: knb5 type knb5.

* from configuration
  knb5-bukrs = config=>parameter( 'bukrs' ).
  knb5-maber = config=>parameter( 'maber' ).


 select single mansp madat mahns
   from knb5
      into corresponding fields of knb5
        where kunnr = kunnr
        and bukrs = knb5-bukrs
        and maber = knb5-maber.

    mansp = knb5-mansp.
    madat = knb5-madat.
    mahns = knb5-mahns.

endmethod.

HTML
<div class="subtitle">
    Mahndaten
</div>

<div style="padding:10px 10px 0px 10px">

    <div class="infoblock">
        <label class='label' name="madat@label"></label><br />
        <span class="output" name="madat"></span>
    </div>

    <div class="infoblock">
        <label class='label' name="mahns@label"></label><br />
        <span class="output" name="mahns"></span>
    </div>

    <div class="infoblock">
        <label class='label' name="mansp@label"></label><br />
        <span class="output" name="mansp@text"></span>
    </div>

</div>

 

In the build method, the company code and the dunning area are assumed to be fixed (configuration of the application). It would be even more variable to also define these as import parameters and to populate them outside the build routine from the configuration. Then it would look like this:

data:
     kunnr   type kunnr,
     bukrs   type bukrs,
     maber   type maber,

     mansp   type knb5-mansp,
     madat   type knb5-madat,
     mahns   type knb5-mahns.

methods:
  build_bukrs
   exporting
     bukrs type bukrs,

 build_maber
   exporting
     maber type maber,

 build_knb5_data
   importing
     kunnr type kunnr
     bukrs type bukrs
     maber type maber
   exporting
     mansp type knb5-mansp
     madat type knb5-madat
     mahns type knb5-mahns.

method build_bukrs.
  bukrs = config=>parameter( 'bukrs' ).
endmethod.

method build_maber.
  maber = config=>parameter( 'maber' ).
endmethod.

method build_knb5_data.

  clear: mansp, madat, mahns.

  data: knb5 type knb5.

 select single mansp madat mahns
   from knb5
      into corresponding fields of knb5
        where kunnr = kunnr
        and bukrs = bukrs
        and maber = maber.

    mansp = knb5-mansp.
    madat = knb5-madat.
    mahns = knb5-mahns.

endmethod.

If a build method has no import parameters, as in the case of "bukrs" and "maber", the build method is only called on the first access and then always takes the determined value.
It is also worth noting here that the HTML code

<span class="output" name="mansp@text"></span>

causes the following actions:

- The value of "mansp.text" is requested, i.e. the standard name of the dunning block.
- To do this, the value of the dunning block is determined
- This is done via the build method "build_knb5_data".
- First, the values of the import parameters "bukrs" and "maber" must be determined via their build methods.
- Now the dunning block can be read.
- Finally, the text for the dunning block is determined

Tips for writing build methods

• Work with build methods from the beginning, because you have many changes to the user interface, especially in early project phases, and the build methods give you flexibility. If you postpone the installation of the build method until a later project phase, you will have more work to do if changes are made during development and you will have to change more complex coding again later.
  
• Do not forget any field in the import parameters on which the output fields depend. It is best to go through the code critically to see if any attributes not mentioned in "importing" are still being used. Otherwise, old output values will remain despite a new user input.
  
• Reset the output fields with "Clear" at the beginning of the build method.
  
• Write the build methods in a particularly stable way, e.g. take into account that some import fields may be empty when the build method is called in a data collection. 
  
  
• Make sure that the import and export parameters have the same type as the corresponding attributes. Otherwise, the automatic call of the build method may abort or output values will be truncated.

Components: S10 Framework