Реализация системы логирования для 1С(SQL)   

   

Скорее всего, многие сталкивались с ситуациями, когда шеф просит выяснить, кто сделал изменения в документе, в результате которых фирма потеряла деньги. Другая ситуация, когда программист пытается доказать пользователю, что это он сделал изменения, а пользователь в свою очередь говорит, что это несовершенная программа выполнила эти изменения. Бывают ситуации, когда необходимо кого-то поймать на воровстве, манипуляции с данными в БД. Иногда просто необходимо получить список измененных объектов в той последовательности, в которой они изменялись. Все эти ситуации попадают под разряд решений аудита и логирования.

В этой статье я хочу рассказать об системе логирования для БД под 1С 7.7.(SQL). Для начала пожалуй, стоит остановится на системе идентификации пользователей в среде MSSQL в контексте работы под 1С. Эта статья не про безопасность в среде 1С, поэтому просто расскажу про две возможные реализации идентификации пользователей.

Первая реализация

Создаем линовочную, таблицу в которой будет два поля (spid - процесс пользователя ,username - имя пользователя(предпочтительно NT)).При начале работы системы 1С в соответствующей процедуре прописываем процедуру, которая будет делать запись в линковочную таблицу о соответствии пользователя к процессу.Таким образом, в дальнейшем при обработке триггера мы сможем из этой таблицы по процессу @@spid получить соответствующего ему пользователя.

Вторая реализация

Реализовываем систему Windows NT authorization. Это нам дает возможность в триггере идентифицировать пользователя. Нужно сказать, что такой способ дает еще ряд преимуществ - например, при работе в терминале можно идентифицировать пользователей из Enterprize Manager. Правда, при этой реализации нужно пользователям не забывать выдавать права к БД на уровне SQL. А также не забывать использовать хранимые процедуры типа 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С просматривать различные версии объектов с возможностью отката к требуемой версии. Также решен вопрос автоматической перегенерации триггеров при изменении структуры метаданных, а также проблемы поддержки различных версий объектов метаданных.

Обсуждение статьи

 

Статьи по этой теме:

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

Ведение лога изменений документов: модули 

Ведение лога изменений документов: обработка чтения лога

Программный комплекс "Логирование"


 

Перепечатка, воспроизведение в любой форме, распространение, в том числе в переводе, любых материалов с сайта www.softpoint.ru возможны только с письменного разрешения компании "СофтПоинт". Это правило действует для всех без исключения случаев, кроме тех, когда в материале прямо указано разрешение на копирование (основание: Закон Российской Федерации "Об авторском праве и смежных правах").

 

Статья: Реализация системы логирования для 1С(SQL)

Перейти на главную страницу компании "Софтпоинт"