Это моя первая в жизни статья, конструктивная критика приветствуется.
Целевая аудитория - те, кто первый раз сталкивается с РБД.
Задачи РБД
Первое с чего необходимо начать - это ответить на вопрос «Зачем нам нужна РБД?». Вариантов ответов много, в частности:
- У нас есть филиалы, работающие в несвязных БД. Теперь мы хотим, чтобы информация между ними синхронизировалась;
- У нас есть филиалы, однако нагрузка на базу слишком велика (имеются ввиду блокировкитранзакций, не объем БД) и онлайн актуальность (не путать с актуальностью в несколько минут, онлайн - это когда после выполнения каждой транзакции данные передаются во второй узел) данных для филиалов не требуется;
- У нас есть филиалы, в которых происходит только ввод данных (например, розничные магазины), поэтому можно существенно снизить нагрузку на центральную БД;
- Из соображений безопасности мы хотим, чтобы в филиалах даже теоретически(с админ. паролем) не было доступа к важным данным, например балансу предприятия.
В одном случае для меня были актуальны вопросы 2 и 4, в другом 2 и 3. Первый пункт слишком обширный и в рамках тематики данной статьи рассматриваться не будет.
Также лучше сразу рассмотреть проблематику транспорта файлов обмена, потому что в некоторых случаях она может наложить существенные ограничения на реализацию обмена данных. Сначала необходимо определить в каких филиалах точно появятся узлы РБД (обычно это региональные филиалы). Далее рассматриваем, где ещё мы хотим установить узлы РБД, и нужна ли в них онлайн актуальность. Например, для розничных магазинов далеко не всегда есть возможность установки даже модема, а установка беспроводной связи будет слишком дорогая. Здесь необходимо принять решение - возможно, данный магазин может работать в оффлайне и периодически обмениваться с центром (раз в день/раз в неделю) с помощью физического носителя, например флешки.
В некоторых случаях обмен посредствам физического носителя невозможен, например это очень удаленный филиал, где есть существенные проблемы с наладкой высокоскоростной связи. Здесь стоит примерно подсчитать объем информации при обмене. Часто при актуальности раз в час либо несколько раз в день достаточно 32к модема. Однако стоить помнить, что вместе с обновлениями данных придется иногда присылать обновления самой конфигурации или внешних файлов (печатный формы, фотографии товаров), поэтому периодически будет возникать ситуация, когда файл обмена существенно увеличиться из-за таких обновлений.
Топология
Итого мы получили следующие вопросы, на которые необходимо ответить:
- В каких подразделениях мы гарантированно будем устанавливать узлы РБД и есть ли там возможность установить высокоскоростной канал;
- В каких подразделениях установка узла РБД не требуется;
- Какие подразделения могут работать с актуальностью в несколько часов;
- Какие подразделения могут работать в оффлайн режиме (обмен данными меньше 3-4х раз в день).
Ответив на эти вопросы, мы получаем приблизительную схему нашей РБД. Для крупных компаний обычно получается нечто следующее:
Рис 1. Типовая схема РБД крупной компании
Если с узлами «Филиал» все относительно ясно - это крупные центры, требующие автоматизации, то под узлами «Магазин» подразумевается узел с серьезной нагрузкой на БД при вводе данных, который для снижения нагрузки следует отделить. Например, магазин с 50-тью кассами и ежедневным товарооборотом больше 10000 единиц.
- Магазины - ввод данных о собственном товарообороте и движении денежных средств. Аналитика поверхностная, только по своему магазину.
- Филиалы - ввод данных неавтоматизированных точек, бухгалтерия, зарплата и кадры, производство и т.п. Аналитика в рамках собственного филиала.
- Центр - ввод данных неавтоматизированных филиалов. Аналитика предприятия в целом.
Важно понимать в каких целях будет использоваться БД в каждом узле. От целей выстраиваются задачи, необходимые к реализации, например:
- Филиалы видят историю взаиморасчетов с контрагентами друг друга;
- Магазины видят остатки товаров во всем (либо части) предприятия;
- Аналитика доходов/расходов, выполнения бюджета и т.п.видны только в рамках иерархии собственного подразделения;
- Бухгалтерия, зарплата и кадры видны только в рамках иерархии собственного подразделения;
- Номенклатура, все её свойства и характеристики видны во всех узлах РБД;
- Относительно иерархии подразделений все данные попадают вверх, но фильтруются вниз;
- В центр попадает абсолютно вся информация о компании.
Ставя перед собой подобные вопросы можно ответить на самый сложный вопрос - какая информация, где и как должна курсировать между узлами РБД? Почему самый сложный? Зная, какие наборы данных курсируют между узлами, можно однозначно понять, как «нарезать» текущую БД, чтобы данные оставались логически целостными. Например, нельзя данные об остатках товаров отрывать от данных о текущих резервах.
Теперь, в зависимости от потоков информации, перерисуем схему РБД:
Что мы видим на рисунке 2? Согласно иерархии подразделений компании выстроилась топология потока информации между узлами БД. Также добавился узел «Центр 2», почему? При реализации топологии «Звезда» нагрузка на центр всегда выше, чем нагрузка на периферийные узлы, при этом часто нагрузка, генерируемая самим узлом, и так высока. Примеры использования узлов «Центр 1» и «Центр 2»:
- «Центр 1» служит только для консолидации данных остальных узлов РБД. Доступ к нему имеет только администратор. «Центр 2» служит для работы головного офиса;
- «Центр 1» служит для работы головного офиса. Однако тяжелые аналитические, тестовые, создающие огромную нагрузку на БД, операции выполняются в узле «Центр 2»; например восстановление последовательности, перепроведение закрытых периодов, формирование сводных отчетов по всему предприятию за длительный промежуток времени, формирование аналитики, приводящей к изменению данных;
- «Центр 1» служит для работы головного офиса. «Центр 2» является резервным, на случай непредвиденных ситуаций для быстрого восстановления всей РБД.
Реализация обмена
Существуют 2 варианта работы РБД:
- Автоматический - происходит без участия пользователя. Контроль за внештатными ситуациями,возложен либо на администратора БД, либо на продвинутого пользователя;
- Ручной - обмен происходит только по желанию пользователя.
По своему опыту приводил все реализации всегда к автоматическому варианту. Если были проблемы с транспортом файлов обмена (наличие сети в узле не постоянно), то максимум, что позволял пользователю - это нажать кнопку «Произвести обмен сейчас». Ситуации, когда помимо обновления данных идет обновление конфигурации желательно приводить тоже к полностью автоматическим (например, используя стороннее ПО).
Формирование пакетов обновлений
Так как есть однозначное решение о том, на какие узлы РБД возложены какие функции, то можно сформировать только тот пакет данных, который нужен этому узлу. С одной стороны, необходимо указать какие типы объектов будут синхронизироваться между узлами. Например, регистры бухгалтерии для узла «Магазин 1» не должны вообще синхронизироваться, т.к. данные вводятся только на уровне узла филиала. С другой стороны те типы данных, которые подлежат обмену необходимо фильтровать с привязкой к подразделению. Например, данные о поступлении денег узла «Магазин 1 филиала 2» могут находиться только в узлах «Филиал 2», «Центр 1» и «Центр 2».
Однако есть и обратная проблема, если слишком сильно фильтровать данные обмена, то пакет данных потеряет логическую целостность. Например, остатки товаров учитываются в разрезе складов, а резервы учитываются в разрезе фирмы в целом, тогда если фильтровать остатки товаров по складам и не фильтровать резервы, то данные будут некорректными.
Также следует решить, на каком этапе своей жизни объект подлежит обмену. Например, обмену подлежат только проведенные расходные накладные, но никак не просто сохраненные. Либо Расходные накладные магазинов никогда не выгружаются из узла «Центр», даже после их корректировки, однако нужно учитывать обратный эффект - данные могут быть рассинхронизированы, либо какие-то изменения могут быть затерты.
Важно понимать - при обмене между узлами, какой-то из них является приоритетным. Рассмотрим ситуацию:
- В узле «Магазин 1» создали документ;
- При обмене он попал в узел «Филиал 1»;
- Документ корректируется одновременно в обоих узлах.
Какой из документов будет считаться истинным? В 1С 8.х при использовании механизма «Планы обмена» по умолчанию приоритетным является главный узел, т.е. в данном случае изменения, сделанные в узле «Магазин 1» будут утеряны и заменены на данные из узла «Филиал 1».
Есть другая, более сложная ситуация, когда корректируют одновременно два связных объекта. Например, расходная накладная и ПКО по ней корректируются в разных узлах, здесь существует вероятность потери целостности, если изменят цены, сумму оплаты, контрагентов и тп.
Также немаловажно контролировать удаление объектов, иначе это может привести к тому, что, например, расходной накладной уже существовать не будет, а движения по бухгалтерскому учету останутся.
Механизмы обмена в 1С 8.х
Существуют два подхода для реализации:
- Механизм «Планы обмена»;
- Собственная реализация регистрации объектов.
Рассмотрим оба варианта.
Механизм планов обмена позволяет, без какой либо настройки, за несколько минут, создать РБД с полным обменом данными. Если установить флаг «Распределенная информационная база», то при создании пакета обновления будут выгружены и обновления конфигурации. Всего за несколько минут можно настроить и правила разрешения/запрета обмена различными типами данных, открыв состав плана обмена. Если установить флаг «Авторегистрация» в положение «Запретить», то данный тип объекта, без дополнительных усилий, никогда обмениваться не будет.
Зачем нужна регистрация, почему не выгружать все и сразу? В любом случае файл, содержащий только изменения состояния БД, будет меньше полного снимка самой БД. Поэтому вариант полной выгрузки рассматриваться не будет.
Как настроить фильтрацию данных по принадлежности к подразделению? Здесь уже придётся программировать. В моей реализации на запись любого объекта была установлена подписка на событие «При записи», где, посредством свойства «ОбменДанными.Получатели», можно установить список получателей данного объекта. Т.е. при выгрузке стандартными средствами для узла, которого нету в списке, объект выгружен не будет. Есть и другое решение - выбирать выгружать ли объект можно непосредственно при выгрузке объекта, в процедурах «ПриОтправкеДанныхПодчиненному» и «ПриОтправкеДанныхГлавному» модуля плана обмена.
Оба варианта имеют право на существование. Однако в качестве лучшего варианта выбрал первый, потому что вычисление признака выгружаемости происходит сразу же при записи объекта, что увеличивает длительность записи объекта на 3-5% (можно оптимизировать, в некоторых случаях можно досвести до 0.01%) т.е. в среднем 0.1-0.3 секунды, а в случае расчета выгружаемости объекта непосредственно при отправке данных, которая и так создает существенную нагрузку на БД, это время будет составлять до нескольких минут.
Для полного понимания работы механизма «Планы обмена» рекомендую прочитать главу 15 книги «Профессиональная разработка в система 1С:Предприятие 8», Габец А.П., Гончаров Д.И.
Любая собственная реализация, на мой взгляд, либо повторит механизм «Планы обмена», либо будет выгружать объект сразу при изменении, либо будет выгружать больше, чем механизм «Планы обмена» (например, выгрузить все изменения за сегодняшний день). Данный вопрос не рассматриваю за неимением опыта реализации.
Транспорт
Задача транспортировки файлов от главного к подчиненному узлу сводиться к максимальной отказоустойчивости. Не редко файлы шифруются либо передаются по защищенному каналу. Для передачи файлов желательно использовать несколько различных служб, либо подготовить несколько различных вариантов подключения. Например, основной способ передачи - это используя FTP -сервер, подключенный через VPN -туннель; резервный - это e -mail сервер с TLS -подключением. Зачем нужен резервный канал с другой службой? Как показывает практика, использовать 2 различных FTP сервера менее надежно, чем FTP сервер и E -Mail .
Рекомендую службу создания пакета обновления отделять от службы транспорта, это повысит отказоустойчивость всего комплекса обмена данными. В случае, если служба, занимающаяся транспортом файлов, не отработает, то служба создания пакетов обновлений продолжит нормально работать и при некоторых условиях будет перезапускать службу транспорта и наоборот.
Моя реализация РБД
Реализация полностью автономна, поэтому как подзадача выступала максимальная отказоустойчивость. Отсюда получилось 2 службы - служба транспорта обновлений и служба импорта/экспорта данных. Обе службы работают независимо друг от друга.
После каждого успешного цикла импорта-экспорта данных сохранялось время последнего обмена с этим узлом. Если обмена не происходило очень долго, то транспортная служба начинала выгружать файлы во все, доступные ей, каналы связи из расчета на то, что второй узел все-таки получит обновления и выгрузит свои файлы. В случае исключительных ситуаций система сама отправляет сообщение администратору с подробным описание ошибки.
Для сокращения объема траффика xml -файлы упаковывались в zip -архивы. Система поддерживает два вида транспорта - FTP и E -mail .
В качестве настроек для фильтра данных существуют две таблицы. В одной (табличная часть планов обмена) хранятся условия по общим реквизитам (для каждого объекта система пытается найти этот реквизит), в другой настройки под конкретный объект метаданных. При записи любого объекта сначала происходит поиск условий по общим реквизитам (например, Подразделение), после чего система пытается определить, есть ли персональное правило на этот тип объекта по всем его реквизитам. Не рекомендую фильтровать списки - велика возможность ошибиться, например, из табличной части расходной накладной исчезнут несколько строк, а остатки при этом будут двигаться все и наоборот.
Важно понимать, под каким системным пользователем будут работать службы, т.к. может не хватить прав на создание файлов даже во временной папке 1С. Для отладки крайне рекомендую писать каждую, успешно выполненную, операцию в журнал регистраций, либо в txt -файл. В 1С 8.1 выполнение серверного кода отладить нельзя.
Для удобства отладки и настройки своей реализации прикладываю обработку "Регистрация изменений", описание которой находится в самой обработке.
Общая схема работы комплекса обмена данными указана на рис 3.
Фильтрация данных происходит в подписке на событие «ПередЗаписью» каждого объекта. Не стоит забывать, что при создании начального образа узла данные тоже необходимо отфильтровать. Процедура создания начального образа довольно длительна, поэтому рекомендую оптимизировать по максимуму её код (например, кэшировать настройки фильтрации).
Послесловие
Главная задача - это ответить на список вопросов:
- Зачем нам нужна РБД?
- Чем не устраивает работа через RDP- клиент?
- Где и почему мы хотим установить узлы РБД?
- Как будет происходить транспорт обновлений?
- Какой уровень отказоустойчивости будет реализован?
Обработка "РегистрацияИзменений"
Обработка позволяет принудительно регистрировать изменения в объектах. Есть несколько вариантов регистрации изменений:
- Если установлена галочка на каком-либо метаданном и НЕ выбран ни единый объект и НЕ установлен флаг "Выгружать по всем значениям", то РЕГИСТРИРУЕТСЯ ТОЛЬКО ВЫБРАННАЯ ТАБЛИЦА;
- Если установлен флаг "Выгружать по всем значениям", то выбранные метаданные будут выгружен по всем объектам в цикле;
- Если переключатель установлен в режим "Выгружать только выбранные объекты", то буду выгружены исключительно выбранные объекты (например: установка флага на метаданном без выбора объектов равносильна включенному флагу "Выгружать по всем значениям" и переключателю в позиции "Выгружать только выбранные объекты";
- Если переключатель установлен в режим "Выгружать выбранные и непосредственно связанные объекты" то буду выгружены выбранные объекты и те объекты, существование которых зависит от существования выбранного объекта(например: у справочников - подчиненные справочники);
- Если переключатель установлен в режим "Выгружать по всем ссылкам", то буду выгружены ВСЕ объекты в которых присутствует ссылка на выбранный объект.
Из дополнительного функционала доступно:
- Перерегистрация зарегистрированных объектов, часто требуется для отладки;
- Удаление зарегистрированных, часто требуется для отладки;
- Печать изменений - печать полного перечня объектов, которые помечены как измененные;
- Печать дерева конфигурации - только для удобства просмотра всей конфигурации.
ОЛЕГ ФИЛИППОВ , АНТ-Информ, заместитель начальника отдела разработки, [email protected]
РИБ в 1С. Границы возможностей
Технология распределенных информационных баз (РИБ) в платформе 1С:Предприятие вызывает много споров. Постараемся разобраться, когда ее целесообразно использовать, а когда лучше предпочесть альтернативные решения
Часто, читая форумы или статьи online-авторов по поводу РИБ в 1С, можно встретить противоречивые мнения от «это лучшее и единственное, что можно использовать» до «оно безнадежно устарело». Давайте постараемся разобраться, какобстоят дела на самом деле.
В ноябрьском номере за 2016 год я уже писал о некоторых особенностях РИБ применительно к конкретной практической задаче, поэтому об основах буквально пару слов, и несколько углубимся в технологические детали.
РИБ – технология распределенных информационных баз 1С:Предприятия – не путать с универсальным обменом, с схожей технологией, но принципиально отличающейся поддержкой централизованного обновления конфигураций информационных баз. Он состоит из следующих функциональных частей (которые могут использоваться и отдельно):
- Служба регистрации изменений – при включении начинает автоматически регистрировать изменения объектов или записей для обмена (или других целей). В режиме РИБ используется также для регистрации изменений конфигурации информационной базы.
- Сериализация объектов/записей в XML. Практически любой объект 1С:Предприятия штатным образом сериализуется в XML.
- Механизм поддержки одинаковой конфигурации всех узлов распределенной информационной базы. В режиме РИБ обмен данными между различными узлами возможен только в случае если у них одинаковая конфигурация. Переносится она при обмене автоматически. В конечном узле нужно только принять изменения.
- Инфраструктура сообщений при обмене в распределенной информационной системе – гарантированная доставка. Зарегистрированные изменения упаковываются в сообщения и отправляются на конечный узел в пакетах. Удаляются изрегистрации только после подтверждения доставки пакета.
- Инфраструктура уровня прикладных решений. Конечно, все вышеперечисленное не будет работать без развитых механизмов на уровне прикладных решений, часть из которых уже включена в БСП. В решениях реализована возможность выгружать данные по определенным правилам, изменять принципы их регистрации, определять способ доставки пакета.
Как видим, РИБ в 1С может достаточно много. В большинстве случаев данной функциональности более чем достаточно. К примеру, на рис. 1 приведена форма узла информационной базы в 1С, где можно видеть и возможность загрузить правила регистрации, и указать параметры подключения, и посмотреть список зарегистрированных к обмену объектов.
Из описания выше можно сделать вывод о возможностях РИБ 1С как распределенной системы:
- Поддержка единой конфигурации информационной базы (полуавтоматизированная).
- Поддержка отслеживания изменений.
- Гарантированная доставка.
- Возможность схемы master-master.
- Возможность схемы «звезда».
- Возможность выборочной фильтрации изменений.
Достаточно неплохо – потребности небольшой сети вполне удовлетворит. Но у РИБ есть определенные ограничения, во многом связанные с архитектурными особенностями платформы 1С, которые накладывают определенные ограничения на использование данной технологии:
- Необходимость обновления конфигурации информационной базы в ручном режиме с завершением работы пользователей. Остановка обменов до обновления конфигурации.
- Транзакционное ограничение инфраструктуры сообщений на выборку данных. При выборке изменений для выгрузки происходит блокировка таблицы базы на запись новых изменений, при больших объемах выгрузки это может занимать длительное время, останавливая работу.
- Накладные расходы на поддержание большого количества узлов синхронизации (количество служебных записей равно количеству узлов).
- Проблемы загрузки больших объемов данных.
Постараемся теперь сравнить это с какой-либо «продвинутой» системой, которая имеет механизм репликации.
Инструкция по созданию и настройке распределенных баз с помощью компоненты УРБД (УРИБ)
Компонента УРБД (Управление распределенными базами данных) применяется для обмена информацией между двумя идентичными базами 1С. Если конфигурации разные, то применять ее также можно, об этом написано в другой . Для работы компоненты необходимо наличие файла DistrDB.dll в папке BIN программы 1С: Предприятие.
Рассмотрим действия по созданию распределенных баз данных. Например, у нас есть рабочая база в каталоге D:\base1. Требуется сделать ее центральной и создать периферийную базу.
1. Создаем каталог D:\base2 для периферийной базы.
2. В каталогах D:\base1 и D:\base2 создаем папки CP и PC (используем латинские буквы).
3. Запускаем конфигуратор центральной базы (D:\base1) и выбираем Меню - Администрирование - Распределенная ИБ - Управление.
4. Нажимаем кнопку "Центральная ИБ", в появившемся окне вводим код и наименование базы. Для кода лучше использовать цифры или латинские буквы. Вводим, например, 001 и "Центральная база", подтверждаем нажатием кнопки "ОК".
5. Нажимаем кнопку "Новая периф. ИБ" для того чтобы создать периферийную базу. Вводим для нее параметры: 002 и "Периферийная база 1".
6. Курсором выделяем базу "Периферийная база 1" и нажимаем кнопку «Настр. автообмена». В настройках меняем ручной режим на автоматический. Будьте внимательны, это важно.
7. Курсором выделяем базу "Периферийная база 1" и нажимаем кнопку «Выгрузить данные», затем кнопку "ОК". В результате выгрузки появится файл D:\base1\CP\020.zip.
8. Запускаем 1С в режиме конфигуратора, добавляем в окне запуска 1С новую базу "Периферийная база 1", указываем для нее ранее созданный каталог D:\base2.
9. Выбираем Меню - Администрирование – Распределенная ИБ – Управление. На заданный вопрос «Информационная база не обнаружена. Выполнить загрузку данных?» нажимаем кнопку "Да" и указываем имя файла "D:\base1\CP\020.zip", нажимаем кнопку "ОК". После окончания загрузки процесс создания периферийной базы можно считать законченным.
В и еще в приведены способы создания периферийной базы путем восстановления из бэкапа копии центральной базы либо приаттачивания файлов копии центральной базы для формата SQL и выполнения скрипта. Это будет полезно при больших объемах данных, когда выгрузки-загрузки растягиваются на часы или вообще нереальны.
Инструкция по обмену между распределенными базами с помощью компоненты УРБД (УРИБ)
Рассмотрим упрощенный пример, выполнять обмен будем вручную, запуская конфигуратор. Можно использовать пакетный режим конфигуратора, для доставки пакетов обмена можно использовать почту, ftp, автоматическое копирование файлов.
Для выполнения обмена необходимо выбирать Меню - Администрирование - Распределенная ИБ - Автообмен. Если обмен автоматический (см. пункт 6 предыдущей инструкции), то все у нас получится.
1. Итак, изменяем либо создаем какие-то объекты, которые мигрируют в периферийную базу. Правила миграции объектов задаются на вкладке "Миграция" в свойствах объекта (см. дерево объектов в конфигураторе).
2. Запускаем конфигуратор центральной базы, выбираем Меню - Администрирование - Распределенная ИБ - Автообмен, нажимаем кнопку "Выполнить".
3. Полученный файл D:\base1\CP\020.zip перемещаем в папку D:\base2\CP\
4. Изменяем какие-то объекты периферийной базе данных. Желательно не те, которые менялись до этого в центральной базе, т.к. центральная база имеет приоритет изменений объектов при обмене.
5. Запускаем конфигуратор периферийной базы, выбираем Меню - Администрирование - Распределенная ИБ - Автообмен, нажимаем кнопку "Выполнить".
6. В результате автообмена у нас должны появиться изменения, поступившие из центральной базы данных. Также у нас должен появиться файл для передачи в центральную базу D:\base2\PC\021.zip
7. Копируем файл D:\base2\PC\021.zip в папку D:\base1\PC
8. Повторяем пункт 2. В результате в центральной базе появятся изменения, поступившие из периферийной базы.
Итак, общий принцип обмена: попеременное выполнение автообмена с одновременным перемещением файлов (пакетов обмена) из папки PC одной базы в папку PC другой базы и из папки CP одной базы в папку CP другой базы.
Изменение конфигурации производится только в центральной базе. При изменении конфигурации необходимо проведение обмена в периферийных базах в монопольном режиме. Для успешной обработки пакетов из периферийных баз в центральной базе конфигурация должна быть загружена в периферийные базы. Если вы запутались - ничего страшного, отвергнутый центральной базой пакет выгрузится повторно.
В данной статье речь пойдет о настройке распределенной базы данных 1С предприятие 7.7, в качестве примера будет использована конфигурация Управление Торговлей 9.2.
Что бы настроить РИБ в 1С 7.7 нужно зайти в конфигуратор и перейти в Администрирование-Распределенная ИБ-Управление.
Затем необходимо конвертировать вашу базу в РИБ, если она ещё не конвертирована в РИБ, для этого нужно нажать кнопку "Центральная ИБ".
Установите Код и Описание как на скриншоте сверху и нажмите "OK". Должно появиться предупреждение как на скриншоте снизу, не обращайте на него внимания и нажмите "Да".
После этого ваша база будет готова для создания периферийных узлов.
Нажмите на кнопку "Новая периф. ИБ" и установите значения полей как на следующем скриншоте, впрочем, вы можете использовать свои обозначения.
Нажимаем OK и переходим к следующему шагу - настройке автообмена.
В данной статье я расскажу как настроить автообмен используя локальную сеть, если вам понадобится автообмен по почте, то оставьте ваш запрос в комментариях или свяжитесь со мной по и я вам расскажу как это сделать.
Выставляем все как на слайде, пути к каталогам у вас могут быть свои, галочки должны стоять как на скриншоте сверху. Нажимаем OK.
Теперь выгружаем начальный образ периферийной базы на диск, для этого нажимаем кнопку "Выгрузить данные". После выгрузки начального образа окно управления РИБ будет выглядеть следующим образом:
Предположим, что компьютер на котором будет работать наша риб находится недалеко от основного компьютера с центральной базой и оба компьютера объединены в локальную сеть.
Теперь необходимо настроить РИБ на клиентском компьютере, для этого берем наш выгруженный на предыдущих шагах zip-файл и создаем на его основе информационную базу. На скриншотах внизу показана полная последовательность действий.
Нажимаем кнопку "Добавить" и указываем пусть к пустой папке и нажимаем OK.
Выбираем новую ИБ и переходим в режим конфигуратора. 
В пустой папке мы создаем пустую ИБ, поэтому 1С просит указать нас в каком формате будет наша база, выбираем *.dbf. Нажимаем OK.
Теперь загрузим выгруженный на прошлых шагах zip-файл в нашу базу, для этого перейдем в администрирование-загрузить данные.
Укажем путь к файлу и нажмем OK.
По окончании загрузки нажмем OK и перейдем в администрирование-распределенная иб-автообмен.
На данном шаге необходимо учитывать правило: Директория выгрузки ЦБ = Директории загрузки ПБ и наоборот, т.е. если в центральной базе мы выгружали в папку out а загружали из папки in, то в периферийной базе мы будем загружать из папки out, а выгружать в папку in. Нажимаем OK и переходим к следующему шагу. Выполняем автообмен. Для этого в центральной базе зайдите в администрирование-распределенная иб-автообмен.
Нажмите кнопку "Выполнить", после чего проделайте то же самое на базе-клиенте. Проделайте операцию автообмена поочередно на каждом из компьютеров несколько раз.
Теперь автоматизируем процесс. Для этого необходимо создать по 4 файла на каждом компьютере. По 2 *.prm файла и по 2 *.bat файла на каждую из операций загрузки-выгрузки.
*.bat файл должен содержать в себе следующую строку:
"<путь к файлу 1cv77.exe>" config /D"<путь к информационной базе>" /N<логин> /P<пароль>/@"<путь к prm-файлу>"
У меня файлы загрузки и выгрузки выглядит так:
"C:\Program Files\1Cv77\BIN\1cv7s.exe" config /D"C:\base\rib\" /Nadmin /P1 /@"c:\download.prm"
"C:\Program Files\1Cv77\BIN\1cv7s.exe" config /D"C:\base\rib\" /Nadmin /P1 /@"c:\upload.prm"
Вы прописываете свои значения. Теперь разберемся с prm-файлами!
Структура файла.prm:
Секция “General” – предназначена для описания основных параметров работы пакетного режима. Возможные параметры:
Output – путь к лог-файлу;
- Quit – нужно ли завершить работу конфигуратора после выполнения всех заданий;
- AutoExchange – нужно ли выполнять автообмен;
- SaveData – нужно ли выполнять сохранение базы;
- UnloadData – нужно ли выполнять выгрузку;
- CheckAndRepair – нужно ли выполнить тестирование и исправление базы.
Возможными значениями данных параметров могут быть 1(Y) или 0(N).
Секция “AutoExchange” – предназначена для определения параметров автообмена. Параметры:
SharedMode – указывает режим работы с базы данных. Если параметр не задан, то будет использоваться монопольный режим;
- ReadFrom - указывает от каких баз следует получать данные. Идентификаторы баз необходимо указывать через запятую. Если же необходимы все, то ставится * ;
- WriteTo - указывает для каких баз следует выгружать данные. Если же необходимо для всех, то ставится * .
Секция “SaveData” – предназначена для определения параметров сохранения базы. Возможные параметры:
SaveToFile – указывает путь, куда будет производиться сохранение;
- FileList – указывает список сохраняемых файлов. Перечисляются имена файлов через пробел или запятую;
Секция “ UnloadData” – предназначена для определения параметров выгрузки данных. Параметры:
UnloadToFile – указывает путь сохранения, включая имя файла;
- IncludeUserDef – указывает нужно ли в файл переноса включать список пользователей;
- Password – указывает пароль,который будет установлен на файл переноса.
Секция “ CheckAndRepair” – предназначена для определения параметров восстановления базы данных. Возможные параметры:
Repair – указывает, необходимо ли проводить восстановление базы данных;
- PhysicalIntegrity – указывает, нужно ли проводить проверку физической целостности таблиц информационной базы;
- Reindex – указывает необходимость проведения реиндексации базы;
- LogicalIntegrity – указывает, необходимо ли проводить проверку логической целостности таблиц;
- RecalcTotals – указывает, необходимо ли производить пересчет итогов бухгалтерского и оперативного учета;
- Pack – указывает, необходимо ли освобождать место, занятое удаленными записями;
- SkipUnresolved – указывает, пропускать неразрешенные ссылки или их исправлять;
- CreateForUnresolved – указывает, способ разрешения неразрешенных ссылок. Если 1, то для неразрешенной ссылки будет создан объект соответствующего типа. Если же 0, то ссылка будет очищена.
Исходя из этого мои файлы будут содержать следующее:
для загрузки из ЦБ в периферийную:
Output = log.txt
Output = 1
ReadFrom = ЦБ
для выгрузки из ЦБ в периферийную:
Output = log.txt
Output = 1
WriteTo = ЦБ
для загрузки из периферийной в ЦБ:
Output = log.txt
Output = 1
ReadFrom = ПБ1
для выгрузки из периферийной в ЦБ:
Output = log.txt
Output = 1
WriteTo = ПБ1
Теперь достаточно поместить bat- и prm- файлы в одну папку и запускать по очереди для выполнения загрузки и выгрузки.
Если остались вопросы - wellcome в комментарии!
Зачастую на практике встречаются такие ситуации, когда различные подразделения или филиалы территориально располагаются в разных местах. При этом данные, заносимые в программу в удаленных подразделениях должны как-то попадать в головной офис, чтобы велся общий учет.
В настоящее время данная проблема зачастую решается предоставлением территориально удаленным сотрудникам удаленный доступ к общей базе. Он может быть осуществлен посредством публикации базы на веб-сервере, через удаленный рабочий стол и проч.
Однако, не редки и такие ситуации, когда в территориально удаленном офисе попросту нет интернета, либо он не достаточно стабилен для работы в общей информационной базе. Для этого в 1С существует механизм настройки распределенной базы.
Проще говоря, в головном офисе располагается главная база. В удаленном подразделении используется подчиненная. Таких подчиненных баз может быть и несколько. В результате такая распределенная база объединяется в одну посредством синхронизации. Ее можно производить как в автоматическом режиме по расписанию, так и вручную.
В данной статье мы рассмотрим настройку распределенной базы данных для 1С:Бухгалтерия 3.0. Несмотря на это, инструкция подойдет и для большинства других конфигураций 1С 8.3.
Обратите внимание , что все необходимые доработки конфигурации должны производиться только в главной базе РИБ. При синхронизации эти изменения передадутся во все подчиненные базы и вступят в силу.
Главная информационная база
При использовании распределенной базы данных основные настройки приходятся на главную базу. Производить их нужно в разделе «Администрирование», как показано на изображении ниже.
В открывшемся окне сразу же установите галку «Синхронизация данных». В нижней части укажите префикс главной (текущей базы). Он может состоять не более чем из двух символов. В нашем случае префиксом будет «БГ», так как мы подразумеваем, что эта РИБ 1С «Бухгалтерия главная».
Теперь можно приступить к настройке самой синхронизации, а именно к указанию того, с какой базой (или базами) будет производиться обмен данными. Для этого перейдите по гиперссылке «Настройки синхронизации данных». Она будет доступна для перехода только при установленной галке слева.
В открывшемся окне из меню выберем пункт «Полный…». Он позволит нам указать любую информационную базу 1С для произведения синхронизации.
В первом окне подключения подчиненной базы, которая расположена в территориально удаленном офисе, отметим флагом, что подключение будет производиться через локальный или сетевой каталог. В нашем случае это «D:\DB\InfoBase». Так же заранее проверим возможность записи в него.
Обязательно указывайте разные префиксы для разных баз. Дело в том, что при синхронизации данных для данных, перегруженных из каждой базы, устанавливается свой префикс. При их дублировании работа будет некорректной, поэтому программа не даст вам такой возможности.
Когда программа предложит вам создать начальный образ, выберите эту опцию. Данная процедура займет некоторое время, после чего сохраните его на компьютер с именем «1Cv8.1CD».
Сама синхронизация может производиться как автоматически по расписанию, которое вы можете настроить самостоятельно, так и вручную. Во втором случае достаточно нажать на кнопку «Синхронизировать» в удобное для вас время.
Подчиненный узел РИБ
Количество производимых настроек в подчиненной базы значительно меньше. В том же разделе установите флаг «Синхронизация данных» и перейдя по соответствующей ссылке будет доступна кнопка «Синхронизировать».
В рамках нашего примера в главную базу были добавлены две номенклатурные позиции: «Брус» и «Доска». После синхронизации они попали в подчиненную базу. Как вы можете увидеть на рисунке ниже, им присвоился префикс «БГ». Остальным двум позициям («Токарный станок» и «Поддон») присвоен префикс «БП», так как они были заведены непосредственно в подчиненной базе.
Обратите внимание , что нумерация элементов в нашем случае сквозная, но только в пределах одного и того же префикса.
Загрузка...
