Модуль RVMC
Модуль RVMС – это модуль для удаленного управления виртуальными машинами, который присутствует как в локальной, так и в сетевой версии программы. Модуль содержит функции для запуска алгоритмов на клиентском месте и на сервере, а также предоставляет возможности для генерации событий, которые могут передаваться другим прикладным блокам.
Для запуска алгоритмов используются функции ВЫПОЛНИТЬ (запускает алгоритм на клиентском месте) и ВЫПОЛНИТЬ_СЕРВ (запускает алгоритм на сервере).
Алгоритмы могут принимать входные параметры, т.е. использоваться, подобно функциям, другими алгоритмами и компонентами платформы.
Алгоритмы, запускаемые из меню и таблицы бланков, не должны иметь параметров. Алгоритмы, которые используются для настройки компонентов платформы и модификации объектов (например, алгоритмы журналов операций и плана аналитики), имеют фиксированные наборы параметров, которые обеспечивают обмен данными в контексте рабочей ситуации. Кроме этих случаев применения, алгоритмы могут использоваться другими алгоритмами. Взаимодействие алгоритмов можно условно разделить на взаимодействие алгоритмов с программным кодом платформы и взаимодействие алгоритмов между собой. В первом случае используются специальные функции преобразования данных (так называемые конвертеры языковых объектов) для представления объектов платформы в виде значений внутреннего языка (виртуальной машины). Конвертеры преобразуют входные параметры алгоритма перед его запуском, а после завершения работы алгоритма преобразуют значения выходных параметров. Во втором случае задание входных и получение выходных параметров осуществляется вызывающим алгоритмом.
Существует два способа запуска алгоритма относительно инициатора вызова:
- синхронный запуск;
- асинхронный запуск.
При синхронном запуске запускающий алгоритм приостанавливает свое выполнение до завершения работы запускаемого алгоритма, и наиболее удобный способ обмена данными между алгоритмами – через входные и выходные параметры запускаемого алгоритма. Асинхронный запуск отнимает у запускающего алгоритма небольшое время, после чего запускающий и запускаемый алгоритмы выполняются параллельно. При асинхронном запуске не существует штатного способа обмена данными между запускающим и запускаемым алгоритмами. Узнать о завершении работы асинхронного алгоритма также нет возможности. Асинхронные алгоритмы не могут возвращать выходные параметры, но могут принимать входные.
В принципе, любой алгоритм может быть запущен как синхронно, так и асинхронно. При вызовах асинхронных алгоритмов платформа Афина создает специальное окружение, которое позволяет алгоритму работать с одной стороны от лица текущего пользователя, а с другой - в качестве отдельного клиента серверной части. Это означает, что для асинхронного алгоритма создается собственное соединение с базой данных, используются собственные кэши в серверной части, поддерживаются изолированные транзакции и собственные очереди серверных событий. При вызове асинхронных алгоритмов на стороне сервера подключение к серверу осуществляется на общих основаниях, через механизм сетевого взаимодействия. Из сказанного в частности следует, что:
- При работе с серверной частью в монопольном режиме нет возможности использовать асинхронные алгоритмы.
- Даже в локальной версии или в случае одного рабочего места в сетевой версии асинхронные алгоритмы работают как параллельные клиенты, что должно учитываться при разработке прикладных решений (например, требуется обработка логических блокировок данных).
- С клиентского места не может быть оказано никакого влияния на асинхронные алгоритмы, запущенные на сервере. В частности, они не могут быть прерваны штатными средствами.
Таким образом, запуск асинхронного алгоритма требует выполнения большего количества действий, чем запуск синхронного, выполняемого в контексте существующего соединения с серверной частью. Тем не менее, асинхронный запуск может быть полезен в некоторых случаях:
- При отладке алгоритмов в среде разработки отлаживаемый алгоритм и пользовательский интерфейс отладчика принципиально должны работать в разных потоках (асинхронно).
- При выполнении длительных действий, результат которых может быть востребован позже. Например, пользователь запускает алгоритм некого расчета, результаты которого по завершении сохраняются в файл. При асинхронном запуске такого алгоритма клиентское приложение не блокируется, а пользователь может выполнять текущую работу.
- При создании активных алгоритмов-агентов в клиентском приложении, которые, например, могут запускаться при входе в клиентское приложение и периодически выполнять некоторые действия.
В клиентском приложении предусмотрен монитор алгоритмов, позволяющий отслеживать запущенные асинхронные алгоритмы. Сочетание клавиш Ctrl+Del вызывает монитор алгоритмов - диалог, в котором можно увидеть запущенные алгоритмы и при необходимости остановить их работу. Монитор позволяет прервать выполняющийся алгоритм в двух режимах: корректно и аварийно. Сначала алгоритму выставляется признак необходимости завершения и в течение нескольких секунд ожидается завершение работы алгоритма. Если алгоритм не завершился за отпущенное время, то у пользователя запрашивается: продолжить ожидание для корректного завершения алгоритма или прервать его аварийно. При аварийном прерывании асинхронного алгоритма возможна утечка различных ресурсов, что ставит под сомнение бесперебойную работу клиентского приложения в этом сеансе.
Отладчик в среде разработки использует собственный механизм управления выполнением отлаживаемого алгоритма. В крайнем случае, отлаживаемый алгоритм может быть аварийно прерван с помощью монитора алгоритмов.
Запуск асинхронных алгоритмов на сервере из клиентского приложения (или алгоритма, выполняющегося на клиенте) является таким же запросом к серверу, как и десятки других. Запросы, поступающие от одного клиента, сервер выстраивает в очередь. Поэтому две подряд команды клиента с требованием асинхронного запуска алгоритмов на сервере не приведут к параллельному выполнению этих алгоритмов.
Пример:
// код на клиенте
ВЫЧИСЛИТЬ
ВЫПОЛНИТЬ_СЕРВ ( { "a.ibx" }, НЕТ )
ВЫПОЛНИТЬ_СЕРВ ( { "b.ibx" }, НЕТ )
КОНЕЦ
Клиенсткий алгоритм, код которого приведен выше, будет, вероятно, завершен самым первым. Алгоритм b.ibx будет запущен на сервере только после того, как алгоритм a.ibx завершит работу.
При локальной работе все асинхронные алгоритмы работают параллельно. Это касается как запуска с помощью ВЫПОЛНИТЬ, так и запуска с помощью ВЫПОЛНИТЬ_СЕРВ. В локальной версии приведенный пример будет работать иначе, чем в сетевой. Алгоритмы a.ibx и b.ibx, вероятно (в зависимости от времени выполнения a.ibx), будут выполняться параллельно.
Существует ограничение на типы параметров, передаваемых и получаемых алгоритмами, а именно: параметры алгоритма не могут иметь тип, определенный в этом или другом алгоритме. Таким образом, алгоритмам можно передавать следующие типы параметров:
- Стандартные типы языка И++ (СТРОКА, ЧИСЛО …).
- Типы, объявленные в подключаемых модулях языка.
- Типы времени выполнения, объявляемые подключаемыми модулями на основании внешних данных (в платформе Афина используются типы времени выполнения для объектов аналитики и типов операций, которые объявляются в соответствии с информацией из базы данных).
Даже если два алгоритма используют при компиляции одну и ту же библиотеку с определением объектного типа, то объекты этого типа нельзя передавать из одного алгоритма в другой.
Для получения версий подключаемых модулей во время выполнения объявлены функции ВЕРСИЯ_МОДУЛЯ и ВЕРСИЯ_МОДУЛЯ_СЕРВ.
Для получения версии платформы объявлен тип ВЕРСИЯ_ПЛАТФОРМЫ. Зафиксировать версию платформы на момент компиляции кода можно с помощью константы КОД_ВЕРСИЯ_ПЛАТФОРМЫ. Получить версию платформы во время выполнения кода можно функциями ТЕК_ВЕРСИЯ_ПЛАТФОРМЫ и ТЕК_ВЕРСИЯ_ПЛАТФОРМЫ_СЕРВ.
Для генерации событий в модуле объявлен тип СОБЫТИЕ и функции СОБЫТИЕ_ДЛЯ_ВСЕХ и СОБЫТИЕ_ДЛЯ_БЛОКА. Возможность генерации событий необходима для создания механизма, который позволяет различным прикладным блокам обмениваться информацией в реальном времени. К примеру, операция перемещения товара в блоке "Склад" может приводить к формированию соответствующей проводки в блоке "Бухгалтерия". Код генерации события включается в исходный код алгоритмов прикладного блока, но генерация события сама по себе не приводит к обработке этого события. Необходимо реализовать систему взаимодействия, которая включает в себя, помимо самих событий, специальные алгоритмы, отвечающие за обработку этих событий, и файлы описаний, которые поставляют информацию о правилах обработки событий в каждом прикладном блоке.
Подробнее о правилах обработки событий читайте в разделе Механизм межблочного взаимодействия справочной системы платформы Инфо-Бухгалтер 10.
Физический тип КАЛЬКУЛЯТОР предоставляет методы, позволяющие вычислять произвольные выражения на внутреннем языке.
Функции
- ВЫПОЛНИТЬ
- ВЫПОЛНИТЬ_СЕРВ
- СЧИТАТЬ_ЗАГОЛОВОК_КОДА
- ТЕК_ЗАГОЛОВОК_КОДА
- ТЕК_НОСИТЕЛЬ_КОДА
- СОБЫТИЕ_ДЛЯ_ВСЕХ
- СОБЫТИЕ_ДЛЯ_БЛОКА
- СБРОС_СОБЫТИЙ
- КОНВ_АЛГ_ПАРАМ_В_СОБ
- КОНВ_АЛГ_ПАРАМ_ИЗ_СОБ
- ТЕК_ВЕРСИЯ_ПЛАТФОРМЫ
- ТЕК_ВЕРСИЯ_ПЛАТФОРМЫ_СЕРВ
- ВЕРСИЯ_МОДУЛЯ
- ВЕРСИЯ_МОДУЛЯ_СЕРВ
- АТРИБУТ_ОКРУЖЕНИЯ
- АТРИБУТ_ОКРУЖЕНИЯ_СЕРВ
- РАЗВЕРНУТЬ
- РАЗВЕРНУТЬ_СЕРВ
- ЗАГРУЗИТЬ_ФАЙЛ_СЕРВ
- СКАЧАТЬ_ФАЙЛ_СЕРВ
- УДАЛИТЬ_ФАЙЛ_СЕРВ