How to Implement an Automatic Change Log BAdI

Especially if you are working with sensitive data, it is crucial to track the latest changes. Such process creates responsibility and helps to avoid business risk due to error or negligence. In the "How to track changes with NextTables" article, you learned the basics of the change log process. In this article you will receive step by step guidance through the technical side of implementation.

At the end of this article, you will be able to lock the change log fields and fill them automatically. You can see an example below.

Automatic change log

Necessary Steps

In order to achieve the desired result, we have to change the setting EDITABLE of the fields Changed on and Changed by to locked. In order to ensure it, we will set this setting in the META method of the /NLY/BADI_EDITOR BAdI.

Implementing class

Furthermore, we have to derive and fill these fields in the I_STEP 1 of the UPDATE method.

Technical implementation

In the How to implement a BAdI for NextTables article you have learned how to create a BAdI implementation. To make sure that the BAdI is executed for a certain table only, you have to setup the filter criteria accordingly. Please enter respective table name and table type. In our example we use the DSO ZOMACOST.

Filter values

The logic itself is implemented in the implementing class. First, we will utilize the method /NLY/IF_EDITOR~SET_META_EXIT to change the field editability settings. Double click on the method to create an implementation.

Implementing Class

In our example, we use the fields ZCUSER and ZCDATE to store the Changed by and Changed on information. In order to prevent manual changes, we have to set editability of those fields to locked using the following code.

METHOD /nly/if_editor~set_meta_exit.
    DATA: l_s_fields_info TYPE /nly/ts_fields_info.
    FIELD-SYMBOLS:  <l_s_fields_info> TYPE /nly/ts_fields_info.

* Change properties 
    LOOP AT ch_t_fields_info ASSIGNING <l_s_fields_info>.

      CASE <l_s_fields_info>-fname.
          <l_s_fields_info>-editable = '1'.


After activation, user cannot edit these fields via front end.

Fields not editable

After we have ensured that the fields are not editable, we will fill them automatically. In our example we use system parameters sy-uname, which contains the active user, and sy-datum, which represents the current date. Please create an implementation of the Update method /NLY/IF_EDITOR~SET_UPDATE_EXIT with the following code.

METHOD /nly/if_editor~set_update_exit.

      <fs_t_table> TYPE ANY TABLE,
      <ls_table>   TYPE /bic/azomacost2. "Table structure

    CHECK co_table IS BOUND.
    ASSIGN co_table->* TO <fs_t_table>.

    CASE i_type.

      WHEN /nly/cl_table_rest_v3=>co_type_validate.

        CASE i_step.

          WHEN /nly/cl_table_rest_v3=>co_step_before_update.
          WHEN /nly/cl_table_rest_v3=>co_step_after_update.


      WHEN /nly/cl_table_rest_v3=>co_type_update

        OR /nly/cl_table_rest_v3=>co_type_insert
        OR /nly/cl_table_rest_v3=>co_type_delete.

        CASE i_step.

          WHEN /nly/cl_table_rest_v3=>co_step_before_update.

            LOOP AT <fs_t_table> ASSIGNING <ls_table>.
              <ls_table>-/bic/zcuser = sy-uname.
              <ls_table>-/bic/zcdate = sy-datum.

          WHEN /nly/cl_table_rest_v3=>co_step_after_update.

Now, as you change the values, the fields Changed by and Changed on are updated automatically.

Fields automatically updated

As you implement your custom logic, please make sure that all involved pieces are activated, not only the implementing class. You need to activate the following objects:

  • implementing class together with methods
  • BAdI implementation
  • Enhancement implementation

Technical Tutorials