IE2017

Журнал регистрации с фоновой загрузкой изменений (8.2 - толстый клиент).

Администрирование - Журнал регистрации

Журналов на Инфостарте было недостаточно :), решил исправить это досадное недоразумение.

Как работает.

Идея прямиком и полностью сдута из Быстрого журнала регистрации от Expert1C (за это ему респект), но к сожалению тот журнал на 8.2 работать отказался. Вторая часть идеи сдута из публикации Простой способ регистрации изменений реквизитов объектов от Поручик (ему тоже рекспект). Просьба не пинать за плагиат :).

Журнал "является копией штатного журнала регистрации, но хранится в регистре сведений".

В данном журнале регистрируются только изменения некоторых ссылочных типов, а именно документов, справочников, планов видов расчета, планов видов характеристик, все остальные изменения (задачи, регистры сведений и т.д.) не регистрируются. Также следует отметить, что в журнал попадают лишь события, связанные с "Добавлением", "Удалением", "Проведением", "Снятием с проведения" и "Изменением" объектов, а такие события как "Сеанс. Аутентификация",  "Сеанс. Ошибка аутентификации" и прочие в журнал также не попадают. Еще убрал из регистрируемых справочник "сохраненныенастройки" (присутствует в типовых), по моему никакой смысловой нагрузки в регистрации этих событий нет. 

Таким образом, собирается только "наиболее важная" с точки зрения изменений объектов информация, с этим, конечно, можно и поспорить, но в данном случае это так.


Установка и описание объектов конфигурации

Все объекты конфигурации имеют префикс жр_ , поэтому для вживления в свою базу нужно при объединении (можно отобрать по подсистеме "жр_ПодсистемаЖурналРегистрации") добавить все объекты с этим префиксом, а именно:

1) Подсистема: жр_ПодсистемаЖурналРегистрации.

2) Общий модуль: жр_МодульЖурналаРегистрации.

3) Подписки на события: жр_ПередЗаписьюДокумента и жр_ПередЗаписьюОбъекта.

4) Регламентное задание: жр_ЗагрузкаЖурналаРегистрации (расписание можно/нужно настроить по своему усмотрению, по умолчению загрузка из штатного журнала выполняется каждые 3600 секунд).

5) Регистр сведений: жр_ЖурналРегистрации.

6) Обработка: жр_ЖурналРегистрации - ее, кстати, можно в конфигурацию не добавлять, а сохранить как внешнюю обработку, а затем запустить в режиме "Предприятие", при первом запуске обработка предлагает зарегистрировать себя в справочнике "Внешние обработки" (для типовых!), после утвердительного ответа откроется окно для того чтобы скорректировать список объектов, по умолчанию это все документы и справочники.

7) Обработка: жр_ЗаполнениеЖурналаРегистрации - данной обработкой можно воспользоваться для первоначальной загрузки данных из типового журнала если в этом вообще есть необходимость, рекомендую загружать данные небольшими партиями. Включать в состав конфигурации не нужно.

 

Итак, "вживляем" в свою конфигурацию, загружаем начальные данные, настраиваем расписание регламентного задания и регистрируем внешнюю печатную форму, которую и вызываем из любого объекта по кнопке "Печать" (для типовых!). Печатная форма (обработка) сделана на основе построителя отчета, и по умолчанию при открытии из документа отбор устанавливается только по этому документу, но можно настраивать и другие отборы. Закрыта возможность формировать журнал без отбора по ссылке или без указания периода (защита от зависания, т.к. отчет без отбора при больших объемах может наглухо повесить приложение).

 

Аналогичные публикации

1) //infostart.ru/public/19711/

2) //infostart.ru/public/71896/

3) //infostart.ru/public/16379/

4) //infostart.ru/public/19364/

5) //infostart.ru/public/59386/

6) //infostart.ru/public/63420/

7) //infostart.ru/public/18588/

8) //infostart.ru/public/22167/

Скачать файлы

Наименование Файл Версия Размер
Журнал регистрации
.cf 37,91Kb
23.03.12
132
.cf 37,91Kb 132 Скачать

См. также

Комментарии
1. Владимир (oberon355) 11 24.03.12 22:11 Сейчас в теме
Интересно, насколько это базу утяжеляет и замедляет? Особенно если запустить массовое перепроведение документов? И еще один нюанс, насколько я понял регистры сведений при их активном использовании очень сильно увеличивают журнал транзакций в скуле. Соотвтетствнно при перепроведении колласпс может наступить ну очень быстро.
2. sound sound (sound) 522 26.03.12 09:07 Сейчас в теме
(1) Ну вообще утяжеляет нормально, как говорится, за все нужно платить. В любую базу бездумно ставить такой механизм я бы не стал. По идее можно еще подумать перед записью обработать данные из журнала, "свернув" их в пределах одной транзакции и сделав только одну запись - получится гораздо экономнее. Еще если не нужна такая "сильная" детализация можно вообще убрать подписки на события - получится гораздо быстрее. И вообще вынести это все в отдельную базу :). Хотя у меня и в таком виде работает.
3. Владимир (oberon355) 11 26.03.12 09:36 Сейчас в теме
А что значит "нормально"? +10% объема? +20%? или + 60% объема базы? И как это хранить в другой базе? т.е. при записи открывать по com другую базу и писать туда? Т.е. увеличивать время проведения документа? Сейчас проскочила бредовая мысль - а может имеет смысл это делать через планы обмены ?
4. sound sound (sound) 522 26.03.12 09:50 Сейчас в теме
(3) Вы не так поняли, данные пишутся в регистр не в момент записи/проведения документов, в эти моменты срабатывают только подписки на события, которые пишут данные в стандартный журнал (хотя их как я писал выше можно вообще убрать), а в регистр данные попадают в момент запуска регламентного задания, которое соответственно срабатывает по расписанию. То есть по идее убрав подписки мы вообще никак не будем влиять на скорость проведения документов.
5. sound sound (sound) 522 26.03.12 10:00 Сейчас в теме
Вот, кстати, цифры примерно за 1,5 года работы этого журнала:

Кол-во записей: 3 050 142
Общий размер: 2 684 208,00 (в КБ)

1С Бух КОРП, пользователей около сотни, размер базы ~30 ГБ.
6. Владимир (oberon355) 11 26.03.12 11:33 Сейчас в теме
За цифры спасибо огромное. А на счет подписки не согласен. Подписка на событие наступает в момент проведения документа ( в нашем случае). Так что время проведения документа увеличится по любому.
7. Владимир (oberon355) 11 26.03.12 11:34 Сейчас в теме
Пардон, гоню в понедельник с утра
8. sound sound (sound) 522 26.03.12 15:49 Сейчас в теме
9. dfxi dfxi (agr) 04.09.12 12:16 Сейчас в теме
А что нибудь, что фиксирует изменения в регистрах сведений существует?
10. sound sound (sound) 522 04.09.12 12:25 Сейчас в теме
(9) Что-то где-то однозначно существует, но в данном случае упор делался только на объекты ссылочного типа как наиболее востребованные для анализа их истории. Для регистров нужно что-то мудрить и вообще тут еще нужно подумать что вообще есть запись регистра сведений?
11. dfxi dfxi (agr) 08.09.12 16:13 Сейчас в теме
У нас регистр сведений должен находится под контролем так как в него попадают на некоторое время данные которые потом используются для расчетов с контрагентами.
12. sound sound (sound) 522 25.12.12 15:41 Сейчас в теме
(11) agr, значит Вам нужен какой-то другой механизм
13. Михаил Косовов (z8491) 07.03.13 11:12 Сейчас в теме
День добрый, Скажите плиз по вашей разработке Журнал регистрации с фоновой загрузкой изменений (8.2 - толстый клиент). как увидить какие именно были сделанны изменения , а то в журнале видно просто событие данные изменены, а какие не понятно
14. Доминант ГК (ingmar) 13.05.15 11:45 Сейчас в теме
Есть один минус у данного способа.
Когда ЖР загружается, запись в регистр сведений тоже генерирует запись в ЖР. Следовательно ваш ЖР (файл) вырастит примерно в полтора раза и далее будет расти быстрее чем раньше.
15. sound sound (sound) 522 13.05.15 17:40 Сейчас в теме
(14) Ну я у себя давно все это дело переписал, я уж и не помню что там в конфигурации понаписано, но по моему, в регистр пишутся данные только по событиям ссылочного типа, а обычный журнал просто усекается и все, поэтому 3 года работает, я б не сказал что прям беда какая-то. Хотя у всех свои случаи конечно.
16. Доминант ГК (ingmar) 14.05.15 09:22 Сейчас в теме
(15) sound, А что переписали, если не секрет? Идея мне нравится, но вот пугает вероятность огромных логов. Усекать их - значит терять информацию (ту которая не будет писаться в регистр). А для архивации придется писать скрипт.
17. sound sound (sound) 522 22.05.15 16:09 Сейчас в теме
(16) Ну по доброму конечно надо писать это в отдельную базу, то есть создать там одну таблицу с ключом по GUID объекта (или что-то в этом духе), если только про ссылочный тип речь, и потом регламентное задание запускается, коннектится к этой базе и в нее пишет то, что возьмет из типового журнала. Где то тут было на сайте что-то подобное, поищите. А потом сделать внешнюю печатную форму "История объекта", например, для всех документов и справочников, и для тех, у которых есть кнопка "Печать" соотв-но можно будет прям оттуда эту историю выводить в какую нить печатную форму, а у которых нет кнопки печать, те смотреть какой-то специальной обработкой, которая как и печатная форма будет ломиться в эту базу внешнюю и брать оттуда данные. Как-то так :)
18. Юрий Машков (newtype) 18.03.16 11:16 Сейчас в теме
Очень всё понравилось. но добавил в регистр сведений журнала отдельно номер документа, чтобы видеть , если изменён номер документа.
19. sound sound (sound) 522 23.03.16 11:37 Сейчас в теме
(18) newtype, ну я уже неоднократно писал, что не претендую на какую-то оригинальность и что у всех свои задачи :)
Оставьте свое сообщение