Типовые сценарии интеграции

#1

Добрый день.
Пока только начал изучать демо yelow-rabbit mq и возникли типичные вопросы пользователей планов обменов :slight_smile: . Попробую изложить вопросы в виде сценариев на языке Gherkin.

Функционал: Обмен данными между 1С и сторонней системой

Как Пользователь обмена
Я хочу Обмениваться НСИ и документами с ИС-приемником
гарантированной доставкой
чтобы избежать дублирования информации в обоих системах
И избежать коллизий в обоих ИС

Контекст: 
   Дано Есть конфигурация 1С и сторонняя система
   И есть справочник "Партнеры"
Сценарий: Я отправляю 3 изменения справочника "Партнеры" из 1С в ИС-приемник
    Допустим я создал элемент справочника "Партнеры" у которого Реквизит1 = Ложь и Реквизит2 = Ложь
    Тогда сфомировалось сообщение обмена и отправилось в рабочую очередь обмена
    я изменил Реквизит1 в значение Истина и сохранил изменения
    Тогда сфомировалось сообщение обмена и отправилось в рабочую очередь обмена
    И я изменил Реквизит2 в значение Истина и сохранил изменения
    Тогда сфомировалось сообщение обмена и отправилось в рабочую очередь обмена
    И в ИС-приемник я прочитал первое сообщение и отправил ack
    И в ИС-приемник я прочитал второе сообщение и отправил ack
    И в ИС-приемник я не смог прочитать третье сообщение и выбросил исключение
    Тогда у меня в 1С у элемента справочника "Партнеры" Реквизит1 = Истина и Реквизит2 = Истина
    И в ИС-приемник у элемента справочника "Партнеры" Реквизит1 = Истина и Реквизит2 = Ложь
#2

Я так понимаю, данный вопрос решается c помощью dead-letters exchange. Только вот хотелось бы уточнить сценарий.
Как я это вижу:

  1. в очередь с DLX уходит сообщение, которое мы не приняли
  2. 1С считывает из этой очереди сообщение, подтверждает получение
  3. находит у себя объект по guid сравнивает номера версий объектов?
  4. если они отличаются делает повторную отправку этого элемента

В верном я направлении мыслю или нет?

#3

Коротко: в верном.

#4

А можете еще прояснить момент из документации:

“документ проведен” – это, конечно, событие, но лучше всего использовать конкретные бизнес-события “в заказе покупателя добавлена новая строка”

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

#5

Это зависит от конкретной нагрузки и бизнес-сценариев. Когда-то достаточно согласовать с транзакциями 1С, когда-то нет. Нет единого общего решения.