v8: Регистрация событий
Ключевые слова: Журнал, регистрация, автор, редактор, изменение.
В программе 1С есть штатный механизм регистрации событий, это журнал регистрации.
Тем не менее, этот механизм имеет как ряд преимуществ, так и ряд недостатков.
Из недостатков можно назвать недостаточность информации и практическую невозможность использовать эту информацию как в системе прав RLS, так и в остальных случаях работы с программой.
Из достоинств можно отметить то, что при использовании альтернативного механизма некоторую информацию сложно или невозможно получить средствами встроенного языка программы 1С, а также то, что не придется прописывать функционал в конфигурацию и не будет дополнительного замедления работы программы.
В общем-то, пожалуй, ситуация такова, каждому нужно самому решить, достаточно ему штатного журнала регистрации или ему нужны дополнительные механизмы регистрации событий.
Некоторые размышления на тему того, какие требуются в 1С механизмы регистрации различных событий, привели меня к тому, что таких механизмов четыре.
Первый – это регистрация авторов и последних редакторов объектов.
Предполагается хранение информации о том, кто, когда, в какой распределенной базе создал и кто, когда, в какой распределенной базе последним отредактировал объект.
Причем информация хранится непосредственно в самих объектах, в дополнительно созданных реквизитах.
Недостатки и преимущества такого решения очевидны.
Первый недостаток в том, что мы имеем крайне скудную информацию, только о том, кто создал и последним изменил объект, не располагая информацией о том, кто был, к примеру, предпоследним редактором или какие именно реквизиты были изменены.
То есть получить информацию о том, что цены в таких-то строках такой-то расходной накладной поправил Вася вчера в полдень с компьютера директора (пока директор был на деловой встрече) нам не удастся.
Второй недостаток тот, что при удалении объекта мы теряем и информацию по этому объекту, поскольку информация хранится в самом объекте.
С другой стороны, есть и неоспоримые преимущества.
Первое преимущество в том, что мы можем привязывать систему прав RLS непосредственно к реквизитам объекта, не делая соединений с таблицами других объектов.
Таким образом, мы не перегружаем систему выполнением лишних запросов.
Второе преимущество в том, что мы можем в формах списков объектов видеть эти реквизиты и делать по ним отбор.
Третье преимущество в том, что в запросах можно обращаться к реквизитам объекта через точку, не делая соединения с другими таблицами.
Второй механизм предназначен для регистрации событий запуска и закрытия программы и открытия и закрытия форм объектов.
Здесь речь идет об отдельном регистре сведений.
Информация вынесена в отдельный регистр сведений, поскольку имеет ярко выраженный реквизитный состав, отличный от остальных трех механизмов, кроме того, запуск и закрытие программы не имеют отношения к какому-либо конкретному объекту.
Третий механизм предполагает регистрацию событий изменения реквизитов объектов, за исключением реквизитов табличных частей.
Четвертый механизм выполняет ту же функцию, что и третий но для табличных частей объектов.
Третий и четвертый механизмы будут использовать регистр сведений, но для каждого механизма будет свой регистр.
На то есть как минимум пара причин.
Во-первых, регистрация изменения реквизитов табличных частей – довольно трудоемкое дело, которое при определенном стечении обстоятельств либо нешуточно напряжет систему либо вовсе сделает работу невозможной.
А поэтому эту таблицу лучше отделить от других таблиц, чтобы не перегружать лишний раз программу нагромождением всего в одну кучу.
А во-вторых реквизитный состав этих регистров будет различным.
Подробно каждый из механизмов будет рассмотрен в отдельных статьях.
Первый из них уже рассмотрен в статье Книга знаний: v8: Авторство обьектов в базе.
Остальные три механизма будут описаны в ближайших статьях. |