Как сделать обмен данными через универсальный формат быстрее? Реализация многопоточного обмена данными

0. 6318 30.12.19 22:59 Сейчас в теме
Предлагаю Вашему вниманию интересный кейс по реализации обмена данными через универсальный формат между современными типовыми конфигурациями в режиме многопоточности. Учитывая все тонкости механизмов обмена данными и сложности типовых правил конвертации, сделать это оказалось совсем не так просто.

Перейти к публикации

Комментарии
В избранное Подписаться на ответы Сортировка: Древо развёрнутое
Свернуть все
1. YPermitin 10487 31.12.19 12:32 Сейчас в теме
(0) Мощная реализация.

А у скольких компаний такое используется?

P.S. С наступающим! )
ids79; pavelpribytkin96; +2 Ответить
2. Mick2iS 304 31.12.19 16:07 Сейчас в теме
(1) С Наступающим, Коллеги!

Многопоточные обмен и обработки в продукте 2is:Интеграция появились в 2015 году и тогда же были обкатаны на ряде весьма крупных проектах. Т.е. сам подход к многопоточности (распараллеливанию) универсален и его можно применять в любых обработках. Готовые примеры распараллеливания из 2iS: замена дублей в базах, удаление объектов по условиям, проведение документов и формирование проводок (где нет завязки на последовательность), обмены по разным сценариям и т.д.
Таким образом, многопоточность, как инструмент применяют все кто используют продукт с 2015 года (замечу, что при обмене данными, многопоточность включается автоматически при достижении заданного размера очереди, по умолчанию это 1000 объектов).
В настоящей статье, Дмитрий описал пилотный проект (т.е. первый:-) по применению данного подхода к обмену в универсальном формате EnterpriseData (КД3) и раскрыл имеющиеся подводные камни на пути к его реализации.
Поддержка многопоточного обмена в формате EnterpriseData (КД3) была включена в один из последних релизов 2is:Интеграции и, таким образом, уже доступна в тиражном решении. Статья будет полезна также тем, кто собирается внедрять данную функциональность.
ids79; YPermitin; +2 Ответить
4. YPermitin 10487 31.12.19 18:38 Сейчас в теме
(2) благодарю за развернутый ответ.

Эх, пощупать бы это все. Но проектов "в доступности" таких нет.

+
8. ids79 6318 03.01.20 18:17 Сейчас в теме
(4)Можно посмотреть саму Интеграцию, как там все это устроено. Код открыт за исключением одного модуля, где проверяется лицензия. Также можно протестировать и погонять на реальных данных с trial ключом.
3. MaxS 2181 31.12.19 17:33 Сейчас в теме
С наступающим!
Данные в плане обмена регистрируются же порциями, соответственно так же можно разбивать на порции при обмене.
Ещё как вариант - анализировать данные - связанные документы и справочники направлять в один поток.
Ещё полезно было бы организовать очередь. В числе первых обмениваться справочниками, потом документами.

По поводу сравнения скорости обмена КД2 и КД3. Где-то была статья с замерами. КД3 на 20% была быстрее. Сам пока не проверял. Субъективные ощущения, что разницы почти нет. А файл с универсальным форматом выглядит лаконичнее и читабельнее. И с учетом ограничения формата, реквизитов на каждый объект минимальное достаточное количество.

В типовом обмене, если использовать ручной запуск кнопкой Синхронизировать. Время обмена увеличивается в 2 раза. Первый - предварительно прочитать файл и выдать диалог синхронизации, второй раз данные читаются для непосредственной загрузки в базу.
7. ids79 6318 03.01.20 18:12 Сейчас в теме
(3)Я тоже не делал замеры, но по моим субъективным ощущением, обработка правил КД2 по быстрее. Может быть сама передача файла КД2 будет медленнее, так как правила нужно передавать в файле.
5. Yashazz 3742 01.01.20 14:56 Сейчас в теме
Я вот только одного не понимаю. Сначала всё усложнили, а потом героически боремся с этими сложностями. Зачем вообще использовать для больших объёмов с ограничениями времени типовой обмен? Пишем свой и живём спокойно, не завися от блажи создателей БСП в очередном релизе и степени их криворукости. А так - ну подсчитайте накладные расходы на извращения вокруг БСП и на написание своего с чистого листа, и увидите: своё побыстрее и попроще будет.
ybatiaev; Mick2iS; dsdred; Fox-trot; Lancelot-2M; Sherwood; +6 Ответить
6. ids79 6318 03.01.20 18:08 Сейчас в теме
(5)Да, свой безусловно быстрее будет.
Но если много документов и справочников, то это трудоемкий процесс получится.
Решением может стать перенос нескольких особо тяжелых документов с помощью не типового спец. обмена, а остальное типовым делать.
У меня была еще мысль вообще отказаться от XDTO. Зашить описание формата в общий модуль и использовать JSON. Уже собрался делать, но результаты тестов показали, что больше всего времени уходит не на работу с XDTO, а на обработку правил конвертации, от которых все равно никуда не денешься. Ускорение если и получится, то незначительное. Так что отказался от этой идеи.
Может быть разработчики со временем сделают возможность опционально использовать или XDTO или JSON.
9. Mick2iS 304 04.01.20 16:03 Сейчас в теме
(6) Я делал замеры, когда JSON только появился в платформе - разницы с xml \ xdto сериализацией практически не было (места меньше, но читабельность сильно хуже) и да - это менее 2% от процесса, далее, по-нормальному, 48% занимает конвертация по правилам, и наконец 50% - обработка данных после загрузки (дозаполнение, проведение и т.п.). Последняя, очевидно, должна быть вынесена в отдельный асинхронный поток, дабы не замедлять обмен данными...
10. Mick2iS 304 04.01.20 16:15 Сейчас в теме
Напишите ваше сообщение
(5) Если под "своим обменом" понимать разработку правил с нуля на КД2, с заточкой под конкретную бизнес-логику (читай, сильно доработанными типовыми), то согласен - будет и работать быстрее и разработка займет меньше времени...
Выше описан реалистичный и наиболее частый из практики случай - "когда-то было типовым" и "так исторически сложилось"))
11. Yashazz 3742 04.01.20 17:42 Сейчас в теме
Люди добрые, да зачем вам КД вообще, хоть 2, хоть 3? Своё от начала до конца, и это вовсе не столь трудоёмко, как кажется! Меня тоже запугивали на одном проекте, мол, без КД вилы, а там засчёт отказа от кд-шных принципов обработки данных и скорость повысить удалось (точные проценты не скажу, уже не помню), и надёжность, и ресурсоёмкость. Ясное дело, при небольших задачах КД наше всё, но не делайте из неё панацею)
ybatiaev; +1 Ответить
12. Константин С. 686 08.01.20 15:21 Сейчас в теме
(11)
ость. Ясное дело, при небольших задачах КД наше всё, но не делайте из неё панацею)

Но еще нужно не забывать о дальнейшей поддержке рабочей системы. Понятности что происходит и простоты модернизации.
А то один такой умник внедренец (это не оскорбление, а реальная оценка), а после ищи кто сможет это сопровождать.
13. Yashazz 3742 08.01.20 18:22 Сейчас в теме
(12) Делать надо нормально, структурированно и прозрачно. По-умному делать. И инструкции да схемы после себя оставлять, документировать нормально. Тогда любой грамотный спец за пару дней вникнет и сможет сопровождать.

А то есть такие умники, например, бсп накатали, а внутри хрен разберёшься, и описаний внятных нет, несмотря на раскрутку и типа универсальность. И ищи, кто сможет это сопровождать. Да ещё загибающееся от собственных наворотов и переделок.

Я это к чему - если спец хороший и объёмы адские, то, разумеется, свой обмен выигрышнее. В том числе по дальнейшей поддержке и доработке. А если пионэры, то они и в КД так наколбасят, что чёрт ногу сломит.
nik2500; ybatiaev; +2 Ответить
15. ybatiaev 54 22.01.20 17:40 Сейчас в теме
(13) Поддержу Вас! Если спец, то он и в КД разберётся и в чужом коде. У нас так, если стандартный обмен, то он и есть стандартный, что тут рожать, а если с закавыками, то проще заложить в обработку. С JSON трафик меньше, читабельность лучше, преобразование проще(на мой взгляд быстрее). А львиная доля времени затрачивается на проверки, поиски, сравнения, особенно, если бухгалтера не понимают, что чем безалабернее ведутся справочники, тем дольше ищется (с доп проверками)
14. NoRazum 28 09.01.20 12:16 Сейчас в теме
К большому сожалению, разработчики типового обмена данными, сделали его достаточно сложным. В типовых правилах очень активно используется создание виртуальных объектов при выгрузке, создание объектов «на лету» при загрузке, сохранение большого числа коллекций с объектами и их последующая обработка. По всей видимости они не задумывались над возможным использованием этого механизма в многопоточном режиме, а очень зря.


имхо: Они походу ВООБЩЕ НЕ ДУМАЛИ. Думали только чтоб целостность данных была.
Чуть больше объем и даже хорошее железо не спасает.
ybatiaev; +1 Ответить
16. titanium2008 22 19.02.20 15:21 Сейчас в теме
Воспрос - например у меня есть обмен через КД 3 между УТ и БП. Можно ли вынести пакет EnterpriseData и общие модули правил обмена в отдельную конфигурацию и при помощи данной конфигурации инициировать обмен? К кому можно обратиться чтобы посмотреть 2is интеграцию с КД 3?
17. acanta 19.02.20 15:25 Сейчас в теме
Планы обмена с ED в любом случае стыкуются исключительно вручную. Подтверждение о получении пакета есть в РИБ?
Оставьте свое сообщение
Вопросы с вознаграждением