SAPфорум.RU
https://sapboard.ru/forum/

Листинг в качестве журнала. Как сохранить SPOOL в случае прерывания программы.
https://sapboard.ru/forum/viewtopic.php?f=13&t=96803		 Страница 1 из 1
Автор:  Parazit [ Чт, сен 06 2018, 20:48 ]
Заголовок сообщения:  Листинг в качестве журнала. Как сохранить SPOOL в случае прерывания программы.
Часто пользуюсь Write для протоколирования операций в своих утилитах. Как говорится - дёшево и сердито.
Одно плохо, если программа неожиданно закончилась, выпала в дамп или соединение пропало, то и журнал пропадёт.
За сим нашёл решение, всегда пишем в Spool и периодически Commit-им:

Code:
Report ZLOG_WRITE.

Tables:
  UST04.

Parameters:
  Dump as checkbox.

Start-of-Selection.

  Data:
    lv_Cursor       type Cursor,
    A               type F,
    ls_Print_Params type PRI_PARAMS,
    lv_Valid        type C length 1.

  Perform Log_Init.

  Open cursor with hold lv_Cursor for
    select *
      from UST04.

  Do.
    Fetch next cursor lv_Cursor
      into Ust04.
    If sy-subrc <> 0 or
       sy-dbcnt > 10.
      EXIT."Do
    EndIf.

    Write: / sy-dbcnt, Ust04-BName.

    Case sy-dbcnt.

      when 7.
        If Dump = 'X'.
          A = 1 / 0."Дамп
        EndIf.

      when others.
        Perform Log_Commit.

    EndCase.

  EndDo.

  Close cursor lv_Cursor.

  Perform Log_Close.

  Perform Log_Show using sy-spono.

******************************************
Form Log_Init.
  Call function 'GET_PRINT_PARAMETERS'
    exporting
      No_Dialog      = 'X'
    importing
      Out_Parameters = ls_Print_Params
      Valid          = lv_Valid
    exceptions
      others         = 99.

  If lv_Valid is initial or sy-subrc <> 0.
    Leave program.
  EndIf.

  ls_Print_Params-Prnew = 'X'.
  New-Page
    print on
    new-section
    parameters ls_Print_Params
    no-title
    no-heading
    no dialog.
  Write /.
EndForm.

Form Log_Commit.
  New-Page
    print off
    no-title
    no-heading
    no-topofpage.

  ls_Print_Params-Prnew = ''.

  New-Page
    print on
    parameters ls_Print_Params
    no-title
    no-heading
    no dialog.

  Call function 'DB_COMMIT'.


EndForm.

Form Log_Close.
  New-Page
    print off
    no-title
    no-heading
    no-topofpage.
  Call function 'DB_COMMIT'.
EndForm.

Form Log_Show using iv_Id.
  Data:
    lv_Spid     type TSP01-RQIDENT.

  lv_Spid = iv_Id.

  Call function 'RSPO_DISPLAY_SPOOLJOB'
    exporting
      Rqident = lv_Spid.
EndForm.


tags:
List, Write, Spool, Log.
Автор:  Kengur [ Пт, сен 07 2018, 09:30 ]
Заголовок сообщения:  Re: Листинг в качестве журнала.
А почему именно DB_COMMIT?
Автор:  Besa [ Пт, сен 07 2018, 09:55 ]
Заголовок сообщения:  Re: Листинг в качестве журнала.
Не уловил фишки :) Подскажи, если можно коммитить почему не использовать стандартный лог SLG?
Автор:  Kengur [ Пт, сен 07 2018, 10:03 ]
Заголовок сообщения:  Re: Листинг в качестве журнала.
Besa написал:
Не уловил фишки :) Подскажи, если можно коммитить почему не использовать стандартный лог SLG?

Я человек простой - дебажу через write :shumlol:
Автор:  Parazit [ Пт, сен 07 2018, 10:45 ]
Заголовок сообщения:  Re: Листинг в качестве журнала.
Kengur написал(а):
А почему именно DB_COMMIT?

Это "мягкий" Commit, он выполняется только на уровне БД, его можно вызывать даже внутри Select (в конструкции Open cursor with hold ... ).
Автор:  Parazit [ Пт, сен 07 2018, 11:26 ]
Заголовок сообщения:  Re: Листинг в качестве журнала.
Besa написал:
Не уловил фишки :) Подскажи, если можно коммитить почему не использовать стандартный лог SLG?

Стандартный SLG слишком громоздкий. Его я конечно использую, но в относительно серьёзных разработках, предназначенных для конечного пользователя.
А в утилитах (для себя), например, импорта-экспорта большого количества файлов с компьютера, мне достаточно простого протокола из одного Write с именем очередного загруженного файла. Чтобы, просто заглянув в Spool, знать, с какого файла продолжить загрузку, если вдруг сессия отвалилась. Городить огород в SLG не имеет смысла, и просто лень. :) А спул не требует много ресурсов, не оставляет мусора (отомрёт сам по себе), не требует дополнительных настроек и создания объектов разработки. Простое решение для специфических, простых и временных задач.
Единственное, что меня не устраивало - листинг не сохранялся при критическом прерывании программы. Кстати, в SLG с этим тоже шаманить приходилось, насколько помню. А из select-а не пробовал, может и не получится.

В общем ещё один способ протоколирования. Что использовать - каждый сам для себя решает.
Автор:  Kengur [ Пт, сен 07 2018, 12:28 ]
Заголовок сообщения:  Re: Листинг в качестве журнала.
Parazit написал:
Kengur написал(а):
А почему именно DB_COMMIT?

Это "мягкий" Commit, он выполняется только на уровне БД, его можно вызывать даже внутри Select (в конструкции Open cursor with hold ... ).

И чего? Если ты до этого написал где то update то он ляжет в базу. Я так понимаю не работают только апдейт модули?
Автор:  LKU [ Пт, сен 07 2018, 12:51 ]
Заголовок сообщения:  Re: Листинг в качестве журнала.
В утилитах можно так поступить: пишем подпрограмму вывода сообщения, в которой ветвим логику: если режим диалоговой - используем write, если фоновый - message.
Итого в фоновом режиме сообщения будут собираться в журнал фонового задания.

По сравнению со спулом поудобнее будет:
1. Насколько помню, спул доступен в sm37 только после отработки фонового задания, а сообщения в журнале появляются в процессе работы.
2. В журнале sm37 сообщения привязаны к моменту времени в отличие от спула, т.е. удобно трейсить производительность, деля программку на логические шаги с выводом сообщения по итогам каждого из них.
Автор:  Parazit [ Пт, сен 07 2018, 14:00 ]
Заголовок сообщения:  Re: Листинг в качестве журнала.
Kengur написал(а):
Parazit написал:
Это "мягкий" Commit, он выполняется только на уровне БД, его можно вызывать даже внутри Select (в конструкции Open cursor with hold ... ).

И чего? Если ты до этого написал где то update то он ляжет в базу. Я так понимаю не работают только апдейт модули?

Мне нужен был commit по логике программы, и я его написал, и сделал его мягким, чтобы была возможность получать неубиваемые логи даже изнутри select-а. Любой другой commit, явный или неявный, в этом случае вывалил бы дамп.
Об особенностях "Open cursor with hold" (в т.ч. DB_COMMIT) подробно написано в стандартном хелпе.
Автор:  Parazit [ Пт, сен 07 2018, 14:51 ]
Заголовок сообщения:  Re: Листинг в качестве журнала.
LKU написал:
В утилитах можно так поступить: пишем подпрограмму вывода сообщения, в которой ветвим логику: если режим диалоговой - используем write, если фоновый - message.
Итого в фоновом режиме сообщения будут собираться в журнал фонового задания.

По сравнению со спулом поудобнее будет:
1. Насколько помню, спул доступен в sm37 только после отработки фонового задания, а сообщения в журнале появляются в процессе работы.
2. В журнале sm37 сообщения привязаны к моменту времени в отличие от спула, т.е. удобно трейсить производительность, деля программку на логические шаги с выводом сообщения по итогам каждого из них.

Проблема была как раз с Write в диалоге, нужно было как-то делать промежуточное сохранение спула на случай внезапной смерти программы. Что я и сделал.

Возможность выбора удобства тоже удобство! :)
В моём конкретном случае утилита работает в диалоге и в фоне, причём иногда одновременно, поэтому для меня удобней, чтобы все логи были в одном месте.
Автор:  pberezin [ Чт, сен 13 2018, 10:14 ]
Заголовок сообщения:  Re: Листинг в качестве журнала.
а чем не устраивает ASSERT, LOG-POINT и логи транзакции SAAB ?

для логирования технических (отладочных) helloworld-ов - самое оно. Отключил, не логирует (не садит производительность программы лишними коммитами), включил, логирует.
Автор:  Parazit [ Чт, сен 13 2018, 14:28 ]
Заголовок сообщения:  Re: Листинг в качестве журнала.
pberezin написал:
а чем не устраивает ASSERT, LOG-POINT и логи транзакции SAAB ?

для логирования технических (отладочных) helloworld-ов - самое оно. Отключил, не логирует (не садит производительность программы лишними коммитами), включил, логирует.

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

Тему создал для того, чтобы описать приём, как делать промежуточное сохранение списка. В первую очередь для себя, т.к. дожил до того, что иногда на некоторые вопросы стал находить в интернете свои же ответы :shock: , написанные много лет назад. Склероз! :D
Ну, может и ещё кому-то пригодится.
Автор:  LKU [ Чт, сен 13 2018, 17:22 ]
Заголовок сообщения:  Re: Листинг в качестве журнала.
Parazit написал:
Тему создал для того, чтобы описать приём, как делать промежуточное сохранение списка.


Кстати, на эту тему есть еще Secondary Database Connections.
В отличие от мягкого DB_COMMIT точно ничего лишнего в БД не запишет.

Вот здесь обсуждали:
viewtopic.php?f=13&t=91536
8051core написал(а):
Если посмотреть код BAL_DB_SAVE, то он как раз через Secondary Database Connections и работает.
Автор:  Parazit [ Чт, сен 13 2018, 21:49 ]
Заголовок сообщения:  Re: Листинг в качестве журнала.
LKU написал:
Кстати, на эту тему есть еще Secondary Database Connections.
В отличие от мягкого DB_COMMIT точно ничего лишнего в БД не запишет.
Да, Connection хорошая тема для развязки по коммитам. Если есть своя таблица и остальной сервис (просмотр, удаление, автоматическая чистка по срокам и т.д.).

8051core написал(а):
Если посмотреть код BAL_DB_SAVE, то он как раз через Secondary Database Connections и работает.
В старых версиях SAP таки нет Connection, то есть решение не универсальное, а жаль.
Страница 1 из 1 Часовой пояс: UTC + 3 часа
Powered by phpBB © 2000, 2002, 2005, 2007 phpBB Group
http://www.phpbb.com/