1. Администрировать и поддерживать нужно только одну информационную базу.
2. Все регламентные процедуры выполняются только в одной информационной базе, не создавая лишней нагрузки на оборудование.
3. Общие данные не дублируются и всегда актуальны для всех пользователей.
4. Для «консолидированных» операций над полной совокупностью данных не требуется выполнять постоянную синхронизацию, и данные не дублируются.
При этом пользователи-абоненты имеют доступ только к «своим» данным и могут даже не подозревать о наличии в системе данных других пользователей. Такая архитектура называется «multitenancy» (множественная аренда) – единый экземпляр прикладного решения обслуживает множество независимых абонентов.
Собственно, именно такую архитектуру и обеспечивает новый механизм разделения данных, реализованный в версии 8.2.14 «1С: Предприятия». В чем же заключается принципиальная разница? Принципиальная разница – в технической реализации разграничения доступа.
Механизм RLS в «1С: Предприятии» работает следующим образом: для совокупности сущностей «объект метаданных, роль, право доступа» разработчик конфигурации описывает дополнительные ограничения доступа к данным. Ограничения описываются на языке запросов и могут представлять собой довольно сложные конструкции. При работе пользователя с объектами данных информационной базы стандартные запросы, выполняемые платформой в СУБД, дополняются запросами RLS. Например, если в RLS задано ограничение «роль Кладовщик имеет право чтения документа Накладная только в том случае, если пользователь прикреплен к нужному складу», в любой запрос СУБД, выполняющий чтение соответствующих таблиц, будет добавляться соответствующее условие.
Этот механизм был реализован еще в «1С: Предприятии 8.0», и он весьма эффективен при правильном применении по назначению – в тех случаях, когда требуется ограничить доступ некоторых пользователей к некоторым объектам данных по некоторым, причем весьма разнообразным в разных случаях, правилам. Скажем, менеджер по продажам имеет доступ на изменение только своих сделок, или руководитель подразделения не имеет права читать ежедневные отчеты сотрудников других подразделений.
Настройка разделителя данныхНо в нашем случае придется установить RLS-ограничения на доступ всех пользователей ко всем объектам данных. На практике это означает следующее:
1. Потребуется выполнить огромный объем работ по настройке, отладке и тестированию RLS-ограничений практически для каждого объекта метаданных конфигурации (а они могут измеряться многими сотнями).
2. Нагрузка на СУБД при выполнении запросов к данным, «обернутым» RLS-ограничениями, существенно увеличивается. Как следствие – падает производительность при параллельной работе множества пользователей.
Новый механизм разделения данных позволяет полноценно реализовать multitenancy-архитектуру прикладного решения, когда разграничивается не только доступ к данным информационной базы, но и использование других механизмов технологической платформы.
Подробный технический разбор механизма разделения данных выходит за рамки статьи, поэтому мы рассмотрим только наиболее важный, с нашей точки зрения, момент – ограничение доступа к данным. В отличие от RLS, при использовании механизмов разделения данные информационной базы разделяются на области без внесения существенных изменений в конфигурацию и практически без потерь производительности. Благодаря чему это достигается?
1. В платформе появился новый объект метаданных – общий реквизит. Такой реквизит может быть включен в состав практически любого прикладного объекта, отвечающего за хранение данных (справочник, документ, план счетов, бизнес-процесс и т. д.), установкой одного флажка.
2. У общего реквизита есть свойство «Разделение данных», установка которого превращает общий реквизит в разделитель данных. Соответственно все прикладные объекты, включенные в состав общего реквизита, также переходят в режим разделения данных.
3. В конфигурации может быть определено любое количество разделителей, причем для каждого можно настроить условие, при котором он считается действующим. Соответственно можно реализовывать сколь угодно гибкие схемы выделения и изоляции областей данных внутри информационной базы. Причем как для уникальных решений, так и для тиражных, которые должны уметь переключаться между разделяемым и автономным режимами без изменения конфигурации, посредством параметрической настройки.
4. В отличие от механизма RLS, который оперирует ограничениями конкретных прав доступа для конкретных ролей (скажем, можно запретить чтение, но разрешить изменение объекта), логика механизма разделения данных значительно проще: объект или входит в область данных, доступную пользователю, или не входит.
5. Структура хранения разделителей данных в СУБД спроектирована таким образом, чтобы оказывать минимальное влияние на производительность параллельной работы множества пользователей с разделенными данными.
Следует уточнить, что механизм разделения данных никоим образом не подменяет механизмы ролей, прав и ограничений доступа, а дополняет их. Если объект входит в область, доступную пользователю, но пользователь не обладает необходимой ролью и/или не выполняется условие соответствующего ограничения RLS – доступа к объекту пользователь не получит.
Отдельно следует отметить разделение пользователей информационной базы. Разделители данных можно настроить таким образом, что пользователю будет доступна только та часть общего списка пользователей информационной базы, которая принадлежит к доступной области данных. Более того, если задействовать свойство «Разделение аутентификации», то в разных областях данных можно создавать одноименных пользователей – при обычной практике «именем пользователя в базе является его фамилия, иногда дополненная инициалами», такое свойство разделителя данных представляется крайне полезным.
Внешние источники данныхДругое важное новшество версии 8.2.14 – механизм доступа к данным внешних источников. Наверное, нет необходимости приводить конкретные примеры задач, в которых реализовано получение информационной базой «1С: Предприятия» данных «извне». Задачи вида «прочитать из Excel», «прочитать из Access», «прочитать из Oracle» возникают практически на любом предприятии, причем часто задача формулируется не просто «прочитать и записать в базу», а «выполнять регулярное чтение и использовать прочитанные данные в логике расчетов и/или в качестве базы для формирования отчета».
Открытие форм в закладкахРазумеется, и в предыдущих версиях «1С: Предприятия» была возможность обратиться к внешнему источнику данных (будь то файл или СУБД) и получить оттуда любую доступную информацию. Если к внешнему источнику можно обратиться через какой-либо интерфейс (COM, ADODB, etc.), значит, из него можно получить данные. Выполнение таких задач никогда не было трудным, но всегда было трудоемким, поскольку все манипуляции с внешним источником нужно было выполнять «из кода». Многие программисты в процессе работы над задачами интеграции даже обзаводились собственными небольшими «библиотеками полезных и универсальных функций», упрощающими написание прикладного кода для работы с внешними данными (у автора, например, имеется подобная библиотека для взаимодействия с базами данных Oracle). Но даже такая тривиальная задача, как «прочитать из Oracle таблицу начислений, сопоставить с ней остатки по регистру задолженности и вывести результат в виде отчета», требовала написания огромного количества кода, а зачастую и полного дублирования внешних данных в информационной базе.
Начиная с версии 8.2.14 взаимодействие с внешними источниками данных поддерживается платформой «из коробки». Появился специальный объект метаданных, при помощи которого в конфигурации можно описать состав таблиц внешнего источника (для доступа к внешним данным платформа использует механизм ODBC). Появились соответствующие объекты и методы встроенного языка, а также возможность «бесшовного» вывода внешних данных в формах и динамических списках; на внешние данные даже можно накладывать ограничения прав доступа. Но самое главное – появилась возможность использовать внешние данные в запросах «1С: Предприятия» и схемах компоновки данных.
Разумеется, лучше всего это новшество оценят программисты, которым больше не потребуется каждый раз изобретать объекты для хранения структуры и содержимого таблиц внешних баз данных и вручную описывать всю логику работы с ними.
Но следует признать, что «немного счастья для программиста» – это и вполне конкретные выгоды для бизнеса. Меньше рабочего времени на рутинные операции, меньше ошибок, лучшая переносимость, лучшая сопровождаемость, стандартизация подхода – в совокупности это означает, что решение задач интеграции «1С: Предприятия» с внешними системами становится значительно проще и дешевле.
Необходимо также отметить, что механизм внешних источников данных позволяет использовать платформу «1С: Предприятие» в качестве генератора отчетов и средства визуализации данных других информационных систем.
Развитие интерфейсной моделиПоследнее (по перечислению, но не по важности) крупное новшество версии 8.2.14 – дальнейшее развитие интерфейсной модели управляемого приложения и появление нового режима отображения открытых форм.
Предыдущие версии «1С: Предприятия» в режиме управляемого приложения поддерживали только один режим открытия формы – каждая форма открывалась в отдельном окне и отдельно отображалась в Панели задач ОС. Такой режим вызвал у пользователей определенные нарекания, и следует признать, что не всегда эти нарекания были связаны с непривычностью принципиально новой, по сравнению с версией 8.1, интерфейсной модели. Модель «одна форма – одно окно» действительно удобна во многих типовых сценариях работы операторов (например, «открыл список, нашел контрагента, создал счет, подобрал товар, записал и закрыл»). Но когда приходится одновременно работать в нескольких информационных базах, особенно если эти базы идентичны по конфигурации и при этом требуется держать отк