Начиная с релиза ABAP 7.50 у нас появилась возможность создания не только AMDP процедур, но и AMDP функций. В зависимости от типа AMDP функции они могут быть вызваны:
Далее рассмотрим все варианты использования AMDP функций.
Начиная с ABAP 7.4 SP08 нам стал доступен специальный тип BAdI — AMDP BAdI, который позволяет заменить/расширить стандартную реализацию AMDP процедур реализованных SAP-ом или в Custom решениях. Основное предназначение AMDP BAdI — вызов процедур реализованных в реализации AMDP BAdI из других AMDP процедур в системе. Чтобы это стало возможным используется ключевое слово USING в определении AMDP процедуры:
|
1 2 3 4 5 6 7 |
METHOD some_amdp_method BY DATABASE PROCEDURE FOR HDB LANGUAGE SQLSCRIPT OPTIONS READ-ONLY USING amdp_badi_name=>amdp_method_name. CALL "AMDP_BADI_NAME=>AMDP_METHOD_NAME" (:some_parameters); ENDMETHOD. |
Особенности AMDP BAdI:
Далее реализуем свой AMDP BAdI, реализацию к нему по умолчанию через Fallback класс, а так же дополнительную Custom реализацию.
У оператора VALUE #( ) при формировании внутренних таблиц есть так называемая короткая форма:
|
1 2 3 4 5 6 7 8 |
VALUE dtype|#( [let_exp] [BASE itab] col1 = dobj11 ... ( col2 = dobj12 col3 = dobj13 ... ) ( col2 = dobj22 col3 = dobj23 ... ) ... col1 = dobj31 col2 = dobj32 ... ( col3 = dobj33 ... ) ( col3 = dobj43 ... ) ... ). |
Что соответствует следующему полному синтаксису:
|
1 2 3 4 5 6 7 8 |
VALUE dtype|#( [let_exp] [BASE itab] ( col1 = dobj11 ... col2 = dobj12 col3 = dobj13 ... ) ( col1 = dobj11 ... col2 = dobj22 col3 = dobj23 ... ) ... ( col1 = dobj31 col2 = dobj32 ... col3 = dobj33 ... ) ( col1 = dobj31 col2 = dobj32 ... col3 = dobj43 ... ) ... ). |
Таким образом мы можем не указывать все столбцы, если хотим их заполнить на основе столбцов вне внутренних скобок.
Удобно использовать для формирования диапазонов:
|
1 2 3 4 5 6 |
DATA lt_range TYPE RANGE OF i. lt_range = VALUE #( sign = 'I' option = 'BT' ( low = 1 high = 10 ) ( low = 21 high = 30 ) ( low = 41 high = 50 ) option = 'GE' ( low = 61 ) ). |
Все что указано за пределами внутренних скобок дублируется в следующие строки:
| SIGN | OPTION | LOW | HIGH |
| I | BT | 1 | 10 |
| I | BT | 21 | 30 |
| I | BT | 41 | 50 |
| I | GE | 61 | 0 |
Но данный синтаксис в случае вложенных конструкторных операторов может приводить к непредвиденным результатам.
|
1 2 3 4 5 |
DATA lt_range TYPE RANGE OF i. lt_range = VALUE #( ( low = 1 ) ( VALUE #( sign = 'I' option = 'EQ' low = 2 ) ) ( low = 3 ) ). |
Исходя из документации в третьей строке мы должны увидеть пустые значения sign и option, т.к. мы ничего не указывали за пределами внутренних скобок, однако они заполнены из второй строки:
| SIGN | OPTION | LOW | HIGH |
| 1 | 0 | ||
| I | EQ | 2 | 0 |
| I | EQ | 3 | 0 |
Описанное поведение судя по всему является багом, исправление будет под нотой: 3042453
Казалось бы, выборка единственной записи из таблицы довольно простая и логически понятная операция, однако все еще частой ошибкой находимой на code-review является следующее предупреждение Code Inspector’a:
Syntax check warning
In «SELECT SINGLE …», the WHERE condition for a key field does not test for equality or the FROM clause contains a join. This means the result is possibly not unique. Internal message code: MESSAGE GSB
Deactivatable using pragma ##WARN_OK. Message Code WRN 1305
Далее рассмотрим что это такое и почему это не нужно игнорировать.
Иногда бывает полезно посмотреть каталог ALV без погружения в код или в отладку. Cделать это можно для любого ALV зажав Shift и щёлкнув два раза правой кнопкой мыши на не занятом данными месте, пример:
Откроется сервисный инструмент (alv consistency check), где среди прочего есть каталог полей:
В полноэкранных ALV можно просто набрать команду &SOS.
Начиная с версии ABAP 7.40 мы можем считывать данные из таблиц через табличные выражения следующим образом:
|
1 2 3 4 5 |
TRY. ls_row = lt_itab[ id = lv_find_id ]. CATCH cx_sy_itab_line_not_found. " INTO DATA(lo_exception) " В случае отсутствия записи необходимо обработать исключение. ENDTRY. |
Однако такой вариант кроме того что является слишком длинным аналогом других, может оказывать существенное влияние на производительность в случае частого отсутствия записей, т.к. старт исключения довольно затратная операция. Альтернативные варианты могут быть следующими:
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 |
" Все эти варианты не требуют обработки исключений в блоке TRY..CATCH ls_row = VALUE #( lt_itab[ id = lv_find_id ] OPTIONAL ). " IF ls_row IS NOT INITIAL... ls_row = VALUE #( lt_itab[ id = lv_find_id ] DEFAULT ls_default ). DATA(lr_row) = REF #( lt_itab[ id = lv_find_id ] OPTIONAL ). " IF lr_row IS BOUND... ASSIGN lt_itab[ id = lv_find_id ] TO FIELD-SYMBOL(<ls_row>). " IF sy-subrc = 0... READ TABLE lt_itab INTO row WITH KEY id = lv_find_id. " IF sy-subrc = 0... " Если нужно проверить только наличие записи DATA(lv_idx) = line_index( lt_itab[ id = lv_find_id ] ). READ TABLE lt_itab WITH KEY id = lv_find_id TRANSPORTING NO FIELDS. " IF sy-subrc = 0... |
Сравнение на примере:
Уже несколько раз сталкивался с ситуацией когда разработчик пишет что-то вроде:
|
1 2 3 4 5 6 7 8 9 10 11 12 |
TYPES: BEGIN OF ts_some_type, a TYPE i, b TYPE i, END OF ts_some_type. DATA: lt_some_table TYPE SORTED TABLE OF ts_some_type WITH UNIQUE KEY a, b. lt_some_table = VALUE #( ( a = 1 b = 1 ) ( a = 1 b = 2 ) ). |
Данный код приведёт к исключению CX_SY_ITAB_DUPLICATE_KEY. Все потому, что при определении полей ключа разработчик указал запятую. Запятая в данном случае отделяет определение переменной lt_some_table от переменной b с типом C 🙂
Обнаружил для себя забавную особенность при работе с сообщениями.
Есть код:
|
1 2 |
START-OF-SELECTION. MESSAGE s000(ztest). |
Логично предположить что сообщение будет вида ‘S’ (Status), однако есть возможность внутри самого сообщения указать принудительно DISPLAY LIKE, переопределив тем самым отображаемый вид сообщения:
Более того, можно подставить & вместо типа сообщения и передавать его как параметр 🙂
Начиная с ABAP 7.4. нам стали доступны операторы конструкторы, такие как:
|
1 2 3 4 |
... NEW| VALUE| CONV| REDUCE| CAST| REF| EXACT| CORRESPONDING| COND| SWITCH | FILTER| type( ... ) ... |
Одной из особенностей данных операторов является возможность неявного определения типа через #, из-за чего у некоторых разработчиков часто возникают ошибки связанные с их использованием.
Далее рассмотрим типичные из них.
Рассмотрим простой пример:
|
1 2 3 4 5 6 7 |
DATA: lv_p TYPE p LENGTH 10 DECIMALS 5. TRY. lv_p = `7588408675670886700030`. CATCH cx_sy_conversion_overflow. ENDTRY. |
В данном случае у нас возникнет исключительная ситуация, т.к. среда не сможет целиком поместить указанное число в переменную типа p.
Как вы считаете что в данном случае будет с переменной lv_p? Очевидным ответом будет — ну раз произошло исключение, значит переменная осталась без изменений. В реальной же ситуации все несколько иначе.
Далее рассмотрим почему.