Служба регистрации изменений
Довольно сложно разделить службу регистрации изменений и инфраструктуру сообщений: их функциональность тесно связана. Но все же постараемся рассмотреть особенности их работы по отдельности. Начнем со службы регистрации изменений.
Целью регистрации изменений является получение списка измененных элементов данных, которые должны быть переданы в очередном сообщении тому или иному узлу, с которым производится обмен данными. При каждом изменении данных должно быть зарегистрировано, что имеются изменения, которые предстоит передать во все узлы, с которыми поддерживается обмен этими данными. При получении подтверждения приема сообщения, в котором были отправлены изменения, записи регистрации изменений должны быть удалены.
Регистрация изменений может выполняться для следующих элементов данных:
- КонстантаМенеджерЗначения.<имя>.
- Объекты базы данных:
- СправочникОбъект.<имя>;
- ДокументОбъект.<имя>;
- ПланСчетовОбъект.<имя>;
- ПланВидовХарактеристикОбъект.<имя>;
- ПланВидовРасчетаОбъект.<имя>;
- БизнесПроцессОбъект.<имя>;
- ЗадачаОбъект.<имя>.
- Наборы записей:
- РегистрСведенийНаборЗаписей.<имя>;
- РегистрБухгалтерииНаборЗаписей.<имя>;
- РегистрНакопленияНаборЗаписей.<имя>;
- ПоследовательностьНаборЗаписей.<имя>;
- РегистрРасчетаНаборЗаписей.<имя>;
- ПерерасчетНаборЗаписей.<имя>.
Для каждого из приведенных элементов данных ведется своя таблица регистрации изменений. Таблицы имеют разную структуру в зависимости от того, для каких элементов данных регистрируются изменения, но все-таки структуры таблиц подобны. В структуре можно выделить три составляющих:
- ключ элемента данных, для которого регистрируются изменения;
- ссылка на узел, в который изменение должно быть передано;
- номер сообщения, в котором изменение передано в первый раз.
Следует отметить, что в конфигурации может быть определено несколько планов обмена. Для каждого из них может включаться регистрация изменений какого-либо объекта. Так вот, вне зависимости от количества планов обмена, в рамках которого регистрируются изменения какого-либо объекта, таблица регистрации изменений у объекта одна (можно сказать, что поле, содержащее ссылку на узел плана обмена, может иметь составной тип).
Структуры таблиц регистрации изменений для разных данных отличаются ключом, так как ключи у разных данных разные.
- Для константы ключом является идентификатор константы.
- Для объектов базы данных в качестве ключа используется ссылка на объект.
- Для наборов записей, для которых определен регистратор, в качестве ключа используется ссылка на объект-регистратор.
- Для набора записей регистра сведений, если регистратор не определен, в качестве ключа используется совокупность измерений, входящих в основной отбор. А если регистр сведений является периодическим и включен основной отбор по периоду, то в ключ входит еще и период.
Основной отбор (для регистров сведений) позволяет определять логическую единицу обмена данными. Рассмотрим это понятие более подробно (рис. 3.4).
Рис. 3.4. Свойство «Основной отбор»
Понятно, что физически минимальной единицей обмена является запись регистра сведений. Но всегда ли правильно обмениваться записями? Рассмотрим пример. Есть регистр сведений, в котором содержатся данные о дополнительных свойствах номенклатурных позиций. Речь идет именно о свойствах, которые четко характеризуют товарную позицию. Если для какого-то товара свойство имеет другое значение, то, значит, это другой товар. Например, такое свойство, как количество компрессоров холодильника. У данного регистра сведений два измерения: ссылка на номенклатуру и ссылка на свойство.
Если обмен будет производиться по каждой записи отдельно, у одного участника обмена добавили одно свойство, а у другого – другое, то в результате обмена у элемента номенклатуры появятся два свойства. Но в данном случае более правильно, чтобы свойства отдельно взятого товара представляли собой единое логическое целое (входили в некий логический квант данных).
Как раз для того, чтобы объединить несколько физических записей в один логический набор данных, и используется понятие Основной отбор. Если в приведенном примере для измерения Номенклатура (содержащего ссылку на номенклатурную позицию) установить свойство Основной отбор, то при изменении хотя бы одной физической записи обмен будет производиться всеми свойствами данной номенклатуры.
В качестве примера рассмотрим следующие данные (наполнение регистра сведений) – табл. 3.2.
Таблица 3.2. Записи регистра сведений
| Измерение «Номенклатура» (входит в основной отбор) | Измерение «Свойство» (не входит в основной отбор) | Значение |
|---|---|---|
| Атлант МХМ 1704-00 | Количество компрессоров | 2 |
| Атлант МХМ 1704-00 | Цвет | Белый |
| Ardo TL 1000 EX-1 | Тип загрузки | Вертикальная |
| Ardo TL 1000 EX-1 | Количество подшипников | 1 |
Добавим в регистр запись о новом свойстве (выделена серым фоном) – табл. 3.3.
Таблица 3.3. В регистр сведений добавлена запись
| Измерение «Номенклатура» (входит в основной отбор) | Измерение «Свойство» (не входит в основной отбор) | Значение |
|---|---|---|
| Атлант МХМ 1704-00 | Количество компрессоров | 2 |
| Атлант МХМ 1704-00 | Цвет | Белый |
| Атлант МХМ 1704-00 | Отделов в морозильной камере | 3 |
| Ardo TL 1000 EX-1 | Тип загрузки | Вертикальная |
| Ardo TL 1000 EX-1 | Количество подшипников | 1 |
В результате будут зарегистрированы следующие изменения (табл. 3.4).
Таблица 3.4. Записи, попавшие в регистрацию изменений
| Измерение «Номенклатура» (входит в основной отбор) | Измерение «Свойство» (не входит в основной отбор) | Значение |
|---|---|---|
| Атлант МХМ 1704-00 | Количество компрессоров | 2 |
| Атлант МХМ 1704-00 | Цвет | Белый |
| Атлант МХМ 1704-00 | Отделов в морозильной камере | 3 |
Если в основной отбор включить все измерения (если регистр сведений периодический, то включить в основной отбор и период), то логической единицей обмена будет отдельно взятая запись регистра сведений.
Следует отметить тот факт, что при записи набора в регистр сведений состав этого набора определяется логикой работы конфигурации и не обязательно совпадает с набором, получаемым «при использовании» основного набора. А при принудительной регистрации изменений для набора записей обязательно должен быть установлен отбор, совпадающий с основным (иначе будет вызвано исключение). Такой порядок работы определяется тем, что основной отбор является специфической чертой именно механизма обмена данными. Из сказанного выше следует, что при изменении основного отбора необходимо будет менять и программный код, в котором производится принудительная регистрация записей регистра сведений (во всех вхождениях в конфигурацию).
Изменение элемента данных должно быть зарегистрировано для всех узлов, в которые изменение должно быть передано. Таким образом, в результате изменения элемента данных в таблице регистрации изменений должно появиться N записей (наборов записей), где N – количество узлов, для которых регистрируются изменения (все узлы плана обмена, за исключением предопределенного). В каждой из этих записей (наборе записей) указано одно и то же значение ключа элемента данных и различные значения ссылки на узел.
Непосредственно после выполнения регистрации изменения номер сообщения имеет значение NULL. При первой отправке изменения в составе сообщения в данное поле помещается номер сообщения, в котором изменение отправлено.
Рассмотрим приведенный алгоритм на примере. Считаем, что в плане обмена включена регистрация для документа РасходнаяНакладная. В плане обмена определено три узла: один – предопределенный, другие – с кодами Оптовый и Розничный. После включения регистрации было изменено два документа. В соответствии с этим таблица регистрации изменения примет следующий вид (табл. 3.5).
Таблица 3.5. Состав таблицы регистрации изменений
| ДокументСсылка.РасходнаяНакладная | Узел | Номер сообщения |
|---|---|---|
| Расходная накладная № 1 от… | Оптовый | Null |
| Расходная накладная № 1 от… | Розничный | Null |
| Расходная накладная № 2 от… | Оптовый | Null |
| Расходная накладная № 2 от… | Розничный | Null |
После этого были произведены формирование и отправка сообщения с номером 1 для узла Оптовый. Таблица приняла следующий вид (табл. 3.6).
Таблица 3.6. Состав таблицы регистрации изменений
| ДокументСсылка.РасходнаяНакладная | Узел | Номер сообщения |
|---|---|---|
| Расходная накладная № 1 от… | Оптовый | 1 |
| Расходная накладная № 1 от… | Розничный | Null |
| Расходная накладная № 2 от… | Оптовый | 1 |
| Расходная накладная № 2 от… | Розничный | Null |
Далее было зарегистрировано изменение еще одного документа (табл. 3.7).
Таблица 3.7. Состав таблицы регистрации изменений
| ДокументСсылка.РасходнаяНакладная | Узел | Номер сообщения |
|---|---|---|
| Расходная накладная № 1 от… | Оптовый | 1 |
| Расходная накладная № 1 от… | Розничный | Null |
| Расходная накладная № 2 от… | Оптовый | 1 |
| Расходная накладная № 2 от… | Розничный | Null |
| Расходная накладная № 3 от… | Оптовый | Null |
| Расходная накладная № 3 от… | Розничный | Null |
После этого были сформированы и отправлены сообщения для узлов Оптовый и Розничный. Фактически были проведены две выгрузки (сформировано два сообщения). Для узла Розничный сообщение имело номер 1, для узла Оптовый – номер 2 (табл. 3.8).
Таблица 3.8. Состав таблицы регистрации изменений
| ДокументСсылка.РасходнаяНакладная | Узел | Номер сообщения |
|---|---|---|
| Расходная накладная № 1 от… | Оптовый | 1 |
| Расходная накладная № 1 от… | Розничный | 1 |
| Расходная накладная № 2 от… | Оптовый | 1 |
| Расходная накладная № 2 от… | Розничный | 1 |
| Расходная накладная № 3 от… | Оптовый | 2 |
| Расходная накладная № 3 от… | Розничный | 1 |
После выгрузки для узла Оптовый запись в таблице для документа Расходная накладная № 3 отмечается номером сообщения 2 (первый раз изменение было передано именно в сообщении с таким номером), другие записи (для которых в поле НомерСообщения содержалось значение 1) остались без изменений (именно таким образом работает служба регистрации изменений).
Для узла Розничный все изменения были отнесены сообщением с номером 1.
Предположим, что после выполнения вышеуказанных действий произошло повторное изменение документа Расходная накладная № 1. В этом случае таблица регистрации изменений будет иметь следующий вид (табл. 3.9).
Таблица 3.9. Состав таблицы регистрации изменений
| ДокументСсылка.РасходнаяНакладная | Узел | Номер сообщения |
|---|---|---|
| Расходная накладная № 1 от… | Оптовый | Null |
| Расходная накладная № 1 от… | Розничный | Null |
| Расходная накладная № 2 от… | Оптовый | 1 |
| Расходная накладная № 2 от… | Розничный | 1 |
| Расходная накладная № 3 от… | Оптовый | 2 |
| Расходная накладная № 3 от… | Розничный | 1 |
Продолжая разговор о службе регистрации изменений, следует отметить, что состав плана обмена распространяется на все узлы данного плана обмена. Поэтому если, например, с разными узлами нужно обмениваться разным составом информации, то необходимо создавать несколько планов обмена, в которых объединять узлы, обменивающиеся одинаковым составом информации.
Например, если с одним узлом необходимо обмениваться изменениями в справочнике Номенклатура, а с другим изменениями – в документах РасходнаяНакладная, то не стоит создавать один план обмена, лучше создать план обмена ПоНоменклатуре (с соответствующей настройкой состава данных, по которым ведется регистрация изменений) и план обмена Расходные (с другим составом).
