DaJet Exchange: обмен данными с 1С (часть 1)

Наиболее оптимальным вариантом регистрации изменений является использование подписок на события 1С. Это позволяет выполнять код регистрации изменения и его публикации в одной транзакции с изменением объекта 1С. Это условие очень важно для выполнения требования целостности регистрации изменения. Выполнение такого требования необходимо для предотвращения потери сообщений или наоборот отправки ложных сообщений, когда транзакция изменения объекта 1С отменяется по той или иной причине.

Кроме этого, используя в качестве способа публикации изменений объектов 1С очередей сообщений, речь идёт о системе отслеживания изменений с данными. Это позволяет в полной мере выполнить требование об отсутствии ожиданий на блокировках СУБД. В свою очередь этот вариант отслеживания изменений увеличивает объём регистрируемых данных.

Подробнее о том какие бывают системы отслеживания изменений, а также чем они отличаются друг от друга, можно ознакомиться в моей публикации "Планы обмена 1С" в разделе "Основные техники регистрации изменений".

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

Немного подробнее о видах репликации можно узнать из моей публикации "Размышления о регистрации изменений в обмен" в разделе "Способ репликации".

Процедура Объект_ПередЗаписью(Источник)
	
	Если Источник.ОбменДанными.Загрузка Тогда
		Возврат; // Импорт данных из внешней информационной системы
	КонецЕсли;
	
	ПравилоПубликации = ПолучитьПравилоПубликации(Источник);
	Если ПравилоПубликации = Неопределено Тогда
		Возврат;
	КонецЕсли;
	
	Источник.ДополнительныеСвойства.Вставить("ЭтоНовый", Источник.ЭтоНовый());
	Источник.ДополнительныеСвойства.Вставить("ПравилоПубликации", ПравилоПубликации);
	
КонецПроцедуры

Процедура Объект_ПриЗаписи(Источник)
	
	ПравилоПубликации = Неопределено;
	Источник.ДополнительныеСвойства.Свойство("ПравилоПубликации", ПравилоПубликации);
	Если ПравилоПубликации = Неопределено Тогда
		Возврат;
	КонецЕсли;
	
	СтруктураДанных = СформироватьСтруктуруДанных(ПравилоПубликации, Источник);
	Если СтруктураДанных = Неопределено Тогда
		Возврат;
	КонецЕсли;
	
	СформироватьИсходящееСообщение(Источник, СтруктураДанных);
	
КонецПроцедуры

Процедура Объект_ПередУдалением(Источник)
	
	Если Источник.ОбменДанными.Загрузка Тогда
		Возврат; // Импорт данных из внешней информационной системы
	КонецЕсли;
	
	ПравилоПубликации = ПолучитьПравилоПубликации(Источник);
	Если ПравилоПубликации = Неопределено Тогда
		Возврат;
	КонецЕсли;
	
	СтруктураДанных = СформироватьСтруктуруДанных(ПравилоПубликации, Источник);
	Если СтруктураДанных = Неопределено Тогда
		Возврат;
	КонецЕсли;
	
	СформироватьИсходящееСообщение(Источник, СтруктураДанных);
	
КонецПроцедуры

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

Кроме этого в обработчике "ПередЗаписью" возможно реализовать логику проверки фактического изменения данных объекта при помощи, например, следующего кода:

Если Источник[ИмяСвойства] <> Источник.Ссылка[ИмяСвойства] Тогда

// Данные фактически изменены

КонецЕсли;

Для табличных типов данных (наборов записей) обработчик "ПередУдалением" не используется. Разделение кода на два обработчика "ПередЗаписью" и "ПриЗаписи" не обязательно и можно использовать только обработчик "ПриЗаписи".

Для управления регистрацией и публикацией изменений удобно использовать внешние, по отношению к узлу обмена 1С, средства. Это позволяет менять правила "на лету" без изменения конфигурации 1С. Кроме этого такие настройки позволяют управлять гранулярностью регистрации и публикации изменений до уровня реквизитов объектов.

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

Например, это может быть файл настроек в формате JSON следующего содержания:

{
  "ChangeTracking": {
    "Documents": {
      "ЗаказКлиента": {
        "Properties": [
          { "Name": "Ссылка" },
          { "Name": "Дата" },
          { "Name": "Номер" },
          { "Name": "Проведен" },
          { "Name": "ПометкаУдаления" }
        ],
        "TableParts": [
          {
            "Name": "Товары",
            "Properties": [
              { "Name": "НомерСтроки" },
              { "Name": "Номенклатура" },
              { "Name": "Количество" }
            ]
          }
        ]
      }
    }
  }
}

Проблему целостности регистрации и публикации изменений объектов 1С при реализации задач обмена данными я подробно рассмотрел в своей публикации "Использование таблиц SQL Server в качестве очередей сообщений".

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

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

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

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

Другими словами при генерации кода справочника, например, в кластере 1С коды элементов могут совпадать, а второе поле индекса "Ссылка" (_IDRRef) не гарантирует правильную последовательность событий в пределах одного кода справочника-очереди.

Таким образом, я считаю, что средствами 1С реализовать абсолютно корректную последовательность публикации изменений объектов 1С, особенно в контексте репликации транзакций, невозможно. Об этом, а также о том, каким образом это можно преодолеть средствами SQL Server наиболее дешёвым способом, я писал в своей публикации "Планы обмена 1С" в разделе "Репликация транзакций, как решение проблемы целостности данных".

В частности там приводится код триггера для фиксации идентификатора транзакции СУБД для регистра сведений 1С, используемого в качестве очереди исходящих сообщений:

USE [my_exchange];
GO

IF OBJECT_ID('_InfoRg17_INSERT', 'TR') IS NOT NULL DROP TRIGGER [dbo].[_InfoRg17_INSERT];
GO

CREATE TRIGGER [dbo].[_InfoRg17_INSERT]  
ON [dbo].[_InfoRg17]
INSTEAD OF INSERT   
AS
	DECLARE @transaction_id bigint;
	SELECT @transaction_id = [transaction_id] FROM sys.dm_tran_current_transaction;

	INSERT [_InfoRg17]
	(
		[_Fld18], [_Period], [_Fld19_TYPE], [_Fld19_RTRef], [_Fld19_RRRef], [_Fld20]
	)
	SELECT
		@transaction_id, i.[_Period], i.[_Fld19_TYPE], i.[_Fld19_RTRef], i.[_Fld19_RRRef], i._Fld20
	FROM
		inserted AS i;
GO

ALTER TABLE [dbo].[_InfoRg17] ENABLE TRIGGER [_InfoRg17_INSERT];
GO

Более того, если речь заходит о регистрации изменений таких связанных между собой объектов, как, например, документ и его движения, то, без использования вышеприведённого кода SQL, формирование сообщения потребует дополнительных усилий по реализации программного кода. Конечно же использование вышеприведённого триггера не решает всех проблем автоматически, так как логическая зависимость структур данных друг от друга может быть гораздо сложнее, чем просто "документ и его движения". Тем не менее его использование может существенно упростить решение задачи.

Кроме этого, использование кода SQL может очень сильно помочь в вопросе формирования последовательных номеров или кодов сообщений. Например, можно использовать объект СУБД SQL Server SEQUENCE.

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

Хотелось бы ещё отметить, что использование справочника позволяет в некоторых случаях использовать его реквизит "ВерсияДанных", о чём я буду писать ниже.

Формирование тела сообщения об изменении объекта узла обмена 1С может выполняться в различных форматах. В последнее время популярным форматом стал JSON. Например тело сообщения типа "CatalogRef.Номенклатура" может выглядеть следующим образом:

{
  "Ссылка": {
    "type": "CatalogRef.Номенклатура",
    "value": "83193fb5-5037-11eb-9c8e-408d5c93cc8e"
  },
  "Код": "00000001",
  "Наименование": "Тестовый элемент",
  "ПометкаУдаления": false,
  "РеквизитДата": "2021-01-06T18:54:52",
  "РеквизитЧисло": 123.45,
  "РеквизитСтрока": "Привет, мир!",
  "РеквизитБулево": true,
  "РеквизитСсылка": {
    "type": "CatalogRef.Номенклатура",
    "value": "83193fb5-5037-11eb-9c8e-408d5c93cc8e"
  },
  "РеквизитПеречисление": {
    "type": "EnumRef.ВидНоменклатуры",
    "value": "Товар"
  },
  "ВерсияДанных": "AAAAAAABisc="
}

Кроме этого можно использовать стандартный объект платформы 1С "СериализаторXDTO" и его методы для чтения и записи XML и JSON. 

Почему следует выполнять публикацию изменённого объекта 1С при помощи таблицы-очереди я подробно объяснил в своей публикации "Использование таблиц SQL Server в качестве очередей сообщений". Коротко: это связано в первую очередь с необходимостью обеспечения целостности данных.

Идеальным решением я считаю использование SQL Server Service Broker или таблиц-очередей СУБД. Лучше всего использовать эти возможности СУБД в комбинации с вышеупомянутым триггером фиксации идентификатора транзакции СУБД.

Кому интересно, можно ознакомиться с моими публикациями по SQL Server Service Broker: "1С + SQL Server Service Broker (презентация)" и "DaJet MQ - надёжный обмен данными".

После того, как изменения объектов 1С опубликованы в справочнике или регистре сведений, используемых в качестве очереди исходящих сообщений, возникает вопрос каким образом доставить эти сообщения во внешнюю систему обмена данными.

Первый, самый очевидный способ, создать регламентное задание по переносу сообщений из 1С во внешнюю систему при помощи http сервиса, RabbitMQ и т.д.

Следующий код 1С демонстрирует основную идею:

ДанныеСообщения = ПрочитатьСообщениеИзИсходящейОчереди();
НачатьТранзакцию();
Попытка
   ОтправитьСообщениеВоВнешнююСистему(ДанныеСообщения);
   УдалитьСообщениеИзИсходящейОчереди();
   ЗафиксироватьТранзакцию();
Исключение
   ОтменитьТранзакцию();
КонецПопытки;

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

Пожалуй единственным негативным побочным эффектом такого кода является то, что если отправка сообщения выполниться успешно, а удаление по какой-то причине потерпит неудачу, то такое сообщение будет отправлено во внешнюю систему повторно.

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

Поясню, что я имею в виду: например есть элемент справочника "Номенклатура". Меняем его наименование. Сообщение попадает в исходящую очередь с новым наименованием (отслеживание изменений с данными). Начинается выгрузка сообщения, открывается транзакция СУБД. Сообщение уходит во внешнюю систему. В этот момент другой пользователь меняет наименование этого же самого элемента справочника. Второе изменение попадает в исходящую очередь. Первая транзакция выгрузки сообщения удаляет своё уже отправленное сообщение (обмен данными без квитирования — используется гарантированная доставка, например, брокером сообщений). Первая транзакция завершается успешно. В данном сценарии второе изменение наименования нашего элемента справочника "Номенклатура" не будет удалено — потому что очередь. Всё работает как надо. Почему потребовалось это объяснение ? Представьте себе, что было бы если бы использовалась технология планов обмена 1С (таблица изменений справочника "Номенклатура"): регистрация второго изменения была бы удалена и система этого даже не заметила бы. Важный контекст данного примера: использование гарантированной доставки без квитирования и механизма номеров сообщений.

Вторым вариантом является самостоятельный забор сообщений из 1С внешней системой. Например для этих целей может быть использован следующий код SQL:

WITH [CTE] AS
(
	SELECT TOP(1)
		[_Fld83] AS [ТипОперации],
		[_Fld84] AS [ТипСообщения],
		[_Fld85] AS [ТелоСообщения]
	FROM
		[dbo].[_Reference81] WITH(rowlock)
	ORDER BY
		[_Code] ASC, [_IDRRef] ASC
)
DELETE [CTE]
OUTPUT deleted.[ТипОперации], deleted.[ТипСообщения], deleted.[ТелоСообщения];

От себя хотелось бы добавить (да, я очень люблю технологии SQL Server =), что, в случае использования второго варианта и технологии SQL Server Service Broker, можно организовать доставку сообщений из 1С в любую другую информационную систему фактически в онлайн режиме. 

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

Для организации параллельной выгрузки данных необходимо использовать какой-нибудь разделитель, например, тип сообщения или даже отдельный объект 1С (по объектная выгрузка). Обсуждение конкретной реализации параллельной обработки сообщений не является темой данной публикации.

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

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

Чтобы этого не произошло я рекомендую использовать аналогичную номерам сообщений механизма планов обмена 1С технику. Эта техника широко используется в мире SQL программирования. Например можно прочитать про её использование в статье "Synchronizing SQL Server data using rowversion".

Суть заключается в использовании поля "ВерсияДанных" ссылочных типов данных 1С. В нашем случае, если использовать в качестве очереди исходящих сообщений справочник 1С, то можно использовать поле именно этого справочника-очереди. На уровне СУБД это поле называется "_Version".

Значение этого поля генерируется СУБД автоматически каждый раз когда выполняется изменение данных. В случае SQL Server это значение всегда увеличивается на единицу и уникально в пределах базы данных СУБД. Данное поле имеет тип данных timestamp или rowversion в более новых версиях SQL Server, однако по сути своей это binary(8). Поэтому при выгрузке значения этого поля в JSON мы получим строковое представление в формате BASE64.

Текущее значение версии данных для конкретной базы данных СУБД можно посмотреть при помощи следующего кода SQL:

USE [my_1c_database];
GO

SELECT @@DBTS AS [my_1c_database_current_rowversion];

Принимающая система может запоминать последнее полученное от отправляющего узла обмена 1С значение версии данных и сравнивать его каждый раз со значением в новых сообщениях. Если в какой-то момент времени будет получено меньшее значение, чем было получено ранее, значит в источнике данных произошёл сбой и восстановление базы данных из бэкапа. Такие сообщения можно безопасно отбросить и не обрабатывать. 

Для демонстрации практической пригодности изложенных в данной публикации идей разработана подсистема DaJet Exchange для 1С.

Конфигурация 1C DaJetExchange и все необходимые для её использования материалы опубликованы на GitHub: DaJet Exchange.

Моя позиция заключается в том, что планы обмена 1С плохо работают при интенсивных обменах в больших информационных системах. Альтернативных решений, реализованных исключительно средствами 1С и решающих все проблемы целостного обмена данными, не существует. Практический пример DaJet Exchange является, наверное, самым простым компромиссным решением для платформы 1С:Предприятие 8 и не претендует на универсальность. Я вообще не верю в универсальные решения. Я уверен, что надёжный обмен данными в контексте 1С необходимо реализовывать гибридными средствами, используя в том числе средства СУБД и других программных платформ. Лицензионное соглашение для 1С:Предприятие 8 в части работы с СУБД мешает развитию этих решений. Вполне возможно, что я ошибаюсь, но я всё время учусь, ищу и открыт для конструктивного диалога =) 

DaJet Exchange Agent

Агент обмена данными для выгрузки сообщений из SQL Server,

на котором работает сервер 1С с подсистемой DaJet Exchange.

Из справочника DaJetExchangeQueue в очередь RabbitMQ.

Реализован режим онлайн (риалтайм) обмена данными.

Агент может быть установлен как Windows сервис.

Дистрибутив можно скачать здесь.