Есть нетленка, в ней РегламентноеЗадание.
Выполняется на сервере, ессно...
Как бедному юзеру узнать, что задание выполнено успешно, а лучше - увидеть детальный отчет ( N строк загружено, Z строк выгружено).
Вариантов реализации несколько:
1. Штатный ЖР, поле Комментарий
2. Справочник
3. РС
4. Что-то ещё

Мысли какие: нетленка небольшая, "раздувать" паразитными метаданными не хочется, задание будет выполнять 1 раз в 15/20 минут.
М.б. ЖР хватит?

Кто решал подобные задачи, нужно ваше мнение, КАК правильнее?

Упсс. как странно список отформатировался

независимый РС с периодической чисткой

при построчной записи РС уступает справочнику по скорости?...

Все протоколы обычно веду в текстовых файлах на сервере.
Принципиально.
Но необходимости читать их юзеру обычно нет.
Можно читать серверной функцией. Последний протокол для удобства можно писать в отдельный файл.

отдельная скл база ))

блин несколько записей в регистр в течение часа - и вы спорите что быстрее?

(0) в одном периодическом РС - статус, в другом - лог. Еще лог можно хранилть в журнале регистрации, где ему, к слову, самое место, но получать его от туда зело хлопотно

(5) Верочная тема, если есть регулярная необходимость в разухабистом анализе лога.
Когда возникала разовая необходимость - грузил текстовый протокол в сиквел и там анализировал.

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

Эту парадигму я практикую с дветыщи какого-то десятого, что ли. Доставляет.

(4) Юзер как бы НЕ читает, он МОНИТОРИТ.
Как ему, бедному, знать: отработало задание на сервере?
живо ли оно  вааще?

(5), (8) Из пушки по воробьям. Мне не нужно ХРАНЕНИЕ лога, задача - мониторинг активности задания.
Если задание не стартует или завершается с ошибкой - "кричать" вверх по инстанции

(7) и грузить ЖР своими записями ресурсоемко (по большому счёту)

(6) Уже делаю ;)
Следующий вопрос : Приодический РС или нет?

(10) ага, вот в ЖР эти записи будут весить типа намного больше, чем в твоем логе? Лежать-то и то, и другое будет на том же сервере и хранить тебе это и так, и эдак.

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

(10) периодический зачем? чтобы хранить еще одно физическую таблицу?

(11) В этой ИБ ЖР вообще вести не собирался. не нужет он.

(12) думаю...
Уговорил, пусть будет Непериодический ;)

(12) только КАК его чистить? он же Непериодический?...

(14) реквизит/измерение дата события

Есть у меня такая база.
РС периодический в пределах секунды.
В измерение кроме ссылок на объекты добавлено числовое поле ОчередностьСобытия - на случай, если в одну секунду происходит более одного события.

(3) уступает

А как в регистре сведений хранить лог. Расскажите, ато я не понимаю.

(4) как часто закрываешь файл, что бы сохранился лог при вылете или исключении регламентного задания?

Регистр с отправкой уведомлений почтой в случае отвала регзадания

(20) В некоторых особо важных случаях рекомендую отправлять уведомление о выполнении задания. Если письма нет, то основание для разбора ситуации.
+ СМС

(14) а не надо его чистить. надо определить параметр - период хранения лога и апдейтить устаревшие записи...

(14) этот вопрос лучше обдумать тогда, когда возникнет такая необходимость

(18) так чтобы готично - см. http://infostart.ru/public/19711/

В моем _конкретном_ случае достаточно:
Непериодический Независимый РС с измерениями
  ДатаВремя     тип ДатаВремя
  НомерЗаписи   тип Число 3
и ресурсом
  Комментарий   тип Строка

В этот РС записываю всё достойное внимания.


(19) Технически - несложно, практически - малоэффективно, т.к. юзер по природе ленив и в почту может заглядывать нечасто ;)

(22), (24) Чтобы не плодить "лишних" сущностей, думаю поручить чистку РС этому же регламентному заданию: пусть перед выполнением основного функционала удалит "старые" данные из РС (например, > недели).

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

Добрый день(утро) все обсуждающим тему. У меня актуален очень похожий вопрос(пытался его поднять и развить на разных форумах, но отклика не нашел).

Цели и исходные условия совподают с условиями (1)

Но есть не большие различия:
1)Задания выполняются ежедневно
2)Одно задание состоит из нескольких блоков(сравнимо с бизнес процессом)
3)Объемы загружаемых данных колеблятся от 40000 записей до 1200 000.
4)Допустимы ситуации когда элементы(блоки) каждого из заданий могут быть не выполнены, но в целом синхронизация может считаться успешной.

Задача таже, пользователям предоставить удобный инструмент для чтения результатов выполнения. Для этого нужно определиться с местом хранения информации.

Сейчас используется(достался по наследству) справочник.(он быстрей РС, на построчной записи. Но еще быстрей ЖР, но с ним есть проблема.

Заданы события которые должны в него писаться(и ОТКЛЮЧЕНЫ !! запись о начале и завершении транзакции) но записи о транзакциях все равно пишутся, в результате штатный лог за неполных 2 месяца занимает 46гб.

Вот и желаю спросить совета, как хранить логи в такой задаче, и как все таки избавиться от записи в ЖР о осуществлении транзакций?

(27) в ходе выполнения пиши в ЖР. Потом отдельным регзаданием перекидывай из ЖР в регистр сведений для удобства пользователей

ЖР, соответственно, после перебросов с чистой совестью чиститшь

(0) v8: Как трассировать регламентные задачи? -
читай сообщение №17 в указанной ветке (принцип работы отчетов, выполняющихся в фоне).

Да, (28, 29) в принципе я к такому выводу и сам пришел, вплоть до того, что пришлось написать службу, которая читает файлы ЖР, и убирает от туда записи о транзакциях. Но все таки это самодеятельность(а всегда хочется решить проблемы информационной системы, ее собственными средствами). Так сказать получается "иерархический" лог нужно вести, но конечно желательно в одном файле(таблице).