Почему никто не любит обмены, и что с этим делать?

10.10.23

Интеграция - Перенос данных 1C

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

Всем здравствуйте! Меня зовут Лилия Алёхина. Я представляю компанию Самокат.

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

  • Среди разработчиков (дай бог, если их в компании больше чем один) выбиралась жертва.

  • Эта жертва делала обмен в одиночку под ключ (а это анализ, разработка, тестирование) - качество зависело от квалификации, опыта, личной ответственности и сроков.

  • После запуска на проде - ошибки, хот-фиксы, доработки, откаты (много или мало зависело не только от качества, но и от правильного понимания задачи - это же разработчик, а не аналитик).

  • В итоге все выливалось в переработки в авральном режиме, а все шишки сыпались на единственного исполнителя (а на кого же еще?).

И чем чаще ты пишешь обмены, тем чаще выбирают тебя, потому что у тебя же опыт.

Какая уж тут любовь?

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

А для этого необходимо повысить уровень комфорта при разработке обменов – и таким образом удовлетворить ту самую «потребность в безопасности» в пирамиде Маслоу.

Тогда разработчиков 3 типа станет больше, а значит, и результат будет лучше.

Я расскажу про подходы, которые мы внедрили в своей компании для реализации обменов.

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

В целом я выделяю 5 следующих составляющих в реализации обмена, на которые стоит обратить внимание и поработать над их качеством:

  • автоматизация рутинных операций;

  • внятное техническое задание, написанное системным аналитиком;

  • качественное тестирование перед запуском на прод;

  • регулярная сверка результатов после запуска;

  • и прозрачность системы в целом – с той простой целью, чтобы не только исполнитель мог потом с этим разобраться.


Подсистема событийной интеграции

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

  • В первый по триггеру в транзакции пишется ссылка на объект, связанный с событием. Что важно, не всегда этот объект в итоге входит в событие. При этом отбор вынесен из транзакции в регламентное задание конвертации, чтобы в самой транзакции у нас был минимум манипуляций – зарегистрировали и забыли.

  • Второй РС – это очередь сообщений к обмену, сюда уже пишется итоговый JSON.

  • После транзакции информация обрабатывается последовательно 4 регламентными заданиями:

    • в источнике 2 регламентных задания отвечают за конвертацию и отправку в брокер сообщений;

    • в приемнике 2 – за получение из брокера и обработку на стороне базы-приемника.

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

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

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

  • Либо наоборот, когда сообщение приходит из внешнего сервиса в брокер и дальше уже обрабатывается в вашей базе 1С.

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

Мы для себя решили, что описывать каждый раз весь обмен в коде с нуля – это нецелесообразно, т.к.:

  • немасштабируемо;

  • трудозатратно при разработке и для разбора другими разработчиками;

  • приводит к неминуемому копипасту.

Если в вашей команде используется системный подход, то транспорт чаще всего плюс-минус одинаковый. И конвертация плюс-минус одна и та же – каждый раз перечисляются реквизиты, которые надо переносить.

В итоге мы постарались вынести максимум настроек в интерфейс, результатом чего стало 2 справочника:

  • спр. «События», в котором:

    • состав события;

    • простые отборы;

    • включение обмена;

    • настройки для многопоточности (о них я расскажу дальше).

  • спр. «Объекты метаданных» (он чем-то похож на правила конвертации объекта в «Конвертации данных 2»), в котором:

    • варианты полей поиска (здесь уже привет «Конвертации данных 3»);

    • псевдонимы объектов, реквизитов и табличных частей для JSON;

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

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

Благодаря такому подходу:

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

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

Не буду останавливаться на каждой процедуре отдельно – за них говорит их название.

  • Есть смысл упомянуть процедуры на стороне приемника ПроверитьЛогикуПоОбъекту() и ПроверитьЛогику(). Здесь реализуются проверки данных, они зависят от задачи и от того, какие могут быть косяки в данных – могут наращиваться по ходу тестирования или даже после запуска, если, например, уже на большом объеме реальных данных у нас появляются какие-то странные вещи. В целом важно понимать, насколько такие проверки целесообразны в конкретных процессах.

  • То же касается и автоматической корректировки данных, что возможно в процедуре ПодготовитьСтруктуруКОбработке(). Например, если у нас в поле «Количество» пусто, можно при желании единицу ставить, или наоборот удалять такую строку – это все, опять же, на усмотрение по логике задачи.


Транспорт

Транспорт – тоже общий механизм, здесь используем брокер сообщений Apache Kafka.

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

Мы долгое время в качестве транспорта использовали http-сервис. Нас более чем устраивала скорость, была гарантия доставки. Все было хорошо. Единственную проблему, которую мы решали, перенося транспорт на Apache Kafka – произвольное число получателей.

Мы решили остановиться на продукте компании «Серебряная Пуля», поскольку нам уже доводилось с ним сталкиваться пару лет назад и он устроил нас в качестве фундамента, на основе которого мы можем строить собственное решение.

Перенесли конфигурацию в расширение и сделали минимум доработок (они на слайде). Бонусом получили ускорение доставки при больших объемах.

В итоге полное время выполнения от регистрации до завершения обработки в приемнике – от 1 до 5 минут (при отсутствии ошибок в данных).


Многопоточность

Как ни крути, самое узкое место в плане производительности – это обработка сообщений после получения в базе-приемнике.

В ходе развития подсистемы нами был выработан подход к реализации многопоточности.

У каждого события есть:

  • приоритет;

  • дата возникновения события;

  • вид аналитики для многопоточности.

Приоритет и дата обеспечивают порядок, в котором обрабатываются события.

Вид аналитики – критерий, по которому данные группируются в потоки:

  • Вариант «Без аналитики» хорошо укладывается для нормативно-справочной информации и для документов прихода – для них порядок при организации многопоточности не важен.

  • Вариант «По складу» разумно использовать для документов расхода, потому что у нас используются серии, для которых важен хронологический порядок проведения документов.

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

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

На слайде приведена таблица с примерами , какие настройки могут быть для событий по цепочкам документов:

  • приоритет события;

  • вид аналитики для многопоточности;

  • состав события;

  • и триггер - объект, при изменении которого событие возникает (обратите внимание, что есть варианты, когда сам триггер в состав события не входит).


Проработанное ТЗ

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

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

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

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

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


Тестирование и регулярная сверка

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

На слайде приведены этапы тестирования, которые мы выделяем. Отдельно остановлюсь на тестировании на ограниченной и полной выборке – при больших объемах часто проявляют себя кейсы, которые, как говорится, нарочно не придумаешь.

  • Тестирование на полной выборке справедливо для нормативно-справочной информации.

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

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

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

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

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

  • Ничего не мешает писать запрос и к внешним сервисам, если возникнет такая необходимость, и получится договориться с коллегами «по ту сторону» о том, что мы шлем им запрос, и они нам взамен присылают данные в нужном формате.

  • Сверка выполняется регламентным заданием. Настроена метрика в Prometheus. В случае отклонений приходит уведомление.

  • События сгруппированы в функционалы. И по ним можно настроить уведомления ответственным в случае ошибок, сбоев и успешном выполнении. Например, кому-то из пользователей нужно узнавать, что появился новый контрагент, чтобы что-то там в нем урегулировать – например, завести ему договор.


Прозрачность + Стабильность = Любовь

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

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

Система масштабируема:

  • и в плане реализации обменов (достаточно добавить единые расширения в новую базу, что делается за полдня);

  • и в плане подключения новых потребителей сообщений за счет брокера.

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

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

Спасибо за внимание!

 

*************

Статья написана по итогам доклада (видео), прочитанного на конференции Infostart Event.

 

30 мая - 1 июня 2024 года состоится конференция Анализ & Управление в ИТ-проектах, на которой прозвучит 130+ докладов.

Темы конференции:

  • Программная инженерия.
  • Инструментарий аналитика.
  • Решения 1С: архитектура, учет и кейсы автоматизации на 1С.
  • Управление проектом.
  • Управление продуктом.
  • Soft skills, управление командой проекта.

Конференция для аналитиков и руководителей проектов, а также других специалистов из мира 1С, которые занимаются системным и бизнес-анализом, работают с требованиями, управляют проектами и продуктами!

Подробнее о конференции.

 


См. также

SALE! 10%

Синхронизация и обмен для 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 руб.

12.06.2017    136630    729    292    

393

Перенос данных из УПП 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 руб.

04.08.2015    161329    361    269    

352

Перенос данных из БП 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 (правила конвертации данных)

45650 руб.

31.10.2014    233176    91    328    

299

Перенос данных из 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 руб.

15.04.2019    69493    166    141    

112

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    47486    203    64    

164

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

28000 25200 руб.

15.12.2021    21068    138    38    

97

Перенос данных из 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 руб.

03.12.2020    34803    83    58    

81

SALE! 10%

[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, почту.

14580 руб.

18.02.2016    183615    565    508    

509
Комментарии
Подписаться на ответы Инфостарт бот Сортировка: Древо развёрнутое
Свернуть все
1. shiaju 25 11.10.23 12:08 Сейчас в теме
В целом согласен, надо просто более основательно подходить. Просто часто отсутствует понимание всего спектра проблем при обмене, это можно частично решить через развернутое ТЗ, но все равно подводные камни останутся, будет затягивание сроков и недовольство руководства - в целом у меня такие впечатления от разработки обменов.
Lili4ka; sandr13; +2 Ответить
6. Lili4ka 33 15.10.23 23:06 Сейчас в теме
(1) Подводные камни обычно становятся заметнее с опытом. Конечно, желательно их закладывать в сроки сразу (с запасом на те, которые не видно, но могут появиться). Но, к сожалению, не каждое руководство готово принять адекватные сроки. Тут я бы опиралась на доверие и отталкивалась итеративно от результата - "Вот вы видели, что я не бездельничал. Вот результат - он вот такой по качеству и вот в такие сроки. В следующий раз вы хотите такой же результат или лучше? Значит, нужны такие-то ресурсы"
2. Dimony4 3 11.10.23 12:10 Сейчас в теме
Здравствуйте.
Какой инструмент вы используете для регулярной сверки?
Хочу автоматизировать контроль результата обмена и пока не нашел готовое решение.
7. Lili4ka 33 15.10.23 23:09 Сейчас в теме
(2) Вся подсистема разработана командой Самокат, кроме транспорта
3. shiaju 25 11.10.23 12:10 Сейчас в теме
Ну и мало кто может себе позволить описанную схему - аналитик+разработчик+тестировщик, типа дорого это. Понятное дело экономия на таких вещах крупному бизнесу выходит боком
Lili4ka; sandr13; +2 Ответить
8. Lili4ka 33 15.10.23 23:12 Сейчас в теме
(3) У нас в команде на момент написания доклада (2021 год) не было тестировщиков.
Если нет аналитика, то его работу выполняет разработчик. По моему опыту зарплата разработчика больше или равна зарплате аналитика. Получается, что отсутствие аналитика обходится дороже.
Если разработчик выполняет функцию аналитика плохо, то страдает качество, т.е. плюс еще затраты
4. gybson 13.10.23 10:25 Сейчас в теме
Как получить ссылки по простому отбору? =)

И зачем делать свою КД2, если есть типовая, которую много кто знает. Но лучше конечно делать сразу по типу КД3, со схемами XDTO.

Сверка p2p довольно сомнительная штука с учетом двойной конвертации. Например у нас есть такой вариант обмена, при котором строки из ТЧ "Товары" перетекает в ТЧ "Услуги".
user623969_dusa; +1 Ответить
10. Lili4ka 33 15.10.23 23:19 Сейчас в теме
(4) Могу только порадоваться за вас, что ваши потребности полностью покрывает КД3, и вам не нужна сверка.
11. gybson 16.10.23 13:46 Сейчас в теме
(10) Непонятно зачем КД2 воспроизводить. У меня просто перед глазами решение, где событийный обмен вполне через КД2 работает. Загрузка в бухгалтерию. Она же уже есть, даже не надо задание от аналитика, просто переключить обмен с планов обмена, на событийный с теми же правилами и алгоритмами.

И лучше справочник использовать для сообщений, у него можно завести ТЧ с ключами маршрутизации, заголовками сообщения, дополнительными свойствами и прочим. У него есть ссылка, по которой можно идентифицировать сообщение. По кодам можно порядок следования определять.
13. izihizich 19.10.23 19:07 Сейчас в теме
(11) а как красиво в рамках КД2 или КД 3 построить обмен чтобы выгружался только документ ЗаказПоставщику у которого статус в самописном регистре был в списке статусов определенных и вместе с этим заказом поставщику выгружались еще свойства из двух других регистров (но сами регистры не выгружались как объекты, а были именно свойствами выгруженного объекта заказа поставщику)? При этом желательно чтобы всё это шло в один топик из которого будет читать например бухгалтерия, самописная 1с и сервисы написанные не на 1с, которым соотвественно лучше иметь json ?
14. izihizich 19.10.23 19:47 Сейчас в теме
(13) В дополнение искренне хочу узнать как на кд3 сделать многопоточную обработку одного типа документа разделяя потоки чтобы не было конфликтов блокировок.
17. gybson 19.10.23 23:35 Сейчас в теме
(14) Блокировки возникают точно не при конвертации документа, при чем тут КД3?
19. Vyacheslav_Kochnev 141 19.10.23 23:41 Сейчас в теме
(17)
А как же их загрузка в базу и их проведение?
20. gybson 19.10.23 23:45 Сейчас в теме
(19) Да собственно как всегда, вызываете метод "Записать" и платформа записывает. Или есть ноу-хау какое-то, о котором тут умолчали?
22. Vyacheslav_Kochnev 141 19.10.23 23:53 Сейчас в теме
(20)
Нет, ноу-хау тут нет :)
Если вы загружаете документ и вызываете Записать(РежимЗаписиДокумента.Проведение) и при этом вы это делаете в 1 поток, то проблем нет.
Если вы будете осуществлять загрузку документов в потоков 20 и сразу же их проводить, то велика вероятность получить конфликт блокировок.
Для этого и был добавлен "вид аналитики для многопоточности".

Отложенное проведение тут не прокатит, т.к.:
1. Объёмы большие и при отложенном проведении всё равно будет нужна многопоточная обработка.
2. Мы "придерживаемся стратегии, что при обменах изменения должны быть идентичными с интерактивными изменениями данных". Из-за этого при прогрузке цепочки документов важно чтобы у предыдущего документа уже были движения, иначе ввод на основании не отработает.
25. gybson 20.10.23 00:28 Сейчас в теме
(22) Тут всё хорошо, но это вопрос маршрутизации, не конвертации и тут надо чтобы получатель мог разделить входящий поток так, чтобы его алгоритмы проведения оптимальны были. Они у каждого получателя разные могут быть. Можно и средствами 1С писать все это в регистр и потом по потокам распределять для проведения. Будет меньше связанности и никакой зависимости от средств интеграции.

Кстати, о перемещении. Вот кого Бог велел разделить на два ордера и отправлять каждый на свой склад для складских систем. Если вы не ведет в базе каждого склада учет по всем складам, то не надо перемещение. Тут отгрузил, там принял. Остаток уменьшается по факту отгрузки и увеличивается по факту приемки. Перемещение плохой документ для оперативного учета.
16. gybson 19.10.23 23:29 Сейчас в теме
(13) 1. КД не ограничивает вас в средствах регистрации. Но если там вы на этапе формирования сообщения можете отказаться от выгрузки любого объекта. Почти на любом этапе вроде можно поставить Отказ = Истина, то при выгрузки по одному объекту, будет странно зарегистрировать сообщение и отправить пустым, хотя и страшного ничего. Но, опять же, главная цель это конвертация привычными средствами. Выгрузка свойств из регистров в КД2 и КД3 будет немного отличаться. В КД2 вы запрос в таблицу выгружаете и ставите ее как источник данных, она выгрузится по заданным правилам. В КД3 чуть сложнее, через допсвойства табличку прокинуть и сейчас уже точно не помню полный алгоритм. Но суть такая же. Это вот никогда не было проблемой и в типовых правилах встречается. Ну так вот вы сконвертировали объект в XML и дальше шлите хоть в топик, хоть по почте, а можно через телегу отправить. ФабрикаXDTO спокойно выгружает объект в JSON, вообще без проблем.

Просто берете обработку типовую КонвертацияОбъектовXDTO и там метод экспортный ВыгрузкаОбъектаВыборки, получите в КомпонентыОбменаОтправка.ФайлОбмена запись XML. Ну или около того, у меня своя обработка, которая по КД3 выгружает, но схему берет из макета, а не конфигурации.

С КД2 такая же петрушка, вообще не проблема сконвертировать один объект и отправить.
27. izihizich 20.10.23 11:29 Сейчас в теме
(16) Подсистема событийной интеграции сочетает в себе и регистрацию объектов и правила прохождения отборов и конвертацию и отправку в различные источники, и соответственно чтение из различных источников, разделение на приоритеты и потоки и группы пришедших данных и конвертацию на стороне источника, и отправку подверждений каких либо по этим событиям, и сверку обменом и метрики по кучи моментов. Не стоит её рассматривать как механизм конвертации. Да можно нечто подобное построить на кд2/кд3, но как мы уже поняли по комментариям, надо будет и допилить обработку, чтобы в многопоток красиво делать и еще обработки чтобы сверку делать и еще что либо и вот опять получается некая подсистема состоящая из кучи всего.
28. gybson 20.10.23 12:09 Сейчас в теме
(27) Все верно, конвертацию лучше брать готовую, всем знакомую и годами отработанную, а остальное уже допиливать.

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

А вот систему управления интеграцией, её приходится делать. И то вон народ на сторону глядит всё время, в сторону готовых шин.
36. Lili4ka 33 22.10.23 19:27 Сейчас в теме
(28)
На рынке не так много хороших специалистов по обменам, которые еще не нашли свое место под солнцем, чтоб их легко можно было заполучить к себе в команду. Большинство краем глаза видели КД3 и что-то простенькое пилили на КД2 методом тыка. Если за 2 года ситуация поменялась - это отлично.
Описанные подходы в том числе делают выбор специалистов шире.
"Самописный обмен это только первые несколько раз весело." - при описанных подходах нет никаких "раз", обмен не пишется каждый раз с нуля, процесс поставлен на поток, и он интуитивно понятен (документация, конечно есть, но нельзя назвать ее объемной).
35. Lili4ka 33 22.10.23 19:15 Сейчас в теме
(11)
1. Доклад в первую очередь не про выбор инструментов, а про подходы, которые помогают поставить процесс на рельсы один раз и навсегда. Выбор инструментов - это тот вопрос, где сколько людей - столько же мнений. Возможно, это хорошая тема для другого доклада и/или обсуждения в формате "круглого стола" на конференции. Но кажется, что так или иначе все при своем мнении.
2. "И лучше справочник использовать для сообщений"- проходили, это хорошо, когда сообщения загружаются в один поток, иначе начинаются проблемы с блокировками.
18. Vyacheslav_Kochnev 141 19.10.23 23:39 Сейчас в теме
(4)
(4)
Сверка p2p довольно сомнительная штука с учетом двойной конвертации. Например у нас есть такой вариант обмена, при котором строки из ТЧ "Товары" перетекает в ТЧ "Услуги".

Сравнение документов, как правило, делаются по ресурсным полям. Т.е. нет смысла сверять построчно табличные части. Есть смысл сверять суммы по этим табличным частям. Ну и т.к. сверка строится на результатах запросов, то вам ничего не мешает для источника написать выборку из ТЧ услуги, а не из ТЧ Товары.
21. gybson 19.10.23 23:52 Сейчас в теме
(18) Для УТ-БП наверное здорово актуально, но для них сверочных отчетов даже тут тьма. Для НСИ уже не так здорово. Как ни крути, а конвертация всё усложняет. В ЗУП руководитель сотрудник, в СДО пользователь. Очень все индивидуально.
23. Vyacheslav_Kochnev 141 19.10.23 23:58 Сейчас в теме
(21)
Сверочных отчётов тьма - это которые должен пользователь руками сформировать и глазами сверить? (Я просто не знаю, вдруг какая-то типовая автоматизация сравнения данных есть). Тут же выводятся только расхождения между источником и приёмником. Глазами ничего не сравнивается.

С НСИ и случаями когда в первой системе реквизит имеет один тип, а во второй второй тип - да, реализация усложняется. Но мы имеем автоматическую регулярную сверку данных.
24. gybson 20.10.23 00:03 Сейчас в теме
(23) Наверняка кто-то и такой выложил, разные тут бывают отчеты. Я чаще видел отчеты по расхождениям такие, в которых расхождения указаны.

Сверка хорошо, но сама по себе не относится к конкретному методу интеграции. Я, было дело, делал сверку для обычного обмена. Но под одну конкретную задачу, чтобы в бухгалтерии все нормально было по цифрам.
26. vikad 130 20.10.23 07:43 Сейчас в теме
(21) если есть правила КД 2.0, в качестве сверочного отчета можно использовать https://infostart.ru/1c/tools/666070/
31. G_107333513132196623416 20.10.23 19:50 Сейчас в теме
(26) По этой ссылке вы в комментариях пишите, если я правильно вас понял, что обработка не сравнивает ссылки, т.е. не учитываются правила конвертации при сравнении.
Сравнение в рамках событийной интеграции видит все поля поиска для объектов метаданных и сравнивает все ссылки согласно этих полей и правил. Т.е. сравнительный отчет показывает именно результат обмена. Также в событийке есть фишки для быстрого поиска ссылок - регистр типизированных ссылок, собственный регистр Соответствия объектов метаданных. Эти регистры учитываются как при обмене, так и при сравнении данных.
(26)
32. vikad 130 20.10.23 19:57 Сейчас в теме
(31) по ссылке в (26) универсальный инструмент для анализа и сравнения любых результатов запросов к базе-источнику и базе-приемнику, включая сравнение табличных частей документов при обнаружении различий в объекте (т.е. не только реквизиты шапки сравниваются). Возможно, инструмент решает только частную задачу - но от него большего и не требовалось при разработке
33. gybson 20.10.23 21:04 Сейчас в теме
(31) Единственное, что происходит в "событийке", так это обмен одним объектом за раз.

Если обмен синхронный, то объект сразу отправляется через ком, http, разное.
Если обмен асинхронный, то регистрируется событие, которое потом обработается.

На этом всё. Совсем всё. Вообще всё. Конвертация, транспорт, логирование, мониторинг и прочее идут уже поверх этого.

Есть еще тонкости с гарантированной доставкой, но тут у планов обмена 100% результат, а у других схем не совсем. Поэтому сверка и нужна.
5. sandr13 34 14.10.23 12:18 Сейчас в теме
Хорошие пожелания. Рисунок пирамиды Маслоу можно бы ещё сюда добавить, раз уж упомянули. Неплохо бы эту задачу переложить на плечи ИИ.
9. Lili4ka 33 15.10.23 23:16 Сейчас в теме
(5)
Неплохо бы эту задачу переложить на плечи ИИ.

Интересная мысль, спасибо!
12. Maxus43 21 19.10.23 11:35 Сейчас в теме
Использовать готовую Шину был не вариант (датареон, 1с:шина, 1С:Интеграция)? Там и планы обмена не используюся и прочее. Готовые коннекторы и к 1с и к другим системам
15. Vyacheslav_Kochnev 141 19.10.23 23:29 Сейчас в теме
(12)
Использовать готовую Шину был не вариант (датареон, 1с:шина, 1С:Интеграция)? Там и планы обмена не используюся и прочее. Готовые коннекторы и к 1с и к другим системам


- 1С:Шина вышла в 2022 году. Доклад же был от 21 года. Т.е. её ещё на тот момент не было. 1С:Шина - не вариант.
- 1С:Интеграция, судя по новостям, вышла тоже в 2022 году. Получается, что и она не вариант.
- Датареон, на момент старта разработки не рассматривали. Спасибо, стоит поближе взглянуть на их решение :)
29. yyv-911 20.10.23 15:30 Сейчас в теме
знакомая тема. в свое время тоже пошел по тому же пути.
работает не хуже конвертации. легко масштабируется. есть дополнительные плюшки по типу статусов объектов, доработки логики проведения и доступов к системе и т.п.. Но до полноценной продаваемой конфигурации не дошел. Сложно такое в одно лицо реализовать.
За все время сколько существует подобная моя система (разные обмены, между разными системами) работает очень стабильно. С конвертацией было бы гораздо больше проблем.
С другой стороны начата статья с правильного - должно быть хорошее понимание обменов и процессов где это происходит.
30. пользователь 20.10.23 19:49
Сообщение было скрыто модератором.
...
34. Поручик 4677 22.10.23 01:12 Сейчас в теме
Люблю обмены и переносы.
dsdred; Lili4ka; +2 Ответить
Оставьте свое сообщение