Занятие 1.18
Механизмы распределенных БД
В 8.2 практически не актуальны, т.к. идея 8.2 в клиент-серверной архитектуре, клиенты которой могут быть территориально удаленными.
«Конфигурация – Общие - Планы обмена» - для реализации механизмов распределенных БД. Две технологии работы:
Есть Центр и периферийные БД (технология «Звезда» - главный и удаленные узлы). Обмен данными происходит через Центр, при этом на периферийные БД могут быть наложены ограничения в получении/передаче данных.
Произвольный обмен данными. При этом обмен придется описывать самостоятельно. В первом варианте настройка обмена заложена в самой платформе. Настраивать придется только специфические тонкости.
Планы обмена позволяют накапливать информацию об измененных объектах, упорядочить процесс загрузки/выгрузки данных, контролировать процесс переноса данных
Теория:
Допустим, есть две БД (может быть и более), одна из которых – Центральная. В Центральной и Удаленной БД накапливается информация об объектах, которые входят в План обмена. По сути, План обмена – это таблица, фиксирующая несколько состояний записей:
Создан.
Изменен.
Удален.
Эту информацию накапливает каждый узел Плана обмена и при выгрузке/загрузке формируется XML-файл с этой информацией.
Допустим, ЦБ отправляет в УБ информацию об изменениях – формируется пакет данных №1. УБ загружает данные и при следующем соединении с ЦБ она формирует пакет, в котором хранятся:
Данные о том, что надо загрузить из УБ в ЦБ.
Извещение о том, что пакет данных №1 был принят.
Если Извещения нет, то ЦБ вместе с пакетом №2 выгрузит и передаст УБ данные пакета №1.
Ограничение технологии распределенных БД – конфигурации всех БД должны быть идентичны. Изменения допускаются только в ЦБ.
Канал передачи данных пользователь выбирает самостоятельно (электронная почта, FTP-сервер и т.д.).
Пример:
Создадим План обмена «Распределенка»
Свойство |
Значение |
Имя |
Распределенка |
Синоним |
Распределенка |
Распределенная база данных |
Истина |
Закладка «Подсистемы» |
Предприятие |
«Распределенная база данных – Истина» - включает механизм распределенных БД. Если «Ложь», то механизм придется описывать вручную.
Кнопка «Состав» - объекты передачи м/ду БД.
Например, надо чтобы передавались все документы: Приходная и Расходная. Если просто отметить их, то кроме документов ничего передаваться не будет. Но в документе есть реквизиты, которые тоже должны передаваться:
«Действия – Подобрать связанные для всех» - для передачи всех, связанных с отмеченными, данных.
При этом автоматом не отмечаются для передачи движения по регистрам. Это объясняется тем, что движения по регистрам иногда строятся по данным учетной системы. В УБ передаваемые документы будут записаны, а могут быть еще и проведены, т.е. сформируются необходимые движения. Передача же существующих движений только увеличит объем передаваемых данных. В примере смысла в этом нет, т.к. данные по документам передаются полностью.
В режиме исполнения:
ЦБ уже есть, но поля в ней пустые. Заполним их:
Создадим УБ (периферийную БД):
В итоге у нас есть БД:
Записать изменения – выгрузка изменений.
Прочитать изменения – загрузка изменений.
Создать начальный образ подчиненного узла РБД – начальная выгрузка БД. Создается файл формата «.CD», т.е. это файл БД (не сжатый, а уже полностью готовый к работе). Т.е. фактически это создание копии ЦБ. Перед созданием система спросит, в какое место сохранить файл.
Теперь, если мы, допустим, создадим еще одну Приходную, то система узнает, что для распределенной БД появился документ, который надо выгрузить. Далее в Плане обмена «Распределенка» открываем периферийную БД и нажимаем «Записать изменения», укажем место сохранения файла (это будет XML-файл, который будет находиться в ZIP-архиве, если «Сжимать сообщение - Истина»).
Загрузка данных производится в периферийной БД, где БД обозначены по-другому:
Встанем на БД «Центр», нажмем «Прочитать изменения» и выберем выгруженный из ЦБ файл.
Если номер принимаемого файла совпадает с номером уже принятого, то система выдаст ошибку и проигнорирует его.
При обмене возникают коллизии, которые приходится вычислять и исправлять вручную.
Конфигурации
Производить обновления и исправления БД, при этом каждый раз выгоняя пользователей, не совсем правильно.
Если надо для клиента стать поставщиком конфигурации:
Надо обозначить свою конфигурацию – дать имя и указать информацию о поставщике. «Конфигурация – ПКМ - Свойства»:
Свойство |
Значение |
Имя |
ЧастьПервая |
Синоним |
Часть первая |
Поставщик |
edu1c.ru |
Версия |
0.0.1.0 |
Свойство «Адрес каталога обновлений» - это HTTP-каталог, или FTP-каталог, или локальный каталог и т.д., т.е. место, где платформа по умолчанию будет искать обновления конфигурации
«Конфигурация – Поставка конфигурации – Создать файлы поставки и обновления конфигурации» - можно создать файл поставки:
«.CF» - файл конфигурации без данных.
«.CFU» - файл результата сравнения новой конфигурации с предыдущими релизами.
«Каталог файлов поставки» - задается путь к каталогу, в котором будут храниться файлы поставки.
При нажатии на «Выполнить», будет выгружен CF-файл.
На основе выгрузки можно сформировать файл обновления, который не позволит пользователю менять конфигурацию самостоятельно, а позволит только обновлять ее.
«Конфигурация – Поставка конфигурации – Комплект поставки» - создается для более удобного обновления конфигурации. Это такая же конфигурация, только упакованная в EXE-файл, при запуске которого запускается мастер шаблонов конфигураций, которые можно увидеть при запуске программы.
Создадим Комплект поставки:
Итого получилось Описание шаблона:
Нажмем кнопку «Создать комплект»:
Система предложить сохранить файл «Описания комплекта поставки» (EDF-файл) и сам Комплект, состоящий из двух файлов:
EXE-файл – мастер установки.
EFD-файл – в него упакована конфигурация, данные. Также в него можно упаковать другие объекты.
При запуске EXE-файла запускается мастер установки конфигурации:
И при создании новой БД, система предложит созданный Комплект как шаблон:
«Часть первая» - это конфигурация без данных.
«Часть первая (демо)» – это конфигурация вместе с данными.
В данной конфигурации указывается состояние объекта поставки:
Желтый кубик – объект редактируется с сохранением поддержки, т.е. обозначает, что это поставка.
Замок – разрешен только просмотр объектов.
Сейчас поставка конфигурации находится на поддержке, с выключенной возможностью изменений. При этом, если надо что-либо обновить у Клиента, то просто выгрузим новую версию конфигурации:
Свернем пока конфигурацию Клиента и откроем конфигурацию разработки. Создадим в ней новый справочник, при этом у нас получается как бы новая версия конфигурации: «Конфигурация – ПКМ – Свойства - Версия»:
«0.0.1.1»
Создадим новый Комплект поставки и установим его.
Далее обновим конфигурацию Клиента – «Конфигурация – Поддержка – Обновить конфигурацию»:
При этом выполнились все новые изменения, и конфигурация по-прежнему осталась на поддержке, без права изменения вручную.
Динамическое обновление – допускается, только если не требуется реструктуризация таблиц БД. При Динамическом обновлении бывает «зависание» старого КЭШа метаданных, при этом результат обновления не виден.
Обновление можно сделать полностью автоматическим с помощью пакетного запуска программы (с указанными ключами). Можно создать Шедулер (планировщик), который будет в определенное время запускать процесс обновления.
Нетиповая конфигурация
«Конфигурация – Поддержка – Настройка поддержки – Включить возможность изменения» - разрешение на внесение изменений в конфигурацию.
Замки – дают уверенность, что конфигурация не изменялась. При этом система не проверяет, что изменено в конфигурации, а сразу обновляет.
Желтые кубики – при каждом изменении объектов система запоминает, какие объекты изменились. В конфигурации образуются два файла метаданных:
Поставщика – с замками и кубиками, т.е. на поддержке и запрещен для изменения.
Разработчика (текущий) – с кубиками. С которым сейчас работаем.
При любом изменении система будет сравнивать конфигурацию Поставщика и Разработчика. На результат изменений наложится файл обновления. Если Разработчик менял то, что было реализовано Поставщиком, то автоматом обновление к измененным объектам применяться не будет.
Пример:
В конфигурации Клиента, в справочнике «Справочник1» изменим длину кода – сделаем 8. Сохраним конфигурацию
В оригинальной конфигурации добавим справочник «Справочник2», сохраним конфигурацию, изменим версию конфигурации, создадим Комплект поставки и установим его.
Обновим конфигурацию Клиента, используя метод обновления Поддержка. Но теперь автоматического обновления не происходит и система показывает таблицу сравнения объектов:
По умолчанию объекты измененные разработчиком не отмечены галочкой.
При включенной возможности изменения конфигурации на поддержке, размер БД будет больше, т.к. одновременно будут храниться конфигурация Поставщика и Разработчика.
Конфигурация не на поддержке
«Конфигурация – Поддержка – Настройка поддержки – Снять с поддержки»
В данном случае обновление конфигурации через Поддержку больше не работает.
Возврат конфигурации обратно на Поддержку
Допустим сняли конфигурацию с поддержки, исправили ошибки, а в следующем релизе такие же ошибки уже тоже исправлены. Надо поставить конфигурацию обратно на Поддержку:
Единственный правильный способ – «Конфигурация – Сравнить, объединить с конфигурацией из файла». После сравнения, когда конфигурация полностью идентична конфигурации поставки 1С, надо выполнить:
«Конфигурация – Загрузить конфигурацию из файла»
!!!Неправильно:
Сделать из своей конфигурации конфигурацию Поставщика. При этом для каждого объекта метаданных система создает новый идентификатор. При обновлении система проверяет объекты по идентификаторам. Тогда, при обновлении, пришедшем от 1С, идентификаторы не совпадают: а записи объектов, где идентификаторы не совпадают, при обновлении удаляются.
Итог: конфигурация обновится, но данные из БД исчезнут.