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

13.05.20

Интеграция - Обмен между базами 1C

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

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

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

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

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

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

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

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

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

Однажды было принято решение создать единую базу с хранением нужной НСИ, которая раздавала бы данные по мере необходимости, не дожидаясь полного цикла обмена. Более подробно о проблеме и решении описано тут (//infostart.ru/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-сервера не являлось для нас проблемой, т.к они уже были подняты для других задач. Мы надеемся, что данный подход возможно поможет оптимизировать обмена на других предприятиях. В любом случае любая обратная связь по вышеописанной концепции будет нам ценна и полезна.

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

См. также

SALE! 20%

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

04.08.2015    159665    363    267    

345

SALE! 15%

[ED3] Обмен для ERP 2.5, КА 2.5, УТ 11.5 БП 3.0, Розница, УНФ и других с EnterpriseData (универсальный формат обмена), правила обмена

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

Правила в универсальном формате обмена для ERP 2.5, КА 2.5, УТ 11.5, БП 3.0, Розница, УНФ, для последних версий конфигураций. Ссылки на другие конфигурации в описании публикации. Правила совместимы со всеми другими версиями конфигураций новыми и старыми, поддерживающими обмен в формате EnterpriseData. Не требуется синхронного обновления правил после обновления другой конфигурации, участвующей в обмене. Типовой обмен через планы обмена кнопкой Синхронизация вручную или автоматически по расписанию, или вручную обработкой.

25080 22572 руб.

12.06.2017    134919    722    291    

388

SALE! 20%

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

15.04.2019    68413    178    138    

111

SALE! 20%

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

03.12.2020    34167    80    58    

78

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    46283    196    64    

157

SALE! 10%

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

50722 45650 руб.

31.10.2014    231389    124    327    

295

Перенос данных из Парус 10 в ЗГУ ред.3

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

Обработка позволяет перенести кадровую информацию и данные по заработной плате, фактических удержаниях, НДФЛ, вычетах, страховых взносах из базы Парус 10 учреждений в конфигурацию 1С:Зарплата и кадры государственного учреждения ред. 3 (ЗГУ) и начать с ней работать с любого месяца года.

60000 руб.

05.10.2022    9205    9    8    

10

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

28000 25200 руб.

15.12.2021    20234    132    38    

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

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

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

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

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


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

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


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

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

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

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