Как мы РИБ на веб-сервисы переводили

Публикация № 1233012

Разработка - Обмен данными 1С - Распределенная БД (УРИБ, УРБД)

УРИБ РИБ веб-сервис обмен настройка обмена

Решение проблем обмена РИБ с 10+ баз с помощью веб-сервисов и базы обмена.

В начале был РИБ, и РИБ был медленный...

Как и большинство феодальных дистрибьюторских бизнесов, все начиналось с одной-единственной базы УТ.

Далее, как говорится, шли годы, компания росла, добавлялись новые филиалы - количество которых приблизилось к 30-ти, а потом и превысило это количество, к тому же разрастались процессы и запросы к актуальности данных. Продолжительность полного цикла обмена между 30 базами РИБ с большим количеством документов не отвечала требованиям бизнеса и многие данные должны были появляться «здесь и сейчас». 

Центральная база не успевала отработать весь объем, блокировала работу и, как следствие, была выделена только для обмена, т.к работа в ней пользователей была невозможна. Сделали так, что центральная база (ЦБ) превратилась в периферийную, а обменная база (ОБ) стала главным узлом. Так как в качестве транспорта данных использовался FTP и в схему передачи данных добавилось ещё одно звено ОБ, то при этом значительно увеличилось время для передачи данных от ЦБ до филиала: до 6 часов. А такие вещи как скидки, например, или установку цен номенклатуры, очень хотелось, да собственно прямо скажем - требовалось - передавать побыстрее. Приоритезация решалась последовательностью обмена с ОБ (сначала ЦБ, потом остальные).

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

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

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

Эпоха веб сервисов

Однажды было принято решение создать единую базу с хранением нужной НСИ, которая раздавала бы данные по мере необходимости, не дожидаясь полного цикла обмена. Более подробно о проблеме и решении описано тут (//appaas.u-clouds.com/public/944961/).


Думаем... думаем... и придумываем

Технология веб-сервисов зарекомендовала себя с хорошей стороны и возникла шальная мысль: 

«А не перевести ли весь обмен на веб-сервисы? Базы все однотипные (модное слово “не гетерогенные”), будет работать сериализация, напилим базу-диспетчер обмена и будет нам счастье». 

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

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

1. Изменения конфигурации

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

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

2. Приоритезация изменений

В базе-диспетчере (БДО) есть приоритет (число) для каждого филиала. Если пришел объект в БДО с более высоким приоритетом, то он перезаписывается в раздаче для получателей. Перед загрузкой в более приоритетную базу проверяем наличие изменений в плане объекта и принимаем решение по приоритету.

3. Маршрутизация

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

4. Отказоустойчивость

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

Сеем

Инициатором всех процессов является БДО. В ней для каждой ПБ есть регламентное задание для обмена, выполняющее 2 процедуры: ПрочитатьИзменения(..) и ЗаписатьИзменения(..).  

Чтение данных (концептуальный вариант)

  • Из плана обмена “ВебОбмен” выполняется считывание 1 зарегистрированного там объекта и его сериализация в XML-текст.
  • После того, как объект считан и XML-текст помещён в массив - объект снимается с регистрации в плане обмена “ВебОбмен” и записывается в регистр сведений “Прочитанные объекты”.
  • Чтение происходит до тех пор, пока размер формируемого пакета, не превышает установленного значения (в нашем случае 1,5 мб), либо пока не кончатся элементы в регистре.
  • Сформированный массив XML-текстов в сжимаемом типе данных “ХранилищеЗначения” передается  в обменную базу.
  • Каждый полученный XML-текст записывается в регистр сведений “ОчередьПакетов” в обменной базе при условии, что уже имеющаяся запись с таким же объектом не от базы с повышенным приоритетом. После записи каждого XML-текста в базу-отправитель по web-сервису отправляется команда на удаление записи в регистре сведений «Прочитанные объекты». Если по какой-либо причине не удаётся выполнить запись XML-текста в регистр сведений “ОчередьПакетов”, то удаления объекта из регистра не происходит. В следующий раз объект будет повторно выгружен в п.5. (перед обменом данные регистра загружаем в план обмена).
  • Операции 1-5 выполняются до тех пор, пока не закончатся объекты в плане обмена.

Запись изменений в базу-получатель

  • В обменной базе сразу после получения данных формируется выборка XML-текстов, которые нужно передать в базу-получатель (эта же база только что была базой-отправителем). 
  • Запись одного XML-текста регистра сведений “ОчередьПакетов” блокируется в обменной базе.
  • XML-текст передаётся по web-сервису в базу-получатель, десериализуется в объект 1С.
  • Объект 1С записывается в базе-получателе в транзакции. В случае документа, также происходит запись проводок.
  • Запись из регистра сведений “ОчередьПакетов” удаляется.
  • Снимается блокировка с записи XML-текста регистра сведений “ОчередьПакетов” в обменной базе.
  • Операции 2-8 выполняются по циклу до тех пор, пока не закончится выборка.

Концептуальная схема обмена

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

Пожинаем

  • Ускорение обменов
  • Обменная база значительно повышает скорость передачи данных между ЦБ и подчиненными базами. 
  • Разгружает центральную базу.  Обменной базе достаточно обменяться с обменной базой только один раз, которая далее обменивается с периферийными базами. 
  • Значительно реже случаются конфликты блокировок. Сервер обмена не блокирует центральную базу целиком при выполнении обмена. Блокировка данных (начало транзакции - конец транзакции) включается только на момент передачи одного экземпляра объекта. Это существенно разгружает базу данных, если управляемые блокировки таблиц в конфигурации ещё не включены.
  • Отказоустойчивость
  • Восстановление передачи данных с точки прерывания. При повторном запуске передача продолжится с того же места. Можно самостоятельно остановить выполнение передачи данных. 
  • Мониторинг и статистика обменов
  • Видим очередь объектов в режиме он-лайн, можем анализировать и конфигурировать объемы данных и расписание.
  • Сбор статистики: понимаем, что “ходит” в обмене, делаем выводы для оптимизации.
  • Информирование пользователя о статусе обмена объекта.
  • Обменная база в инфраструктуре позволяет использовать полезные сервисные функции:
  • Исполнение произвольного кода на периферии.
  • Хранение тяжелых регистров сведений (нетиповое версионирование, например).
  • Централизованное выполнение регламентов (последовательности и т.д).

Не баги, а фичи….

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

Время собирать камни помидоры обратную связь

К тому моменту, когда система стала работать слаженно и бесперебойно, мы прошли через огромное количество споров по поводу технологии обмена. На Инфостарте есть куча отличных примеров от вдохновляющих нас ребят по работе с RabbitMQ и прочих интеграционных шин. На выбор технологии на платформе 1С повлияли экзистенциально-языческие сомнения в стабильность связки 1С и решений из “внешнего мира”. Хотелось обойтись без привлечения сторонних средств с целью избежания bus-фактора в команде. Обращения в техподдержку после ввода системы снизились в разы. Поддержка решения не требует специфических знаний сторонних технологий. 

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

Специальные предложения

Комментарии
Избранное Подписка Сортировка: Древо развёрнутое
Свернуть все
1. savostin.alex 76 14.05.20 05:24 Сейчас в теме
2. RSConsulting 135 14.05.20 13:54 Сейчас в теме
(1) Да, технология аналогичная, мы немого добавили сервиса для контроля обмена и сбора статистики, также выделили все в отдельную базу-диспетчер.
3. EvgeTrofi 17 15.05.20 11:03 Сейчас в теме
(1) Skype, Watsapp, Telegram, ICQ, Viber... список можно ещё продолжать
Какие у них особенности? Одно и то же ведь. И всё равно живут.
Тут дело в подходе.
Кто серьёзней, качественней и дешевле - тот и лидер.
Любой качественный велосипед найдёт своего потребителя.
4. acanta 15.05.20 11:11 Сейчас в теме
(3) в отличие от РИБ (появившейся еще во время дискет) можно легко представить себе что аськи или скайпа никогда не было. И как то же жили. Левитана слушали и патефоны с ручным приводом.
Но аську к РИБ не прикрутили, поэтому можно сделать вывод что даже миллион частных пользователей ничего не значит, если есть возможность поставить одного хотя бы одного робота.
5. EvgeTrofi 17 15.05.20 11:18 Сейчас в теме
(4)
Но аську к РИБ не прикрутили же

если бы был спрос на это - прикрутили бы.

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

если робот начинает не устраивать - миллион пользователей начинают искать другое решение
6. acanta 15.05.20 11:26 Сейчас в теме
(5) Ну так он и был, у нас сначала в компании аську запретили, а затем сделали внутрикорпоративные служебные чаты на miranda. Одно приложение - две учетные записи. И только потом появился Фейсбук, который в отличие от аськи можно не устанавливать на компьютер. Тенденции на развитие бизнес-приложений были очевидны, хотя сейчас похоже бизнес решил что разделять бесполезно и вышел со всем своим контентом в телеграмм/инстаграмм/FB и тенденции как-то поменялись. Может в скором времени мы увидим публичную бухгалтерию в одноклассниках, почему нет, интересно же знать балансы тех, кто фотается на фоне чужих тачек..
10. savostin.alex 76 16.05.20 05:07 Сейчас в теме
(3)А причем тут соцсети и мессенджеры?
7. Rustig 1489 15.05.20 16:06 Сейчас в теме
(0) не понял, для чего используется веб-сервер?
вы разделили весь пакет обмена на мелкие пакеты, за счет чего скорость обмена улучшилась.
И самое главное, оставили ЦБ для обменных процессов, а в качестве основной базы для работы пользователей выделили еще одну базу (пусть она и стала еще одной периферийной базой).
Неужели этого не достаточно для оптимизации?
Для чего еще веб-сервисы для обмена документами подключать?
Веб-сервисы для контроля НСИ описаны в другой статье - про это понятно.
8. RSConsulting 135 15.05.20 19:20 Сейчас в теме
(7) Пакеты конечно мелкие, но все равно достаточно затратно по времени обменять весь цикл. (ПБ-ЦБ-ПБ). Причем это не будет работать при измененной конфигурации. Веб-сервисы отрабатывают на порядок быстрее и у нас есть возможность дополнительно мониторить всю информацию по обмену в отдельной базе.
9. Rustig 1489 15.05.20 19:23 Сейчас в теме
(8)а можете указать , где это описано в статье? или дополнительно дать развернутый ответ в части :

Веб-сервисы отрабатывают на порядок быстрее и у нас есть возможность дополнительно мониторить всю информацию по обмену в отдельной базе.
11. RSConsulting 135 16.05.20 07:31 Сейчас в теме
(9)Да, напрямую не описали. Это как следствие следующих тезисов "Любые срочные динамические изменения приводили к полному циклу обмена.", "Низкая масштабируемость решения (каждый раз создавать отдельный план) наводила на мысли о неверном пути".
В любом случае, типовой урезанный обмен работает не универсально, допустим мы захотели менять документ по установке цен, надо в обмен добавить всю ветку по ссылкам из документа и следить за этим при изменениях конфигурации, а то будут ненайденные ссылки. В случае веб сервиса типовая сериализация берет на себя эту функцию + мы дописываем движения документа в пакет.
12. Rustig 1489 16.05.20 10:56 Сейчас в теме
(11)
надо в обмен добавить всю ветку по ссылкам из документа


а как вы добавляете? вроде как платформа и объект метаданых ПланОБмена следит за этим...

В случае веб сервиса типовая сериализация берет на себя эту функцию


как сериализация следит за изменениями? если нет нового реквизита, должно в любом варианте ошибку выдать - что для сериализации, что для обычного обмена пообъектно.
13. RSConsulting 135 16.05.20 13:58 Сейчас в теме
(12)
а как вы добавляете? вроде как платформа и объект метаданых ПланОБмена следит за этим...

Нет, если я в план обмена добавлю галку только на документ, без входящих в него спр. то при обмене, в случае отсутствия элемента спр. будет <объект не найден>.

как сериализация следит за изменениями?

Она следит чтобы все реквизиты по ссылкам попали в пакет. Если в метаданных изменился реквизит то будет коллизия. От этого не застрахован ни один обмен, отвязанный от метаданных.
14. Rustig 1489 16.05.20 22:16 Сейчас в теме
15. EvgeTrofi 17 25.05.20 14:57 Сейчас в теме
Добавлена возможность выбрать способ хранения информации в обменной базе:
1. Очереди пакетов - Каждый сериализованный в XML объект записывается в отдельную очередь на отправку, предназначенную для конкретного получателя. Такой механизм используется на сервере очередей RabbitMQ.
Применяется, когда не требуется повторной переотправки сообщений.
Особенности: Объект из очереди удаляется сразу же после записи в получатель. Если объект ещё не получен получателем, а источник снова прислал этот же объект, но уже изменённого содержания - то объект перезаписывается во всех очередях.
Достоинства: Учитывается приоритет при попадании одного и того же объекта из разных баз.
Недостатки: Медленно работает для большого количества баз так как для каждой очереди будет записана отдельная запись одного и того-же объекта.
2. Журнал изменений - Все объекты записываются в одну очередь, упорядоченную по моменту времени. При чтении объекта каждый получатель ставит свой флаг напротив прочитанной ячейки данных. Технология сервера распределённых журналов событий (Distributed Event Log) Apache Kafka.
Применяется при необходимости иметь возможность переотправить все объекты (например, за вчерашний день), при случае, когда база-получатель была повреждена и восстановлена из копии.
Особенности: Объект из очереди не удаляется до тех пор, пока не закончится его срок годности, при условии, что все получатели получили объект.
Достоинства: Одинаково быстро работает для любого количества баз.
Недостатки: Не учитывается приоритет при коллизиях. Каждая версия объекта будет записана в свой момент времени. Сколько раз изменится объект в источнике - столько записей будет создано в журнале изменений и столько же раз эта запись будет перезаписана в получателе.
Прикрепленные файлы:
16. EvgeTrofi 17 26.05.20 19:35 Сейчас в теме
Создан раздел "Сборщики мусора". В этом разделе задаются параметры очистки устаревших данных и размещаются обработки очистки мусора. Наиболее крупные таблицы с данными в обменной базе оказались таблицы хранения версионирования. В них записаны все действия всех пользователей всех баз. В разделе "Сборщики мусора" имеется возможность настроить очистку по расписанию список накопленных пакетов данных, предназначенных для обмена, журнал регистрации 1С и очистку таблиц версионирования прямыми запросами к SQL.
17. EvgeTrofi 17 26.05.20 19:48 Сейчас в теме
Особое внимание уделено маршрутизации. Казалось бы, всё просто: например документ "Реализация", созданный в филиале "Тюмень" должен попасть в базу центрального офиса, который расположен например в Москве, а распространяться на базы других филиалов - не должен.
Предусмотрен такой случай, что в базу центрального офиса загрузили платёжку, указав, что документ принадлежит к филиалу "Томск". Обменом документ появляется в Томске. Затем оператор центрального офиса меняет подразделение в документе на "Тюмень". Обмен отправляет документ в Тюмень, а в Томске - помечает на удаление!
Кроме этой наглядной заморочки ещё много других, но я пока ограничусь этим.
18. user1035175 1 31.05.20 07:41 Сейчас в теме
что значит: "Обменной базе достаточно обменяться с обменной базой только один раз"
19. RSConsulting 135 31.05.20 11:41 Сейчас в теме
(18)Опечатка: "Центральной базе"
20. XSlava 143 04.06.20 15:42 Сейчас в теме
Вопрос: почему пошли путем обмена данными, а не единой базы на управляемых формах?
21. RSConsulting 135 04.06.20 20:54 Сейчас в теме
(20)на момент выбора архитектуры управляемые формы не применялись в промышленных масштабах и качество связи оставляла желать лучшего
22. RSConsulting 135 05.06.20 04:49 Сейчас в теме
Оставьте свое сообщение

См. также

Публикаций не найдено

Попробуйте расширить область поиска, проверьте поисковый запрос и повторите попытку.

Или закажите индивидуальную разработку вашего решения.

Создать заказ на разработку