Transport BADI

Список:
CTS_EXPORT_FEEDBACK -> feedback after export of a transport request.
CTS_IMPORT_FEEDBACK -> feedback after import of a transport request.
CTS_INT_REQUEST_CHCK -> internal: request checks.
CTS_REQUEST_CHECK -> request checks.
CTS_TASKDOC_TEMPLATE -> determine template for the task documentation.

Пример:
https://blogs.sap.com/2013/09/19/how-to-trigger-atc-or-code-inspector-checks-during-the-release-of-a-transport-task/
https://wiki.scn.sap.com/wiki/display/Snippets/Email+Feedback+for+Transports

Идеи:
CTS_REQUEST_CHECK-CHECK_BEFORE_CREATION – можно сделать проверку name convention для транспортов

CTS_REQUEST_CHECK-CHECK_BEFORE_RELEASE – перед релизом проверить в что там нет пакетов и DTP или что параметры в пакете и DTP идентичны параметрам в продуктивной системе

CTS_REQUEST_CHECK-CHECK_BEFORE_RELEASE_SLIN – можно натравить проверку по name convention из SLIN’a для проверки ABAP’a

CTS_REQUEST_CHECK-CHECK_BEFORE_CHANGING_OWNER – можно настроить уведомление владельца о этом действии

CTS_INT_REQUEST_CHCK- CHECK_BEFORE_RELEASE – не совсем понял чем он отличается от CTS_REQUEST_CHECK-CHECK_BEFORE_RELEASE

CTS_EXPORT_FEEDBACK или CTS_IMPORT_FEEDBACK
- тут можно устроить проверку на момент загрузки данных и переноса… чтобы не мудрить, проверка на активные цепочки
- ну и уведомление BW группы в случае переноса в продуктив , cебе же спокойней будет
- кстати и запрет на перенос в продуктив тоже настроить можно попробовать

Compaund & Reference удивляет

Как то я ранее говорил, не люблю я компаунды, т.к. проблемки при их использовании нет да и вылазят в самый неподходящий момент. В общем с моей точки зрения, это такое необходимое зло, без которого ты не можешь обойтись...

Но тут на днях компаунд меня порадовал...
Необходимо было сделать 2а ссылочных признака и добавить атрибутами в один признак... Добавляя 2й ссылочный признак, меня настигает осознание ...твою же ж м... что компаунд характеристика не будет добалена 2й раз - что по условием задачи, не хорошо.

Т.е. надо делать 2й признак компаунд, забыть о ссылочных. Да, признак не большой и прогружать его надо раз в год, но сам подход разочаровывает...

Но, зайдя в ссылочную характеристику на изменение, я вдруг обнажил что я могу поменять компаунд характеристику. И создав ссылочный признак на компаунд, я его заменил.

Примеры:

P.s. Cистема следит чтобы reference не поменялся... т.е. подменить на аналогичный по типу данных объект не получится. Это логично, но было интересно проверить.

За TYPES ляю

Как то понадобилось включить тип в тип... и затупил...
В общем оставил чтобы не вспоминать ещё раз.

   TYPES:
      BEGIN OF tt_data,
        GUID TYPE ZGUID.
        INCLUDE TYPE ZBWXXXXX.
    TYPES:
      END OF tt_data.

  TYPES:
    BEGIN OF tt_result.
     INCLUDE TYPE ZBWXXXXX.
  TYPES:
     GUID TYPE ZGUID,
    END OF tt_result.

data: it_ekpo TYPE STANDARD TABLE OF EKKO INITIAL SIZE 0

lt_tab    TYPE TABLE OF abap_compname WITH EMPTY KEY,
lt_tab = VALUE #( ( 'MANDT' )
                  ( 'FIELD1' )
                  ( 'FIELD2' )
                  ( 'FIELD3' )
                  ( 'FIELD4' )
                  ( 'FIELD5' ) ).

SELECT (lt_tab)
        FROM MKPF.



 TYPES:
    BEGIN OF ty_tab,
      field1 TYPE MKPF-field1,
      field2 TYPE MKPF-field2,
      field3 TYPE MKPF-field3,
      field4 TYPE MKPF-field4,
      field5 TYPE MKPF-field5,
    END OF ty_tab.

    lt_tab      TYPE SORTED TABLE OF ty_tab,
    lo_descr    TYPE REF TO cl_abap_structdescr,
    lt_details  TYPE abap_compdescr_tab WITH HEADER LINE,

    "Get the field list of the structure TY_TAB.
    lo_descr ?= cl_abap_typedescr=>describe_by_name('TY_TAB').
    lt_details[] = lo_descr->components[].

    SELECT (lt_details-name)
      FROM MKPF.