Структура и технология работы 1С:УРБД
Управление распределенными базами данных (УРБД) - компонент системы программ 1С:Предприятие 7.7. Инструмент, предназначенный для работы базы данных в распределенном пространстве. При помощи этого механизма решается много разных задач, таких как работа удаленного склада, консолидация информации с филиалов, работа бухгалтера на дому (для плохих бухгалтеров, дома надо отдыхать :-)), еще много всего.
Остановимся на внутреннем устройстве системы и возможностях, лежащих за пределами задекларированных производителем.
Информация в системе организована довольно просто. Это обусловлено простотой механизма и ориентацией всего 1С:Предприятия 7.7 на небольшие фирмы, у которых даже сетевик приходящий, не говоря об администраторе баз данных. Все должно быть предельно просто, функционально ограничено и иметь минимальную возможность ошибки. ER-диаграмма схемы данных приведена на рис.1.
Основная таблица, содержащая описаня баз данных, участвующих в обмене - _1SDBSET. Ниже приведен перечень ее основных полей.
DBSIGN Код базы данных
DBDESCR Описание
DBSTATUS Статус базы. M-центральная, C-периферийная
DBUUID GUID базы. Уникальный идентификатор базы, присваемый при создании.
В принципе, достаточно. Остальные поля настроечные - в них хранятся имена файлов обмена, признаки установленного автообмена, адреса и все такое. Всеми этими параметрами можно спокойно управлять с конфигуратора. Следует отметить, что в центральной базе в этой таблице хранится перечень всех баз данных информационного пространства, в периферийной - только себя и центральной.
Следующая таблица, играющая немаловажную роль в работе механизма - _1SSYSTEM Это таблица, в которой хранятся данные об общих настройках базы, таких как точка актуальности, дата рассчитанных бухгатерских итогов, etc. В частности, УРБД касаются такие поля:
DBSIGN Код этой базы
DBSETUUID GUID информационного пространства
Вот и все, касаемо настройки базы данных. Удалите данные из таблицы _1SDBSET - база станет центральной. Удалите поле DBSIGN в таблице _1SSYSTEM, а поле DBSETUUID забейте ноликами вместо чисел - она станет еще и нераспределенной (вопреки предупреждению, выдаваемому системой при распределении базы данных). Манипулируя этими полями, с распеределенным информационным пространством можно делать практически что угодно - переподчинить базу другой базе, переподчинить базу другому информационному пространству.
Таблица, в которой буферизируются изменения - _1SUPDTS. Очень полезная таблица, применять ее можно в задачах, лежащих за областью применения УРБД. Например, одно из моих решений в области аналитических систем для пополнения своей базы данных из базы 1С пользуется именно этой таблицей. В базе-источнике 1С заведена фиктивная периферийная база данных, изменения, которые отражены в этой таблице, обрабатываются уже моим механизмом, для которого важно иметь информацию об измененных с последнего импорта данных объектах.
DBSIGN Код базы, для синхронизации с которой записывется изменение
TYPEID ID типа объекта
OBJID ID объекта
DELETED Признак физического удаления объекта
DWNLDID ID сессии УРБД
При любом изменении объекта система добавляет в таблицу запись для каждой базы данных, в которую должны эти изменения отправиться. Если объект физически удален, в поле DELETED пишется флажок D. В поле TYPEID записывается идентификатор типа объекта (это число, которым идентифицирован объект в конфигураторе), в поле OBJID - идентификатор самого объекта. При выполнении сеанса УБРД все записи из буфера выгружаются в текстовый файл в определенном формате. В поле DWNLDID записывается идентификатор сессии для записей, в которых этот идентификатор не проставлен. Таким образом, в каждую выгрузку уходят все записи, подтверждение приема которых не поступало. При получении подтверждения сесии, идентификатор которой записан в это поле, или любой другой последующей сессии, запись из буфера удаляется.
Последняя, и самая неинтересная таблица - _1SDWNLDS. В ней собрана информация о незакрытых (неподтвержденных) сессиях обмена УРБД в разрезе баз данных. При приходе первого же подтверждения приема данных записи обо всех сесиях, подтвержденной и предыдущих, удаляются.
Пакет обмена данными - zip-архив, в котором содержатся 2 или 3(если изменялась конфигурация в центральной базе) файла. Файл 1Cv77Dld.id несет в себе информацию о сессии обмена. Содержит единственную строчку
{"Download ID",A37F7532-5939-42F1-BEC8-3FEABB70A128,"EKC",CE395095-F690-42B0-B954-0B99208FC947,"ECM",D76EE5A2-B06E-4E03-8B05-F81138819F59,"2184|EKC"}
A37F7532-5939-42F1-BEC8-3FEABB70A128 GUID сессии обмена данными
"EKC" код базы-отправителя
CE395095-F690-42B0-B954-0B99208FC947 GUID базы-отправителя
"ECM" код базы-получателя
D76EE5A2-B06E-4E03-8B05-F81138819F59 GUID базы-получателя
"2184|EKC" ID сессии обмена данными
Эта же информация повторяется в файле с данными. Назначение этого файла для меня до сих пор загадка, видимо он служит для того, чтобы при попытке обработать старый файл быстро, не открывая большого файла с данными, выругаться, что файл уже принимался системой. Файл 1Cv77Chs.dat несет в себе информацию, которая подлежит синхронизации. Состоит из нескольких узлов. В первом узле, без названия, повторяется информация с файла 1Cv77Dld.id. Во втором - "Distributed data" - расшифровывается эта информация. Не знаю зачем, видимо для улучшения читаемости. Важен подузел этого узла Acknowledgements, который несет подтверждение приема предыдущих выгрузок. Далее идет информация об измененных объектах системы, а именно:"Constants", "References","Documents", "Accounts", "Template Operations" (константы, справочники, документы, счета и типовые операции, соотв). После узлов, несущих информацию об измененных объектах, идут узлы с информацией об удаленных "Deleted References","Deleted Documents","Deleted Accounts","Deleted Template Operations" Информация в файле структурирована имеет древовидную структуру, где ветки отделены знаками {}, а листья "". Путем довольно несложных операций по замене/вставке символов легко преобразуется в XML, с которым можно работать из любого языка программирования, либо поддерживающего OLE, либо имеющего собственный анализатор XML.
Механизм работает очень просто. Система на своем уровне регистрирует изменения в буфере, потом формирует файл выгрузки. Файл выгрузки содежрит в себе информацию о текущей сессии, подтверждение принятия предыдущих файлов обмена, и информацию об измененных и удаленных объектах. При приеме файла выгрузки система удаляет информацию о подтвержденных сессиях, загружает измененные объекты и удаляет удаленные. При удалении удаленных объектов проверяется ссылочная целостность, и если она нарушается - объект не удаляется, а отмечается как измененный. При формировании ответной выгрузки объект, удалить который не удалось, уедет по-новому, как измененный, и успешно загрузится в базу данных. В принципе, по технологии работы все. Инструмент доступен и серьезен :-), как и все продукты этого производителя.
Коллизии, или конфликты распределенной обработки данных есть везде, где есть оная обработка. Их можно минимизировать, их можно успешно разрешать, но от них никуда не денешься. Порой они могут приносить достаточно много проблем. В УРБД принят метод разрешения коллизий с приоритетом центральной базы данных. Таким образом, при конфликте изменения, сделанные в периферийной базе, затираются, и принимаются изменения в центральной. Это несколько неправильно, особенно неправильно то, что этот метод прошит жестко и не поддается настройке штатными средствами. На мой взгляд, более логичным было бы сделать приоритетными изменения, сделанные в базе, откуда родом объект, (я молчу про пользовательскую настройку метода разрешения конфликта для каждого типа объектов). В принципе, возможна реализация пользовательского менеджера разрешения конфликтов. Но это уже выходит за рамки статьи.
Иногда по непонятным причинам крошатся настройки распределенной базы данных. На моей практике такое встречалось несколько десятков раз. Симптомами слета настроек является внезапное поведение периферийной базы данных, как центральной, непринимание файла выгрузки как файла из неизвестной базы, etc. В этом случае наиболее простой выход из ситуации - держать первые (инициализационные) выгрузки периферийных баз, и выгрузку центральной сразу после распределения. В случае слета настройки базы необходимо заново загрузить соответствующую выгрузку и перенести информацию, касаемую УРБД в сбойную базу. Если же этого файла нет - тоже ничего страшного. Информация о настройках описана в этой статье и идет в файле обмена данными.
Пользоваться встроенными механизмами передачи данных 1С (почтовая рассылка) я не рекомендовал бы. У него есть ряд огромных недостатков.
Он шлет некриптованные файлы. Защита файла при помощи пароля архиватора ничего, кроме улыбки, не вызывает.
Он шлет файлы только по одному адресу.
Он их не всегда шлет, равно как и не всегда забирает.
Операционной системе необходимо иметь прописанного почтового клиента по умолчанию.
В случае незакрытой кем-то пользовательской сессии обмен просто не выполнится
И еще много всего
Поэтому, если Вы желаете наладить безлюдный автообмен информацией - лучше напишите (или закажите) скрипты, которые это делают без приведенных мною недостатков.
Механизм выгрузок/загрузок информации УРБД - самый надежный механизм, который я видел реализованным в 1С. Но иногда и он дает сбои. На моей практике я замечал порядка десяти дублирований данных, и столько же - недоставаний их. Практика у меня обширная, как по времени, так и по количеству распределенных баз, которые случалось организовывать и обслуживать, поэтому приведенную статистику можно считать ничтожной в процентном отношении. Но забывать про нее тоже нельзя. Посему я рекомендую проводить сверку на предмет количества записей в таблицах периферийной и центральной баз данных. В регулярные регламентные работы эту можно не включать, но будет гораздо приятней, если этот сбой заметите Вы, а не разгневанный пользователь.
Из описанных мною подводных камней системы самый страшный - когда при проектировании бизнес-логики распределенной системы не учитывали ее распределенность, особенно если назначение системы - не простая консолидация данных самостоятельных бизнес-единиц, а автоматизация одной, но распределенной, например, задачи автоматизации удаленного склада, магазина, или отдела продаж. Приятно наблюдать округленные глаза девочки, которая обнаружила изменения в своем документе после сеанса УРБД, который поменяла на свой вкус другая девочка, и, естесственно, забыла об этом сказать. Еще хуже, когда это изменение сразу не замечено, а обнаружено впоследствии, при инвентаризации, например. Несмотря на то, что проблема выходит за рамки предметной области распределенных баз данных, а в равной степени касается и обычных многопользовательских систем, поверьте - изрядная доля шишек будет сыпаться на механимз и должностное лицо, ответственное за его поддержку. Поэтому, если у Вас на УРБД работает офис и удаленный склад - не надо заводить и проводить расходную накладную менеджеру в центре. В свою очередь, если ее не проводить - есть все шансы продать уже проданный товар несколько раз. Решает вопрос уже прикладной механизм резервирования, а также цепочка документов приказ на выдачу/выдача, вместо всеобемлющей расходной накладной.
Управление распределенными базами данных от 1С - для 1С:Предприятие 7.7 лучшее, на мой взгляд, решение для организации собственно распределенных баз. Такие недостатки, как ограниченная функциональность, невозможность фильтровать объекты для миграции по определенному значению полей, невозможность организации системы по принципу "снежинка" довольно просто и дешево устраняются несложным вмешательством в системные таблицы и файлы обмена данными. Экплуатационные ошибки и сбои системы - во-первых, я еще не видел бессбойных систем, во-вторых, нормально налаженный процесс администрирования минимизирует последствия этих сбоев практически до нуля. Ибо знаемая и задокументированная ошибка - не баг, а фича. В целом, деньги, которые стоит компонента, она отрабатывает полностью.
Оригинал статьи, см. здесь
