В данном посте я хочу продолжить описание решения вопроса по автоматизации восстановления последовательности (предыдущий пост доступен по ссылке). НО: перед тем как приступить к автоматизации, в первую очередь необходимо обеспечить себя достоверной информацией о том, чем на самом деле занимается система ))) . Таким образом, нам необходима надежная и гибкая система логирования работы по восстановлению последовательности.
Постараюсь сформулировать основные требования к системе логирования:
- Доступность из разных источников и удобство доступа.
- Независимость от базовой системы (если не работает система, это не значит, что мы не видим логов работы).
- Гибкость структуры – в одном хранилище необходимо хранить разные виды ошибок с разным набором параметров.
- Возможность управления правами доступа к хранилищу ошибок.
- Хранение больших объемов данных.
- Скорость доступа к логам работы.
Рассмотрим возможные варианты хранения логов работы системы:
Таким образом, единственным вариантом, который удовлетворяет всем критериям, является внешнее хранилище в базе данных, и ниже я постараюсь обосновать свой выбор по каждому требованию к системе логирования:
| Параметр | Комментарии |
| Доступность | Доступ к базе SQL можно получить множеством способом:Из 1С (с помощью кода или специальной консоли запросов)Из Microsoft ExcelC помощью прямых запросов к базе данныхИз разнообразных средств проектирования отчетов (пр. Microsoft Reporting Services)и т.д. |
| Независимость | База полностью независима от 1С и, в общем случае, основываясь на информации в базе данных, можно определить, доступна ли 1С в принципе. |
| Гибкость | Гибкость хранения достигается за счет специальных типов данных (пример XML). |
| Права | Очень гибкие права доступа |
| Объемы хранения | Почти неограниченные (во всяком случае для нашей задачи). При этом удаление старых записей делается быстро и безболезненно. |
| Скорость доступа | С помощью грамотно построенных индексов возможно обеспечить приемлемую скорость доступа к логам для анализа. |
Таким образом, единственным вариантом, который удовлетворяет всем критериям, является внешнее хранилище в базе данных, и ниже я постараюсь обосновать свой выбор по каждому требованию к системе логирования на базе MS SQL Server (именно на ней я остановил свой выбор):
Структуры для хранения логов достаточно подробно описаны по следующей ссылке http://borisfrolovsqlservertips.wordpress.com/2013/02/03/database-structure-to-store-performance-metrics/, но для наших целей придется создать гибридную таблицу. Набор столбцов представлен указанным ниже образом, чтобы в будущем использовать созданную таблицу не только для логирования разнообразных процессов, но и для хранения ошибок возникающих в системе:
| Поле | Краткое описание |
| ID | Уникальный идентификатор записи |
| ErrorDate | Дата вставки записи в таблицу |
| UserName | Имя пользователя, под которым работал процесс |
| ErrorTypeID | Тип ошибки (ссылка на справочник типов ошибок, чтобы предотвратить зоопарк) |
| ErrorMessage | Сообщение об ошибке |
| StackPath | Место возникновения ошибки |
| ErrorLog | Детальный текст ошибки (полный лог) |
| ErrorXML | Колонка с типом XML, которая позволит нам для каждого вида записи формировать свой набор дополнительных параметров. |
В следующий раз подробно разберем, как из 1С выполнять запись в таблицу на стороне SQL Server.