Tkkastur.ru

Авто Бан
0 просмотров
Рейтинг статьи
1 звезда2 звезды3 звезды4 звезды5 звезд
Загрузка...

Конвертация данных 3. 0 инструкция. И несколько слов про набор в группу

Конвертация данных 3.0 инструкция. И несколько слов про набор в группу

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

В моём случае обмен настраивается между конфигурациями «Управление торговлей 11.2» (далее УТ) и «Бухгалтерия предприятия 3.0.43» (далее БП). Обмен односторонний, из УТ в БП. До обновления «Управление торговлей 11.1» на версию «11.2» обмен данными был настроен с помощью конфигурации «Конвертация данных 2.0». Однако после перехода на «11.2» в «Управление торговлей» появились ошибки при работе пользователей. Процедура обновления правил обмена была проведена, но результата это не дало. Отладчик показывал, что проблема в обмене данными. Было решено удалить настройку обмена данными в обеих конфигурациях и настроить заново.

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

Ошибка при вызове метода контекста (Проверить): Ошибка проверки данных XDTO:
Структура объекта «/БанковскийСчетКонтрагента/Банк» не соответствует типу: КлючевыеСвойстваБанк
Проверка свойства «БИК»:
форма: Элемент
имя: БИК
тип:
Отсутствует обязательное свойство
Объект: ДоговорСКонтрагентом № .

Для анализа ошибки нажал на пиктограмму «Состав отправляемых данных» и в списке зарегистрированных к отправке договоров контрагентов нашёл договор, по которому появилась ошибка. Открыл договор, запомнил банковский счёт контрагента, указанный в договоре. Затем перешёл к зарегистрированным к отправке банковским счетам. Оказалось, что нужного счёта нет в списке зарегистрированных. Я перепровёл проблемный банковский счёт и договор. После этого зарегистрировал вручную нужный банковский счёт.

Повторил попытку синхронизировать данные из УТ. На этот раз данные успешно выгрузились. В сетевой папке сформировался XML файл, содержащий данные для переноса из УТ в БП.

Следующий этап — загрузить данные из файла в Бухгалтерию предприятия. В конфигурации «Бухгалтерия предприятия» я нажал кнопку «Синхронизировать», открылась форма обработки с сообщением «Выполняется анализ данных». Чуть позже сообщение сменилось на «Выполняется выгрузка данных». При этом индикатор и счётчик показывали, что из БП выгружается более 80-ти тысяч объектов. Это меня смутило, ведь я указывал в настройках, что из БП ничего не должно выгружаться. Обработка выполнялась довольно долго и завершилась ошибкой:

Событие: Обмен данными
<ОбщийМодуль.ДлительныеОперации.Модуль(371)>: Аварийно завершился рабочий процесс фонового задания
ВызватьИсключение(ТекстОшибки);

Чтобы локализовать ошибку, попробовал изменять настройки синхронизации и вараанты работы базы БП. В итоге, когда я перевёл базу в файловый вариант, система отработала адекватно: открылась форма сопоставления двух баз. После сопоставления объектов начальная синхронизация прошла успешно. Затем я снова перевёл базу в клиент-серверный вариант.

При дальнейшей «обкатке» синхронизации, потребовалось внести кое-какие изменения в правила конвертации объектов. Настало время воспользоваться конфигурацией «Конвертация данных 3.0». Во встроенной справке конфигурации описан порядок работы. Также помогли статьи на сайте ИТС.

В итоге я загрузил в «Конвертация данных 3.0» следующие данные:

  • Тексты общего модуля «МенеджерОбменаДаннымиЧерезУниверсальныйФормат» из двух баз
  • Схема обеих баз
  • Описание формата EnterpriseData (из одной любой базы)
  • Правила конвертации

После загрузки открыл в «Конвертация данных 3.0» правила конвертации данных, объектов, свойств. Внёс необходимые мне правки. Затем воспользовался кнопкой «Выгрузить модуль менеджера обмена». Текст модуля скопировался в буфер обмена. Осталось только вставить его в конфигурацию.

Поэксперементировав с настройкой правил в «Конвертация данных 3.0», я для себя заключил, что в случае, когда вносимые правки незначительны, проще настраивать правила непосредственно в конфигурациях УТ и БП, в общем модуле «МенеджерОбменаДаннымиЧерезУниверсальныйФормат». Если же правки серъёзные, такие как, например, добавление нового объекта в обмен, тогда стоит воспользоваться конфигурацией » Конвертация данных 3.0″.

Задачу по добавлению документа «Заказ поставщику» в план обмена я выполнял с помощью » Конвертация данных 3.0″. В стандартном варианте УТ — БП этого документа в плане обмена нет.

Будем помнить, что правила регистрации объектов для выгрузки попрежнему настраиваются в конфигурации «Конвертация данных 2.0».

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

P.S. Если есть вопросы и собственные наблюдения по обмену данными через Универсальный формат и конфигурации » Конвертация данных 3.0″, пишите в комментариях. Будем обмениваться опытом.

  • Синхронизация данных
  • Универсальный формат EntepriseData
  • Конвертация данных 3.0
  • Конвертация данных 2.0
  • Управление торговлей
  • Бухгалтерия предприятия

Конвертация данных 2.0 и 2.1 — технологическая конфигурации фирмы 1С, реализованная на версии платформы от 8.1 до 8.3.

Главная задача инструмента — написание правил обмена между прикладными решениями 1С 8 и 7. Актуальная версия конвертации данных сегодня — 3.0.

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

Конфигурацию очень удобно использовать при .

Конвертация данных будет полезна любому программисту: наличие навыков создания правил обмена — это серьезный плюс к профессиональным навыкам.

Читайте так же:
Отрегулировать свет на шевроле лачетти универсал

Для обучения работы с конфигурации лучше всего подойдет решение практических задач. Попробуйте придумать себе задачи, например: перенести какую-либо информацию из одной базы в другую, превратить документ реализации в документ поступления, «загнать» текущие остатки по бухгалтерскому учету в документ «ввода остатков» и другие задачки.

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

Для постижения основ вам потребуются материалы, рассмотрим их ниже.

Подготовительные действия для настройки обмена в БП

вкладка администрирование, заходим в настройку синхронизации (обмена данными) 1С

Давайте приступим к настройке синхронизации, сначала зайдем в базу 1С «Бухгалтерия предприятия 3.0» (приемник), нам необходимо проверить включена ли синхронизация для этой базы, для того чтобы это сделать нам нужно сначала зайти в базу. Как только база откроется переходим на вкладку «Администрирование» —> «Настройки синхронизации данных»

включаем галочку синхронизации данных (обмен) и задаем префикс базы

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

Пошаговая инструкция настройки обмена через файл между 1С: Управление торговлей 11 и 1С: Бухгалтерия 3.0

Задача: требуется настроить обмен данными через файл из 1С: Управление торговлей 11 (далее УТ) в 1С: Бухгалтерия 3.0 (далее Бухгалтерия).

  • платформа 1С: Предприятие 8.3 (8.3.13.1690),
  • конфигурация Управление торговлей, редакция 11 (11.4.7.150),
  • конфигурация Бухгалтерия предприятия (базовая), редакция 3.0 (3.0.72.72)
  • режим Файловый (без сжатия).
  • настроить параметры подключения.
  • настроить параметры подключения,
  • настроить правила отправки и получения данных,
  • выполнить начальную выгрузку данных.
  • настроить правила отправки и получения данных,
  • выполнить сопоставление и загрузку данных,
  • выполнить начальную выгрузку данных.

ШАГ 1. Настройка в УТ

Переходим в раздел «НСИ и администрирование» и выбираем пункт «Синхронизация данных». Обязательно должен быть указан префикс информационной базы. В нашем случае это «ЦБ».

Устанавливаем флаг «Синхронизация данных» и переходим по ссылке «Настройки синхронизации данных». Нажимаем кнопку «Новая синхронизация данных». В открывшемся окне выбираем конфигурацию, с которой будем настраивать обмен. В нашем случае это «Бухгалтерия предприятия, редакция 3.0».

Откроется окно настройки синхронизации. Выберем пункт «Настроить параметры подключения».

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

Далее укажем каталог и настроим архивацию файлов.

Далее укажем префикс базы бухгалтерии и название файла с настройками синхронизации.

Обратите внимание: если указать префикс, по которому уже есть обмен, то будет ошибка, программа предложит указать уникальный код. Нажимаем «Далее» и на этом заканчивается первый шаг настройки.

В результате у нас появится два файла в указанной папке: файл с данными (Message_ЦБ_БП.zip) и файл с настройками обмена (Синхронизация данных через универсальный формат.xml). Обратите внимание: если в УТ попробовать перейти к этапу «Настроить правила отправки и получения данных», то будет ошибка.

ШАГ 2. Настройка в Бухгалтерии

Перед настройкой синхронизации в Бухгалтерии нам понадобятся два файла, созданных на предыдущем шаге. Разместим файлы Message_ЦБ_БП.zip и Синхронизация данных через универсальный формат.xml в любую папку на компьютере с базой Бухгалтерии. Внимание: если Бухгалтерия находится на одном компьютере с УТ, то ничего переносить не нужно. Будем использовать ту же папку, что и для УТ.

Сначала перейдем в раздел «Администрирование» и выберем пункт «Синхронизация данных». В открывшемся окне проверим, чтобы префикс указанной базы совпадал с префиксом, который мы указали на первом шаге.

Устанавливаем флаг «Синхронизация данных» и переходим по ссылке «Настройки синхронизации данных». Нажимаем кнопку «Новая синхронизация данных». В открывшемся окне выбираем конфигурацию, с которой будет настроен обмен. В нашем случае это «1С: Управление торговлей, редакция 11».

Откроется окно настройки синхронизации. Выберем пункт «Настроить параметры подключения».

Так как обмен настраиваем через файл, то выбираем пункт «синхронизация данных через файл, без подключения к другой программе». На Шаге 1 мы уже создали файл с настройками обмена Синхронизация данных через универсальный формат.xml, поэтому выберем его. Если был создан другой каталог и туда скопировали файл с настройками обмена, то выбираем его.

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

Далее проверяем настройки префиксов и на этом настройка параметров подключения в Бухгалтерии завершена.

Далее переходим к следующему этапу «Настройка правил отправки и получения данных».

Так как задачи выгрузки из Бухгалтерии у нас нет, то в настройках отправки данных укажем «не отправлять».

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

Нажимаем «Записать и закрыть». Далее переходим к следующему этапу «Выполнить начальную выгрузку данных».

Читайте так же:
Как регулировать редуктор переднего моста нивы

После выполнения операции будет создан в каталоге обмена файл с данными Message_БП_ЦБ.zip. На этом этап настройка обмена в Бухгалтерии закончена.

ШАГ 3. Окончание настройки в УТ

Вернемся в УТ. Если использовался другой каталог, то в папку обмена УТ перенесем файл, созданный на прошлом шаге Message_БП_ЦБ.zip.

Продолжим настройку синхронизации в УТ с этапа «Настроить правила отправки и получения данных».

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

1.Отправлять только используемую в документах нормативно-справочную информацию.

2.Отправлять все, начиная с даты. Это поле полезно, так как бывает, что нужно начать синхронизацию с определенного времени. Например, учет в УТ уже был настроен ранее, а в
Бухгалтерии только начинаем вести учет. Тогда нет необходимости переносить все документы из УТ в Бухгалтерию. Или второй случай: нужно поменять настройки обмена, но чтобы они действовали только для документов с определенной даты.

Все остальные поля заполняем в зависимости от учета.

В нашем случае настройка получения данных не требуется. Оставляем ее без изменений.

Нажимаем «Записать и закрыть». Переходим к следующему этапу «Выполнить сопоставление и загрузку данных».

В нашем случае программа ничего загружать не будет и перейдет к следующему этапу.

На последнем этапе «Выполнить начальную выгрузку данных» программа выгрузит данные из УТ в файл Message_ЦБ_БП.zip.

Обратите внимание (для случая с двумя каталогами): полученный файл Message_ЦБ_БП.zip копируем в каталог обмена Бухгалтерии. В Бухгалтерии выполняем синхронизацию. При этом Бухгалтерия сначала загрузит данные из присланного файла Message_ЦБ_БП.zip, потом обновит свой файл выгрузки Message_БП_ЦБ.zip Этот файл выгрузки Message_БП_ЦБ.zip нужно скопировать обратно в каталог обмена УТ и в УТ выполнить синхронизацию. При этом УТ сначала загрузит данные (если они там есть) из файла Message _БП_ЦБ.zip, а потом обновит свой файл выгрузки Message _ЦБ_БП.zip и т.д.

Обмен через универсальный формат (КД 3.0): подключение НЕтипового документа

В статье описан порядок действий при подключении нетиповых документов к механизму «Синхронизация данных через универсальный формат» (КД 3.0).

В контексте данной статьи термин «нетиповой» означает, что документ не описан ни в одном из XDTO-пакетов механизма «Синхронизация данных через универсальный формат».

Если же документ описан в типовом XDTO-пакете, то порядок его подключения к обмену можно посмотреть в статье «Обмен через универсальный формат (КД 3.0): подключение типового документа».

1. Зачем изменять типовой XDTO-пакет?

Основной смысл технологии КД 3.0 (обмен через универсальный формат) – это добиться «универсальности» правил обмена, чтобы правила выгрузки/загрузки объектов не зависели от того, какая конфигурация (или ее релиз) находятся на том «конце провода». И если мы корректируем типовой XDTO-пакет, то мы эту «универсальность» разрушаем.

Но в полной мере преимуществом «универсальности» может воспользоваться только сама 1С (и ее партнеры – разработчики конфигураций), которая таким образом упрощает себе процедуры обновления правил обмена при переходе от одного релиза типовых конфигураций 1С 8.3 к другим, а также упрощает подключения к обменам новых конфигураций.

На стороне пользователя выгоды от «универсальности» гораздо меньше, ведь он работает с конкретной конфигурацией-источником и конкретной конфигурацией-приемником. Все изменения правил обмена между этими конфигурациями (в т.ч. структура XDTO-пакетов) согласованы внутри его «корпорации». А то, что его правила обмена становятся несовместимы с правилами обмена, принятыми в других «корпорациях», его в большинстве случаев не волнует. Поэтому изменить структуру XDTO-пакета обычно некритично.

Более того, если речь идет о добавлении в обмен новых объектов, то технически это проще сделать через технологию КД 2.0:

· Там нужно писать всего один комплект правил обмена вместо двух для КД 3.0.

· Включение в обмен КД 3.0 промежуточного «универсального формата» сильно повышает уровень абстракции (он уже не связан напрямую с прикладной областью) и избыточности (он же «универсальный»). А это, в свою очередь, повышает требования к квалификации специалистов, которые этот обмен будут настраивать.

Но в последних конфигурациях 1С продвигается обмен именно по технологии КД 3.0. И чтобы для своих нетиповых объектов не строить параллельно еще и второй механизм обмена (на КД 2.0), приходится корректировать типовые XDTO-пакеты.

Есть описания примеров, когда для нетиповых объектов создаются отдельные XDTO-пакеты, а для работы с ними в 1С запускается отдельная 1С 8.3 XDTO-фабрика. Но это опять-таки – построение параллельного механизма обмена (два механизма на КД 3.0), а этого хочется избежать.

Итак, если мы хотим остаться внутри единого механизма «Синхронизация данных через универсальный формат», и для нас некритичен факт изменения типового XDTO-пакета, то изменим типовой XDTO-пакет.

2. Образцы описания документа в XDTO-пакете

Объекты обмена, которые включены в состав механизма «Синхронизация данных через универсальный формат», описаны в XDTO-пакетах, наименования которых начинаются с «EnterpriseData». Например, EnterpriseData_1_2_3 … EnterpriseData_1_6_20, где 1_2, … 1_6 – это номера «версий форматов».

Добавлять описание своего объекта необязательно во все XDTO-пакеты EnterpriseData_1_2_3 … EnterpriseData_1_6_20. Достаточно это сделать только для того номера версии формата, на котором обмениваются наши конкретные конфигурации. Узнать его можно в настройках синхронизации данных.

Читайте так же:
Регулировка руля нивы 2121

Т.е. в нашем примере достаточно скорректировать пакет EnterpriseData_1_5_20.

Корректировать XDTO-пакет можно либо вручную, либо с использованием специализированного редактора.

Посмотрим на образец описания документа. В примере добавляем описание нетипового документа «экзРапортФ114». Вносим описание типа значения:

Вносим описание его структуры (реквизиты шапки, в т.ч. ключевые свойства, табличную часть «Сырье» и реквизиты строки табличной части:

Такую настройку необходимо выполнить в обеих обменивающихся конфигурациях. Поскольку одноименные XDTO-пакеты во всех конфигурациях одинаковы, то настройку достаточно произвести в одной из них, а во вторую – перенести настройки через «сравнение и объединение».

3. Обновление 1С 8.3 записей регистра сведений НастройкиОбменаДаннымиXDTO

После добавления описания документа в XDTO-пакет есть один тонкий момент. Даже если Вы включили свой документ (в примере — это «экзРапортФ114» синоним «Рапорт на выработку комбикорма») в состав плана обмена «СинхронизацияДанныхЧерезУниверсальныйФормат», и он появится на форме регистрации изменений, этот документ еще не включен в механизм обмена. Об этом свидетельствует его отсутствие на ветке «AvailableObjectTypes» файла обмена.

Дело в том, что механизм обмена содержит в себе описание «доступных объектов», которое среди прочего хранится в регистре сведений НастройкиОбменаДаннымиXDTO. «Доступные объекты» в этом регистре заполняются:

А) Из состава XDTO-пакет при первичной настройке плана обмена à определяются объекты, которые «в принципе могут обмениваться».

Б) При анализе правил обмена текущей конфигурации à уточняется перечень объектов, доступных на «прием» и «отправку» относительно текущей базы.

В) При анализе ветки AvailableObjectTypes полученного файла обмена от конфигурации-корреспондента à уточняется перечень объектов, доступных на «прием» и «отправку» относительно конфигурации-корреспондента.

Объект становится «доступным на отправку», если он «в принципе может обмениваться» (выполнен п.А), имеет правила «на отправку» в текущей базе (п.Б) и имеет правила «на приемку» в базе-корреспонденте (п.В). Аналогично «доступен на приемку», если есть п.А, есть правила «на приемку» у текущей (п.Б) и правила «на отправку» у корреспондента (п.В).

Для того, чтобы выполнить п.Б и п.В достаточно настроить правила обмена (инструкции и примеры можно найти в интернете оп запросу «1С:Конвертация данных 3»).

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

Можно, например, в настройку синхронизации добавить команду «Обновить настройку синхронизации», которая перечитывает состав XDTO-пакетов. Текст модуля этой команды приведен в прил.1.

Данную команду необходимо настроить и выполнить в обеих обменивающих конфигурациях.

После того как Вы включили свой нетиповой документ в состав «доступных объектов», в т.ч. выполнили настройку правил обмена, Ваш документ появится на ветке AvailableObjectTypes.

В примере выполняется односторонний обмен документом «экзРапортФ114» из конфигурации Бухгалтерия 3.0 в конфигурацию «1С:ERP Управление предприятием 2». Поэтому в файле, выгруженном из «1С:Бухгалтерия 3.0» документ прописан на ветке «Sending».

А в файле, выгруженном из «1С:ERP Управление предприятием 2», документ прописан на ветке «Receiving»/

Нетиповой документ готов к обмену через типовой механизм.

Если документ не описан в XDTO-пакете, то для его включения в обмен посредством механизма «Синхронизация данных через универсальный формат» необходимо выполнить следующие процедуры:

1. Описать документ в XDTO-пакете обеих обменивающихся конфигураций.

2. Обновить записи регистра сведений НастройкиОбменаДаннымиXDTO обеих обменивающихся баз.

3. Выполнить действия для «типовых» документов (см. статью «Обмен через универсальный формат (КД 3.0): подключение типового документа», — ссылка в начале):

a. В конфигурации-источнике подключить документ в состав плана обмена «СинхронизацияДанныхЧерезУниверсальныйФормат».

b. Настроить правила обмена (КД 3.0) в обеих конфигурациях

Данный способ универсален и пригоден для любых конфигураций и любых видов объектов (Документов, Справочников и т.п.).

Синхронизация данных через универсальный формат что это

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

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

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

Подобную задачу можно решить с помощью системы DBSync, разработанной компанией РЕЛЭКС.

Читайте так же:
Как отрегулировать редуктор заднем мосту на ниве 2121

DBSync – это программный комплекс, предназначенный для разработчиков и администраторов распределенных IT систем. Он обеспечивает конфигурирование, администрирование и двухстороннюю синхронизацию данных между серверами, персональными, мобильными и встроенными базами данных. Фактически все они в этом случае являются узлами одной распределенной базы данных.

Основные возможности DBSync:

  • Синхронизация данных между базами данных различных производителей. Произвольная топология связей между синхронизируемыми базами.
  • Фильтрация синхронизируемых данных. Позволяет настроить синхронизацию только части колонок таблицы или части строк, удовлетворяющих некоторому условию.
  • Одно и двунаправленная синхронизация данных для различных таблиц.
  • Обнаружение и разрешение конфликтов записей. В случае модификации одних и тех же данных на разных узлах в процессе синхронизации будет обнаружен конфликт. DBSync имеет возможность настройки правил разрешения конфликтов.
  • Различные способы идентификации записей. Возможность синхронизации таблиц с суррогатным первичным ключом.
  • Интеграция с деревом каталогов. Позволяет хранить условия синхронизации таблиц во внешнем дереве каталогов в виде объектов. При синхронизации эти условия используются для выборки данных.
  • Автоматическое восстановление синхронизации после сбоев. В случае потери пакетов или восстановления базы данных из архивной копии DBSync автоматически производит полную синхронизацию между базами.
  • Защита информации от несанкционированного доступа.

Архитектура DBSync

DBSync включает следующие компоненты:

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

Поддерживаемые платформы и СУБД

Для платформы Windows 2000/XP

  • Oracle 8 и выше;
  • MS SQL Server 7, MS SQL Server 2000;
  • DB2;
  • Sybase 7;
  • Linter 5.9 и выше ;
  • MySQL 4.x (с ограничениями).

Для платформы Windows CE

  • Linter 5.9.
  • Linter 5.9 и выше;
  • MySQL 4.x (с ограничениями);
  • Oracle 8 и выше.

Функционирование системы

При установке DBSync в базе данных создается набор служебных таблиц и таблиц для хранения информации об изменениях в базе данных. В служебных таблицах хранится следующая информация:

  • списки узлов синхронизации (удаленных баз данных);
  • списки таблиц, которые необходимо синхронизировать;
  • правила синхронизации и т.д.

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

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

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

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

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

Разрешение конфликтов

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

  • Конфликт первичных ключей

Наиболее серьезным типом конфликтов является конфликт первичных ключей. Первичные ключи используются DBSync для идентификации записи. Поэтому конфликты первичных ключей не детектируются и не разрешаются.

  • Конфликты, связанные с ограничениями таблицы

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

  • Конфликты одновременной модификации данных

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

Читайте так же:
Как отрегулировать дроссельную заслонку шевроле лачетти

Способы обмена данными

Обмен данными между узлами может происходить с помощью одного из поддерживаемых протоколов. К ним относятся TCP/IP, HTTP/HTTPS, E-mail, File и ActiveSync.

  • TCP/IP является наиболее универсальным из них. Он используется в корпоративных сетях и является самым надежным, быстрым и удобным. Если есть возможность, то для работы синхронизации следует выбирать именно его.
  • HTTP/HTTPS протокол менее надежен и быстр, но он может оказаться более удобным для мобильных клиентов, которые работают через Proxy-серверы.
  • E-MAIL — передача пакетов синхронизации по электронной почте;
  • FILE — обмен между узлами при помощи файлов;
  • ActiveSync — протокол для работы с платформой Windows CE.

В качестве формата обмена данными используется XML, как наиболее универсальный из всех форматов. За основу структуры XML в DBSync принят формат, используемый в SyncML, который на сегодняшний день является стандартом де-факто в области синхронизации с мобильными устройствами. Используемая нами кодировка UTF-8 позволяет без проблем использовать национальные кодировки и обеспечивает переносимость между различными платформами. DBSync поддерживает синхронизацию бинарных данных, которые хранятся в базе данных в полях типа BLOB.

Сферы применения DBSync

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

Варианты применения

Баланс нагрузки серверов

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

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

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

Хранилище данных

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

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

Повышение надежности системы

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

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

Поддержка мобильных пользователей

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

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

Откройте «Настройки» и выполните одно из описанных ниже действий.

На iPhone c Face ID. Коснитесь «Face ID и код‑пароль».

На iPhone с кнопкой «Домой». Коснитесь «Touch ID и код‑пароль».

Включите функцию «Стирание данных».

Статьи для программиста по обмену данными в 1С

Если Вы начинаете изучать 1С программирование, рекомендуем наш бесплатный курс (не забудьте подписаться на YouTube — регулярно выходят новые видео):

К сожалению, мы физически не можем проконсультировать бесплатно всех желающих, но наша команда будет рада оказать услуги по внедрению и обслуживанию 1С. Более подробно о наших услугах можно узнать на странице Услуги 1С или просто позвоните по телефону +7 (499) 350 29 00. Мы работаем в Москве и области.

голоса
Рейтинг статьи
Ссылка на основную публикацию
Adblock
detector