1с 8 упп риб настройка. Распределенная информационная база: Основы. Настройка синхронизации в периферийной базе данных

Распределенная Информационная База (РИБ) — применяется когда необходимо иметь доступ к распределенным данным кампании или предприятия с целью использования и обмена содержащейся в них информации.

Примером служит конфигурация Управление Торговлей 11 (11.0.6.9) — платформа 1С 8.2.

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

1. Первое что мы делаем, это запускаем 1С:Предприятие, затем переходим на вкладку "Администрирование" и в конечном итоге выбираем пункт "Настройка параметров учета".
2. После этого откроется окно и уже в нем выбираем пункт "Обмен данными". Нажимаем на разрешение использования обмена данными, и после этого нажимаем кнопку "Записать и закрыть".
3. После того как включим обмены данными, в левой части окна должен появится новый пункт "Обмен данными". Кликаем по пункту "Обмен данными".
4. Когда откроется окно, кликаем на кнопку "Создать". Выбираем пункт "Создать обмен в распределенной информационной базе" После этого откроется окно мастера по созданию Распределительно Информационной Базы.
5. Ищем в открывшемся окне кнопку "Далее" и нажимаем на нее, после этого переходим к другому окну. В проссматриваемой Вами статье изображен обмен данными через локальный или сетевой каталог.
6. Находим каталог обмена, ставим галочку напротив пункта "Сжимать файл исходящего сообщения". Затем нажимаем на "Далее" и пропускаем два следующих окна (делаем это потому что в этой статье не будем рассматривать обмен через FTP и почту).
7. Жмем "Далее".
8. Называем как Вам удобно имя для плана обмена данными, я выбрала, например, "Обмен_С_Периферийной_Базой", Вы можете установить свое имя. Затем проверяем что бы "Основной способ обмена данными" был "Обмен через локальный или сетевой каталог" и нажимаем "Далее".
9. После того как проверим содержимое текущего окна и нажимаем "Далее".
10. В данном окне также ничего не меняем и нажимаем кнопку "Готово".
11. Указываем путь к папке для создания Распределительно Информационной Базы. Указывать нужно в формате UNC, например "\\rib\1Cv8.1CD". Если все правильно — то в указанной папке создастся файл распределенной базы данных.
12. Теперь настраиваем автообмен и его расписание. Для этого переходим на вкладку "Администрирование" и выбираем пункт "Обмен данными" и делаем двойной клик по существующей строке в списке обменов данными:
13. В открывшемся окне кликаем по "Сценарии обменов данными":
14. В открывшемся окне нажимаем на кнопку "Добавить":
15. В открывшемся окне кликаем по строке "Каждый день, каждые 900 сек.":
16. В открывшемся окне устанавливаем нужные параметры:
17. Устанавливаем такие параметры, чтобы обмен выполнялся ежедневно с 00:00:00 по 23:59:59 с перерывом в 30 секунд. Это делается для того, что бы показать, что обмен выполняется в прилагаемом видеоролике, вы можете установить у себя другие значения параметров. В предыдущем окне нажимаем на кнопку"OK" и "Записать и закрыть".
18. Завершена настройка обмена данными для центрального узла, аналогично производится настройка периферийного узла. Необходимо изменить ярлык запуска 1С, добавив параметр запуска "/CDoScheduledJobs" для того, что бы обмен выполнялся в автоматическом режиме.

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

Конфигурация в распределенке обновляется так: вручную, сначала изменения делаются в ЦБ, потом делаем выгрузку и несем в периферийку. Автоматом, обычно, не срабатывает обмен.

В данной статье речь пойдет о настройке распределенной базы данных 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С Предприятие. Это позволяет иметь общее информационное пространство даже с теми подразделениями, которые не имеют надежного канала связи, сочетая высокую автономность узлов с возможностью оперативного обмена информацией. В наших статьях мы рассмотрим особенности и практическую реализацию этого механизма на платформе 8.2

Прежде всего зададимся вопросом: почему именно автообмен? Современные технологии, в сочетании с недорогим и быстрым интернетом, позволяют организовать удаленную работу без каких либо затруднений. Выбор способов как никогда широк: RDP, тонкий и веб-клиенты, объединение сетей при помощи VPN - есть над чем задуматься. Однако все эти способы имеют один существенный недостаток - сильная зависимость от качества канала связи.

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

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

РИБ на платформе 8.2 не является чем-то принципиально новым, представляя собой дальнейшее развитие УРИБ платформы 7.7, только теперь эта технология стала доступней и проще. В отличии от компоненты УРИБ, которую нужно было приобретать отдельно, РИБ является неотъемлемой частью многих типовых конфигураций и работает полностью в пользовательском режиме, позволяя обойтись без Конфигуратора даже на этапе настройки.

На этом месте пора бы было перейти к практической части, но придется сделать еще одно отступление. Дело в том, что переход на платформу 8.2, который вроде бы уже произошел, по факту привел к появлению двух типов конфигураций: на основе управляемого приложения, "родные" для платформы 8.2, и адаптированные с 8.1, продолжая использовать устаревшие технологии и механизмы. Так как существенная часть конфигураций (Бухгалтерия предприятия, Зарплата и управление персоналом) являются адаптированными или переходными, то сбрасывать их со счетов нельзя, поэтому первая часть нашей статьи будет посвящена этим конфигурациям (по сути платформе 8.1), в то время как во второй мы разберем настройку автообмена для конфигураций на основе управляемого приложения (платформе 8.2).

Рассмотрим практическую задачу: настроить автообмен через FTP для конфигурации Бухгалтерия предприятия 2.0. Несмотря на то, что РИБ позволяет производить обмен с использованием электронной почты или общих файловых ресурсов, мы рекомендуем использовать именно FTP, как наиболее простой и надежный способ связи. Как настроить собственный FTP-сервер вы можете прочитать в , либо можно использовать FTP сервис любого хостинг провайдера.

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

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

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

Теперь перейдем Сервис - Распределенная информационная база (РИБ) - Настроить узлы РИБ .

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

Закладка Автоматический обмен позволяет настроить расписание обменов, обмен по событиям (начало и завершение работы и т.п.), данные настройки производятся для пользователя от чьего имени будет выполняться обмен, поэтому убедитесь в наличии у него прав для обмена данными.

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

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

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

Это моя первая в жизни статья, конструктивная критика приветствуется.

Целевая аудитория - те, кто первый раз сталкивается с РБД.

Задачи РБД

Первое с чего необходимо начать - это ответить на вопрос «Зачем нам нужна РБД?». Вариантов ответов много, в частности:

1. У нас есть филиалы, работающие в несвязных БД. Теперь мы хотим, чтобы информация между ними синхронизировалась;
2. У нас есть филиалы, однако нагрузка на базу слишком велика (имеются ввиду блокировкитранзакций, не объем БД) и онлайн актуальность (не путать с актуальностью в несколько минут, онлайн - это когда после выполнения каждой транзакции данные передаются во второй узел) данных для филиалов не требуется;
3. У нас есть филиалы, в которых происходит только ввод данных (например, розничные магазины), поэтому можно существенно снизить нагрузку на центральную БД;
4. Из соображений безопасности мы хотим, чтобы в филиалах даже теоретически(с админ. паролем) не было доступа к важным данным, например балансу предприятия.

В одном случае для меня были актуальны вопросы 2 и 4, в другом 2 и 3. Первый пункт слишком обширный и в рамках тематики данной статьи рассматриваться не будет.

Также лучше сразу рассмотреть проблематику транспорта файлов обмена, потому что в некоторых случаях она может наложить существенные ограничения на реализацию обмена данных. Сначала необходимо определить в каких филиалах точно появятся узлы РБД (обычно это региональные филиалы). Далее рассматриваем, где ещё мы хотим установить узлы РБД, и нужна ли в них онлайн актуальность. Например, для розничных магазинов далеко не всегда есть возможность установки даже модема, а установка беспроводной связи будет слишком дорогая. Здесь необходимо принять решение - возможно, данный магазин может работать в оффлайне и периодически обмениваться с центром (раз в день/раз в неделю) с помощью физического носителя, например флешки.

В некоторых случаях обмен посредствам физического носителя невозможен, например это очень удаленный филиал, где есть существенные проблемы с наладкой высокоскоростной связи. Здесь стоит примерно подсчитать объем информации при обмене. Часто при актуальности раз в час либо несколько раз в день достаточно 32к модема. Однако стоить помнить, что вместе с обновлениями данных придется иногда присылать обновления самой конфигурации или внешних файлов (печатный формы, фотографии товаров), поэтому периодически будет возникать ситуация, когда файл обмена существенно увеличиться из-за таких обновлений.

Топология

Итого мы получили следующие вопросы, на которые необходимо ответить:

1. В каких подразделениях мы гарантированно будем устанавливать узлы РБД и есть ли там возможность установить высокоскоростной канал;
2. В каких подразделениях установка узла РБД не требуется;
3. Какие подразделения могут работать с актуальностью в несколько часов;
4. Какие подразделения могут работать в оффлайн режиме (обмен данными меньше 3-4х раз в день).

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

Рис 1. Типовая схема РБД крупной компании

Если с узлами «Филиал» все относительно ясно - это крупные центры, требующие автоматизации, то под узлами «Магазин» подразумевается узел с серьезной нагрузкой на БД при вводе данных, который для снижения нагрузки следует отделить. Например, магазин с 50-тью кассами и ежедневным товарооборотом больше 10000 единиц.

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

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

• Филиалы видят историю взаиморасчетов с контрагентами друг друга;
• Магазины видят остатки товаров во всем (либо части) предприятия;
• Аналитика доходов/расходов, выполнения бюджета и т.п.видны только в рамках иерархии собственного подразделения;
• Бухгалтерия, зарплата и кадры видны только в рамках иерархии собственного подразделения;
• Номенклатура, все её свойства и характеристики видны во всех узлах РБД;
• Относительно иерархии подразделений все данные попадают вверх, но фильтруются вниз;
• В центр попадает абсолютно вся информация о компании.

Ставя перед собой подобные вопросы можно ответить на самый сложный вопрос - какая информация, где и как должна курсировать между узлами РБД? Почему самый сложный? Зная, какие наборы данных курсируют между узлами, можно однозначно понять, как «нарезать» текущую БД, чтобы данные оставались логически целостными. Например, нельзя данные об остатках товаров отрывать от данных о текущих резервах.

Теперь, в зависимости от потоков информации, перерисуем схему РБД:

Что мы видим на рисунке 2? Согласно иерархии подразделений компании выстроилась топология потока информации между узлами БД. Также добавился узел «Центр 2», почему? При реализации топологии «Звезда» нагрузка на центр всегда выше, чем нагрузка на периферийные узлы, при этом часто нагрузка, генерируемая самим узлом, и так высока. Примеры использования узлов «Центр 1» и «Центр 2»:

1. «Центр 1» служит только для консолидации данных остальных узлов РБД. Доступ к нему имеет только администратор. «Центр 2» служит для работы головного офиса;
2. «Центр 1» служит для работы головного офиса. Однако тяжелые аналитические, тестовые, создающие огромную нагрузку на БД, операции выполняются в узле «Центр 2»; например восстановление последовательности, перепроведение закрытых периодов, формирование сводных отчетов по всему предприятию за длительный промежуток времени, формирование аналитики, приводящей к изменению данных;
3. «Центр 1» служит для работы головного офиса. «Центр 2» является резервным, на случай непредвиденных ситуаций для быстрого восстановления всей РБД.

Реализация обмена

Существуют 2 варианта работы РБД:

1. Автоматический - происходит без участия пользователя. Контроль за внештатными ситуациями,возложен либо на администратора БД, либо на продвинутого пользователя;
2. Ручной - обмен происходит только по желанию пользователя.

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

Формирование пакетов обновлений

Так как есть однозначное решение о том, на какие узлы РБД возложены какие функции, то можно сформировать только тот пакет данных, который нужен этому узлу. С одной стороны, необходимо указать какие типы объектов будут синхронизироваться между узлами. Например, регистры бухгалтерии для узла «Магазин 1» не должны вообще синхронизироваться, т.к. данные вводятся только на уровне узла филиала. С другой стороны те типы данных, которые подлежат обмену необходимо фильтровать с привязкой к подразделению. Например, данные о поступлении денег узла «Магазин 1 филиала 2» могут находиться только в узлах «Филиал 2», «Центр 1» и «Центр 2».

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

Также следует решить, на каком этапе своей жизни объект подлежит обмену. Например, обмену подлежат только проведенные расходные накладные, но никак не просто сохраненные. Либо Расходные накладные магазинов никогда не выгружаются из узла «Центр», даже после их корректировки, однако нужно учитывать обратный эффект - данные могут быть рассинхронизированы, либо какие-то изменения могут быть затерты.

Важно понимать - при обмене между узлами, какой-то из них является приоритетным. Рассмотрим ситуацию:

1. В узле «Магазин 1» создали документ;
2. При обмене он попал в узел «Филиал 1»;
3. Документ корректируется одновременно в обоих узлах.

Какой из документов будет считаться истинным? В 1С 8.х при использовании механизма «Планы обмена» по умолчанию приоритетным является главный узел, т.е. в данном случае изменения, сделанные в узле «Магазин 1» будут утеряны и заменены на данные из узла «Филиал 1».

Есть другая, более сложная ситуация, когда корректируют одновременно два связных объекта. Например, расходная накладная и ПКО по ней корректируются в разных узлах, здесь существует вероятность потери целостности, если изменят цены, сумму оплаты, контрагентов и тп.

Также немаловажно контролировать удаление объектов, иначе это может привести к тому, что, например, расходной накладной уже существовать не будет, а движения по бухгалтерскому учету останутся.

Механизмы обмена в 1С 8.х

Существуют два подхода для реализации:

1. Механизм «Планы обмена»;
2. Собственная реализация регистрации объектов.

Рассмотрим оба варианта.

Механизм планов обмена позволяет, без какой либо настройки, за несколько минут, создать РБД с полным обменом данными. Если установить флаг «Распределенная информационная база», то при создании пакета обновления будут выгружены и обновления конфигурации. Всего за несколько минут можно настроить и правила разрешения/запрета обмена различными типами данных, открыв состав плана обмена. Если установить флаг «Авторегистрация» в положение «Запретить», то данный тип объекта, без дополнительных усилий, никогда обмениваться не будет.

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

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

Оба варианта имеют право на существование. Однако в качестве лучшего варианта выбрал первый, потому что вычисление признака выгружаемости происходит сразу же при записи объекта, что увеличивает длительность записи объекта на 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.

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

Послесловие

Главная задача - это ответить на список вопросов:

1. Зачем нам нужна РБД?
2. Чем не устраивает работа через RDP- клиент?
3. Где и почему мы хотим установить узлы РБД?
4. Как будет происходить транспорт обновлений?
5. Какой уровень отказоустойчивости будет реализован?

Обработка "РегистрацияИзменений"

Обработка позволяет принудительно регистрировать изменения в объектах. Есть несколько вариантов регистрации изменений:

1. Если установлена галочка на каком-либо метаданном и НЕ выбран ни единый объект и НЕ установлен флаг "Выгружать по всем значениям", то РЕГИСТРИРУЕТСЯ ТОЛЬКО ВЫБРАННАЯ ТАБЛИЦА;
2. Если установлен флаг "Выгружать по всем значениям", то выбранные метаданные будут выгружен по всем объектам в цикле;
3. Если переключатель установлен в режим "Выгружать только выбранные объекты", то буду выгружены исключительно выбранные объекты (например: установка флага на метаданном без выбора объектов равносильна включенному флагу "Выгружать по всем значениям" и переключателю в позиции "Выгружать только выбранные объекты";
4. Если переключатель установлен в режим "Выгружать выбранные и непосредственно связанные объекты" то буду выгружены выбранные объекты и те объекты, существование которых зависит от существования выбранного объекта(например: у справочников - подчиненные справочники);
5. Если переключатель установлен в режим "Выгружать по всем ссылкам", то буду выгружены ВСЕ объекты в которых присутствует ссылка на выбранный объект.

Из дополнительного функционала доступно:

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

В этом материале подробная инструкция по настройке обмена РИБ для 1С:Предприятие 8 и проблемы, с которыми столкнулся автор.

1. Создание узлов
Создаем новые узлы (главный и подчиненный): в пользовательском режиме "Операции / Планы обмена/Полный"
Выберем план обмена "Полный"
Создаем две записи:
- первую запись назовем "ЦБ" (главный узел), код укажем "ЦБ",
- вторую запись назовем "Подчиненный узел", код укажем "ПУ".
Значек с зеленным кружком - "ЦБ" (главный узел)

Для подчиненного узла нажимаем на иконку "Создать начальный образ". (Потребуется монопольный доступ)
Создать начальный образ
Далее в открывшемся окне заполняем параметры новой базы. По окончании нажимаем кнопку "Готово"
Создание начального образа ИБ
Начнется создание начального образа подчиненного узла распределенной информационной базы, по окончании появится сообщение "Создание начального образа успешно завершено". Жмем кнопку "ОК".
Добавляем базу подчиненного узла в список баз, запускаем ее.
В этой подчиненной базе открываем полный план обмена - значок "ЦБ красный, это значит, что этот узел является главным для информационно базы, в которой мы находимся.

2. Настройка префиксов
Для каждой базы, в настройках параметров учета (в УПП "Сервис / Параметры учета") на закладке "Обмен данными", устанавливаем префиксы. Это делается для того чтобы не возникало конфликтов в номерах и кодах документов и справочников, созданных в двух базах.
Для автообмена, устанавливаем галочку "Использовать механизм автоматического обмена..."
Закладка "Обмен данными"

3. Добавляем настройку обмена данными между узлами
Открываем: "Сервис \Распределенная информационная база (РИБ)\Настроить узлы РИБ"
Нажимаем "Добавить", откроется окно "Настройка обмена данными"
Настройка обмена данными

Нажимаем на значок "Выполнить обмен по текущей настройке"
Выполнить обмен по текущей настройке

Теперь о "подводных камнях"
1. Обмен данными может выполняться в автоматическом режиме и может быть инициализирован в следующих случаях:
* При запуске программы. Обмен будет выполняться при запуске программы,
* При завершении работы с программой. Обмен будет выполняться перед завершением пользователем работы с программой,
* При появлении каталога. Обмен будет выполнен только в том случае, если каталог указанный пользователем был невиден, а в настоящий момент стал виден. Настройка может быть использована для выполнения автоматического обмена при подключении к локальной сети или flash карты. Программа периодически будет проверять видимость указанного в настройках каталога и отмечать его текущее состояние,
* При появлении файла. Рекомендуется использовать данные режим, когда нужно выполнить обмен, если появляется входящий файл обмена данными. В этом случае, достаточно указать полный путь к входящему файлу обмена данными. Программа периодически анализирует наличие файла, и как только он появится, будет выполнен обмен, а после обмена этот файл будет принудительно УДАЛЕН (это делается для того, что бы процедура обмена не выполнялась постоянно),
* Периодический обмен данными. Обмен будет выполняться согласно настройкам периодического обмена данными. Если информационная база работает в файл-серверном режиме, то периодический обмен выполняется только у пользователя, который указан в параметрах учетной политики как "Пользователь для регламентных заданий в файловом режиме". В Клиент-серверном варианте обмен выполняется на сервере 1C:Предприятия.

У меня Клиент-серверный вариант - для работы регламентного автообмена пришлось перегружать сервер

2. Кодировка Windows.
Обмен прерывался ошибкой - так как не происходит сжатие файла. Это из-за ошибки кириллицы в командной строке при сжатии.
Лечится исправлением кодировок в реестре.
Например, для Windows Server 2008 -
Код

REGEDIT4
"1250"="c_1251.nls"
"1251"="c_1251.nls"
"1252"="c_1251.nls"
"1253"="c_1251.nls"
"1254"="c_1251.nls"
"1255"="c_1251.nls"

3. Создавая копию базы (например, для доработки) в клиент-серверном варианте, НЕОБХОДИМО, чтобы РЕГЛАМЕНТНЫЕ ЗАДАНИЯ КОПИИ базы были ВЫКЛЮЧЕНЫ. Блокировка регламентных заданий для копии ВКЛ

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