Table Maintenance - Update Method Explained

In this article you will learn everything about the SET_UPDATE_EXIT method of the /NLY/BADI_EDITOR BAdI used for table maintenance. You will understand the sequence of validation steps and recieve guidance for your BAdI implementation.

Method SET_UPDATE_EXIT explained

Using the UPDATE method, you can populate new fields and enhance data entered by user. One example could be the derivation of fields Last changed on and Last changed by to track changes automatically.

Your custom logic can be implemented in the BAdI via interface /NLY/IF_BADI_EDITOR using the method /NLY/IF_EDITOR~SET_UPDATE_EXIT.

User Actions

When data is entered in the table via clipboard, new manual entry or edit of the existing value, different events are triggered. Parameter I_TYPE is filled with the following values, depending on the type of data modification:

• update
• insert
• delete
• validate
• default

They are represented by the following constants:

• /nly/cl_table_rest_v3=>co_type_default - when inserting a new or copying one or multiple existent rows
• /nly/cl_table_rest_v3=>co_type_update - when updating existing records in the table
• /nly/cl_table_rest_v3=>co_type_insert - when inserting new records to the table (via Insert Row or Import dialog)
• /nly/cl_table_rest_v3=>co_type_delete - when deleting existing records in the table

• /nly/cl_table_rest_v3=>co_type_validate - when data is updated, inserted or deleted a validation is triggered.

Default

The default process is triggered every time a new row is created and if one or multiple existing rows are copied. It is processed before the input dialog opens, which means it can not react on any input in the dialog. However it can perform calculations, determine or check data and prefill the fields of the dialog. 

Currently there is no difference for the default between the before and after update i_steps. 

Validation

Validation process is triggered every time when data is updated, inserted or deleted. Depending on the respective step, you can implement your own logic here. For example, in step 1 you could auto-correct or transform certain values. In step 2 you can add additional entries in the validation, such as conditional values for two fields, where both of the fields have to be filled. In this step you could also add or remove standard validation messages.

Regardless of custom validation logic, standard validation is always executed. Standard validations include checks if mandatory fields are filled, checks if key already exist and also checks if values are valid in the InfoObject. In the chart below you can find an overview of respective validation checks.

The ideal time to execute custom validations is after the standard validations were executed. There, you can utilize the following message types which result in different system behaviour:

• /nly/cl_table_rest_v3=>co_msg_type_warning - data can be saved to the database. User gets a message informing him about the issue 

• /nly/cl_table_rest_v3=>co_msg_type_error - data is not saved to the database. Log is generated for user to download, check and correct the data input.

During custom validation you can also differentiate which kind of operation (insert, update or delete) triggered the validation. You can read the respective value from the I_TYPE_VAL parameter and act accordingly in your custom validation logic.

Steps

Each event (validate, insert, update or delete) is executed in two steps: I_STEP 1 and I_STEP 2.

Those are represented by the following constants:

• /nly/cl_table_rest_v3=>co_step_before_update - during this step you are able to correct or enhance data entered by the user before any standard validation or update logic is executed.
  
• /nly/cl_table_rest_v3=>co_step_after_update - during this step you can work with the data after the standard validation or update logic was executed. During the validation it can be used to add additional validation checks or remove standard validation messages, which should not be shown to the user. After update to database you can use this step to start a process chain which utilizes the updated data.
  

Please be aware, that both steps are executed during the Validate event and then again during Insert/Update/Delete events. Please refer to the following chart for an overview of the event types and steps.

Overview of Event Types and Steps

After a user executes an insert, update or delete action the validation process kicks in. In I_STEP 1 (co_step_before_update) you can autocorrect or transform certain values. Afterwards, the standard validation checks are executed. After standard validations you could add additional checks or modify validation messages in I_STEP 2 (co_step_after_update). After the validation process the results are presented to the user, who also has the possibility to accept or decline automatic corrections.

After the validation process, you can execute custom logic before the actual database update. In I_STEP 1 (co_step_before_update) you could enhance data introduced by the user and fill additional fields with a change log. Afterwards, the actual insert, update or delete action is executed and the database is updated. After the actual data base update, in I_STEP 2 (co_step_before_update), you could implement customer logic to start a process chain, which utilizes the updated data. Finally, the user will receive a message of update success or failure.

Overview of all parameters

In the table below you can find an overview of all parameters and possible values.

CT_VALIDATION Explained

I_S_IMPORT_SETTINGS Explained

BAdI Structure

You can use the following code snippet as orientation while implementing your own logic. In the "How to implement an automatic change log BAdI" article you can find a practical application of this method.

    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.

        ENDCASE.

        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.

          WHEN /nly/cl_table_rest_v3=>co_step_after_update.

        ENDCASE.

ENDCASE.

Which License is needed for this feature Professional ✘ | Enterprise ✔