0. barelpro 988 21.03.19 14:40 Сейчас в теме

RabbitMQ + Конвертация Данных 3.0

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

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

Комментарии
Избранное Подписка Сортировка: Древо
1. pbabincev 113 21.03.19 19:30 Сейчас в теме
Парни, вы круты! Очень реально круто!
Kosstikk; tva120; o.nikolaev; barelpro; A_Max; Krio2; +6 Ответить
2. SirAlex1C 21.03.19 22:14 Сейчас в теме
Спасибо за качественную статью!
o.nikolaev; barelpro; A_Max; Krio2; +4 Ответить
3. kalyaka 486 22.03.19 07:05 Сейчас в теме
Напишите как вы на практике решали вопрос с массовыми изменениями? Скажем если происходит обновление данных в справочниках, достаточно ли эффективен в этом случае подход пообъектной сериализации или для таких случаев лучше выполнять синхронизацию, используя другие технологии?
DimaP; A_Max; +2 Ответить
23. barelpro 988 22.03.19 14:40 Сейчас в теме
(3) Хороший овпрос! Массовый обмен надо разделить на два случая:
1. Первичный перенос из старой системы в новую - лучше делать на КД2. Все таки накладные расходы на поштучную обработку отнимают ресурсы и время, да и событийность не надо соблюдать
2. Групповая обработка - тут ничего не поделаешь, если изменяется значение реквизита, который участвует в обмене - ничего не поделаешь надо обмениваться. Но:
- Если реквизит не участвует в обмене - от лишнего трафика спасает механизм на шаге 1.2.
- Если реквизит участвует в обмене - время обработки очереди на шаге №4 (Запись) конечно удлинняется. Если такие изменения позарез нужны бизнесу в течение дня и нет возможности перенести на вечер, тогда кратковременно врубаем 50 параллельных фоновых. Так же у нас есть возможность на шаге №2 в пользовательском режиме отключать чтение очереди "в транзакции". Ведь когда он включен - мы ничем не лучше чтения таблиц регистрации планов обмена - тот же эффект ожидания блокировок. Но мы хотя бы можем это параметрически регулировать.
4. jobkostya1c8 82 22.03.19 09:24 Сейчас в теме
Интересно будет подробнее прочитать про новые технологии.
5. Robbi 53 22.03.19 10:27 Сейчас в теме
Хороший подход, так и надо делать все обмены и рэббит отличная вещь.
Имхо: кд3, куча форматов ed, xdto, xml - это кошмар и тупик. Очень жаль, что 1с идет в этом направлении.
И лично мне не нравится использование com компонент для рэббита и хэша, хотя это простой и легкий путь, но красивее что-то другое придумать.
6. lustin 22.03.19 10:48 Сейчас в теме
(5)
com компонент для рэббита


Откуда взялась информация о COM компоненте ? Там чистый Native Win32/Win64/GCC32/GCC64
7. Evil Beaver 5770 22.03.19 11:10 Сейчас в теме
(6) Переведу многонерусскихбукв от Алексея на 1С-овский :)

Там нет COM-компонентов, не надо ничего на машине регистрировать/администрировать, плюс это полная кроссплатформенность Windows/Linux 32 и 64 бита.

Кстати, у нас вышло в продажу еще и дополнение для БСП, в котором как раз штатными обменами отправляются сообщения в RabbitMQ. На сайте пока нету, но по телефону можно все узнать. Позволяет быстро получить интеграцию на штатных механизмах типовых 1С-систем. С другой стороны, быстро - не значит правильно, и для сложных гетерогенных проектов, когда есть не только 1С, нужно что-то "посерьезнее".
o.nikolaev; artbear; +2 Ответить
9. AntonSm 24 22.03.19 11:37 Сейчас в теме
(7)
у нас вышло в продажу еще и дополнение для БСП, в котором как раз штатными обменами отправляются сообщения в RabbitMQ.

скажите, пожалуйста, стало очень интересно.
Т.е. получается, что можно взять типовые обмены, например, между УТ11 и Розницей, вашу компоненту, поставить рядом RabbitMQ и все будет обмениваться практически в реальном времени?
Я имею ввиду именно ту ситуацию, когда типового обмена достаточно, когда нет реальной необходимости в полноценном внедрении RabbitMQ вашими силами с учетом всех мыслимых нюансов и вот этим всем.
18. lustin 22.03.19 13:28 Сейчас в теме
(9) В целом именно так. То есть меняется только транспорт с файлов/web-сервисов

позволяет сделать следующий ход

0. старт
1. взять инфраструктурщиков и попросить у них кластер RMQ
2. поменять транспорт БСП
3. запустить обмен по новому транспорту
4. переписывать обмены не надо - все полетит уже по новому, PROFFIT Номер 1
5. прикинуть где нужен реальный обмен уже с явным использованием событийной интеграции
6. взять бизнес-событие (например "Обновление данных Номенклатуры")
7. реализовать по новому
8. запустить "Событийную интеграциию для номенклатуры"
9. Запустить уже БЕЗ инфраструктурщиков
10. Proffit Номер 2

То есть получается этакий гибрид штатного обмена и нового.
Прикрепленные файлы:
A_Max; barelpro; +2 Ответить
8. Evil Beaver 5770 22.03.19 11:13 Сейчас в теме
Выяснилось что айтишники периодически в папках сервера 1С чистят кэш


Я просто поинтересоваться - а как это они у вас так чистят кеш? При работающем сервере, прямо у него из-под носа убирают файлы? Клево, а кто им такое разрешил?
15. barelpro 988 22.03.19 13:20 Сейчас в теме
(8) Мы не стали интересоваться, просто перевели сервера в другую обслуживающую компанию )
19. lustin 22.03.19 13:30 Сейчас в теме
(8) это прям жестоко получается - серверный кеш при попытке удаления будет ругаться что файл занят. Это надо постараться чтобы так сделать.
10. artbear 1125 22.03.19 11:46 Сейчас в теме
(0) Добавьте правильную ссылку на компоненту и описание интеграции от Серебряной Пули, пожалуйста.

https://silverbulleters.org/elasticbus
13. barelpro 988 22.03.19 13:10 Сейчас в теме
(10)
Там чтобы скачать документацию надо ввести свои данные. ввел пару раз, но так ничего и не пришло. Это может отпугнуть разрабов, слишок коммерческая страничка.
16. lustin 22.03.19 13:20 Сейчас в теме
(13) Это я так сделал. Я увидел твои заявки и подумал что ты экспериментируешь с сайтом и их почистил ;-). Поэтому коллеги твоих запросов не увидели ;-).
49. barelpro 988 25.03.19 17:13 Сейчас в теме
(16) Мне ответил по почте руководитель отдела продаж, и сказал, что "Документацию предоставляем, кто приобрел dll, но саму документацию утерял."

Вот я сижу и думаю, что за хиртый рекламный ход - размещать на страничке продукта кнопку "Скачать документацию PDF", а потом отказывать в этом?! )
JohnyDeath; +1 Ответить
14. barelpro 988 22.03.19 13:11 Сейчас в теме
(10)
Там чтобы скачать документацию надо ввести свои данные. Ввел пару раз, но так ничего и не пришло. Слишком коммерческая страничка, это может отпугнуть разрабов, .
11. Pipapalamm 22.03.19 11:55 Сейчас в теме
Аплодирую стоя. Пока такие спецы есть - родина без автоматизации не останется!
A_Max; jif; barelpro; +3 Ответить
12. artbear 1125 22.03.19 11:58 Сейчас в теме
(0)
На первом уровне анализа проверяется сам факт передачи объектов в нужных направлениях.

На втором уровне проверяется качество передачи - сравниваем подготовленные заранее XML-эталоны: с XML объекта данных на стороне отправителя, c XML текстом сообщения в формате ED, и с XML объекта данных на стороне получателей.


не совсем понял, зачем и что проверяете.

кролик же гарантирует доставку и качество.

у вас были случаи, когда сообщение доставлено, но частично?
17. petrpk 22.03.19 13:25 Сейчас в теме
(12)когда идёт доработка правил одновременно с разработкой конфигурации есть большой шанс что кто то накосячит, например уберет реквизит или целый справочник . Поэтому сравнение итогового сообщения важная штука.
20. barelpro 988 22.03.19 13:38 Сейчас в теме
(12) Тут речь немного о другом. Мы же проверем новый релиз перед накатом на продуктив.
Качественный анализ автотеста показывает, что с момента создания шаблона что-то произошло именно в контексте этого объекта метаданных - изменились правила, изменился формат, изменилась архитектура. Т.е. заставляет тестировщика сфокусироватья на конкретных изменениях. Если это ошибка - отдать на исправление, если это развитие - актуализировать шаблон.
21. ManyakRus 284 22.03.19 13:52 Сейчас в теме
1) про КОМ-обмен между 1С ничего не написано,
подошло бы лучше всего.
2) В 1С правила обмена уже содежит список изменённых данных предназначенных для обмена, поэтому никакой RabbitMQ не нужен, можно этот же список использовать как очередь
3) "...ERP обменивается со всеми остальными системами" - достаточно изменить 1 конфигурацию 1С, а вашим методом все конфигурации изменять придётся
22. barelpro 988 22.03.19 14:20 Сейчас в теме
(21)
1. К обмену через com-соединение много вопросов: по быстродействую, по чуствуительности к обновлению платформы. Не наш вариант.
2. Механизм "Планы обмена" - хорошая штука, у 95% организаций до сих пор работает. А вы пробовали запускать такой обмен каждые три секунды?
3. Если оставаться на планах обмена и правилах КД2 - то да, ничего менять не надо, кроме самих правил. Но тут см п.2
24. ManyakRus 284 22.03.19 15:49 Сейчас в теме
(22)
1) по быстродействию быстрее, только платформа одинаковая должна быть
2) КОМ-обмен будет работать каждые 3 секунды, через XML вряд ли
3) с КОМ-обменом тоже изменять надо только 1 базу
25. barelpro 988 22.03.19 16:23 Сейчас в теме
(24)Если есть конкретный проект - опишите, с удовольствием почитаем! Я серьезно!
26. MaxS 1602 23.03.19 08:38 Сейчас в теме
Интересно было почитать. Не во все тонкости ещё вник. Была подобная задача в 2015-м году. Интеграция стороннего софта для производства с 1С УПП, в перспективе с КА 2, БП 3 и т.п. Поэтому выбрал КД3. По окончании проекта явно прослеживалась необходимость в другом транспорте, но бюджет и сроки не дали развития. Хорошо, что вам удалось разработать концепцию, собрать команду, реализовать и поделиться идеей.

По поводу формирования строки Routing Key. В типовом XDTO пакете ExchangeMessage есть же свойства To и From тип строка. Можно было их использовать? В поле To записать всех адресатов, на стороне приемника перепроверять для него ли это сообщение.

И некоторое время назад появилось свойство AvailableObjectTypes. Может быть это пригодилось бы.
Это свойство с одной стороны увеличило объем сообщения как в КД2 - в каждое сообщение добавляется список поддерживаемых объектов - что может принять база и что может отправить, чтобы не выгружать то, что не может принять другая сторона.
Может быть имело смысл обмениваться этими данными не в каждом сообщении, а при изменении правил. Как это зафиксировать - другой вопрос. Можно по факту перезаписи настроек узла или по таймеру раз в сутки.
28. barelpro 988 23.03.19 15:44 Сейчас в теме
(26) Спасибо за комментарий!
Вы пишите про маршрутизацию - механизм, который указывает, какие типы метаданных из какого источника в какие получатели и при каких условиях должны уходить. В 1С-ской концепции обмена через универсальный формат за маршрутизацию отвечают знаменитые правила регистрации КД2. Ваше предложение я тоже понял: в конечном итоге надо минимизировать доработки типового механизма, как это кстати сделали ребята из Пули, выпустив. недавно дополнение для БСП, в котором штатными обменами отправляются сообщения в RabbitMQ.
Все эти знания в конечном итоге поступают на вход конкретных проектов, и архитектор принимает одно из двух решений:
1. Использовать комбинацию тиражных решений с минимальныи доработками и в дальнейшем мириться с тем что это не до конца вписывается в потребности конкретного бизнеса (кто-то скажет что у него вписалось идеально, но я в сказки не верю, особенно для крупного бизнеса, где каждая деталь имеет значение)
2. Или кастомизировать имеющиеся решения с максимальным учетом особенностей бизнеса.

А теперь скажите, какое из двух решений является более интересным для нас с вами, и является эволюционным с точки зрения развития имеющихся решений или даже появления новых тиражных продуктов? )))
29. MaxS 1602 23.03.19 16:48 Сейчас в теме
(28) Лично мне интереснее 1-й вариант, т.к. позволяет многократно использовать(продавать) собственные решения за счет максимальной совместимости с тиражными решениями. Проще найти специалиста для поддержки.
2-й вариант на первых порах интереснее бизнесу, дороже, сложнее в долговременной поддержке, т.к. нужны уникальные знания специалистов. И данное решение может отстать в развитии от тиражного, где скорее всего появится что-то интересное для этого бизнеса. Вероятность того что это индивидуальное решение для бизнеса станет тиражным - низкая. А для команды разработчиков и внедренцев этот вариант может оказаться топтанием на месте. Время идёт, деньги платят, собственного развития нет. А конкуренты из варианта 1 за это время уже наработали более совершенный материал для будущего проекта.
30. barelpro 988 23.03.19 20:23 Сейчас в теме
(29) согласен полностью, но я немного о другом )
27. alexei366 23.03.19 15:17 Сейчас в теме
Может быть пригодится, в тексте было:

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

Я гарантирую!) Если создать динамическую подписку "ПодключитьОбработчик" - он точно последним сработает.
То есть можно сделать подписку на все объекты на событие "ПередЗаписью", и там на объект подключать динамическую подписку.
Я использовал такую схему, чтобы замерить к примеру проведение документов, чтоб гарантирована замерить все операции и не вставлять замеры во всевозможных местах.
31. barelpro 988 23.03.19 20:26 Сейчас в теме
(27) интересно!
А можно чуть подробнее про метод ПодключитьОбработчик или ссылку?
45. alexei366 25.03.19 02:25 Сейчас в теме
(31) Да проще в синтаксис помощнике почитать, этого хватить должно.
https://its.1c.ru/db/v8314doc#bookmark:dev:TI000000212​;
barelpro; +1 Ответить
47. barelpro 988 25.03.19 12:17 Сейчас в теме
(45) А, понял, ДобавитьОбработчик, а не ПодключитьОбработчик. Да, инересно, мы совсем забыли про эту возможность, хотя она в 8.2.13 уже была. Спасибо за идею!
78. Teopemuk 16.05.19 17:10 Сейчас в теме
(45) После обновления дизайна ИТС ссылка стала нерабочей
32. Vladimir Litvinenko 1692 24.03.19 12:31 Сейчас в теме
Как в при такой схеме обмена решалась проблема с коллизиями изменения данных?

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

Возьмем классическое описание коллизии для такого случая.

1) В базе "А" изменился элемент справочника "Номенклатура".
2) Одновременно с этим в базе "В" изменился тот же элемент справочника.
3) База "А" выгружается свои изменения в RMQ.
4) База "В" выгружается свои изменения в RMQ.
5) В базу "А" приходит элемент из базы "В" и затирает ранее сделанные в базе "А" изменения.
6) В базу "В" приходит элемент из базы "А" и затирает ранее сделанные в базе "В" изменения.
7) Имеем итог: две базы просто обменялись состоянием элементов. Ни в одной из них оно не стало корректным.

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

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

Обрабатывалась ли такая ситуация в данном случае?
35. barelpro 988 24.03.19 16:04 Сейчас в теме
(32) Да, в теории коллизии возможны, но реальный бизнес мы (автоматизаторы) должны убеждать, что у каждого элемента НСИ или документа должно быть одно место публикации, остальные места - чисто подписчики для чтения. Допускается цепочка дообогащения элементов по базам, но без обработной связи. Иначе будет хаос в информационной системе и в конечном счете в бизнесе .

В данном проекте нам удалось решить коллизию с номенклатурой, которая рождается и в НСИ и в PLM следующим образом:
- выделили разные диапазоны артикулов для новой номенклатуры, заводимой в MDM и в PLM.
- номенклатура, попавшая в PLM из MDM блокируется програмно для изменений
- как только номенклатура, попавшая в MDM из PLM дообогащена, то такая номенклатура в PLM блокируется для изменения
DimaP; A_Max; Vladimir Litvinenko; acanta; +4 Ответить
42. Vladimir Litvinenko 1692 24.03.19 21:32 Сейчас в теме
(35) Большое спасибо за ответ!

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

Представьте себе ситуацию (пример из реальной практики) когда есть центральная база, например ERP, где контрагент/партнер создаётся через обмен с сайтом или после звонка в кол-центр. Затем этот клиент может прийти в магазин, где идёт работа в другой базе, например УТ или Рознице. Там он уточняет персональные данные, которые уходят обменами в центральную базу. Сразу после покупки он может зайти на сайт с телефона или позвонить в кол-центр и поменять ещё какие-то данные о себе. Например забыл в магазине сообщить новый номер телефона и решил его уточнить. А данные эти идут в центральную базу и затем снова в базу магазина.

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


Нет ли при использовании RMQ возможности обработать коллизии программно, а не организационными методами? Например, можно ли при отправке в очередь получить от самого RMQ информацию, что аналогичная информация (например с таким же GUID или заголовком) уже есть в очереди для обработки той базой, которая собиралась отправить её со своей стороны, и перед отправкой должна быть получена и обработана ей?
44. barelpro 988 24.03.19 23:15 Сейчас в теме
(42) Нет, RMQ это всего лишь быстрый транспорт, не более.
Ситуацию которую вы описали можно попробовать решить так: разделить карточку клиента на две группы одинаковых реквизитов по их автору:
1 группа - реквизиты измененные сотрудниками компании
2 группа - реквизиты измененные самим клиентом

Далее должен быть какой-то механизм принятия одного из вариантов в качестве основного, скорее всего привязанный к какому-то событию - не знаю, личному общению клиента с оператором, либо валидация документов. В любом случае - это задача службы, ответственно за НСИ.
Vladimir Litvinenko; acanta; +2 Ответить
33. acanta 55 24.03.19 13:12 Сейчас в теме
При коллизии есть возможность увидеть, чей вариант в данной базе и когда он возник в источнике?
36. barelpro 988 24.03.19 16:06 Сейчас в теме
(33) да, там где это нужно, мы сделали специальный РС для ссылочных объектов - указывающий место публикации элемента
34. acanta 55 24.03.19 14:10 Сейчас в теме
Спасибо за статью, хотела сказать что лично мы застряли на 4 варианте и даже не представляли что такое возможно.
37. barelpro 988 24.03.19 16:09 Сейчас в теме
(34) Интересно, удалось в итоге внедрить эту схему?
38. acanta 55 24.03.19 16:40 Сейчас в теме
(37) это оказалось вредная идея фикс, из за которой генерация других идей и вариантов был остановлен, а реализация этого требует больше времени, чем прогнозное время поддержки формата ED.
Со временем, думаю кд 3 допилят, добавив в нее то, чего в ней не хватает, например корреляции между конфигурациями и форматом ED.
39. barelpro 988 24.03.19 17:52 Сейчас в теме
(38) Вангую, что 1С поймет наконец, что ED надо дать возможность дорабатывать, а не пользоваться суррогатами, типа AdditionalInfo. Может сделают нормальный конструктор. Загрузчик данных из конфигураций. Подключение к хранилищу....
Vladimir Litvinenko; acanta; +2 Ответить
41. MaxS 1602 24.03.19 18:03 Сейчас в теме
(39) универсальный формат ED можно дорабатывать, никто не запрещает и даже КД3 поддерживает. Правда его универсальность пропадёт. Но если в рамках одной организации нужно наладить обмен между зоопарком разных баз, это может быть выходом. Универсальный формат в пределах Вашей организации будет.
43. Vladimir Litvinenko 1692 24.03.19 21:50 Сейчас в теме
(39) Ох. Сколько лет уже прошло, но этой возможности не появилось. Кажется что ED изначально создавался и сейчас развивается в основном для обмена с базами регламентированного учета (БП, ЗУП). Раньше даже обмен характеристиками номенклатуры не был полноценно реализован и доработка была не из простых. И чтобы видами номенклатуры обменяться надо было сильно постараться. Сейчас наверное уже доработали.

P.S.: Проверил. Видов номенклатуры по прежнему нет. То есть, например, чтобы отправить из одной базы УТ в другую номенклатуру нового вида по прежнему нужно свой пакет создавать или делать собственную сериализацию и паковать вид в AdditionalInfo. В таких условиях конструктор пакета действительно не помешал бы.
46. MaxS 1602 25.03.19 06:40 Сейчас в теме
(43) В формате 1.6 виды номенклатуры есть и в ERP 2.4.7 и аналогичных КА, УТ они появились так же как и характеристики, но вариант из коробки опять нерабочий. Нет обмена дополнительными реквизитами характеристик, вид номенклатуры без справочника "Наборы дополнительных реквизитов и сведений".
Пришлось всё переделать в расширении. Но оно не решает все вопросы - пока нельзя изменить состав плана обмена не меняя конфигурации.
Не хватает в ED универсального документа и справочника с универсальной табличной частью, чтобы не меняя формата была возможность обменяться неподдерживаемыми форматом документами и справочниками. Пришлось в качестве универсального справочника использовать статьиДДС и на стороне приемника проверять что это, чтобы подставить нужное ПКО.
A_Max; acanta; +2 Ответить
69. acanta 55 01.04.19 13:22 Сейчас в теме
(43)
P.S.: Проверил. Видов номенклатуры по прежнему нет. То есть, например, чтобы отправить из одной базы УТ в другую номенклатуру нового вида по прежнему нужно свой пакет создавать или делать собственную сериализацию и паковать вид в AdditionalInfo.


Если учитывать что
ED изначально создавался и сейчас развивается в основном для обмена с базами регламентированного учета (БП, ЗУП).

То это логично, в БП виды номенклатуры соответствуют группам финансового учета (хотя он этого тоже не знает).
40. acanta 55 24.03.19 17:56 Сейчас в теме
На доработки конфигурации лимит установлен был виндоус, а не 1с. Количество одновременно открытых объектов при объединении конфигураций ограничено.
Следовательно либо групповая разработка одной конфигурации без объединения, либо предельный размер конфигурации в половину от лимита.
48. DimaP 56 25.03.19 16:24 Сейчас в теме
Очень ценная статья!
Наконец-то начали использовать RMQ для обменов между конфигурациями на 1С.
Собственно, к этому уже давно шло. Возможно, когда-нибудь появится типовое тиражируемое решение.

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

Отдельно увидел ссылку на "Пулю" - было бы интересно увидеть как это решение организовано и работает. Возможно, какие-то сравнительные тесты и как использовали на практике.
50. barelpro 988 25.03.19 19:01 Сейчас в теме
(48) Согласен, для принятие решения, какой вариант использвать в проекте, надо больше информации и сравнительных тестов.
Такие тесты по идее могут себе позволить разработчики тиражных решений, но они точно будут предвзяты в свою пользу )
Мы руководствовались интуицией и здравым смыслом, бюджета и времени на принятие более взвешенных решений не было. И нам очень не хватало независимых мнений. Поэтому мы и написали эту статью, чтобы хоть как-то заполнить пробелы, и помочь членам нашего сообщества.
51. OerlandHue 26.03.19 04:10 Сейчас в теме
Баг, при котором затирается базовый тип у объектов при импорте xsd схемы вы как обошли?
52. barelpro 988 26.03.19 09:22 Сейчас в теме
(51) Ого, тоже через это прошли? )

Ну собственно как я и описал - избавились от ссылки на базовый тип Ref пакета ExchangeMessage. Просто перенесли его внутрь самого пакета ED и переписали на него ссылки всех ссылочных типов.
А до этого в явном виде указывали путь к ExchangeMessage внутри XSD-файла с помощью конструкции:
<xs:import schemaLocation="\\Server\EM.xsd" namespace="http://www.1c.ru/SSL/Exchange/Message"/>
Только так он начинал видеть базовый тип Ref, а не AnyType.
Но это варварство каждый раз дергать файловую систему, поэтому решили радикально.
OerlandHue; +1 Ответить
53. OerlandHue 26.03.19 09:36 Сейчас в теме
(52)
вый тип Ref пакета ExchangeMessage. Просто перенесли его внутрь самого пакета ED и переписали на него ссылки всех ссылочных типов.
А до этого в явном виде указывали путь к ExchangeMessage внутри XSD-файла с помощью конструкции:

Только так он начинал видеть базовый тип Ref, а не AnyType.


А как без решения этого бага можно делать свой ED? Мы сейчас, например, берем, в УП добавляем в свой ED новый объект, теперь нужно обновить в БП его же, приходится делать через сравнение объединение конфигураций, потому что удалять-добавлять из буфера Пакет - а это значит менять идентификатор объекта метаданных, чего делать не хочется - GIT захламляется ненужными изменениями, да и сравнение-объединение не по наименованию при обновлении правильно использовать.

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

Спасибо, что потрудились все выложить, тут материала намного больше, чем кажется и некоторые решения вызывают восхищение. И у нас как раз куплен rabbit MQ, но мы еще не остро столкнулись с медленной работой обмена, нет срочных требований этот обмен ускорить, поэтому не думали, как шину данных применять в этом кейсе.
barelpro; +1 Ответить
63. petrpk 27.03.19 12:00 Сейчас в теме
(53)Мы сейчас, например, берем, в УП добавляем в свой ED новый объект, теперь нужно обновить в БП его же, приходится делать через сравнение объединение конфигураций, потому что удалять-добавлять из буфера Пакет - а это значит менять идентификатор объекта метаданных .

Тоже через это прошли. Поэтому вынесли наш пакет(ed) в хранилище значений отдельного справочника. Добавили к нему номер версии и автоматизировали создание и рассылку новой версии ed из базы кд3 по всем конфигурациям.
54. MaxS 1602 26.03.19 09:42 Сейчас в теме
(51) сталкивался, ещё не пробовал автоматизировать. Может быть поможет совет. В командном режиме выгрузить конфигурацию полностью или частично в файлы, посмотреть в каком виде оно там хранится, подменить файл пакета и загрузить обратно файлы в конфигурацию.
55. barelpro 988 26.03.19 09:50 Сейчас в теме
(54) Ага, почти так и делали. Только когда делаешь выгрузить конифгурацию в файлы, XDTO-пакет туда не попадает. Все гораздо проще делается:

Делаем "Экспорт XML-схемы". Делаем поиск и замену. Делаем "Импорт XML-схемы". Дальше появлется окно "Выбор обновляемых простанств имен", ставишь галочку - и все готово!
56. Vladimir Litvinenko 1692 26.03.19 10:19 Сейчас в теме
(55) При выгрузке/загрузке конфигурации XDTO-пакеты выгружаются/загружаются также как и все прочие объекты. Просто ему даётся расширение .bin. Но фактически это текстовый файл с xml-содержимым:
57. barelpro 988 26.03.19 12:46 Сейчас в теме
(56) Согласен, погорячился )
58. maxim4566 26.03.19 21:21 Сейчас в теме
Только решил изучить, захожу а тут токая годнота.
59. Kosstikk 86 26.03.19 21:38 Сейчас в теме
Спасибо за статью!

Несколько не прозрачно, что именно выбрали для взаимодействия с RabbitMQ из 1С, YellowRabbitMQ?

Подскажите, рассматривали вариант взаимодействия через http api? Насколько он приемлем, есть ли ограничения? (скорость, количество запросов и т.д.)

Если правильно понимаю, такая возможность есть:
https://pulse.mozilla.org/api/
https://stackoverflow.com/questions/32486398/publishing-to-the-default-rabbitmq-exchange-using-the-http-api
60. barelpro 988 26.03.19 22:37 Сейчас в теме
(59) Отвечаю по пунктам:

1. Взяли YRMQ из коробки БИТ:Адаптер (сразу не разобрались, что концепция БИТ:Адаптер нам не подходит, иначе купили бы только YRMQ)

2. Мы тоже по-началу думали, что запросы HTTP можно реализовать средствами 1С и отказаться от внешней компоненты. Но, знающие люди подсказали, что это будет работать в разы медленее. Хотя и не привели никаких веских доказательств или замеров, кроме общедоступных: RPC работает на транспортном протоколе TCP, а HTTP изначально не транспортный протокол. Так что вопрос на самом деле остается открытым. Может кто сможет внятно объяснить или привести пруфлинки?

PS Если поискать в англоязычной среде, то можно найти те же самые выводы, но чуть более обоснованные: https://stackoverflow.com/questions/16838416/service-oriented-architecture-amqp-or-http
61. Kosstikk 86 27.03.19 08:17 Сейчас в теме
(60)
YRMQ


Тоже сразу подумал, про ограничения, http - это 250-500 запросов в секунду, никак не 150 000 )))
а Rabbit умеет MQTT -> AMPQ и это круто, конечно.

Надо подумать про YRMQ.
Просто в одном случае мы имеем доступное api от разработчика rabbit и возможности 1с для реализации, в другом прослойку native api с возможными ограничениями (там вроде же подписку надо покупать и компонента именная, утечет - будут проблемы).
Причем, как я вижу, для любых популярных языков работа с rabbitMQ - разжевана, 1с как всегда оставляет возможность разработать что-то самому и запаковать в компоненту.

Еще вопрос, почему отказались от 1с планов обмена как механизма регистрации изменений?) Объективно.
barelpro; +1 Ответить
62. barelpro 988 27.03.19 11:00 Сейчас в теме
(61)

1. Насчет подписки - точно не обязательно. Она нужна скорее для поддержки и обновлений, чтобы получать возможные новые фичи. А насчет именной компоненты - спросим, на следующей неделе планировали в гости к парням заскочить.

2. Планы обмена не вписывались в концепцию быстрой передачи.Нам надо формировать XML-образ объекта в формате ED сразу, внутри транзакции при измененнии. Поэтому мы сделали РС "Очередь недоставленных сообщений" - по сути аналог плана обмена, С той лишь раницей, что у нас образ объекта формируется сразу на момент изменения, а таблицы изменений плана обмен хранят ссылки. И мы в любой момент готовы отказаться от этого промежуточного буфера, и отправлять сообщение сразу внутри транзакции, если будем иметь гарантию, что транзакция не прервется и каналы связи не заглючат. По поводу действий в конце транзакци транзакции - тут в форуме подсказали старый добрый ДобавитьОбработчик. А по поводу надежности канала - тут надо время пособирать статистику.

Хотя вот прям сейчас подумал, если использовать ДобавитьОбработчик, то последднюю милю по формированию сообщения в ED и его отправке можно пройти уже в фоновом задании, которое запускать прямо перед завершением транакции. В общем есть еще куда расти )))
70. barelpro 988 02.04.19 23:47 Сейчас в теме
(61)
Да, Пуля подтвердила, компонента именная!
Годовая подписка на обновление компоненты - порядка 30тр. Брать или не брать - личное дело каждого. Мы например использовали старую версию, в которой еще не было метода сжатия сообщений, сейчас бы это пригодилось. И еще узнали про пару полезных фичей и исправленных багов. В общем для следующего проекта будем брать компоненту сразу у Пули. Сейчас активно изучаем Кафку (и вспоминаем Грегора Замзу )))
64. Cyberhawk 111 28.03.19 09:22 Сейчас в теме
В шаге 2.1 вы пишете, что накладываете разделяемую блокировку на весь регистр объектов к отправке, что делает невозможным запись в этот регистр на время такой блокировки.
Т.е. во время отправки каждая транзакция записи объекта в БД, которая уже готова пополнить очередь отправки (заблокированный регистр), будет ждать окончания отправки, правильно понимаю?
65. barelpro 988 28.03.19 13:10 Сейчас в теме
(64) Всё верно, это защита от грязного чтения. Точно такой же эффект в механизме планов обмена.
Блокировка типа S накладывается на время выполнения запроса, это никому не мешающая пара миллисекунд, зато запрос читает только записи завершенных транзакций.
Если вдаваться в детали - блокировка S устанавливается не на всю таблицу, а на весь результат запроса - а это уже завершенные записи. Т.е. сам он никому не мешает, зато ему мешают незаконченные транзакции.

Но выше было описан способ как обойти эту проблему.
67. Cyberhawk 111 28.03.19 13:57 Сейчас в теме
(65)
блокировка S устанавливается не на всю таблицу, а на весь результат запроса
А, понятно, т.е. просто Запрос.Выполнить() в транзакции, что в худшем случае (8.2) блокирует считанный диапазон на запись только на время выполнения этого запроса, а в лучшем (8.3 или RCSI) вообще ничего не блокирует.
Я-то сначала думал, что речь о явной (устанавливаемой кодом) упр. блокировке, которая держится до конца транзакции (выгрузки), поэтому и "напрягся" :)
68. barelpro 988 28.03.19 14:24 Сейчас в теме
(67) ага, именно так:
НачатьТранзакцию();
Р = Запрос.Выполнить();
ЗафиксироватьТранзакцию();
71. tambu 9 18.04.19 08:27 Сейчас в теме
Спасибо за такой содержательный материал. Порадовала связка ED+Rabbit. Когда-то, когда появился самый первый курс по КД3, я спрашивал преподавателя, не является ли КД3 предтечей появления шины данных 1С. Он поговорил с разработчиками КД3 и ответил, что таких планов нет.
Спасибо за ваш труд, уверен, он будет очень полезен всем 1Сникам.
Не нашел ответа лишь на один вопрос, как дела у этой связки с производительностью. Понятно, что сам кролик быстр, но всё в комплексе? Если, к примеру, связи не будет сутки и накопится большая очередь? Когда-то мы сравнивали производительность обменов КД2 и КД3 и последняя была не на высоте, на наших объемах скорость выгрузки падала в разы, до загрузки даже и не доходило. Правда это было три года назад.
Плюс, событийная модель. Если «классический» обмен мы можем провести ночью, тем самым утилизируя сервера, когда нет пользователей, то в событийной модели мы как будто получим в базе-приемнике прирост количества пользователей на количество пользователей источника.
Я понял, что вы ограничили количество фоновых и тем самым снизили нагрузку, но хотелось бы услышать для какой системы приемлемы такие параметры? Сколько пользователей, сколько документов создается в час\сутки, сколько сейчас "весит" база и как быстро растёт?
Есть ли у вас опыт применения в высоконагруженных системах, где в источнике и приемнике работают несколько сотен пользователей одновременно?
Понятно, что самое длительное – это проведение документов и его можно отложить на ночь, но тогда несколько теряется смысл, вроде данные доставили, а в отчетах всё равно получим информацию «завтра».
Любопытство не праздное - сами сейчас на распутье, КД2 уже "не вывозит", думаем на что заменить. Пока рабочий вариант - пустить НСИ через веб-сервисы (возможно с кроликом), а документы через КД2, но уже без справочной информации (только ссылки).
72. barelpro 988 19.04.19 08:25 Сейчас в теме
(71) Спасибо за вопросы. Сейчас уже прошло достаточно времени, чтобы взглянуть критично на результаты проекта.
База ERP была скорее средненагруженная, в пике доходило до 300 пользователей, хотя всего лицензий вместе с другими системами - 500. По сравнению с текущим проектом, где уже 2000, а в перспективе 10000 - это вообще ни о чем! Кстати в перспективе хорошая тема для новой статьи. )
При выборе способа интеграции надо исходить из прагматики бизнеса. В данном бизнесе достаточно жесткие временные нормативы по заведению новых контрагентов/номенклатуры, отработки клиентских запросов по срокам поставки, размещению производственных заказов, отгрузки товаров со склада и т.д. Поэтому "классический" КД2-обмен через файлы сильно тормозил бизнес, с его пошаговой логикой доставка в лучшем случае происходила через 30 минут. Вы правильно говорите, что фоновые задания добавляют в базу получателя еще несколько очень активных пользователей, так и есть. И мы к этому пришли не просто так, потому что при поштучной обработке отправки-получения в событийной модели становятся чувствительными накладные расходы - для каждого объекта из хранилища значения вынимается фабрика XDTO и менеджер обработки данных с правилами, у нас временной довесок на стороне отправителя составил максимум 0.4 сек, чаще меньше. Так что если сравнивать на больших объемах данных чистое время загрузки-выгрузки КД2 и нашего механизма в одном потоке, наш механизм немного проигрывал. И мы такие замеры производили. Поэтому и пришли к выводу что нужна параллельная обработка на стороне получателя – в результате даже на 5 фоновых заданиях мы уже обогнали КД2 в разы. Судите сами - на стороне отправителя уже есть естественная параллельная обработка - конвертация каждого объекта в ED происходит внутри пользовательских транзакций. Когда мы сделали такую же параллельную обработку на стороне получателя, то мы уровняли плечи отправителя и получателя, по сути отзеркалировали ту же параллельность.

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

В вашем случае прежде чем приступать к выбору нового механизма интеграции надо сначала изучить статистику – сколько и каких НСИ передается, сколько документов передается, сколько из них проведенных, сколько тратиться времени, каковы последствия сбоев, каковы временные требования со стороны бизнеса – какие данные требуют режима онлайн, а что может подождать 10-15 минут или вообще сутки. Дальше можно провести тестовое моделирование пользовательского ввода этого объема информации на стороне получателя. Если система получателя выдерживает такой поток, тогда можно говорить о переходе на событийную модель.

В общем если что, пишите, поможем! Мы были первооткрывателями, в какой-то момент проекта получили сильную психологическую перегрузку, когда заказчик давит и уже практически выгоняет с проекта, а у нас нет уверенности что все получится. Вот в преодолении этого состояния неопределенности можем помочь )
73. tambu 9 22.04.19 09:51 Сейчас в теме
Спасибо за ответ и за предложение, обязательно воспользуюсь, когда появятся конкретные вопросы :)
А Вы не смотрели в сторону 2ИС:интеграции? Получается, что в Вашей схеме одно из ключевых преимуществ - многопоточность. В 2ИС она реализована на КД2, что называется "из коробки".
У нас очень много обменов написаны именно на КД2 и переписывать их с нуля - дорого и долго. Поэтому пробуем старые правила "заводить" на 2ИС, параллельно выделяя критичные для бизнеса места, которые нужно перевести на онлайн (те же НСИ).
74. barelpro 988 22.04.19 13:24 Сейчас в теме
(73) Да, 2iS:Интеграция смотрели, довольно мощный продукт, помимо интеграции там много чего полезного для администрирования. А параллельной загрузкой они вообще убили - выжали максимум из старой технологии КД2! Но все равно к 2ИС есть вопросы:
- может ли она обеспечить доставку объектов в режиме он-лайн (хотя бы за 10 секунд?)
- если там остался принцип пакетной передачи, то может ли она выборочно снимать с регистрации объекты с успешной доставкой, и оставлять регистрацию для объектов с неуспешной доставкой?
- остался ли КД2шный принцип написания правил "точка-точка"? Т.е. для обмена между 4 базами нам надо создать 12 комплектов правил КД2?
77. Teopemuk 16.05.19 16:59 Сейчас в теме
(74) Отвечу на Ваши вопросы по 2iS
1. Нельзя сказать, что это будем прям вот чистый онлайн, но расписание работы автозаданий обмена можно настраивать с любым произвольным интервалом запуска.
2. Может. Уважаемый tambu уже написал, могу к сказанному добавить, что есть настраиваемый параметр, который управляет, какое количество таких "неудачных" объектов считать порогом "неудачного" обмена. Т.е. если этот парамерт 100, а в процессе обмена неудалось записать 50 объектов - обмен все равно считается успешным. в противном случае регистрируется тревожное состояние и делаются рассылки оповещений.
3. К сожалению, остался. :(
75. tambu 9 29.04.19 07:29 Сейчас в теме
Я на все вопросы не отвечу, с 2ИС мы пока только пилотные обмены запустили. Когда будет более серьёзный опыт напишу.
Сейчас только по второму вопросу. Когда 2ИС не может записать объект, она делает несколько попыток (это может помочь, если ошибки возникают в результате блокировок). Если все попытки неуспешны, то она запоминает этот объект и повторно регистрирует его к отправке со следующим обменом. То есть ответ "да", она снимает объекты с успешной доставкой а неуспешные выгружает повторно. Далее, если вновь будет серия неуспехов, можно уведомлять админов. Режим "шины данных" заявлен, также заявлена поддержка КД3, но мы ещё их на практике не использовали.
76. barelpro 988 29.04.19 12:12 Сейчас в теме
(75) Понял, интересно, я бы почтал отчет о проекте на 2ИС! )


(75)
2ИС не может записать объект, она делает несколько попыток (это может помочь, если ошибки возникают в результате блокировок)
- мы тоже до этого додумались. Только неуспешные мы не выгружаем повторно, а запоминаем и отправляем оповещение в HelpDesk - дальше служба поддержки сама разбирается в причинах недоставки и устраняет их, прежде чем переотправить.
Оставьте свое сообщение
Новые вопросы с вознаграждением
Автор темы объявил вознаграждение за найденный ответ, его получит тот, кто первый поможет автору.

Вакансии

Программист 1С
Санкт-Петербург
Полный день

Программист 1С
Санкт-Петербург
Полный день

Консультант 1С
Нижний Новгород
зарплата до 100 000 руб.
Полный день


Программист 1С
Бобров
зарплата от 100 000 руб. до 150 000 руб.
Временный (на проект)