Парсер технологического журнала (golang + redis + elasticsearch)

Публикация № 1356384 07.01.21

Администрирование - Производительность и оптимизация (HighLoad) - Технологический журнал

технологический журнал redis elasticsearch многопоточность golang go goroutines логи linux github shmell

На просторах интернета, в том числе на данном ресурсе содержится разнообразное количество инструментов, позволяющих читать, трансформировать логи технологического журнала. Инструмент, который я описываю в данной статье, - является альтернативным вариантом, реализованным на стеке технологий Goroutines (golang) + Redis + Elasticsearch.

Что такое технологический журнал, для чего он нужен и какая информация в нем содержится - можно прочитать, на мой взгляд, в самой детальной статье Юрия Пермитина (ну и конечно же - ИТС).

Про Elasticsearch так же уже достаточно статей, что это и как это применять в мире 1С. Например, вот несколько ссылок:

Elastic + filebeat + ТЖ 1С
Взаимодействие 1С со сторонними продуктами
Перенос всех логов в Elasticsearch

В данной статье я подробно опишу возможности предложенного стека, особенности, нюансы.

Итак, все инструменты, в рамках стека - open source, а так же являются кросс-платформенными. Верхнеуровнево, архитектура решения выглядит следующим образом:

 

Что есть что на данной схеме:

Каталог тех. журнала 1С - каталог, в котором содержаться непосредственно логи. Уровень вложенности не важен, так как рекурсивно будут просмотрены все каталоги и прочитаны файлы с расширением *.log.

techLog1C - инстанс парсера. Одновременно может быть запущено несколько инстансов. Парсер принимает на вход массив файлов *.log производит парсинг, после чего отправляет данные в Elasticsearch. Парсер может работать многопоточно внутри своего инстанса а так же сам пишет логи в ходе своей работы (все это конфигурируется в файле settings.yaml - детальные настройки будет приведены ниже). Лучшей практикой является кейс, когда логи инкрементно забираются с продуктового сервера с некоторой периодичностью на служебную машину, где уже непосредственно стартует парсер. Такой подход не приводит к дополнительной нагрузке на продуктовый сервер. 

Redis - NoSQL key-value СУБД. В стеке выполняет роль кэша, для хранения параметров файлов, которые обрабатываются в текущий момент времени и те, которые были обработаны (последняя позиция файла). Почему не используется простой текстовый файл? Все просто - парсер работает в многопоточном режиме, что требует доступ до файла в режиме записи из нескольких потоков. Redis позволяет решать следующие кейсы:

  1. Если файла тех. журнала уже нет, то при запуске парсера анализируются ключи в redis базе и проверяется существование файлов. Если файлы не существуют - ключи таких файлов удаляются.
  2. Так же при запуске еще одного инстанса парсера - будут пропущены файлы тех. журнала, обрабатываемые другими инстансами.

Несмотря на то, что redis все значения хранит в оперативной памяти - периодически служба производит запись на диск, в случае перезагрузки или сбоя службы - последние сохраненные значения будут восстановлены с диска.

Наиболее свежие и стабильные сборки redis осуществляются под linux, но и для windows есть сборки от Microsoft Open Tech.

Elasticsearch - используется как конечная точка хранения распарсенных логов 1С. Нереляционная база данных Elasticsearch позволяет достаточно оперативно получать необходимую информацию, используя поисковые обратные индексы. В связке с Kibana - можно строить выборки, используя декларативный KSQL язык запросов.

1. - Использование запросов KSQL

2. - Распарсенные поля, которые можно использовать в качестве выбранных полей.

При использовании расширения XPACK (30 day free trial) можно задействовать модуль машинного обучения (Machine Learning), что позволит выявлять аномалии и различные зависимости от показателей тех журнала и журнала операционной системы, например утечки памяти.

Описание настроек парсера

Все настройки указываются в файле settings.yaml

# Расположение логов тех журнала 1С
patch: "D:\\tmp\\1C_event_log\\1C_event_log"
#
# Параметры подключения к Redis
redis_addr: "localhost:6379"
redis_login: ""
redis_password: ""
redis_database: 0
#
# Параметры подключения к Elasticsearch
elastic_addr: "http://localhost:9200"
elastic_login: ""
elastic_password: ""
elastic_maxretries: 10
elastic_bulksize: 2000000
#
# Правила формирования индекса Elasticsearch
# Пример: "tech_journal_{event}_yyyyMMddhh", где event - CONN, EXCP, etc...
elastic_indx: "tech_journal_{event}_yyyyMMddhh"
#
# Типы событий тех журнала, которые могут содержать длинные строки '...' и переносы строк \n
tech_log_details_events: "Context|Txt|Descr|DeadlockConnectionIntersections|ManagerList|ServerList|Sql|Sdbl|Eds"
#
# Путь, где будут распологаться логи программы
patch_logfile: "D:\\tmp\\techLogData\\log"
#
# Глубина фиксации ошибок при работе программы:
#   1 - только ошибки
#   2 - ошибки и предупреждения 
#   3 - ошибки, предупреждения и информация
log_level: 3
#
# Уровень параллелизма
maxdop: 14
#
# 0 - отключена сортировка файлов по размеру, 1 - сортировка по убыванию, 2 - сортировка по возрастанию
# полезно включать при массовых операциях, для равномерного распределения файлов по потокам
sorting: 0

Служба Redis может быть запущена на другой машине в сети, так же как и инстанс Elasticsearch. Для этого используются параметры redis_addrelastic_addr. Redis из коробки поддерживает аутентификацию, в то время как Elasticsearch по умолчанию полностью открыт для доступа. Задать базовую аутентификацию для Elasticsearch можно через nginx

Redis содержит внутри себя 16 баз данных, их нумерация целочисленная от 0 до 15. Рекомендуется задать параметр redis_database для случаев, когда в вашей организации уже используется Redis и необходимо изолировать существующие базы.

Параметры elastic_maxretrieselastic_bulksize - позволяют управлять поведением массовой вставки в индексы Elasticsearch. Elasticsearch имеет ограничения на операции массовой вставки bulk api. Из версии к версии они меняются. Ключевыми факторами, влиящими на успешную массовую загрузку являются - дисковая подсистема и процессор, помимо, конечно же объема пакета данных, отправляемых в массовом запросе. Операция bulk может выполняться параллельно из нескольких сеансов. В случае большого суммарного объема данных, которые отправляются сеансами - может произойти ситуация, когда Elastic просто не успеет обновить карту индексов и произвести индексацию загружаемых документов, что непременно приведет к ошибке и остановке службы Elasticsearch. Чтобы избежать этого - рекомендуется подбирать объем данных, отправляемых одним сеансов (в байтах), за что отвечает параметр elastic_bulksize.  elastic_maxretries - число попыток повторной отправки пакета, в случае возникновения ошибок загрузки одного пакета данных.

Правило формирования наименования индекса можно задавать в параметре elastic_indx. Предложенного варианта формирования вполне достаточно для большинства случаев.

Параметры событий, которые могут содержать длинные строки с символами переноса строк лучше сразу указать в tech_log_details_events. По умолчанию, в настройках приведен перечень таких параметров, но если считаете, что указаны не все - их можно внести в настройки. Такой подход значительно сокращает время на парсинг файлов, но и несет в себе существенный минус - в случае появления нового параметра в событиях, например, с выходом новой версии платформы, может возникнуть проблема при формировании полей индексов в Elasticsearch в следствии некорректного парсинга. 

Программа так же ведет логи своей работы, но не пишет их в Elastic, т.к. любой из инструментов стека может оказаться недоступен. Глубина логирования задается параметром log_level. По умолчанию он = 3 - то есть полная информация о поведении программы. Логи пишутся в формате json, что упрощает процедуру анализа впоследствии.

Парсер, как было указано ранее, может работать многопоточно, что особенно полезно когда у вас много логов, они тяжелые (например, включен полный тех журнал), или же вам необходимо произвести первоначальное чтение существующих логов. Количество потоков указывается в параметре maxdop. При использовании параметра sorting можно ускорить операцию чтения исторических логов. Если задать значение параметра = 2 (по возрастанию размера файла), то операции создания карты индекса будут производиться быстрее, т.к. файлы меньшего объема и содержат небольшое количество документов. Но лучшей практикой является описание карты индексов внутри map файлов, которые использует парсер (см. каталог maps). При таком подходе, при создании нового индекса, будет полноценно создаваться карта, а затем в индекс будут загружаться документы, что позволит исключить операции переформирования карты при каждой вставке документа. Тем более, что операция переформирования карты - достаточно дорогостоящая и блокирующая при операциях массовой вставки.

Особенности настройки Elasticsearch

Elasticsearch работает на JVM, поэтому очень требователен к настройкам памяти. По умолчанию размер кучи установлен в 1Gb, что крайне мало при массовой операции вставки документов в индексы Elasticsearch.

  1. XMX/XMS рекомендуется установить равным половине оперативной памяти, доступной физической/виртуальной машине. Например, если у вас 16Gb, то возможный вариант настройки: -Xms8G -Xmx8G Документация

  2. Очистка старых индексов (использование index lifecycle policy). Чем детальнее технологический журнал - тем сильнее будет расти его объем, а значит и индексы в Elasticsearch, это может привести к нехватке свободного места на дисках, где хранятся индексы. Лучшая практика - спустя N дней удалять индексы. Все что необходимо - задать политику жизненного цикла индексов https://www.elastic.co/guide/en/elasticsearch/reference/current/set-up-lifecycle-policy.html После этого задать темплейт, который будет включать индексы тех журнала

PUT _template/tech_journal_template
{
  "index_patterns": ["tech-*"],                 
  "settings": {
    "number_of_shards": 1,
    "number_of_replicas": 1,
    "index.lifecycle.name": "tech_journal_policy"    
  }
}

Но при таком подходе - политика применится только к вновь создаваемым индексам. Чтобы ее применить к уже существующим, нужно выполнить следующий запрос:

PUT tech_*/_settings
{
  "index.lifecycle.name": "tech_journal_policy" 
}

Известные проблемы:

  1. circuit_breaking_exception,  [request] Data too large, data for [<reused_arrays>] would be larger than limit of: Измените параметры XMX/XMS
  2. es_rejected_execution_exception: rejected execution of coordinating operation Уменьшите уровень параллелизма (maxdop), подберите оптимальный размер блока на единицу bulk операции (elastic_bulksize), увеличьте параметр elastic_maxretries в settings.yaml файле.
  3. Долгая индексация, update mapping index. После загрузки каждого документа - если не задана карта индекса - карта создается, что создает накладные расходы, при количестве документов > 1 млн, обновление карты может не уложиться в таймаут по умолчанию (30 сек.). Поэтому, рекомендуется создавать map карты индекса (см. каталог maps)

Производительность

При включенном тех журнале, содержащем следующие настройки:

<?xml version="1.0" encoding="UTF-8"?>
<config xmlns="http://v8.1c.ru/v8/tech-log">

<log location="S:\1C_event_log\all" history="25">
  <event>
      <eq property="Name" value="EXCP"/>
  </event>
  <event>
      <eq property="Name" value="CONN"/>
  </event>
  <event>
      <eq property="Name" value="PROC"/>
  </event>
  <event>
      <eq property="Name" value="ADMIN"/>
  </event>
  <event>
      <eq property="Name" value="SESN"/>
  </event>
  <event>
      <eq property="Name" value="CLSTR"/>
  </event>
   <property name="all"/>
</log>

<log location="S:\1C_event_log\tlocks" history="1">
  <event>
      <eq property="Name" value="TLOCK"/>
  </event>
  <event>
      <eq property="Name" value="TTIMEOUT"/>
  </event>
  <event>
      <eq property="Name" value="TDEADLOCK"/>
  </event>
   <property name="all"/>
</log>
	
</config>

суммарный размер лог файлов за сутки составляет 4,3 Gb. Инстанс парсера, запущенный при настройке 14 потоков на отдельной машине core i3 (v gen) с 16 Gb оперативной памяти, не ssd - обработал логи за 19 минут (bulk size - 200mb). При инкрементном запуске парсера каждую минуту - скорость обработки инкрементных данных варьируется от 5 до 14 секунд.

Самым оптимальным - является запуск парсера с одновременным включением тех журнала. В настройках тех журнала нужно указывать только те события, которые вам действительно нужны, а так же использовать отборы событий по параметрам, например - duration, p:processName и.т.д. Это позволит сократить объемы выходных логов, что положительно скажется на парсинге и хранении логов внутри Elasticsearch.

Резюме

Парсер является полностью открытым, расположен на:

https://github.com/NuclearAPK/go-techLog1C

Можно поучаствовать в его совершенствовании и оптимизации.

Так же буду рад конструктивным замечаниям и предложениям. 

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

Наименование Файл Версия Размер
Парсер технологического журнала (golang + redis + elasticsearch):

.rar 9,42Mb
3
.rar 1.0.0 9,42Mb 3 Скачать

Специальные предложения

Комментарии
В избранное Подписаться на ответы Сортировка: Древо развёрнутое
Свернуть все
1. Smaylukk 850 04.02.21 13:24 Сейчас в теме
Ни в статье, ни на гитхабе не указано, что надо установить Golang.
Попробовал запустить. Исправил файл settings.yaml.
При попытке запустить парсер - пишет "no go files listed".
Подскажите, куда копать?
2. Shmell 391 04.02.21 17:17 Сейчас в теме
(1) на гитхабе я добавил релиз, который содержит бинарник для win64 и debian
https://github.com/NuclearAPK/go-techLog1C/releases/tag/0.1

для запуска в этом случае не требуется Golang.

Если будете использовать в среде windows то для настройки задания планировщика нужно прописать рабочую папку в параметрах.
3. buganov 179 18.05.21 08:23 Сейчас в теме
Можно пояснить, для чего в стеке прокладка в виде редиски? Почему сразу не булкать в эластик?
4. Shmell 391 18.05.21 09:18 Сейчас в теме
(3) в публикации указано для каких целей.
5. krund 03.06.21 15:27 Сейчас в теме
Вадим подскажи пожалуйста что нужно сделать в самой kibane чтобы увидеть данные отправленные парсером в elastic?
6. Shmell 391 04.06.21 05:24 Сейчас в теме
(5)
1. Для начала нужно создать паттерн индекса. Он должен начинаться так же как и наименование индекса

2. Далее, заходим в discovery и выбираем наш индекс паттерн

3. Если все ок, можно начать крутить дашборды, настраивать алерты, подключать xpack итд

см. приложенные файлы
Прикрепленные файлы:
7. krund 04.06.21 08:55 Сейчас в теме
Вадим что то не так у меня. Что я где не доделал?
Прикрепленные файлы:
8. user1461477 16.06.21 15:47 Сейчас в теме
Когда что-то пошло не так
Прикрепленные файлы:
9. user1461477 16.06.21 15:49 Сейчас в теме
Нет, конечно, работа внушает. Красиво
Но вот такой облом с отсутствием шаблона.
Обидно очень
11. Shmell 391 16.06.21 19:20 Сейчас в теме
(9) вы уверены что к нужной публикации комментарий написали?
12. user1461477 17.06.21 12:25 Сейчас в теме
(11) Доброго времени. Что, эта красивая картинка - не ваша работа? Или ваша, но обсуждается где-то в другом месте? Или ваша, но не обсуждается? В таком случае, прошу прощения, больше не буду.
13. Shmell 391 17.06.21 14:54 Сейчас в теме
14. user1461477 17.06.21 14:59 Сейчас в теме
(13) упс. извините, пожалуйста
10. user1461477 16.06.21 16:15 Сейчас в теме
без галки реалтайма - то же
--
Нет соответствия шаблону!
38:50.579133-11,SDBL,3,process=1CV8C,OSThread=13068,Usr=DefUser,DBMS=DBV8DBEng,DataBase=base,Trans=1,Sdbl='INS ERT IN TO Reference47 (Marked, PredefinedID, OwnerID, Description, Fld247, Fld248, Fld249, Fld250, Fld251, Fld252, Fld253, Fld254, Fld255, Fld256, VT257.(LineNo258, Fld259, Fld260, Fld261, Fld262)) VALUES(FALSE,0x00000000000000000000000000000000,35:8dafe164f0d0485b11ebce9c54b39a3f,"31:39.759001-0","31:39.759001-0,CONN,0,process=1CV8C,OSThread=16532,Txt=''Ping direction statistics: address=[::1]:1560,pingTimeout=15000,pingPeriod=3000,period=10063,packetsSent=3,avgResponseTime=0,maxResponseTime=0,packetsTimedOut=0,packetsLost=0,packetsLostAndFound=1''",DATETIME(2021,6,16,15,31,39),759001,0,38:00000000000000000000000000000000,2,44:8dafe164f0d0485b11ebce9c54b39a47,46:8dafe164f0d0485b11ebce9c54b39a4b,0,48:8dafe164f0d0485b11ebce9ca0312b66,((1,45:8dafe164f0d0485b11ebce9c54b39a4f,"Ping direction statistics: address=[::1]:1560,pingTimeout=15000,pingPeriod=3000,period=10063,packetsSent=3,avgResponseTime=0,maxResponseTime=0,packetsTimedOut=0,packetsLost=0,packetsLostAndFound=1",0,""),(2,45:8dafe164f0d0485b11ebce9c54b39a4e,"16532",0,""),(3,45:8dafe164f0d0485b11ebce9c54b39a4d,"1CV8C",0,"")))',Rows=1,Context='

Справочник.Замеры.Команда.ВыполнитьЗагрузку.МодульКоманды : 11 : ОбновлениеДанныхРегламентное.АвтозагрузкаРегламентное(ПараметрКоманды);
ОбщийМодуль.ОбновлениеДанныхРегламентное.Модуль : 21 : ЗагрузкаФайловТЖ(Замер, ФайлыДляЗагрузки);
ОбщийМодуль.ОбновлениеДанныхРегламентное.Модуль : 170 : ОбновлениеДанных.РазобратьФайлВСправочник(Замер, строкарезультата.ПолноеИмя);
ОбщийМодуль.ОбновлениеДанных.Модуль : 463 : Справочники.СобытияЗамера.ЗаписатьСобытие(СтруктураЗаписи);
Справочник.СобытияЗамера.МодульМенеджера : 13 : СобытиеОбъект.Записать();'
{ОбщийМодуль.ОбновлениеДанных.Модуль(375)}: ВызватьИсключение "Нет соответствия шаблону! " + СтрокаТекста;
{ОбщийМодуль.ОбновлениеДанныхРегламентное.Модуль(170)}: ОбновлениеДанных.РазобратьФайлВСправочник(Замер, строкарезультата.ПолноеИмя);
{ОбщийМодуль.ОбновлениеДанныхРегламентное.Модуль(21)}: ЗагрузкаФайловТЖ(Замер, ФайлыДляЗагрузки);
{Справочник.Замеры.Команда.ВыполнитьЗагрузку.МодульКоманды(11)}: ОбновлениеДанныхРегламентное.АвтозагрузкаРегламентное(ПараметрКоманды);
{Справочник.Замеры.Команда.ВыполнитьЗагрузку.МодульКоманды(4)}: ОбработкаКомандыСервер(ПараметрКоманды);
Оставьте свое сообщение

См. также

Автоматизация анализа файлов технологического журнала Промо

Технологический журнал v8 Россия Абонемент ($m)

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

1 стартмани

14.02.2012    33932    77    Aleksey.Bochkov    18    

Просмотр файлов технологических журналов 1С (WinAPI)

Производительность и оптимизация (HighLoad) Технологический журнал v8 Россия Абонемент ($m)

Программа просмотра файлов технологических журналов 1С (WinAPI). Работает с большими файлами. Минимальное потребление памяти при индексировании данных, просмотре. Анализ управляемых взаимоблокировок, таймаутов, ожиданий. Фильтры по событиям, периоду, пользователям, соединениям, сеансам.

1 стартмани

24.08.2021    1147    6    sdf1979    2    

Powershell: Анализ технологического журнала. Топ-25 вызовов.

Технологический журнал v8 Абонемент ($m)

Использование Powershell для анализа технологического журнала 1с. Пример получения топ-25 вызовов

1 стартмани

16.06.2021    3724    1    Dimashiro    15    

Оперативный мониторинг управляемых блокировок и серверных вызовов кластера 1С (windows сервис BETA расширения функционала конфигурации "Центр Контроля Качества")

Технологический журнал ЦКК v8 v8::blocking Абонемент ($m)

Windows сервис расширения функционала счетчиков производительности конфигурации "Центр Контроля Качества". Собирает и агрегирует информацию из технологического журнала об управляемых блокировках (TLOCK, TDEADLOCK, TTIMEOUT), а так же серверных вызовов (CALL в разрезе p:processName для процессов rphost и в разрезе IName для процессов ragent и rmngr). Агрегированная информация каждую минуту отправляется по http в конфигурацию ЦКК и там представлена в виде счетчиков производительности.

1 стартмани

29.03.2021    1864    1    sdf1979    0    

Чтение логов технологического журнала Промо

Технологический журнал v8 Россия Абонемент ($m)

Обработка позволяет читать логи технологического журнала и формировать на основании данных отчет.

1 стартмани

24.04.2009    42295    2137    Широкий    127    

Длина ключа индекса превышает максимально допустимую. Решение с использованием технологического журнала

Тестирование и исправление Технологический журнал v8 1cv8.cf Россия Абонемент ($m)

При разработке конфигурации в клиент-серверном варианте могут возникнуть проблемы при загрузке конфигурации в файловый вариант. В статье описан один из вариантов решения проблемы.

1 стартмани

28.01.2020    6061    3    newtraveller    0    

Elastic + filebeat + ТЖ 1С

Журнал регистрации Поиск данных Абонемент ($m)

Рассмотрим как можно обрабатывать удобно большой объем информации с простой структурой. Это удобно для анализа логов ТЖ, поскольку типовыми механизмами он невозможен.

1 стартмани

18.06.2019    23587    45    pashamak    32    

V8 Log Scanner - утилита для быстрого парсинга логов ТЖ

Сервисные утилиты Технологический журнал v8 Россия Абонемент ($m)

Как можно быстро настраивать logcfg.xml и парсить логи технологического журнала с помощью самописной open-source утилиты V8LogScanner. Без необходимости погружаться в регулярные выражения.

1 стартмани

07.11.2017    24041    5    ripreal1    27    

Techlogqueryviewer - Вьювер запросов к СУБД из технологического журнала 1С: Предприятие

Технологический журнал v8 1cv8.cf Абонемент ($m)

Обработка для отображения текстов запросов, формируемых платформой 1С: Предприятие в том виде, в каком они должны быть выполнены на СУБД. Тексты запросов обработка получает из технологического журнала по мере их там постепенного появления. Генерация запросов может вестись как в обычном, так и в управляемом режиме, но сама обработка работает только в обычном режиме.

1 стартмани

14.08.2016    8518    9    KAV2    8    

Парсер технологического журнала 1С

Технологический журнал v8 1cv8.cf Россия Абонемент ($m)

Простой, шустрый и легкий в использовании off-line парсер технологического журнала 1С.

5 стартмани

06.12.2015    23888    94    sarycheff    29    

Анализ технологического журнала утечек памяти

Технологический журнал v8 1cv8.cf Абонемент ($m)

Конфигурация предназначена для отчитки файлов технологического журнала и помещения данных в базу для дальнейшего анализа. Есть аналоги данного творения, но эта конфигурация заточена только именно для анализа действий CALL и LEAKS. Если заинтересовались, заходим в подкаст.

1 стартмани

14.11.2015    20411    71    logarifm    13    

Анализ технологического журнала

Технологический журнал v8 1cv8.cf Абонемент ($m)

Конфигурация, облегчающая анализ технологического журнала 1С: Предприятие 8 посредством загрузки данных технологического журнала в базу с последующей возможностью анализа при помощи специализированного отчета.

1 стартмани

19.08.2015    15451    187    liurn    8    

Технологический журнал

Технологический журнал v8 1cv8.cf Абонемент ($m)

Как получить правильный logcfg.xml

1 стартмани

11.01.2013    39479    253    romansun    14    

Анализ исключений в технологическом журнале 8.2

Технологический журнал v8 1cv8.cf Россия Абонемент ($m)

Конфигурация позволяет загружать данные технологического журнала извлекая из него исключения (EXCP) и сохраняет их в базу данных, при сохранении производится парсинг, класиффицирующий ошибки по уже известным. Позволяет постфактум проанализировать статистику работы системы, выявить проблемы, оценить мероприятия по отказоустойчивасти Функционал: 1. Анализируется технологический по событиям EXCP и CALL. Загрузка производится из сетевого каталога на стороне сервера 2. По вхождению подстроки в событие определяется «тип ошибки» (справочник заполняется пользователем) 3. В случае добавления в спр новой типовой ошибки – можно повторно пропарсить уже загруженные события 4. Есть свертка базы (удаление записей с датой менее ДатаЧ) 5. Объединено с БСП, использованы подсистемы: отчетов и обновлений

1 стартмани

13.06.2012    10486    100    xoxland    5    

Парсинг технологического журнала 1С средствами SQL CLR

Технологический журнал v8 1cv8.cf Россия Абонемент ($m)

В статье рассказывается о том как реализовать парсинг (разбор) файлов технологического журнала c помощью SQL CLR, а также настроить хранение информации из него в базе данных. В статье приведен полный листинг функции, а также примеры использования.

1 стартмани

29.11.2011    20400    261    squad    25