Добрый день.

Конфигурация УПП 1.3, распределенка по схеме звезда. 5 периферией. В центральной базе для каждой периферики свой сценарий автоматического обмена, настроен каждые 10 минут. Документооборот достаточно большой, для примера только заказов со всех баз в день 1500. И в чем сообствено вопрос, есть ли способы оптимизировать обмен, что бы проходил быстрее. Вообщем если не делать лишних движений, не проводить прошлые документы, не включать расчет себестоимости, то есть работать с текущими доками, то обмен идет вроде как терпимо. Но если допустим кто то из бухов, что то начинает перепроводить, то сразу начинаются долгие выгрузки. Вот и хотелось узнать, может у кого есть опыт и посоветует, чего интересного.

Для бухов - 6ю базу и проводить с ней обмен ночью.

OpenVPN + RDP

А что тут можно посоветовать, если у бухов меняется сумма в прошлых документах?

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

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

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

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

(3) Бухи в одной периферийки. Ну я вот все думал задублировать планы обмена и оставить там только нужное для оперативного учета. У нас собственно встает вопрос в том что бы как можно скорее прилетели Заказы покупателей, остальные объект уже не так критичны.

(2) не пойдет, интернет не всегда стабильный. впн поднят, на него лучше не надеяться)

Объекты с разным приоритетом регистрировать и выгружать через разные планы обмена

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

(6) Так если Заказы - Ну сделай отдельную выгрузку для передачи только Заказов.
Тут у каждого свои предпочтения, но я бы сделал по своему :-)
Завел бы отдельную подписку на событие документов Заказы или какие там еще нужны. В подписке предусмотрел регистрацию изменения в отдельный специально заведенный План обмена со своими казино, блэкджеком и ... Затем выгрузку по этому узлу с высокой частотой, а остальные как раньше, но гораздо реже. И все.

Почему отдельный план? А чтоб существующие горы кода не разгребать и ничего не сломать при этом.

"И тут Остапа понесло..."(с) Не надо множить сущности.

(11) ну почему же не надо?
Это так интересно! Практически "День сурка"

(10) Интересный вариант. Спасибо

(12) У автора примерно 1500 заказов в день, т.е. около 200 документов в час, которые проскочат через обмен на 5-10 секунд... и ради этого городить отдельный план? Это несерьёзно, Фрэнки.

(14) Так это только заказы. Столько же реализаций, плюс платежки, расходник, приходники. Достаточно большой объем возвратов (около 15000), отчеты производства

(14) требования накладные, перемещения. (15) возвраты в месяц 15000

(15) Я не про общий обмен, я против "выделения" заказов покупателей в "отдельный" план обмена. Это только на словах всё просто. Вместе заказами покупателей в план обмена потребуется включить очень много иной информации, которая является "общей" (предназначенная и для других документов). Например, резервирование. Попробуйте как Вы один регистр будете "делить" между планами обмена :)

(17) Ага понял, проблема, надо смотреть походу дела, ну со справочниками тут все просто, они достаточно редко меняются, особенно номенклатура, да контрагенты то же не так часто, ну то что сходу вспомнил, может какие то с другими проблемы будут. Сейчас посмотрел движение которое формирует заказ, нам из всего нужен только регистр сведений Заказ покупателя, думаю с данным регистром проблем не должно быть. Какие еще варианты? Уменьшить между обменами?

(18) ну то, что вводится в общем случае, а по факту изменяется редко - такие данные включить в лишний обмен никакой критики не случится.
Вообще, нужно пробовать, тестить на чем-то. Собственно, именно при дополнительном новом плане оно и будет самый мягкий способ провести все изменения в работе обменов безболезненно. Основные обмены можно будет делать реже, что собственно и так само собой вынужденно происходит, т.к. объемы перебрасываемых данных зашкаливают разумные. А вот оперативные обмены их как раз и заменят.

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