c.  принять данные на точке обмена для того, чтобы подтвердить отправку;

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

3.  На удаленной точке данные не менялись, но пользователю необходимо получить информацию с Центрального сервера. Для этого нужно:

a.  отправить на Центральный сервер запрос на обновление;

b.  принять данные на Центральном сервере;

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

d.  принять данные на удаленной точке.

e.  на удаленной точке автоматически будет сформирован пакет с подтверждением и отослан на Центральный сервер.

f.  для получения пакета на Центральном сервере и подтверждения отправки нужно принять данные на Центральном сервере.

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

Второй вариант автоматической настройки - прием и отправка данных на Центральном сервере, а также прием и отправка на каждой точке. Обязательно нужно учитывать тот факт, что после каждой отправки данных необходимо получить пакет с подтверждением. Особенно это важно для Центрального сервера.

НЕ нашли? Не то? Что вы ищете?

6.3.  Дополнительные возможности репликации

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

*  Отправка SQL-скриптов.

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

*  Управление изменением метаданных.

*  Пользовательское управление репликацией.

6.3.1.  Отправка SQL-скриптов

Существует возможность отправлять не только данные по репликации, но и SQL-скрипты. Для этого SQL-скрипты следует добавить в таблицу «rep_ExecutedSQL» в поле «SQL».

Например,

insert into rep_ExecutedSQL(SQL)

values(‘alter table tbl_Plugin1 add Sale decimal(18,4) not null’)

При добавлении записи автоматически заполняется пароль для запуска этого скрипта на удаленной точке. Этот пароль берется из текущей точки (по умолчанию он пустой). Чтобы SQL-скрипт отработал при получении, необходимо выполнение условий:

1.  Точка, которая прислала скрипт, должна быть в списке точек обмена на точке-приемнике (закладка [Точки обмена] утилиты «SetOffline»).

2.  Пароль на выполнение SQL-скрипта должен совпадать с паролем, указанным при регистрации точек обмена на точке-приемнике (закладка [Точки обмена] утилиты «SetOffline) для точки, которая прислала скрипт (Рис. 5.9).

Рис. 5.9 – Редактирование точки обмена

!

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

Если же SQL-скрипты выполняют изменения схемы репликации, то при их получении необходимо закрыть утилиту «SetOffline. exe».

6.3.2.  Создание исполняемых файлов репликации

Запуск процесса репликации можно осуществлять с помощью исполняемых файлов с расширениями <*.cmd> или <*.bat>. Их необходимо создать самостоятельно. При создании исполняемых файлов можно анализировать переменную %errorlevel%. Значения этой переменной могут быть следующими:

0 – были получены пакеты репликации, репликация прошла успешно;

100 – репликация завершилась с ошибкой;

101 – ошибка при отправке пакета;

102 – последний отправленный пакет репликации не был подтвержден;

201 – при проверке почты не было обнаружено пакетов репликации;

-1 – неизвестный код.

6.3.3.  Управление изменением метаданных

Если при выполнении репликации разрешено изменение метаданных (создание таблиц, добавление полей и т. п.), следует в любой утилите, позволяющей отправлять SQL-запросы, (например, Query Analyzer) запустить хранимую процедуру «rep_PrepareTable».

Например,

exec [rep_PrepareTable] ‘tbl_Acount’,0

где первый параметр – имя таблицы, второй может принимать значения:

*  «0» (по умолчанию) означает добавление в схему репликации;

*  «1» - удаление.

6.3.3.1.  Особенности подготовки таблицы к репликации

При подготовке таблицы к репликации ее физическая структура изменяется следующим образом:

1.  Добавляются, если отсутствуют, служебные поля: «Build_id», «Branch_id», «TimeChange», «Editor_id», «Sender_id», «TimeReceive». В таблицах так же называть собственные поля нельзя.

2.  Все поля, которые используются во внешних ключах, изменяют свое значение с «NOT NULL» на «NULL». Если это ограничение важно, то его необходимо реализовывать на уровне клиента.

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

4.  Добавляются или пересоздаются (если существуют) два триггера для offline репликации:

*  «del_ + имя таблицы»;

*  «iu_ + имя таблицы».

Собственные триггеры с такими названиями создавать нельзя.

5.  Если таблица отсутствовала в схеме репликации, то она добавляется в схему репликации с параметрами: «Отправлять все записи», «Принимать», «Добавлять», «Обновлять» и «Удалять все записи».

6.  Обновляется информация о внешних ключах и составе полей в служебных таблицах «rep_Field», «rep_Constraints».

6.3.3.2.  Добавление пользовательского поля

Для добавления пользовательского поля необходимо выполнить следующую последовательность действий:

1.  Добавить пользовательское поле на сервере.

2.  Выполнить скрипт по созданию поля физически.

3.  Если поле является внешним ключом, то выполнить также скрипт по созданию внешнего ключа и индекса. Эти скрипты необходимо занести в таблицу «rep_ExecutedSQL».

4.  Для включения поля и/или таблицы в схему репликации, необходимо запустить хранимую процедуру «rep_PrepareTable»:

exec [rep_PrepareTable] N'tbl_Account'

и занести скрипт в таблицу «tbl_ExecutedSQL» (см. пример ниже).

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

Рассмотрим примеры добавления пользовательских полей.

Добавление простого поля типа «Строка» в раздел [Контрагенты].

1.  Добавление поля:

if not exists(select * from information_schema. columns

where table_name = lower(N'tbl_Account')

and column_name = lower(N'Name2'))

begin

alter table [tbl_Account] add [Name2] nvarchar(250)

end

2.  Занесение скрипта в таблицу «rep_ExecutedSQL»:

insert into [rep_ExecutedSQL] ([SQL])

select 'if not exists(select * from information_schema. columns

where table_name = lower(''tbl_Account'')

and column_name = lower(''Name2''))

begin

alter table [tbl_Account] add [Name2]

nvarchar(250)

end'

Добавление поля типа «Справочник» в раздел [Контрагенты].

1.  Добавление поля:

if not exists(select * from information_schema. columns

where table_name = lower(N'tbl_Account')

and column_name = lower(N'Offering1ID'))

begin

alter table [tbl_Account] add [Offering1ID] uniqueidentifier

end

2.  Занесение скрипта в таблицу «rep_ExecutedSQL» выполняется по аналогии с предыдущим примером.

3.  Создание внешнего ключа:

if object_id(N'FAccount_Offering1ID') is null

begin

alter table [tbl_Account] add constraint [FAccount_Offering1ID]

foreign key ([Offering1ID]) references [tbl_Offering] ([ID])

end

4.  Занесение скрипта в таблицу «rep_ExecutedSQL» выполняется по аналогии с предыдущим примером.

5.  Создание индекса:

if not exists (select * from [sysindexes]

where [name] = N'IAccount_Offering1ID'

and [id] = object_id(N'tbl_Account'))

begin

create index [IAccount_Offering1ID] on [tbl_Account]([Offering1ID])

end

6.  Занесение скрипта в таблицу «rep_ExecutedSQL» выполняется по аналогии с предыдущим примером.

6.3.4.  Пользовательское управление репликацией

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

*  до отправки пакета – в хранимую процедуру «rep_BeforeInsert_database»

*  после отправки пакета – в хранимую процедуру «rep_AfterInsert_database»

*  до приема пакета – в хранимую процедуру «rep_BeforeSend_Message»

*  после приема пакета – в хранимую процедуру «rep_AfterSend_Message»

Например, необходимо выполнить собственные действия над принятыми данными (таблицы плагина):

alter procedure [rep_AfterSend_Message]

as

begin

update [cm_Table1]

set [Field1] = getdate(),

-- Обязательно для таблиц, участвующих в репликации

TimeChange = TimeChange,

Build_id = Build_id,

Editor_id = Editor_id,

Sender_id = Sender_id,

TimeReceive = TimeReceive

where [id] < 100

end

Из за большого объема этот материал размещен на нескольких страницах:
1 2 3 4 5