Журнал PC Magazine/RE №11/2011

Для каких задач автоматизации может потребоваться такой механизм? Вот несколько типичных примеров.

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

Пример второй – компания предоставляет услуги аренды ПО по модели SaaS («software as a service», программное обеспечение как услуга). В качестве прикладного решения используется одна из типовых или отраслевых конфигураций «1С: Предприятия». Например, бизнес-центр может предложить своим арендаторам функциональность прикладного решения «Управление небольшой фирмой», полностью взяв на себя заботы о серверном оборудовании, поддержке работоспособности, регламентном обслуживании, установке новых версий конфигурации и т. д. Пользователями прикладного решения являются посторонние друг для друга организации – они, разумеется, должны иметь доступ только к своим собственным данным.

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

Следует заметить, что в приведенных примерах, кроме, пожалуй, первого, собственно разграничение доступа к данным не является единственным, и, возможно, даже главным требованием. Это требование, по мнению автора, наиболее очевидно с точки зрения потребностей бизнеса, но с технической точки зрения не менее важно требование обеспечения такой архитектуры прикладного решения, при которой деятельность одного абонента не будет создавать технологических противоречий и помех деятельности других абонентов.

Нельзя сказать, что подобные задачи на платформе «1С: Предприятие» вообще невозможно было решить без специального механизма разделения данных. Разграничение доступа реализовать можно было и ранее, причем двумя принципиально разными способами.

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

Это действительно очень простое решение, но оно обладает рядом серьезных недостатков. Во-первых, поддерживать и администрировать множество информационных баз значительно сложнее и дороже, чем одну. Во-вторых, регламентные процедуры (например, обновление индекса полнотекстового поиска или резервное копирование) также будут выполняться в каждой информационной базе, а это создаст дополнительную нагрузку на оборудование. В-третьих, практически всегда существуют какие-то общие для всех пользователей данные (в простейшем случае – классификатор банков и адресный классификатор). Эти данные необходимо хранить и поддерживать в актуальном состоянии в каждой информационной базе, как следствие – нужно будет позаботиться о синхронизации (не говоря о том, что разместить одну и ту же таблицу КЛАДР в сотнях баз данных явно не очень хорошая идея с точки зрения эффективного использования аппаратных ресурсов).

Архитектура множественной аренды