При использовании «Лицензии для разработчика» (известной также как 1С:Предприятие через комьюнити-аккаунт) у специалистов часто возникает вопрос о безопасности её сосуществования с промышленными (продуктовыми) базами. Основное опасение заключается в том, не «испортится» ли рабочая база и не заблокируется ли работа всей организации. Разберем эту ситуацию подробно, опираясь на технические алгоритмы платформы 1С.
Сразу успокоим: физически с данными в информационной базе ничего не случится. Подключение под лицензией разработчика не вносит изменений в структуру таблиц SQL или файловую базу. Однако техническое поведение сервера 1С:Предприятия изменится. Рассмотрим, в чем именно это выражается. Как только в информационной базе регистрируется хотя бы один сеанс, использующий лицензию разработчика, платформа включает жесткое ограничение: не более трех одновременных подключений к этой базе.
Проанализируем последствия: если в вашей рабочей базе уже находятся 50 пользователей под лицензиями ПРОФ или КОРП, и вы заходите 51-м под лицензией разработчика, сервер не выбросит текущих сотрудников мгновенно. Однако он перестанет пускать новых пользователей и выдаст ошибку: «Операция не может быть выполнена с текущим составом лицензий...». Это ограничение будет действовать до тех пор, пока количество активных сеансов не опустится ниже трех. Выясним причину такого поведения: в лимит «три сеанса» включаются не только обычные пользователи (тонкие и толстые клиенты), но и конфигуратор, фоновые задания, а также внешние соединения через COM или Web-сервисы.
Многие полагают, что если на сервере установлены ключи на 100 пользователей, то клиентское приложение автоматически возьмет один из них. Посмотрим на реальный порядок поиска лицензий, чтобы понять, почему это не всегда так. Платформа 1С:Предприятие 8.3 следует строгому многоуровневому алгоритму. Рассмотрим его по шагам:
HASP.HASP License Manager.Проанализируем ситуацию: если на вашем рабочем месте установлена лицензия разработчика, клиентское приложение обнаружит её на самом первом этапе (локально) и даже не пойдет запрашивать «нормальную» лицензию у сервера. В результате ваш сеанс «отравит» рабочую базу ограничением в три пользователя.
Разберем спорный момент, касающийся публикации баз на веб-серверах (Apache или IIS). Существует важное техническое правило: модуль расширения веб-сервера может самостоятельно раздавать лицензии только для файловых информационных баз. Если же база работает в клиент-серверном варианте (на SQL), модуль веб-сервера отключает функцию раздачи лицензий, и эта задача полностью перекладывается на сервер приложений 1С.
Однако на практике иногда возникают ситуации, когда конфигурация сети или кэширование заставляют систему вести себя нестандартно. Если веб-сервер и сервер 1С находятся на разных машинах, приоритеты поиска могут смещаться, но общее правило остается прежним: локальная лицензия на компьютере пользователя всегда имеет высший приоритет над серверной.
Чтобы избежать блокировки работы коллег в продуктовой базе, рассмотрим несколько практических приемов:
ibases.v8i для разработки и для работы. В параметрах запуска рабочих баз можно явно прописывать ключи, влияющие на поиск лицензий.conf.cfg: Мы можем управлять поведением платформы через конфигурационный файл conf.cfg, ограничивая места поиска лицензий. Это поможет запретить клиенту брать локальные файлы лицензий при обращении к определенным серверам.Если неприятность уже произошла и база начала выдавать ошибки о лимите сеансов, выполните следующие действия: закройте все свои сеансы (включая Конфигуратор), зайдите в консоль администрирования серверов 1С и убедитесь, что в списке активных пользователей вашей лицензии больше нет. В редких случаях, когда лицензия «зависла», может потребоваться перезапуск службы 1C:Enterprise 8.3 Server Agent.
Стоит отметить, что начиная с версий платформы 8.3.23 и выше, фирма 1С активно внедряет новый механизм — Сервер лицензирования. Рассмотрим, что это меняет: новый менеджер призван заменить старый HASP LM и централизованно управлять как программными, так и аппаратными ключами. В будущем это позволит более гибко настраивать политики выдачи лицензий в разрезе пользователей и конкретных информационных баз, что должно окончательно решить проблему случайного использования лицензий разработчика в коммерческой среде.
Подводя итог: лицензия разработчика — мощный инструмент, но она требует дисциплины. Помните о приоритете локальных лицензий над серверными и всегда проверяйте, какой тип ключа используется в текущем сеансе через меню «Справка — О программе».