Скорее всего многие сталкивались с ситуациями когда шеф просит выяснить кто сделал изменения в документе в результате которых фирма потеряла деньги. Другая ситуация когда программист пытается доказать пользователю что это он сделал изменения а пользователь в свою очередь говорит, что это несовершенная программа выполнила эти изменения. Бывают ситуации когда необходимо кого-то поймать на воровстве, манипуляции с данными в БД. Иногда просто необходимо получить список измененных объектов в той последовательности в которой они изменялись. Все эти ситуации попадают под разряд решений аудита и логирования.
Я не буду в этой статье говорить о всех недостатках существующей системы аудита в 1С. Она не выдерживает никакой критики. Пользы практически никакой.
В этой статье я хочу рассказать об системе логирования для БД под 1С 7.7.(SQL). Для начала пожалуй стоит остановится на системе идентификации пользователей в среде MSSQL в контексте работы под 1С. Эта статья не про безопасность в среде 1С поэтому просто расскажу про две возможные реализации идентификации пользователей.
Первая реализация-
Создаем линовочную таблицу в которой будет два поля (spid - процесс пользователя ,username - имя пользователя(предпочтительно NT)). При начале работы системы 1С в соответствующей процедуре прописываем процедуру которая будет делать запись в линковочную таблицу о соответствии пользователя к процессу. Таким образом в дальнейшем при обработке триггера мы сможем из этой таблицы по процессу @@spid получить соответствующего ему пользователя.
Вторая реализация-
Меняем в библиотеке bkend.dll строку коннекта заменяя server=%s;uid=%s;pwd=%s; на trusted_connected=yes; Таким образом все пользователи будут входить с Window NT authorization. Это нам дает возможность в триггере идентифицировать пользователя. Нужно сказать что такой способ дает еще ряд преимуществ - например при работе в терминале можно идентифицировать пользователей из Enterprize Managar. Ну и вообще NT безопасность на порядок выше 1С поэтому мне этот способ нравится больше. Правда при этой реализации нужно пользователям не забывать выдавать права к БД на уровне SQL(кстати используя эту технологию можно на качественно другом уровне решить вопросы безопасности в 1С но это пожалуй материал другой статьи). А также не забывать использовать хранимые процедуры типа sp_addalias...
Следующий шаг это реализация собственно самой системы логирования. Реализовать ее можно несколькими способами например прописав модулях документов соответствующие процедуры которые будут делать записи об изменениях. Но эта технология не надежная и неэффективная по ряду причин. По этому остановлюсь на другой технологии. Лог таблица-ы об изменениях будет вестись на основании отработки триггеров.
Рассмотрим следующий пример:
У нас в системе 1С имеется справочник Контрагенты в котором есть реквизит ДатаЗакрытия. Ему соответствует таблица SC125 а реквизиту ДатаЗакрытия соответствует реквизит Sp47. К этому справочнику в силу объективных причин имеет доступ несколько сотрудников и единственного ответственного сделать не получается. Предположим в любой момент времени необходимо иметь информацию о том кто и какие сделал изменения в этом справочнике. Для этого необходимо завести таблицу Copy_ SC125 в которой будут те же самые поля как и в SC125 плюс дополнительные UserName и Datetime. В эту таблицу будут записываться различные версии объектов справочника Контрагенты плюс в дополнительные поля информация о том кто и когда внес эти изменения. После чего необходимо создать триггер который будет вставлять новые записи в таблицу Copy_ SC125.Например для update будет следующий код.
CREATE TRIGGER [LogSC125] ON [dbo].[SC125]
FOR UPDATE
AS
insert into Copy_ SC125 select * ,suser_sname(),getdate() from deleted
Предположим нам необходимо иметь информацию о том кто и когда изменения делал по всем объектам плюс информация по списку измененных реквизитов(не по значениям). В этом случае имеет смысл сделать одну общую таблицу в которой будут поля (ТипИзменений,Пользователь,Время,Таблица,ИзмПоля,ПервичныйКлюч,ПервичныйКлюч1С) - значения этих полей я думаю комментировать излишне. Из триггеров прописанных в таблицах данных в эту таблицу будут попадать записи об изменениях.
insert into log_1s.dbo.ЖурналИзменений_demo1c(ТипИзменений,Пользователь,Время, Таблица,ИзмПоля,ПервичныйКлюч,ПервичныйКлюч1С) values('U',suser_sname(),getdate(),'SC_Валюты',@Fields,@PK,@PK1C)
Возникает вопрос о том трудоемкий ли процесс прописывания триггеров для каждой таблицы? Нисколько! Все триггера можно генерировать автоматически, а соответствия объектов SQL к объектам 1С получать, например, с помощью rainbow. Проблема удаления триггеров объекта при изменении структуры метаданных решается выносом информации об системе триггеров во внешние таблицы и добавлением системы контроля проверки актуальности системы например ПриНачалеРаботыСистемы. Проверка эта и перегенерация при нормальной реализации выполняется доли секунды. Возможно также вести отдельно лог об включении , отключении триггеров но это пожалуй материал не этой статьи. Нужно отметить, что схемы логирования оптимальной для абсолютно любой базы не существует. Для каждой базы должна быть своя схема т.к. не всегда имеет смысл вести полную систему логирования. Кроме этого в полноценной системе логирования должны быть решены вопросы поддержки различных версий MSSQL объектов т.к. структура объектов 1С может меняется.(с соответствующей поддержкой преобразования типов)
P.s. У автора имеется готовое решение прошедшее неоднократное внедрения с реализацией различных схем логирования и различными наборами отчетов. В том числе есть возможность прямо из интерфейса 1С просматривать различные версии объектов с возможностью отката к требуемой версии. Также решен вопрос автоматической перегенерации триггеров при изменении структуры метаданных а также проблемы поддержки различных версий объектов метаданных.
При использовании материалов данной статьи обязательна ссылка на информационный ресурс и автора статьи.
Автор статьи - Сердюк В.И.
Начать дискуссию