Синхронизация «ведущих» объектов распределенной информационной базы происходит в процессе обмена файлами переноса данных, в промежутках между обменами каждая ИБ работает автономно. Это может привести к тому, что созданному на одной из ИБ документу будет присвоен уникальный в пределах данной ИБ номер, который окажется не уникальным для всей распределенной информационной базы в целом. В таком случае, после обмена файлами переноса данных, в распределенной ИБ могут образоваться два (или больше) документа с одинаковыми номерами, даже если в свойствах номера документа установлены признаки «Контроль уникальности» и «Автоматическая нумерация». Аналогичная ситуация может возникнуть и для кода вновь созданного элемента справочника.
Рекомендуемый способ решения этой проблемы состоит в использовании префиксов номеров документов и кодов элементов справочников. В свойствах номера или кода при конфигурировании следует установить тип «Текстовый». В качестве префикса можно использовать значение локальной константы или код информационной базы. В случае использования локальной константы следует обеспечить уникальность ее значения для каждой ИБ в пределах распределенной ИБ. Если используется код информационной базы, уникальность обеспечивается автоматически, так как в одной информационной базе не может быть двух ИБ с одинаковым кодом - система следит за этим.
Для документов и справочников, имеющих свойство миграции «Место создания», обеспечивать уникальность номера или кода в пределах всей распределенной информационной базы не обязательно.
Пример:
// Установку префиксов производим в процедуре
// ПриКачалеРаботыСистемы глобального модуля
Процедура ПриНачалеРаботыСистемы() // Установка префиксов автонумерации
КодИБ = ТекущаяИБКодО ; // Использование кода ИБ ПрефиксАвтоНумерации("Справочник.Тов7'
// Использование значения локальной :•.
ПрефиксАвтоНумерации( "С-' --.--•--."•/ '•••-
Константа. Т.о'т ~ /I Использование кода :::
ПрефиксАвтоНумерации(•Г
КонецПроцедуры
Компонента «Управление распределенными ИБ» обрабатывает спорные ситуации, возникающие в процессе работы распределенной информационной базы (см. «Принципы разрешения спорных ситуаций»). Однако возникновение коллизий остается нежелательным и их, по возможности, следует избегать.
Спорные ситуации не будут возникать в том случае, если редактирование и удаление «ведущего» объекта доступно только на одной из ИБ распределенной информационной базы. Достичь этого можно несколькими путями.
Метод состоит в создании пользовательских интерфейсов, которые дают доступ только к «безопасным» с точки зрения возникновения коллизий командам системы. Например, интерфейс дает возможность пользователю только вводить новые документы. К сожалению, даже такие ограничения не являются гарантией от возникновения спорных ситуаций (см. ниже).
При использовании данного метода следует иметь в виду, что:
• доступ к корректировке и удалению «ведущих» объектов можно получить не только через пользовательский интерфейс. Например, если документ имеет реквизит типа «Справочник», то при вводе нового документа будет вызвана форма списка справочника, пользователь получает доступ к редактированию и удалению его элементов, и интерфейс перестает быть «безопасным»;
• метод не позволяет разрешать редактирование и удаление данных выборочно, в зависимости от ИБ, на которой выполняется 1С:Предприятие;
• па всех ИБ, кроме одной, должны быть зарегистрированы пользователи, имеющие только «безопасные» интерфейсы, что не всегда возможно в реальной ситуации;
• интерфейсы являются частью конфигурации и мигрируют все вместе, как «безопасные», так и «небезопасные». Поэтому, разработчик конфигурации не гарантирован, что администратор системы не назначит пользователям двух и более ЦБ, входящих в состав распределенной И Б, «небезопасные» интерфейсы.
Таким образом, применение данного метода накладывает существенные ограничения, он может быть рекомендован лишь в Простых случаях.
Настройка прав доступа к данным является более гибким средством для предотвращения коллизий, чем настройка пользовательских интерфейсов. Обеспечив с их помощью ситуацию, в которой любой «ведущий» объект системы может быть отредактирован или удален не более чем на одной ИБ, администратор добьется предотвращения возникновения коллизий.
Применение данного метода позволяет избежать некоторых ограничений, накладываемых методом настройки пользовательских интерфейсов. Однако следует иметь в виду:
• метод не позволяет разрешать редактирование и удаление данных выборочно, в зависимости от И Б, на которой выполняется 1 С:Предприятие;
• права доступа являются частью конфигурации и мигрируют все вместе, как «безопасные», так и «небезопасные». Поэтому разработчик конфигурации не гарантирован, что администратор системы не назначит пользователям двух и более ИБ, входя щи в состав распределенной ИБ, «небезопасные» права;
• возможность возникновения коллизий определяется не составом ИБ (что можно считать постоянным), а составом условно одновременно работающих пользователей (а, точнее, совокупность их прав доступа к данным). В силу этого обстоятельства безопасность зависит не от разработчика, а от администратора.
Заметим, что проблему с администрированием системы на периферийной ИБ можно решить, используя возможность проверки в глобальном модуле при запуске системы набора прав, с которым пользователь входит в систему: то есть в конфигурации можно исключить возможность запуска системы на периферийной ИБ с набором прав который не содержит требуемых ограничений. Возможность защит! конфигурации паролем позволяет предотвратить также и возможны случаи умышленной попытки обойти это ограничение на периферий ной ИБ.
Этот метод является наиболее гибким, а в ряде случаев, и мене трудоемким для разработчика, чем перечисленные выше. Суть его сводится к установке обработчиков действий пользователя, связанны с редактированием и/или удалением «ведущих» объектов, и, на основании доступной с помощью специальных функций информации принятия решения о разрешении или запрещении этого действия.
В таблице приведены некоторые примеры системных предопределенных процедур, предназначенных для «перехвата» действий пользователя.
|
Процедура |
Перехватываемое действие |
|
ПриУдаленииДокумента |
Удаление пользователем документа |
|
ПриУдаленииЭлемекта |
Удаление пользователем элемент справочника |
|
ПриУдаленииСчета |
Удаление пользователем бухгалтерского счета |
|
ПриЗаписиКонстанты |
Изменение значения константы |
|
ПриОткрытии |
Открытие формы элемента справочника, документа или счета. Функция Выбран() должна вернуть 1, если форма открывается для редактирования. |
Описание этих процедур, а также процедур и функций, приведенных ниже, смотрите в книге «1С:Предприятие. Описание встроенного языка».
Запретить или разрешить перехваченное действие пользователя возможно на основании обширного набора информации:
• место создания объекта;
• И Б, на которой исполняется 1:Предприятие;
• используемый интерфейс пользователя:
• название прав доступа.
Также допустимо использование любой комбинации этих данных, что обеспечивает максимальную гибкость в настройке конфигурации для исключения коллизий.
Запретить выполнение перехваченного действия можно с помощью процедуры СтатусВоз врата с параметром 0 (ноль). Если эту процедуру использовать в системной предопределенной процедуре ПриОткрытии, то форма не откроется вообще, для открытия формы только для просмотра используйте процедуру ТолькоПросмотр с параметром 1.
Примеры:
// Корректировка значения константы "Директор" разрешено
// только на центральной ИБ
Процедура ПриЗаписиКонстанты( Наин, Знач)
Если (ТекущаяИБЦентралькая() -= 0) И (Наим - "Директ- ,"'' Тогда
Сообщ ^ "Имя директора можно поменять только в центре!*;
Предупреждение(Сообщ, 2);
СтатусВозврата(0);
КонецЕсли;
КонецПроцедуры
Как уже отмечалось ранее, вводя ограничения Миграции «ведущих» объектов, следует четко представлять себе последствия, к которым это может привести. При этом нужно обратить внимание на следующее.
Ссылочная целостность. «Ведущие» объекты, имеющие ссылки, как правило, имеют равную или более ограниченную миграцию, чем объекты, на которые имеют ссылку.
Особые свойства объекта типа «Документ». Миграция объектов типа «Документ» происходит вместе со всеми изменениями, произведенными им. Обычно, объекты, используемые в изменениях (например, измерения регистров или реквизиты проводок, используемых документом при проведении) должны иметь миграцию, большую или равную миграции документа.
Особые свойства объекта типа «Счет». Миграция объектов типа «Счет» настраивается для всего плана счетов в целом. Кроме того, счета, заданные в метаданных, распространяются на все периферийные ИБ вне зависимости от свойств миграции.
Заметим, что, в отличии от других объектов, свойства объектов типа «Счет» оказывают сильное влияние на другие данные - бухгалтерские операции и бухгалтерские итоги. Изменение настроек учета счетов (валютного, количественного, аналитического учета) влечет за собой пересчет бухгалтерских итогов и, если необходимо, корректировку проводок. Кроме того, счета в плане счетов более взаимосвязаны, чем, например, элементы справочника, и образуют целостную систему.
Вследствие этого, имеет смысл с особым вниманием отнестись к настройке свойств миграции и прав доступа планов счетов. В большинстве случаев рекомендуется средствами конфигурации запретить изменение счетов на периферийных информационных базах (при этом в свойствах миграции можно установить режим «Все информационные базы»).
