DaJet Exchange: обмен данными с 1С (часть 1)

10.02.21

Интеграция - Внешние источники данных

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

Наиболее нетерпеливые могут сразу перейти к разделу "Практика" =)

Вторая часть (продолжение): "DaJet Exchange: двусторонний обмен РИБ (часть 2)"

В своих публикациях "Планы обмена 1С" и "Анализ блокировок СУБД: таблица изменений плана обмена 1С" я подробно анализирую архитектуру планов обмена 1С. Этот типовой механизм обмена данными имеет ряд существенных недостатков, которые особенно ярко проявляются при интенсивных обменах в больших информационных системах. Для преодоления этих недостатков возникает вопрос об использовании альтернативных механизмов обмена данными.

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

Отмечу лишь только то, что некоторые из этих решений используют в качестве альтернативы планам обмена регистрацию изменений объектов 1С в регистрах сведений, которые они используют в качестве таблиц-очередей. Для получения представления о технических подробностях реализации этой методики можно обратиться к моим публикациям: "Планы обмена 1С" (раздел "Альтернатива планам обмена") и "Использование таблиц SQL Server в качестве очередей сообщений".

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

Забегая вперёд, я хочу сказать, что методика использования регистров сведений в качестве таблиц регистрации изменений имеет свои недостатки и является, по моему мнению, не полным решением проблемы.

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

Информационная база (узел обмена) 1С выполняет только три функции:

- регистрация изменений объектов 1С;

- формирование сообщения об изменении в формате JSON;

- помещение сообщения в исходящую очередь в одной транзакции с изменением объекта 1С.

Наиболее важным требованием является то, что любые операции по обмену данными должны выполняться без ожиданий на блокировках СУБД!

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

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

 
1. Регистрация изменений.
 
2. Правила публикации.
 
3. Целостность регистрации и публикации изменений.
 
4. Формирование тела сообщения.
 
5. Публикация сообщения.
 
6. Экспорт сообщений во внешнюю систему обмена данными.
 
7. Параллельная выгрузка данных.
 
8. Восстановление узла обмена 1С после сбоя.
 
9. Практика.
 
Послемыслие. 
 
Дополнение от 22.01.2021

DaJet Exchange Agent

Агент обмена данными для выгрузки сообщений из SQL Server,

на котором работает сервер 1С с подсистемой DaJet Exchange.

Из справочника DaJetExchangeQueue в очередь RabbitMQ.

Реализован режим онлайн (риалтайм) обмена данными.

Агент может быть установлен как Windows сервис.

Дистрибутив можно скачать здесь.

 

 

DaJet Exchange обмен данными интеграция планы обмена

См. также

Перенос данных из Парус 10 в ЗГУ ред.3

Внешние источники данных Кадровый учет Файловый обмен (TXT, XML, DBF), FTP Обмен между базами 1C Платформа 1С v8.3 Сложные периодические расчеты 1С:Зарплата и кадры государственного учреждения 3 Государственные, бюджетные структуры Россия Бухгалтерский учет Бюджетный учет Платные (руб)

Обработка позволяет перенести кадровую информацию и данные по заработной плате, фактических удержаниях, НДФЛ, вычетах, страховых взносах из базы Парус 10 учреждений в конфигурацию 1С:Зарплата и кадры государственного учреждения ред. 3 (ЗГУ) и начать с ней работать с любого месяца года.

60000 руб.

05.10.2022    9156    9    8    

10

Перенос данных из Парус 8 в ЗГУ 3

Зарплата Внешние источники данных Бюджетный учет Платформа 1С v8.3 Сложные периодические расчеты 1С:Зарплата и кадры государственного учреждения 3 Государственные, бюджетные структуры Россия Бухгалтерский учет Бюджетный учет Платные (руб)

Обработка позволяет перенести кадровую информацию и данные по заработной плате, фактических удержаниях, НДФЛ, вычетах, страховых взносах из базы Парус 8 учреждений в конфигурацию 1С:Зарплата и кадры государственного учреждения ред. 3 (ЗГУ) и начать с ней работать с любого месяца года.

84000 руб.

19.08.2020    22354    18    1    

21

Автоматическая многопоточная выгрузка данных 1С 8.3 в БД Clickhouse и MS SQL (для работы с данными 1С в BI-системах)

Внешние источники данных Платформа 1С v8.3 Управляемые формы Анализ и прогнозирование Конфигурации 1cv8 Узбекистан Беларусь Кыргызстан Молдова Россия Казахстан Платные (руб)

Готовое решение для автоматизированной выгрузки данных из 1С 8.3, а также MS Excel в базу данных ClickHouse, а также в Microsoft SQL для работы с данными 1С в Yandex Datalens, Visiology, Apache Superset (и не только) - "Экстрактор данных 1С в BI". Решение отлично работает со всеми типовыми (и не только) конфигурациями 1С 8.3 для управляемых форм. Gозволяет автоматизировать работу бизнес-аналитика по ежедневной выгрузке данных из 1С в БД ClickHouse для последующей работы с этой БД в Yandex Datalens/ Система полностью автоматизирует работу с хранилищем данных в БД Clickhouse/MS SQL. Не надо быть программистом, чтобы одной кнопкой получать любые данные из 1С в Вашей BI-системе

230000 руб.

15.11.2022    12920    12    47    

28

Перенос данных из Парус 7.хх в ЗГУ ред.3

Внешние источники данных Зарплата Бюджетный учет Платформа 1С v8.3 Сложные периодические расчеты 1С:Зарплата и кадры государственного учреждения 3 Государственные, бюджетные структуры Россия Бухгалтерский учет Бюджетный учет Платные (руб)

Обработка позволяет перенести кадровую информацию и данные по заработной плате, фактических удержаниях, НДФЛ, вычетах, страховых взносах из базы Парус 7.хх учреждений в конфигурацию 1С:Зарплата и кадры государственного учреждения ред. 3 (ЗГУ) и начать с ней работать с любого месяца года.

24000 руб.

24.04.2017    48631    96    159    

86

Перенос начальных остатков из Парус 7.71 в БГУ

Внешние источники данных Взаиморасчеты Учет ОС и НМА Логистика, склад и ТМЦ Бюджетный учет Платформа 1С v8.3 Бухгалтерский учет 1С:Бухгалтерия 2.0 1С:Бухгалтерия государственного учреждения Государственные, бюджетные структуры Россия Бюджетный учет Платные (руб)

Перенос словарей и начальных остатков из ПП Парус-Бухгалтерия Бюджет 7.71 в 1Сv8 БГУ2. Заполнение словарей и документов по вводу начальных остатков. Не требуется установка ПП Парус7. Возможна дозагрузка. Позволит автоматически и наиболее полно ввести данные в программу для начала работы. 

15600 руб.

08.12.2011    81473    128    123    

146

Перенос данных из Парус 10 (Торнадо) в ЗГУ ред.3 через Excel

Внешние источники данных Загрузка и выгрузка в Excel Зарплата Бюджетный учет Платформа 1С v8.3 Сложные периодические расчеты 1С:Зарплата и кадры государственного учреждения 3 Государственные, бюджетные структуры Россия Бухгалтерский учет Бюджетный учет Платные (руб)

Обработка позволяет перенести кадровую информацию и данные по заработной плате из Парус 10(Торнадо) учреждений через файлы Excel в конфигурацию 1С:Зарплата и кадры государственного учреждения ред. 3 (ЗГУ). В принципе, обработка может быть использована для загрузки из файлов Excel, полученных из любых информационных систем.

24000 руб.

16.11.2018    29981    20    31    

21
Комментарии
В избранное Подписаться на ответы Сортировка: Древо развёрнутое
Свернуть все
1. dabu-dabu 289 15.01.21 17:05 Сейчас в теме
А почему вы предлагаете использовать справочник, а не документ? Ведь у документа есть момент времени
2. zhichkin 1429 15.01.21 18:21 Сейчас в теме
(1) По той же причине, по которой я не рекомендую использовать периодический регистр сведений. Округление даты документа на уровне SQL Server выполняется до секунд, а не миллисекунд.

Индекс документа по дате и ссылке (уникальный):
1. _Date_Time
2. _IDRRef
3. _Marked

Индекс документа по номеру и ссылке (уникальный):
1. _Number
2. _IDRRef

Индекс по номеру и ссылке будет равнозначен индексу справочника по коду и ссылке (см. в тексте статьи), если номер документа будет числом.

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

В итоге получается примерно такой индекс (уникальный):
_Fld106
_IDRRef
3. zhichkin 1429 15.01.21 19:17 Сейчас в теме
(1) Честно говоря, я не люблю и не советую привязывать последовательность событий в той или иной форме к системной дате сервера. Дело в том, что если время сервера по как-то причине собъётся, то могут возникнуть трудно преодолимые последствия. В моей практике (более 14 лет) такой случай имел место быть. Это было очень неприятно и к тому же замечено не сразу. В итоге пришлось выполнять сверку и синхронизацию достаточно большого объёма данных между базами источника и приёмника.

Ещё раз повторюсь: я рекомендую, по возможности, использовать объект SQL Server SEQUENCE.
4. vdscom 20 17.01.21 16:43 Сейчас в теме
Добрый день

Информационная база (узел обмена) 1С выполняет только три функции:
- регистрация изменений объектов 1С;
- формирование сообщения об изменении в формате JSON;
- помещение сообщения в исходящую очередь в одной транзакции с изменением объекта 1С.


Как по мне, достаточно регистрировать только факт изменения объекта, а сами изменения получать в момент чтения записи об изменениях из исходящей выборки. в таком случае не надо беспокоиться о том, что выгрузится старая версия объекта. Или существует какая то необходимость в обязательном порядке последовательно выгружать всю историю изменений объекта ?

Что касаемо совместной регистрации изменений документа и его движений, для обеспечения когерентности выгружаемых данных предлагаю при изменении данных регистра накопления или регистра сведений, подчиненного регистратору, регистрировать в очереди сообщений изменения самого регистратора. Разумеется, в таком случае выгружаться документ должен со всеми своими движениями. Для независимого регистра сведений регистрироваться должен ключ записи для этого регистра.

Во всяком случае, именно так я реализовывал свою регистрацию изменений для обмена
5. zhichkin 1429 17.01.21 17:40 Сейчас в теме
(4) Регистрация ключа изменённого объекта (факта изменения объекта) называется отслеживанием изменений без данных. Описание того, какие варианты отслеживания изменений существуют и какие у них особенности, есть в моих статьях, на которые в данной публикации я даю множественные ссылки.

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

Как реализовать отслеживание изменений без данных, как Вы предлагаете, и при этом избежать блокировок на таблице регистрации изменений описано во всё тех же моих статьях. Образцово-показательной реализацией этой стратегии можно считать механизм Change Tracking SQL Server.

По второму замечанию согласен с Вами. В статье дополнительно указываю на то, что зависимости объектов между собой могут быть сложнее, чем просто "документ и его движения". Кроме этого бывают ещё регистры сведений, где документ является ведущим измерением, а также имеющие схожую логику зависимости.
8. vdscom 20 17.01.21 21:52 Сейчас в теме
(5)

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

Навскидку могу предположить, что указанная ниже структура измерений регистра сведений, регистрирующего изменения, позволит избежать блокировок:
Объект,
ВерсияОбъекта (или время регистрации, в миллисекундах),
УзелОбмена

При чтении из регистра сведений выбираем все записи по узлу обмена, сворачиваем по объекту, получаем и переносим актуальные на текущий момент данные, очищаем эти записи. Если объект будет повторно изменен в момент выполнения обмена, в регистре появится новая запись по этому объекту, без конфликта блокировок

По второму замечанию согласен с Вами. В статье дополнительно указываю на то, что зависимости объектов между собой могут быть сложнее, чем просто "документ и его движения". Кроме этого бывают ещё регистры сведений, где документ является ведущим измерением, а также имеющие схожую логику зависимости.

Полагаю, что для решения проблемы сложных зависимостей данные нужно регистрировать и переносить не пообъектно, а потранзакционно
9. zhichkin 1429 17.01.21 22:25 Сейчас в теме
(8) Всё верно. Примерно так и работает механизм Change Tracking SQL Server. Там есть некоторые нюансы, но в целом всё так, как Вы описываете. Хорошая статья на эту тему: https://docs.microsoft.com/en-us/sql/relational-databases/track-changes/work-with-change-tracking-sql-server?view=sql-server-ver15

Потранзакционная регистрация, как Вы говорите, возможна конечно же. В таком случае в коде 1С надо явно управлять транзакцией и присваивать ей как-то свой идентификатор. Однако это не всегда возможно сделать абсолютно правильно.
6. dsdred 3231 17.01.21 19:35 Сейчас в теме
Хотелось бы ещё отметить, что использование справочника позволяет в некоторых случаях использовать его реквизит "ВерсияДанных", о чём я буду писать ниже.

Этот реквизит есть и у документов, и у справочников, поэтому на счет справочника не убедили.


ДанныеСообщения = ПрочитатьСообщениеИзИсходящейОчереди();
Попытка
   НачатьТранзакцию();
   ОтправитьСообщениеВоВнешнююСистему(ДанныеСообщения);
   УдалитьСообщениеИзИсходящейОчереди();
   ЗафиксироватьТранзакцию();
Исключение
   ОтменитьТранзакцию();
КонецПопытки;
Показать


Читаем тут https://its.1c.ru/db/v8std/content/783/hdoc
И делаем так:
ДанныеСообщения = ПрочитатьСообщениеИзИсходящейОчереди();
НачатьТранзакцию();
Попытка   
   ОтправитьСообщениеВоВнешнююСистему(ДанныеСообщения);
   УдалитьСообщениеИзИсходящейОчереди();
   ЗафиксироватьТранзакцию();
Исключение
   ОтменитьТранзакцию();
КонецПопытки;
Показать



В остальном еще одна вариация обмена.
Нечто подобное делал, используя все-таки план обмена с одним общим узлом для аккумулирования данных, далее по регламенту их распихивал по узлам в зависимости от отборов и далее бил на порции и складывал в формате JSON в регистр сведений. Плотно использовал "ВерсияДанных" и еще Кеш использовал для понимания поменялось ли что-то.
Рассказывал про это на Митапе в Екатеринбурге в мае.
eeeio; zhichkin; +2 Ответить
7. zhichkin 1429 17.01.21 20:24 Сейчас в теме
(6) Спасибо за очень информативный и конструктивный комментарий.

Спасибо за ссылку про использование транзакций. Абсолютно согласен. Внёс изменение в статью.

По поводу справочник или документ использовать я соглашаюсь с тем, что это равнозначно, в своём комменатрии № 2.

По поводу плана обмена с одним узлом и дальнейшим "перекладыванием" данных в регистр сведений могу сказать, что такое решение используют некоторые известные продукты. Я с ними знаком. Однако это не решает полностью проблемы блокировок на таблицах изменений.
Кроме этого, в своей статье я этот случай косвенно разбираю и объясняю где может подстерегать опасность. Посмотрите, пожалуйста, пункт 6 "Экспорт сообщений во внешнюю систему обмена данными". Абзац начинается со слов: "Поясню, что я имею в виду..." и далее. Думаю надо будет расписать этот вариант подробнее. Сделал себе пометку.

Было бы очень интересно ознакомиться с Вашим выступлением на упомянутом Вами митапе. Если есть возможность, поделитесь, пожалуйста, ссылкой.
10. user1513128 18.01.21 16:33 Сейчас в теме
Есть ли сравнительный анализ пунктов 1 - 3 со штатным механизмом планов обменов?
11. zhichkin 1429 18.01.21 17:04 Сейчас в теме
(10) Если внимательно прочитать эту статью и мои статьи "Планы обмена 1С" + "Анализ блокировок СУБД: таблица изменений плана обмена 1С", то всё должно быть достаточно понятно. Я думаю, что я не понимаю как ответить на Ваш вопрос =)
12. user1513128 25.01.21 13:41 Сейчас в теме
(11)Статьи без сомнения обширные, но хотелось бы узнать результат в ужатом виде - например 1000 док. в минуту не критически влияет на работу при стандартном механизме и т.д.
13. zhichkin 1429 25.01.21 23:46 Сейчас в теме
(12) С конкретными цифрами не так просто. Всё очень сильно зависит от конфигурации 1С, используемого оборудования, интеграций со сторонними системами и т.п.

Кроме того, когда Вы говорите "1000 док. в минуту", то что Вы имеете в виду ? Сколько табличных частей в документе ? Сколько строк в каждой табличной части ? Сколько узлов РИБ участвует в обмене или это обмен только между бухгатерией и торговлей ? И так далее ... Нужна конкретика.

Тем не менее, отвечая на Ваш вопрос и опираясь только на свой опыт могу сказать следующее: стандартная эксплуатация 1С торговой организацией начинает испытывать серьёзные проблемы при 100 узлах РИБ +/- 25 узлов. Обычно при достижении этих цифр начинают думать чем заменить РИБ или из звезды начинают лепить снежинку. Перефразируя известное изречение: "Ёжики плакали, кололись, но с кактусов не слезали."
14. user1513128 26.01.21 13:04 Сейчас в теме
1ска и не позиционируется как высоконагруженная система, 100 узлов это весьма не мало при значительной нагрузке. Нестандартные решения спасают, но сопровождать их несколько сложней., спасибо за детальные статьи.
Оставьте свое сообщение