Реализовано в версии 8.3.10.2168.
При разработке и сопровождении прикладных решений конфигуратор используется не только интерактивно (для изменения конфигурации, описания алгоритмов на встроенном языке), но и программно (для обновления конфигурации, загрузки/выгрузки и др.). Например, новая среда разработки EDT часть своих функций перепоручает конфигуратору.
Наша исходная потребность заключалась в том, чтобы ускорить взаимодействие EDT и конфигуратора. Но в процессе разработки мы решили расширить решаемую задачу. В результате мы реализовали универсальную возможность работы с конфигуратором программно – режим агента. В этом режиме конфигуратор может выполнять произвольное количество «внешних» команд, не завершая своей работы.
Главным преимуществом этого режима для EDT является то, что время выполнения последовательности таких операций как загрузка/выгрузка в файлы и обновление конфигурации базы данных сократилось. Ведь в пакетном режиме, который EDT использовала до этого, конфигуратор запускается, выполняет одну команду, и завершает свою работу. И если необходимо последовательно выполнить несколько команд, накладные расходы на запуск / завершение работы конфигуратора могут быть значительными.
Другим преимуществом, которого не было в наших изначальных планах, явилось то, что в новом режиме вы можете работать с конфигуратором через стандартные ssh-клиенты. А это значит, что вы можете автоматизировать свою работу с конфигуратором. И вот об этой возможности хочется рассказать подробнее.
Для запуска конфигуратора в новом режиме используется ключ /AgentMode, а также ряд других вспомогательных ключей, определяющих настройки подключения. Сразу же, при запуске, указывается информационная база, с которой будет работать конфигуратор.
После запуска агента можно поочерёдно работать с этой информационной базой как запущенным агентом (с помощью ssh-команд), так и конфигуратором, запущенным в обычном режиме. Что значит поочерёдно?
Чтобы управлять конфигуратором из ssh-клиента, нужно сначала подключиться к информационной базе. Выглядит это очень просто:
designer>common connect-ib
Операция завершена успешно
После этого можно выполнять любые другие ssh-команды.
Если выполнить ssh-команду отключения, то можно будет (не завершая работу этого агента) запустить ещё один конфигуратор в обычном режиме и работать с информационной базой как обычно, например, редактировать модули. После завершения работы обычного конфигуратора можно снова, в работающем агенте, с помощью ssh-команд подключиться к информационной базе (ИБ) и выполнить другие операции. Коротко эту последовательность действий можно представить следующим образом:
- подключение к ИБ (ssh-команда)
- … другие ssh команды
- отключение от ИБ (ssh-команда)
- запуск конфигуратора в обычном режиме
- … модификация той же ИБ, к которой подключен агент конфигуратора
- завершение работы конфигуратора в обычном режиме
- подключение к ИБ (ssh-команда)
- … другие ssh команды
- отключение от ИБ (ssh-команда)
К конфигуратору, запущенному в режиме агента, можно подключаться стандартными ssh-клиентами PuTTY, WinSCP, MobaXterm и другими. Пока мы реализовали только самые необходимые команды:
В дальнейшем мы будем рассматривать возможность расширения списка команд.
Как мы уже говорили в начале, использование протокола ssh позволяет вам не только работать из командной строки в стандартных ssh-клиентах, но и автоматизировать свою работу с конфигуратором, используя возможности других, кроме встроенного, языков программирования. Например, на языке Python подключение к информационной базе и отключение от неё реализуется буквально в несколько строк (с помощью библиотеки Paramiko):
import paramiko
host = '192.168.1.1'
user = 'login'
secret = 'password'
port = 1543
client = paramiko.SSHClient()
client.set_missing_host_key_policy(paramiko.AutoAddPolicy())
client.connect(hostname=host, username=user, password=secret, port=port)
stdin, stdout, stderr = client.exec_command('common connect-ib')
data = stdout.read() + stderr.read()
...
stdin, stdout, stderr = client.exec_command('common disconnect-ib')
data = stdout.read() + stderr.read()
client.close()
Конфигуратор сам по себе определяет ряд ограничений, накладываемых на взаимодействие по протоколу ssh.
Во-первых, из-за специфики работы конфигуратора все ssh-команды выполняются синхронно, одновременно к информационной базе может быть подключён только один shell ssh-клиент и несколько sftp-клиентов.
Во-вторых, существует жёсткое ограничение «один агент – одна база». Так как аутентификация выполняется по имени пользователя информационной базы и паролю, то агент сразу (при запуске) должен знать, с какой базой он будет работать.
И, в-третьих, одна из «хотелок», существовавших в процессе разработки этого механизма, заключалась в том, чтобы знать процент выполнения команды, исполняемой конфигуратором. Но после пристального анализа оказалось, что такая возможность есть далеко не у всех операций конфигуратора, а её внедрение это довольно трудоёмкая задача. Поэтому пока эта возможность осталась у нас в статусе пожелания.
