Построение репликации в Navision

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

Сам механизм репликации сильно зависит от:

• характера взаимосвязи баз данных, между которыми настроена репликация;
• топологии репликации, сравнимой с топологией сети («звезда», линейная и т .д.);
• направленности обмена данными (одно-, двухсторонняя, каждый-каждому и т.д.);
• способа и типа передачи данных – online, файловый (XML, текстовый, др.);
• вида репликации (построчная или репликация по полям).

Для корректной работы репликации структура таблиц в реплицируемых базах должна быть максимально одинакова (при отсуствии маппирования при репликации). Для создания механизма репликации необходимо каким-либо образом фиксировать изменения/добавление/удаление записей в таблицы. Это можно делать:

• в самих таблицах;
• в отдельном журнале.

Репликация по счетчику

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

Плюсы:

• данные заносятся только в одну таблицу (не дублируются в журнал).

Минусы:

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

Репликация по действиям

Все действия с таблицей (вставка/изменение/удаление) фиксируются в журнале. Можно создать свой, можно использовать стандартный журнал изменений «Change Log Entry», настроив его должным образом.

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

Во втором случае (при использовании стандартного журнала изменений) добавлений кода в таблицы не требуется (отрабатывают тригерры OnGlobalInsert, OnGlobalModify и т.п. в 1-ом кодеюните «ApplicationManagement»), однако придется модифицировать код создания записей в этом журнале под ваши цели.

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

Плюсы:

• позволяет фиксировать все действия с записью (в т.ч. удаление);
• при репликации по полям не блокирует саму таблицу.

Минусы:

• Одновременное изменение записей в реплицируемых таблицах несколькими пользователями затруднено из-за последовательного использования журнала (журнал становится узким местом);
• Увеличение времени добавления/изменения реплицируемых таблиц (фактически запись ложится в 2 места — в саму таблицу и журнал);
• Рост базы (журнал быстро растет, необходим механизм его «урезания»);
• Нюансы (например пользователь может изменять запись несколько раз, при этом надо, чтобы «лишние» разы не попадали в журнал).

На самом деле это лишь вершина айсберга, конкретные «корни» которого зависят от условий, указанных в пункте 2.

Однако нет ничего невозможно ;) и в нашем случае файловая репликация работает более чем с 50-ю удаленным БД, имеет несколько ступеней и передает любые данные, начиная с документов и до настроек самой себя…

Дополнение к статье от Дмитрия Катсона:

Добрый день.
Хотелось бы добавить по пункту 2 – когда репликация идет по заполнению буфферной таблицы.
Для SQL-версии Navision есть специальная утилитка, которая позволяет настраивать таблицы, которые нужно реплицировать,
а затем позволяет заполнять буфферную таблицу уже подготовленными командами при вставке, удалении, переименовании или модифицировании таблицы.
Затем запускается «учет» буфферной таблицы и все данные перетекают в соответствующую таблицу на SQL в другой базе.
Утилитку бесплатно можно скачать с сайта http://mibuso.com/dlinfo.asp?FileID=883
Также есть возможность настроить репликацию в SQL Management studio.

Другие статьи на тему репликации — «Опыт настройки Navision + SQL Server для консолидации финансовой отчетности» и «К вопросу о репликации Navision средствами SQL Server»