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

31.12.19

Интеграция - Обмен между базами 1C

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

Коллеги, во первых, всех с Наступающим Новым Годом! Желаю всем успехов и побольше хорошего настроения в новом году. 

Тема многопоточности часто возникает на крупных предприятиях во время выполнения различных регламентных процедур. Например закрытие месяца или перенос данных из одной базы в другую. Бывают даже случаи, когда механизм обмена данными выполняясь в фоновом режиме постоянно в реальном времени, не успевает перенести все создаваемые объекты.

Это может стать серьезной проблемой. Увеличивать мощность сервера до бесконечности не всегда правильный вариант. Более правильно распараллелить процессы выгрузки и загрузки данных и выполнять их одновременно.

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

 

Многопоточный обмен данными

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

В данной статье я хочу описать реализацию многопоточного обмена данными между типовыми конфигурациями ЕРП 2.4 и БП 3.0. Все «грабли» и неприятности с которыми пришлось столкнуться, а также способы их устранения.

Спасибо сотрудникам компании 2iS и их продукту 2iS:Интеграция 2.0, который является основным звеном разработки.

Отдельное спасибо сотрудникам компании РЕМИ в лице Дмитрия Кирилкина за помощь в тестировании и поиску «узких мест» механизма.   

Я здесь не буду рассматривать подробно продукт 2iS:Интеграция. Продукт уже достаточно давно на рынке, имеет много документации, и тем кому интересно, тот может самостоятельно его изучить. Если кратко, 2iS:Интеграция позволяет выполнять различные встроенные в нее обработки во внешних информационных базах. Это может быть запуск механизмов обмена, формирование отчетов, обработка документов и выполнение любых необходимых операций. Подключение к информационным базам выполняется через COM. Это не единственный способ подключения, но он является основным.

Уже чувствую гневные возгласы на счет целесообразности использования COM и DCOM в эпоху HTTP и WEB сервисов, ODada и JSON. Скажу сразу, я с этим согласен с некоторыми оговорками. Но, в данной статье я не буду касаться этого вопроса, и приму его как данность. Тем, кому интересно узнать плюсы и минусы реализации взаимодействия через COM в 2iS:Интеграции, смотрите в этой статье.

В 2iS:Интеграции реализовано много полезных сервисов, таких как сохранение контекста подключения между сеансами обмена, обработка различных исключительных ситуаций, обратная связь для передачи информации о ходе выполнения и прочее.

Отдельно стоит отметить механизм разбиения данных на порции и выполнение обменов данными в многопоточном режиме. Многопоточный обмен через 2iS:Интеграцию уже успешно зарекомендовал себя в связке с правилами конвертации КД2 для выполнения обменов между распределенными базами (РИБ) и базами с отличающимися конфигурациями.

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

 

Архитектурные особенности

Общая схема процесса выгрузки данных

Выгрузка данных

 

Общая схема процесса загрузки данных

Схема загрузки данных

 

Основной и базовый механизм программного продукта 2iS:Интеграции, который выполняет все сервисные функции, такие как запуск обработок обмена, разбиение данных на порции, запуск и отслеживание выполнения в отдельных потоках, вывод информации о прогрессе выполнения - называется Сервисный процессор.

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

 

Произвольный алгоритм выборки данных

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

Мы реализовали следующий алгоритм выборки данных:

  1. Объекты не являющиеся документами (элементы справочников, планов видов характеристик) – выгружаются всегда первыми и в полном объеме. Это необходимо для корректной загрузки и проведения документов.
  2. Данные, которые были выгружены ранее, и по ним не получено подтверждение загрузки – необходимо выгружать эти данные первыми, чтобы они не были потеряны в результате обмена. Потеря данных может произойти в случае, если будут выгружены другие данные и получено подтверждение по ним с более большим номером отправленного сообщения. 
  3. Остальные объекты (документы) - в объеме не превышающем максимальный объем выгружаемых объектов.

 

Распределение данных по порциям 

Сам механизм распределения по порциям происходит следующим образом:

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

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

 

Процесс выгрузки и загрузки данных

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

За прототип обработки, которая выполняет сам обмен данными (выгрузку и загрузку) нами была взята типовая обработка «ВыгрузкаЗагрузкаОбъектовXDTO», которая есть во всех типовых конфигурациях.

Дальше есть два подхода к реализации:

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

Нами был выбран второй вариант. При необходимости можно реализовать и первый, достаточно быстро.

В обоих вариантах можно использовать типовой модуль менеджера обмена через универсальный формат (в котором содержатся правила конвертации) или использовать модуль внешней обработки, которая должна быть загружена в 2iS:Интеграцию.

Сам универсальный формат, на данный момент, можно использовать только встроенный в информационную базу.

 

Основные проблемы реализации многопоточности

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

Ниже я приведу основные сложности, с которыми мы столкнулись, и варианты их устранения.

 

Выгрузка дополнительных «виртуальных» объектов

Достаточно часто в типовых правилах конвертации, построенных на КД3, при выгрузке данных создаются виртуальные элементы справочников. Это те элементы которые должны быть в базе получателя и которых нет в базе отправителя. Примером такого поведения может быть выгрузка из конфигурации ERP документа «Приобретение товаров и услуг». В файл обмена могут быть выгружены виртуальные договоры если в ERP поступление оформлено без указания договора (такое возможно в зависимости от настроек).

На этапе загрузки данных, система будет пытаться найти такие договоры в базе Приемнике по полям поиска. Если данные найдены, то они обновляются. Если не найдены – создаются новые элементы. При одновременной загрузке данных в разных потоках, могут возникнуть следующие проблемы:

  1. Возможное дублирование при создании новых элементов справочника, так как при поиске по полям поиска два потока могут начать поиск до записи нового элемента. Это приведет к записи одного и того же элемента дважды.
  2. Если элемент справочника будет найден по полям поиска одновременно в двух потоках то один из них не сможет его записать, так как после получения объекта он будет уже изменен и записан другим потоком (сработает оптимистическая блокировка). 

Аналогичные проблемы могут возникнуть в случае, если в правилах конвертации на этапе загрузки данных предусмотрено создание новых объектов «на лету». Что тоже может встречаться в правилах конвертации.

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

 

Отложенная обработка объектов  

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

Перечислю коротко эти процедуры в порядке их выполнения:

  1. Пометка на удаление объектов – помечаются на удаление все объекты по которым получен признак удаления и не получена загрузка полного объекта,
  2. Удаление временных объектов, созданных по ссылкам – удаление объектов, которые были созданы или найдены по полям поиска, и не были загружены полностью,
  3. Отложенное заполнение объектов – выполнение алгоритмов отложенного заполнения объектов, которые могут быть указаны в правилах для каждого вида объектов,
  4. Обработка события «После конвертации» - выполнение произвольных операций после загрузки всех данных,
  5. Отложенное проведение документов – выполнение проведения загруженных документов,
  6. Отложенная запись объектов – выполнение записи загруженных объектов (не документов) с выполнением всех платформенных проверок и обработчиков.

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

Приведу несколько примеров:

  1. Очень часто перед отложенным заполнением объектов выполняется сортировка всех загруженных объектов по определенному принципу. Соответственно, должен быть список всех загруженных объектов.
  2. При пометке на удаление объектов, или при удалении временных объектов созданных по ссылкам, они могут быть загружены полностью в других потоках.
  3. В алгоритме «После конвертации» есть процедуры такого вида «АктуализироватьПодчиненностьСчетовФактурВыданных». Выполнение этих процедур зависит от связных объектов, которые могут загружаться в других потоках.

Мы решили эту проблему следующим образом:

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

КомпонентыОбмена – это структура, в которую помещаются все данные, необходимые для выполнения обмена. Структура доступна во всех алгоритмах обмена данными. Более подробно читайте в статьях:

Данный подход в целом корректен, но имеет один существенный недостаток. Дело в том, что таблица «ЗагруженныеОбъекты» структуры «КомпонентыОбмена» содержит в себе элементы типа «Объект». Элементы таких типов нельзя сохранить в хранилище общих настроек. Мы были вынуждены очищать поля с типом «Объект» и формировать потом объекты заново.

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

 

Резюме

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

Исходя из всего вышеописанного, можно сделать следующий вывод:

У нас есть рабочий функционал для выполнения обмена данными через универсальный формат в режиме многопоточности между современными типовыми конфигурациями. Но сделать это «из коробки» не получится. В любом случае потребуется дополнительная доработка правил конвертации. Насколько серьезная, это уже зависит от специфики конкретной компании.

 

Есть ли альтернатива?

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

Варианты оптимизации, которые можно использовать:

  1. Кэширование данных из регистра сведений «Публичные идентификаторы синхронизируемых объектов».
  2. Отделение процесса отложенного проведения документов от основного процесса загрузки данных и выполнение его в отдельном потоке.

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

Спасибо за внимание. Если информация, приведенная в статье оказалась полезной или натолкнула кого-то на интересные мысли, очень буду рад!

 

Другие статьи по механизмам обмена данными через универсальный формат:

  1. Теоретическая, вводная статья по EnterpriseData

  2. EnterpriseData  Часть 2. Процесс выгрузки данных

  3. EnterpriseData  Часть 3. Процесс загрузки данных

  4. КД3 - инструкции и примеры, рекомендации 

  5. Пример собственной реализации выгрузки данных в формате EnterpriseData 

  6. Пример доработки правил конвертации данных без использования КД3

обмен данными через универсальный формат многопоточный правилам КД3

См. также

SALE! 20%

Перенос данных из УПП 1.3 в ERP 2 / УТ 11 / КА 2. Переносятся документы, справочная информация и остатки

Обмен между базами 1C Платформа 1С v8.3 1С:Управление производственным предприятием 1С:ERP Управление предприятием 2 1С:Управление торговлей 11 1С:Комплексная автоматизация 2.х Россия Платные (руб)

Перенос документов, начальных остатков и справочной информации из УПП 1.3 в ERP 2 | из УПП 1.3 в УТ 11 | из УПП в КА 2 | Правила конвертации (КД 2) в продаже с 2015 года, постоянно работаем над их развитием | Более 360 предприятий выполнили переход с использованием этого продукта! | Сэкономьте время - используйте готовое решение для перехода! | Позволяет перенести из УПП 1.3 в ERP / УТ 11 / КА 2 всю возможную информацию | В переносе есть фильтр по организации и множество других опциональных параметров выгрузки | Есть несколько алгоритмов выгрузки остатков на выбор

45650 36520 руб.

04.08.2015    159689    363    267    

345

SALE! 15%

[ED3] Обмен для ERP 2.5, КА 2.5, УТ 11.5 БП 3.0, Розница, УНФ и других с EnterpriseData (универсальный формат обмена), правила обмена

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

Правила в универсальном формате обмена для ERP 2.5, КА 2.5, УТ 11.5, БП 3.0, Розница, УНФ, для последних версий конфигураций. Ссылки на другие конфигурации в описании публикации. Правила совместимы со всеми другими версиями конфигураций новыми и старыми, поддерживающими обмен в формате EnterpriseData. Не требуется синхронного обновления правил после обновления другой конфигурации, участвующей в обмене. Типовой обмен через планы обмена кнопкой Синхронизация вручную или автоматически по расписанию, или вручную обработкой.

25080 22572 руб.

12.06.2017    134940    723    291    

388

SALE! 20%

Перенос данных из ERP 2 / КА 2 / УТ 11 в БП 3.0. Переносятся документы, начальные остатки и справочники

Обмен между базами 1C Файловый обмен (TXT, XML, DBF), FTP Платформа 1С v8.3 1С:ERP Управление предприятием 2 1С:Бухгалтерия 3.0 1С:Управление торговлей 11 1С:Комплексная автоматизация 2.х Россия Платные (руб)

Перенос данных из ERP в БП 3 | из КА 2 в БП 3 | из УТ 11 в БП 3 | из ЕРП в БП 3 | В продаже с 2019г. | Воспользовались более 176 предприятий! | Сэкономьте время - используйте готовое решение для перехода! | Перенос разработан в формате КД 2 (правила конвертации данных) | Переносятся все возможные виды документов, начальных остатков и нормативно-справочная информация| Можно опционально выгружать каждую пару "номенклатура+характеристика" как отдельную номенклатуру | Есть выгрузка настроек счетов учета и зарплатных данных из ERP / КА 2 | Можно проверить на вашем сервере перед покупкой, обращайтесь!

34650 27720 руб.

15.04.2019    68420    178    138    

111

SALE! 20%

Перенос данных из ERP 2 / КА 2 в ЗУП 3. Переносятся остатки, документы и справочники

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

Перенос данных из ERP в ЗУП 3 | из КА 2 в ЗУП | Воспользовались более 79 предприятий! | Предлагаем приобрести готовые правила конвертации данных (КД 2) для переноса остатков, документов с движениями и справочной информации 3 | В продаже с 2020г. | Оперативно обновляем правила до актуальных релизов 1С | Есть перенос начальной задолженности по зарплате и начальной штатной расстановки на выбранную дату | Обороты за прошлые годы (данные для расчета среднего) переносятся свернуто в документ "Перенос данных" | Есть фильтр по организациям | Документы за текущий период переносятся сразу с движениями, поэтому не потребуется делать перерасчеты | Перенос можно проверить перед покупкой, обращайтесь!

43450 34760 руб.

03.12.2020    34169    80    58    

78

SALE! 10%

Перенос данных из УТ 10.3 в УТ 11.5. Переносятся документы (обороты за период), справочная информация и остатки

Обмен между базами 1C Файловый обмен (TXT, XML, DBF), FTP Платформа 1С v8.3 Оперативный учет 1С:Управление торговлей 10 1С:Управление торговлей 11 Россия Управленческий учет Платные (руб)

Перенос данных из 1С:Управление торговлей 10.3 в 1С:Управление торговлей 11.5 с помощью правил обмена. Переносятся остатки, документы (обороты за период), справочная информация. Правила проверены на конфигурациях УТ 10.3 (10.3.87.x) и УТ 11.5 (11.5.16.x).

28000 25200 руб.

23.07.2020    46301    196    64    

158

SALE! 10%

Перенос данных из БП 3.0 в УТ 11 / КА 2 / ERP 2. Переносятся начальные остатки, документы и справочники

Обмен между базами 1C Платформа 1С v8.3 1С:ERP Управление предприятием 2 1С:Бухгалтерия 3.0 1С:Управление торговлей 11 1С:Комплексная автоматизация 2.х Россия Платные (руб)

В продаже с 2014г. | Воспользовались более 122 предприятий! | Перенос данных из БП 3.0 в УТ 11 | из БП 3.0 в КА 2 | из БП 3.0 в ERP | Сэкономьте свое время - используйте готовое решение для перехода! | Постоянно работаем над развитием переноса данных | Обновляем на новые релизы 1С | Есть фильтр выгрузки по организациям | Переносятся начальные остатки на выбранную дату, документы за период времени и вся возможная справочная информация | Перенос сделан на технологии КД 2 (правила конвертации данных)

50722 45650 руб.

31.10.2014    231412    124    327    

296

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

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

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

60000 руб.

05.10.2022    9208    9    8    

10

SALE! 10%

Перенос данных из УПП 1.3 в БП 3.0. Переносятся документы (обороты за период), справочная информация и остатки

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

Перенос данных из 1С:Управление производственным предприятием 1.3 в 1С:Бухгалтерия предприятия 3.0 с помощью правил обмена. Переносятся остатки, документы (обороты за период), справочная информация. Правила проверены на конфигурациях УПП 1.3 (1.3.223.x) и БП 3.0 (3.0.149.x). Правила подходят для версии ПРОФ и КОРП.

28000 25200 руб.

15.12.2021    20252    132    38    

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

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

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

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

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

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

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

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

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

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

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


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