Организация репликации между филиалами

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

Стандартный способ

На базовом уровне есть механизм задания фильтров для репликации, использующий поле «КодФилиала». Данное поле, имеющее тип «String» введено во все записи ТБ.Корпорации. В этом поле через запятую перечисляются названия (коды) филиалов, которым «принадлежит» данная запись, например: «Центр,Филиал 1,Филиал 2». Поле может быть пустым.

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

Для того, чтобы работать с данным справочником (через бланк-меню «Настройки ТБ.Корпорации», кнопка с молоточками на инструментальной панели ТБ.Управления), нужно, чтобы текущий пользователь обладал привилегией «Разрешена настройка списков филиалов», которая устанавливается в карточке прав пользователя, на странице «Настройки».

В настройках сервера указывается текущий филиал - ссылка на элемент справочника филиалов. Именно это значение используется по умолчанию для вновь создаваемых документов на данном сервере. Другими словами, насервере каждого филиала нужно произвести настройку, выбрав соответствующий ему элемент из справочника филиалов. Возможность сделать это также регулируется правом «Разрешено настраивать списки филиалов» в типе рабочего места.

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

Поле «КодФилиала» можно применять при задании фильтров репликации, используя функцию Match. Поскольку данное поле является строковым, никаких проблем, связанных с заданием DocID, не возникает. Также данное поле может использоваться для фильтрации записей в правах доступа.

Для справочников реализована групповая простановка поля «КодФилиала» по иерархии - когда данное поле вручную меняется у группы, программа предложит продублировать его во все нижележащие записи.

Дополнительные замечания по описанным механизмам:

  1. Поскольку при наложении фильтра по полю «КодФилиала» фильтрация будет идти по имени филиала, следует выбирать их таким образом, чтобы при работе функции Match не возникало разночтений. Например, не следует называть филиалы «Филиал Городок» и «Филиал Городок Дополнительный» - в этом случае непонятно, принадлежащие к какому именно филиалу записи должны быть выбраны по маске «*Филиал Городок*».
  2. Изменение наименования филилала в справочнике не приводит к изменению значения полей «КодФилиала» в других записях. Поэтому желательно с самого начала выбрать имена филиалам и задним числом их не менять.
  3. Запись МашинаРеквизитов.Настройки.ПараметрыСервера, в которой хранятся настройки сервера, не следует реплицировать - по смыслу в этом справочнике должны храниться разные значения на разных серверах.
  4. Поле «Код филиала» существует у всех записей, но не для всех его нужно использовать при репликации. Например, нет смысла фильтровать таким образом записи структуры бизнеса - они должны быть едиными. Использовать данное поле или нет - зависит от задачи, решаемой настройщиком.

Собственный способ нашего партнера

Вообще говоря, «собственных» способов неограничено много. Однако один из них наиболее распространен. Суть его заключается в следующем. При построении холдинговых схем практически всегда отдельные предприятия выделяются в отдельные папки, в которых хранится вся информация, необходимая для деятельности конкретного предприятия. Это может относиться не только к записи «управление.данные.процесс», но и любому другому справочнику. Данный факт разделения по папкам как раз и используется при задании фильтров и опять же с использованием «Match». Например фильтр может выглядеть так, »…Match(GroupPath,»12.334.*»)…». Минус у этого метода один - он использует информацию о docid (GroupPath), которая, как известно, не является статической, однако на практике все проще - обычно речь идет о каких-то градообразующих группах, которые никогда не изменяются, что позволяет с успехом применять описанный метод.

Замечания

  1. Не нужно реплицировать таблицы «Сис2.Настройки.Семафор» и «Сис2.Настройки.Нумератор» - очевидно, что они должны быть разными на разных серверах.
  2. Обычно не реплицируются таблицы «Kernel.Macroses.*» и «Kernel.Fixed.*», так как там хранятся данные закрытых периодов, которые вероятно на разных серверах разные.
  3. Часто стоимостные показатели не имеет смысла видеть в отдаленных точках, поэтому в таких схемах реплицировать учетные цены и соотвественно рассчитывать стоимостные показатели не нужно. Если есть такая возможность - то лучше ей воспользоваться хотя бы из соображений быстродействия, т.к. этот справочник порой достигает внушительных размеров. При этом нужно не забыть снять репликацию с полей, ссылающихся на справочник учетных цен, например с поля «управление.данные.процесс.позиции.учценаоткуда».
  4. Не нужно реплицировать подтаблицы записи «управление.справочники.функции», хранящие компилированную структуру метаданных. Это не имеет смысла (по крайней мере пока) и может приводить к ошибкам, т.к. компиляция основана на использовании docid реквизитов, а они, как известно, на разных серверах разные.
  5. Если в настройках структуры бизнеса включен флаг условной компиляции функций, то при репликации изменений записи «управление.справочники.функция» на принимающем сервере функции необходимо перекомпилировать (см.предыдущее замечание).
  6. При настройке схем репликации возникает вопрос насколько часто можно обмениваться репликами. В принципе ограничений нет, в реальной практике настраивались и схемы с 5-минутным интервалом. Но с технической точки зрения оптимальным вариантом является обмен один раз в сутки в нерабочее время.
 
doc/repl_filial.txt · Последние изменения: 2016/04/15 15:26 (внешнее изменение)
 
За исключением случаев, когда указано иное, содержимое этой вики предоставляется на условиях следующей лицензии:CC Attribution-Noncommercial-Share Alike 3.0 Unported
Recent changes RSS feed Donate Powered by PHP Valid XHTML 1.0 Valid CSS Driven by DokuWiki