Репликация. Рекомендации по ведению разработки в условиях репликации

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

С описанием механизма репликации можно познакомится в справке.

Основные особенности репликации, которые необходимо учитывать при разработке:

1. Конфликты. Одновременное действие с данными на разных серверах приведет к конфликтам.
2. Доступность данных на сервере. Сеансы репликации проходят не моментально, т.е. на удаленном сервере может не быть необходимых данных.

Доступность данных и ее учет в разработке

Список реплицируемых компонент

Одно из основных действий при настройке репликации – настройка списка реплицируемых компонент. Данный список будет определять какие данные и с какими правами будут реплицироваться на вторичный сервер.

При разработке нужно учитывать реплицируемость данной компоненты. Если данный справочник не реплицируется, то обращение к нему в прикладном коде будет приводить к ошибкам. Так же необходимо учитывать права, с которыми реплицируется справочник на вторичный сервер. Если справочник реплицируется на вторичный сервер с правами только на просмотр, то изменение записи (не важно каким способом произошло изменение данных и получалась запись: с проверкой прав или без нее) на вторичном сервере приведет к конфликту, который будет исправляться в автоматическом режиме (т.е. произойдет потеря данных на вторичном сервере).

Таким образом, при написании кода необходимо проверять список реплицируемых компонент и права, и, при необходимости, актуализировать его.

Фильтраторы в списке реплицируемых компонент

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

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

Репликация документов

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

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

Репликация тел документов

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

Репликация компонент

Компоненты системы (например, пользователи, группы пользователей, ТКЭД, типы справочников, функции и т.д.) не реплицируются. Так же не реплицируются права на компоненты. Это необходимо учитывать при разработке и переносе разработки. К примеру, необходимо определить автоматизированность работника и, следовательно, в условиях репликации не стоит определять автоматизированность работника по данным в компоненте Пользователи, т.к. для каждого сервера репликации список записей в компоненте и состояние реквизитов может быть различное - в данном случае нужно проверять справочник Пользователи.

Константы

Каждая запись компоненты Константы имеет реквизит Статус по серверам со значениями «Реплицировать» и «Не реплицировать». При создании константы и обращении к ней нужно это учитывать. Не стоит заводить реплицируемую константу, в которой будет находиться данные из не реплицируемых справочников, ИД документов, папок и т.д., поскольку к этим объектам может не быть доступа на удаленном сервере.

Временные таблицы, прикладные таблицы.

Очень часто в прикладном коде происходит обращение к прикладным SQL таблицам (при построении отчетов, ведении лога, сборе статистики и т.д.). Нужно понимать, что такие таблицы не реплицируются, т.е. данные из таких таблиц будут недоступны и не будут автоматически обновляться/дополняться данными с удаленных серверов. Если подобные таблицы все-таки необходимы и данные из таблиц должны быть на всех серверах, то такие таблицы необходимо выносить в справочники, при этом необходимо учитывать конфликты репликации.

Конфликты репликации 

Основным источником конфликтов репликации являются бизнес процессы и процессы автоматизации действий администраторов. Решение большинства видов конфликтов приводит к потере данных. Некоторые причины конфликтов:

Типовые маршруты

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

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

Параллельные задачи, обрабатывающие одни и те же данные

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

Параллельные задания

Очень часто при выполнении заданий автоматически вносятся изменения в записи справочников, документы, задачу. Если задачу будут одновременно выполнять на разных серверах, будет происходить конфликт. Для устранения причин конфликта можно вынести изменение данных в отдельный блок, при этом, если пользователь изменил текст задания, конфликта не будет. Про особенности обработки задач службой Workflow можно почитать в справке.

Одновременное изменение данных пользователями

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

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

Программная работа с компонентами

Часто встает задача автоматизации процесса создания групп пользователей и пользователей. Администрирование пользователей в системе с репликацией имеет ряд особенностей. С порядком создания пользователей можно познакомится в курсе 235.

Прочие особенности

Изменение данных SQL запросом

При изменении данных в системе с репликацией, все изменения фиксируются для передачи на удаленный сервер. Фиксация изменений происходит специализированными платформенными ХП. При изменении данных SQL запросом, вызов данных ХП не происходит, т.е. изменения не будут переданы на удаленный сервер. Для фиксации данных изменений необходимо вызывать специальные ХП. Имена данных ХП содержит текст "FixedAction". Фиксация данных происходит при помощи двух основных ХП: MBGetNumActionSP и MBFixedActionSP.

Хранимая процедура MBGetNumActionSP. Процедура предназначена для получения номера действия, в рамках которого должно фиксироваться текущее состояние объекта. Описание параметров ХП можно найти в тексте самой ХП.

Пример использования:

DECLARE @NumActionTask numeric(38,0)
EXECUTE dbo.MBGetNumActionSP 'MB_ANumAction', @NumActionTask output

В @NumActionTask будет содержаться номер действия.

Хранимая процедура MBFixedActionSP. Процедура фиксирует текущее состояние изменяемого объекта. Описание параметров ХП можно найти в тексте самой ХП. При изменении данных в системе SQL запросом, данную ХП необходимо вызвать два раза, до изменения данных и после изменения данных.

Пример использования (изменение истории):

DECLARE @XRecIDTaskProtocol numeric(38,0)
DECLARE @NumActionTaskProtocol numeric(38,0)
-- фиксация таблицы протокола до обновления
EXECUTE dbo.XNextID 'SB_TaskProtocolXRecID', @XRecIDTaskProtocol output
EXECUTE dbo.MBGetNumActionSP 'MB_ANumAction', @NumActionTaskProtocol output
EXECUTE dbo.MBFixedActionSP @FixedServer = NULL, @Sost = 'С', @TableName = 'SBTaskProtocol', 
                            @Where = NULL, @NumAction = @NumActionTaskProtocol OUTPUT, @TypeAction = 'I', 
                            @DevLevel = 0, @SrcRecID = @XRecIDTaskProtocol, @SrcCompIDSPS = NULL
                               
-- запись информации в историю: создание
EXECUTE dbo.SBWriteTaskHistory @TaskID = @TaskID, @JobID = @NewJobID, @UserID = @ConnectedUserID, @ModifyDate = @ServerTime, 
                               @ActionCode = 'C', @ServerCode = @ServerCode, @HistoryRecID = @XRecIDTaskProtocol  
                                 
-- фиксация таблицы протокола после обновления
EXECUTE dbo.MBFixedActionSP @FixedServer = NULL, @Sost = 'Н', @TableName = 'SBTaskProtocol', 
                                   @Where = NULL, @NumAction = @NumActionTaskProtocol OUTPUT, @TypeAction = 'I', 
                                   @DevLevel = 0, @SrcRecID = @XRecIDTaskProtocol, @SrcCompIDSPS = NULL

В зависимости от изменяемой таблицы, будут изменяться значения параметров при вызове хранимых процедур.

Экспорт и импорт разработки в системе с репликацией

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