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

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! 10%

Перенос данных из УПП 1.3 в ERP 2 / УТ 11 / КА 2

Обмен между базами 1C Платформа 1С v8.3 1С:Управление производственным предприятием Россия Платные (руб)

Куплено более 270 раз! Обработка позволяет перенести из УПП в ERP / 1С:УТ 11 / КА 2 всю возможную информацию. Переносятся документы, а также начальные остатки и справочная информация. Типовая обработка от фирмы 1С не позволяет сохранить документы за период работы. Кроме того, наши алгоритмы выгрузки начальных остатков тоже имеют больше функционала и тщательно проверялись на реальных проектах перехода с УПП на ERP. Наша разработка будет полезна как фирмам-франчайзи, которые периодически выполняют перенос данных для заказчиков, так и организациям, самостоятельно выполняющим проект по переходу. При приобретении обработки вы будете четыре месяца получать ее обновления, далее можно приобрести подписку на обновления. Конфигурации 1С постоянно меняются, выходят новые релизы. Имея подписку на обновления, вы всегда можете быть уверены, что правила конвертации данных будут работать на ваших базах 1С.

46083 41475 руб.

04.08.2015    153826    272    258    

315

SALE! 10%

[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. Не требуется синхронного обновления правил после обновления другой конфигурации, участвующей в обмене. Типовой обмен через планы обмена кнопкой Синхронизация вручную или автоматически по расписанию, или вручную обработкой.

22320 руб.

12.06.2017    129929    668    289    

368

SALE! 10%

Перенос данных из УПП 1.3 / КА 1.1 в БП 3.0

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

Для данного перехода не существует стандартной обработки от компании 1С. Наша разработка позволяет перенести остатки по всем счетам бухгалтерского учета, документы за период и всю нормативно справочную информацию из "1С: Управление производственным предприятием 1.3" / "1С:Комплексная автоматизация 1.1" в программу "1С:Бухгалтерия предприятия 3.0" на выбранную дату начала ведения учета. В обработке имеется фильтр по организациям и множество других параметров выгрузки. Поддерживается несколько сценарией работы: как первичного полного переноса, так и догрузки только новых документов из УПП 1.3 / КА 1.1 в БП 3.0. Обмен проводится либо с помощью правил (тариф "Базовый"), либо с помощью готовых обработок для обмена, которые можно подключить к конфигурациям (тариф "Удобно"). Конфигурации при использовании обмена остаются полностью типовыми. Перенос данных возможен в 1С: Бухгалтерию 3.0 версии ПРОФ, КОРП или базовую.

43889 39500 руб.

25.02.2015    165798    366    232    

354

SALE! 10%

Перенос данных из ERP 2 (ЕРП) / КА 2 в ЗУП 3 [КД 2]

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

Наша обработка позволяет не только перенести все документы и справочную информацию из ERP 2 или КА 2 в ЗУП 3, но и организовать регулярный обмен данными между программами 1С:ERP 2 / КА 2 и 1С:ЗУП 3. Вы можете выбрать период отбора данных и установить фильтр по организациям, чтобы выгружать только необходимую информацию. Более того, перенос оперативно обновляется при выходе новых релизов программы 1С, так что вы всегда будете иметь самую актуальную версию обработки. Наша компания также предоставляет техническую поддержку по вопросам, возникающим при использовании обработки. Вы можете обратиться к нам через тикеты на Инфостарте, и мы оперативно решим любые вопросы. Мы гарантируем, что наша обработка будет надежным инструментом для вашего бизнеса, который упростит и ускорит процесс взаимодействия с программами 1С.

43889 39500 руб.

03.12.2020    31803    64    54    

66

Перенос данных из УПП 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.212.x) и БП 3.0 (3.0.142.x). Правила подходят для версии ПРОФ и КОРП.

25000 руб.

15.12.2021    17092    101    36    

55

[ED2] Обмен УПП 1.3, КА 1.1, УТ 10.3 с EnterpriseData (универсальный формат обмена), обработка

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

Регулярный обмен, выгрузка, перенос из КА 1.1, УПП 1.3, УТ 10.3 для обмена с любыми конфигурациями, поддерживающими обмен в формате EnterpriseData (КД3) - БП 3.0, ERP, КА 2, УТ 11, Розница 2, УНФ 1.6 и другими. Правила для старых и доработанных конфигураций не требуют синхронного обновления и совместимы с новыми и будущими конфигурациями. Обмен по расписанию, через папку, FTP, почту.

12600 руб.

18.02.2016    178186    541    507    

497

SALE! 10%

Перенос данных из БП 3.0 в УНФ 3.0 / УНФ 1.6

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

Обработка позволяет начать вести учет в программе "1С:Управление нашей фирмой" редакции 3.0 или 1.6, то есть перенести в нее из существующей базы "1С:Бухгалтерия предприятия, ред. 3.0" начальные остатки на выбранную дату, документы за период времени и также всю необходимую справочную информацию. По вашему запросу мы можем бесплатно добавить в правила переноса дополнительные виды объектов (например, новые виды документов). Обработка по переходу на новую программу 1С включает в себя правила конвертации в формате XML, обработку для выгрузки и загрузки данных, а также инструкцию по работе. В стоимость переноса включена техподдержка в течение месяца с момента покупки, а также получение обновлений переноса в течение 4 месяцев.

43889 39500 руб.

10.07.2018    64438    33    112    

40

SALE! 10%

Перенос данных из ERP 2 / КА 2 / УТ 11 в БП 3.0

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

Перенос позволяет настроить собственный обмен данными между указанными программами, альтернативный предлагаемому фирмой 1С. Перенос данных осуществляется из 1С:ERP 2 / 1С:КА 2 / 1С:УТ 11 в 1С:БП 3.0. Правила обмена оперативно обновляются при выходе новых релизов программы 1С, так что вы всегда будете иметь самую актуальную версию обработки. Наша компания также предоставляет техническую поддержку по вопросам, возникающим при использовании обработки. Вы можете обратиться к нам через тикеты на Инфостарте, и мы оперативно решим любые вопросы. Мы гарантируем, что наша обработка будет надежным помощником для вашего бизнеса, который упростит и ускорит процесс взаимодействия между программами 1С.

35000 31500 руб.

15.04.2019    65018    160    128    

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

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

P.S. С наступающим! )
ids79; pavelpribytkin96; +2 Ответить
2. Mick2iS 273 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 7989 03.01.20 18:17 Сейчас в теме
(4)Можно посмотреть саму Интеграцию, как там все это устроено. Код открыт за исключением одного модуля, где проверяется лицензия. Также можно протестировать и погонять на реальных данных с trial ключом.
3. MaxS 2725 31.12.19 17:33 Сейчас в теме
С наступающим!
Данные в плане обмена регистрируются же порциями, соответственно так же можно разбивать на порции при обмене.
Ещё как вариант - анализировать данные - связанные документы и справочники направлять в один поток.
Ещё полезно было бы организовать очередь. В числе первых обмениваться справочниками, потом документами.

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

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

Но еще нужно не забывать о дальнейшей поддержке рабочей системы. Понятности что происходит и простоты модернизации.
А то один такой умник внедренец (это не оскорбление, а реальная оценка), а после ищи кто сможет это сопровождать.
13. Yashazz 4583 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 37 19.02.20 15:21 Сейчас в теме
Воспрос - например у меня есть обмен через КД 3 между УТ и БП. Можно ли вынести пакет EnterpriseData и общие модули правил обмена в отдельную конфигурацию и при помощи данной конфигурации инициировать обмен? К кому можно обратиться чтобы посмотреть 2is интеграцию с КД 3?
17. acanta 19.02.20 15:25 Сейчас в теме
Планы обмена с ED в любом случае стыкуются исключительно вручную. Подтверждение о получении пакета есть в РИБ?
Оставьте свое сообщение