Класс CL_MESSAGE_HANDLER_MM

111

Необходимо в формулярах заказа на поставку выводить список сообщений об ошибках/замечаниях, возникших при обработке заказа (см. кнопку "Просмотр сообщений" в тр. ME22N при обработке заказов, имеющих ошибки).
Как понимаю, сохраняется все это хозяйство посредством SBAL_LOG.

При печати стандартных формуляров, настраиваемых через IMG и вызываемых стандартно из транзакции ME22N, нашел удобный класс CL_MESSAGE_HANDLER_MM, для получения списка этих сообщений:

Code:

  
DATA: l_msg_handler TYPE REF TO cl_message_handler_mm,
        l_event TYPE REF TO cl_event_mm,
        l_msg_txt     TYPE string,
        lt_event_list TYPE mmpur_event_list WITH HEADER LINE.

  CALL METHOD cl_message_handler_mm=>get_handler
    IMPORTING
      ex_handler = l_msg_handler.

  CALL METHOD l_msg_handler->getlist
*    EXPORTING
*      IM_EVENT_TYPE            =
*      IM_OBJECT                =
*      IM_NULL_OBJECT_VALID     = MMPUR_NO
*      IM_INCLUDE_CHILD_OBJECTS = mmpur_no
*      IM_SEQUENCE              =
     IMPORTING
       ex_events                = lt_event_list[]
*      EX_EVNT                  =
      .

  REFRESH gt_messages .
  LOOP AT lt_event_list .
    l_event = lt_event_list-event_obj .
    CALL METHOD l_event->to_string
       IMPORTING
         ex_string    = l_msg_txt
*          EX_SIGNATURE =
        .
    APPEND l_msg_txt TO gt_messages .
  ENDLOOP.

Все работает.
Но, здесь этот класс натравливается на нужный заказ на поставку сам, автоматом, в транзакции ME22N, и об этом даже не надо думать.
Но необходимо в другом, теперь уже кустомном, формуляре, печатаемом через отдельную транзакцию, организовать такую же беду. Хотелось бы сделать таким же макаром через тот же класс - но тут уже нужно самому устанавливать класс на нужный заказ на поставку.

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

Кто знает - подскажите, плз. Спасибо.

EGF

А почему Вы не хотите воспользоваться функциональными модулями, считывающими журнал приложения напрямую? По-моему, там всё гораздо прозрачней.

111

EGF написал(а):

А почему Вы не хотите воспользоваться функциональными модулями, считывающими журнал приложения напрямую? По-моему, там всё гораздо прозрачней.

Хочется сделать все по-правильному. В стандартных транзакциях работа происходит через этот класс.

T

Мне кажется, что в лог ничего не пишется (а если и пишется, то CL_MESSAGE_HANDLER_MM этого не знает). И для того, чтобы CL_MESSAGE_HANDLER_MM что-то мог показать или вернуть список, ему его кто-то должен передать.
Вот примерчик для CL_PO_HEADER_HANDLE_MM:

Code:

parameters: ebeln type ebeln.

data:
  my_handler     TYPE REF TO cl_message_handler_mm,
  l_messages     TYPE mepo_t_messages_bapi.

  CALL METHOD cl_message_handler_mm=>get_handler
    IMPORTING
      ex_handler = my_handler.
  CALL METHOD my_handler->set_config_for_mepo( ).
  CALL METHOD my_handler->remove_all( ).
  CALL METHOD my_handler->cleanup( ).

  DATA: l_mfs TYPE REF TO cl_mfs_mm.
  l_mfs = cl_mfs_mm=>get_instance( ).
  CALL METHOD l_mfs->register
    EXPORTING
      im_application     = 'MMPUR_PO_DOC'
    EXCEPTIONS
      already_registered = 0.

  DATA: l_po TYPE REF TO cl_po_header_handle_mm.
  CREATE OBJECT l_po.
  CALL METHOD l_po->po_initialize( ).
  CALL METHOD l_po->set_po_number
    EXPORTING im_po_number = ebeln.

  DATA: l_result TYPE mmpur_bool.
  CALL METHOD l_po->po_read
    EXPORTING
      im_tcode     = 'ME22N'
                   im_trtyp = 'V'
                   im_aktyp = 'V'
                   im_po_number = ebeln
    IMPORTING
      ex_result    = l_result.

  CALL METHOD l_po->po_check.

* В табличку
  l_messages = my_handler->get_list_for_bapi( ).

* На экран
  CALL METHOD my_handler->show( im_popup = 'X'
                                im_amodal = space ).

Но это всё эквивалентно заходу в ME22N и нажатию проверки. Соответственно, если кто-то его заблокировал, то получим сообщение о блокировке.

111

T написал:

Мне кажется, что в лог ничего не пишется (а если и пишется, то CL_MESSAGE_HANDLER_MM этого не знает).

Да, точно. Сейчас изучаю - вообще фиг поймешь. Сообщения и локально внутри BAPI могут храниться и никуда не писаться. И в то же время SBAL_LOG все же задействуется для чего-то.

T написал:

И для того, чтобы CL_MESSAGE_HANDLER_MM что-то мог показать или вернуть список, ему его кто-то должен передать.
Вот примерчик для CL_PO_HEADER_HANDLE_MM:

ОК, спасибо большое - кажись то, что нужно.

T

111 написал(а):

И в то же время SBAL_LOG все же задействуется для чего-то.

Для отображения. В методе SHOW зовётся ME_LOG_DIALOG, а внутри
BAL_LOG_CREATE и потом BAL_DSP_LOG_DISPLAY .

EGF

Честно говоря, не очень понятно, зачем городить огород с малознакомым недокументированным классом, практически наугад вызывая его методы и передавая туда такие же малознакомые и недокументированные классы, когда есть хорошо знакомые и отлично документированные функциональные модули:

Code:

CONSTANTS:
  gc_ebeln TYPE ebeln VALUE '4500002897'
.
DATA:
  g_txt_msg TYPE bapi_msg
.
DATA:
  gs_filter TYPE bal_s_lfil,
  gs_extn   TYPE bal_s_extn,
  gs_obj    TYPE bal_s_obj,
  gs_sub    TYPE bal_s_sub,
  gs_handle TYPE balmsghndl
.
DATA:
  gt_header TYPE balhdr_t,
  gt_handle TYPE bal_t_msgh
.
gs_extn-sign = 'I'.
gs_extn-option = 'EQ'.
gs_extn-low = gc_ebeln.
APPEND gs_extn TO gs_filter-extnumber.
gs_obj-sign = 'I'.
gs_obj-option = 'EQ'.
gs_obj-low = 'MMPUR'.
APPEND gs_obj TO gs_filter-object.
gs_sub-sign = 'I'.
gs_sub-option = 'EQ'.
gs_sub-low = 'BUS2012'.
APPEND gs_sub TO gs_filter-subobject.

CALL FUNCTION 'BAL_DB_SEARCH'
  EXPORTING
    i_s_log_filter     = gs_filter
  IMPORTING
    e_t_log_header     = gt_header
  EXCEPTIONS
    log_not_found      = 1
    no_filter_criteria = 2
    OTHERS             = 3.
CHECK sy-subrc = 0.

CALL FUNCTION 'BAL_DB_LOAD'
  EXPORTING
    i_t_log_header     = gt_header
  IMPORTING
    e_t_msg_handle     = gt_handle
  EXCEPTIONS
    no_logs_specified  = 1
    log_not_found      = 2
    log_already_loaded = 3
    OTHERS             = 4.
CHECK sy-subrc = 0.

LOOP AT gt_handle INTO gs_handle.
  CALL FUNCTION 'BAL_LOG_MSG_READ'
    EXPORTING
      i_s_msg_handle = gs_handle
    IMPORTING
      e_txt_msg      = g_txt_msg
    EXCEPTIONS
      log_not_found  = 1
      msg_not_found  = 2
      OTHERS         = 3.
  IF sy-subrc = 0.
    WRITE / g_txt_msg.
  ENDIF.
ENDLOOP.

Этот код выдаёт сообщения предварительно сохранённого заказа на поставку с номером gc_ebeln. Может, пригодится...

T

На счёт огорода присоединяюсь

Но поковырять этот CL_MESSAGE_HANDLER_MM было забавно :lol:

Кстати тот кусок кода про CL_PO_HEADER_HANDLE_MM выдран из BAPI_PO_CHANGE, если кому вдруг интересно. Только PO_CHECK дёрнул вне очереди, чтобы для любого заказа что-то вывелось, да и проверка полная пройдёт. И, понятное дело, SHOW в BAPI не зовётся.. Ну и лишнее там тоже есть (если требуется только вывести сообщения без новой проверки). Так что "огород" можно ужать до:

Code:

  CALL METHOD cl_message_handler_mm=>get_handler
    IMPORTING
      ex_handler = my_handler.
  CALL METHOD my_handler->set_config_for_mepo( ).

  DATA: l_po TYPE REF TO cl_po_header_handle_mm.
  CREATE OBJECT l_po.
  CALL METHOD l_po->po_initialize( ).

  DATA: l_result TYPE mmpur_bool.
  CALL METHOD l_po->po_read
    EXPORTING
      im_tcode     = 'ME22N'
                   im_trtyp = 'V'
                   im_aktyp = 'V'
                   im_po_number = ebeln
    IMPORTING
      ex_result    = l_result.

* На экран
  CALL METHOD my_handler->show( im_popup = 'X'
                                im_amodal = space ).

Но раз уж из журнала всё нормально читается, то это всё и впрямь на фиг не надо ..

111

А теперь похожая задача, но теперь нужен журнал для входящей фактуры логистики.
Что-то не получается найти ни BAPI подходящих, ни классов :-(

.

ФМ из ГФ MRM_BAPI (BAPI_INCOMINGINVOICE_CREATE, BAPI_INCOMINGINVOICE_PARK) не производят требуемых проверок :-(

. Собственно, ковыряюсь в чужой проге - там сделано предварительное сохранение с помощью этих ФМ, а уже полное сохранение (при котором происходят требуемые проверки), сделано с помощью BDC (тр. MIR4).

Чтение логов SBAL после выполнения этого BDC тоже ничего не дает :-(

.

Code:

      CONCATENATE l_invoicedocnumber '/' l_gjahr INTO header-extnumber
        SEPARATED BY space .
      ls_header-object    = 'RMRB' .
      ls_header-subobject = 'RMRB_BTCH' .
      ls_header-aldate    = sy-datum .
      ls_header-aluser    = sy-uname .
      ls_header-altcode   = 'MIR4' .
      ls_header-alprog    = 'SAPLMR1M' .

      APPEND ls_header TO lt_header .
      CALL FUNCTION 'BAL_DB_LOAD'
       EXPORTING
         i_t_log_header                      = lt_header
*         I_T_LOG_HANDLE                      =
*         I_T_LOGNUMBER                       =
*         I_CLIENT                            = SY-MANDT
*         I_DO_NOT_LOAD_MESSAGES              = ' '
*         I_EXCEPTION_IF_ALREADY_LOADED       =
       IMPORTING
         e_t_log_handle                      = lt_log_handles
*         E_T_MSG_HANDLE                      =
       EXCEPTIONS
         no_logs_specified                   = 1
         log_not_found                       = 2
         log_already_loaded                  = 3
         OTHERS                              = 4
                .

Лог возвращается пустой . Такое ощущение, что он живет только во время выполнения MIR4 .
Чего-то лыжи совсем не едут :-(

.

RoadRunner

Там, кроме класса CL_MESSAGE_HANDLER_MM, исппользуетс еще класс CL_MESSAGE_MM, у к-рого есть методы по добавлению и редактированию сообщений. Я этот вопрос уже поднимал здесь, но мне никто даже не сделал попытки ответить...

111

RoadRunner написал:

Там, кроме класса CL_MESSAGE_HANDLER_MM, исппользуетс еще класс CL_MESSAGE_MM, у к-рого есть методы по добавлению и редактированию сообщений.

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

RoadRunner

Жаль, не записал - не думал, что пригодится - был там какой-то ф.модуль или класс, к-рый позволяет получить указатель на бизнесс-объект, для которого нам надо получить список сообщений. Ковырял под отладкой в МЕ22N. Но не доковырял и сдался...

RoadRunner

111 написал(а):

...мне нужно получить весь массив созданных при проверке документа сообщений.

Проблема возникла с добавлением сообщений к логу. В BAdI для РО и в экзите для МИГО выдается обычной командой MESSAGE предупреждающее сообщение, но система его не только не показывает, но и не пишет в журнал. Как добавить к журналу сообщение с типом W?

EGF

Используйте метод BAdi CHECK.

RoadRunner

Разве PROCESS_ITEM для этого не подходит? Очень удобно выдать сообщение по текущей позиции, с к-рой в данный момент работает усер.
Кроме того, есть определенное ограничение: по тому заданию, что мне дали, эта проверка должна выдавать либо предупреждающее, либо запрещающее сообщение, а проверку нужно делать не для всех позиций, а для тех, к-рые были изменены. Иначе, если пользователь попытается сохранить заказ со "старыми" позициями, созданными до этой проверки, то он не сможет этого сделать.

Правила форума

Класс CL_MESSAGE_HANDLER_MM

Кто сейчас на конференции