Abap quick options

The main purpose of the library is to avoid magic numbers and other "permanent data" from the code. And give the ability to change the "constants" in friendly interface.

Accounts by specific mask, texts in generated FI documents or ranges of BKPF-BLART fields in selection screens are good examples of options to maintain.

The maintainable data usually stored in a class attributes (or in a program structure) and can contain data such as:

• ranges (SELECT-OPTION)
• parameters (any simple value as dates, time or BUKRS)
• strings (memo texts)
• any tables (STANDARD, SORTED, HASHED structure based tables)

The first 2 are very similar to STVARV, in strings you can store message templates, and tables are suitable when you need to write a large CASE that depends on a condition that can change, but creating a database table is burdensome.

The best way to describe the library, it is something like tr. STVARV but all parameters and select-options are grouped together as in tr. SLG1. (Package name = OBJECT ID)

Class based options

To create an option based on class attributes, just press F8 in a DEV system.

The description of the fields is similar to the description of the program structure based options except that attributes must be PUBLIC and READ-ONLY.

Since READ-ONLY attributes cannot be changed outside the class you need to add ZCL_AQO_OPTION to the class friends.

*If you forget to do this, a special reminder will be shown at runtime

It is advisable to initialize class attributes once in CONSTRUCTOR or in CLASS-CONSTRUCTOR

  " Create an option (in DEV) OR read new values
  TRY.
      zcl_aqo_option=>create(
        iv_package_id = '$TMP'                " Package    "#EC NOTEXT
        iv_option_id  = 'Class options'(op1)  " Any text < 30 symbols
        " All public read-only attributes is options!  CLASS-DATA or DATA (but not both)
        io_data       = me
      ).
    CATCH zcx_aqo_exception INTO lo_error.
      MESSAGE lo_error TYPE 'S' DISPLAY LIKE 'E'.
      RETURN.
  ENDTRY.

After that, the attributes of ME->* will contain the data that the developer or consultant could change in one of the maintenance programs

After that the attributes data could be edited in tr. ZAQO_EDITOR_OLD.

To make the a long story short the available functionality is listed below:

• The option data is stored in the special table. You can put an option to a request (except of those in ‘$TMP’ package)  & delete it. Export data from PROD to a file & then import it in DEV only.

• Edit some fields in a productive system. Though complex tables is better to transport via request. Simple fields like checkboxes & parameters could be made editable (But then is advisable to export it to DEV again)

1 option can contain several fields

• View changing logs for each filed separately (by default 5 previous versions are stored in DB)

• Store an option in a local structures. But even though I prefer to create a separate local class instead.

Fields’ types:

№1 PARAMETERS
№2 SELECT-OPTIONS
№3 TABLES
№4 STRINGS

• Tables can contain string fields (alternative for SO10), ranges & nested tables (Is an alternative for cluster maintenance SM34). Imho is better to have one internal table instead of several DB tables with parent-key relationships

• You can change table type (sorted to hashed) & edit field catalog for it. For example assign search help or change field’s title. For domain based fields combo boxes will be displayed

• Find an option via SH or code scanner

• Check an option before saving by user

• Edit an option in new UI5 interface. Though in projects I worked on tr. ZAQO_BSP_EDITOR & tr. ZAQO_EDITOR were very unpopular. That’s why all new features are added exclusively for tr ZAQO_EDITOR_OLD

A small practical usage of AQO.

Probably storing tables with nested tables & ranges sounds very bizarre & artificial. But in technical specification like that

Instead of code like that

Personally I prefer approach to create an internal table with FIELD_NAME (NH, OT …)  & range filed T_LGART[]. And T_LGART store range data (1308, 1304 … ) that could be changed later by consultant.

Creating several related DB tables with table generators, creating transactions, grouping them in a SPRO branch  & reading values from these tables in ABAP code are very burdensome for me.

PS

The entire library just helps to automate this tiresome day to day process of creating small option tables.

github project & documentation