Отправляет email-рассылки с помощью сервиса Sendsay

Navision - советы и секреты

Рассылка закрыта

При закрытии подписчики были переданы в рассылку "Идеи бизнеса" на которую и рекомендуем вам подписаться.

Вы можете найти рассылки сходной тематики в Каталоге рассылок.

←   Март 2008   →
 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
Автор
Neubitiy

Статистика

0 подписчиков
0 за неделю
←   Все выпуски   →

Navision - советы и секреты


Добрый день!

Сегодняший выпуск подготовлен с помощью читателя нашей рассылки Дмитрия Пелипенко (dmites@rambler.ru). Он прислал очень интересный материал на тему репликации в Navision.


Технология построения репликации в Navision

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

2. Механизм репликации сильно зависит от характера взаимосвязи баз данных между которыми происходит репликация:

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

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

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

Первый способ - по счетчику

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

Плюсы:

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

Минусы:

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

Второй способ - по действиям

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

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

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

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

Плюсы:

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

Минусы:

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

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

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



На сегодня всё. Свои вопросы, комментарии по статье шлите на likeart@mail.ru.

Прекрасную половину - с наступающим! :-)

P.S.Хотите поделиться своими знаниями? Всегда Welcome! Любые статьи, Q & A, FAQ, советы - все опубликуем, обязательно укажем автора и дадим линк на сайт :-)

С наилучшими пожеланиями,
Андрей Стрельников.

Группа «Technologies like Art».
Разработки в сфере Navision. Скоростные и суперскоростные оптимизации, системная интеграция.
e-mail: likeart@mail.ru.

Технологии как искусство.
Что такое главное?
В избранное