Управляем выполнением кода на серверах
В новой версии системы появились серверные события, с помощью которых можно управлять выполнением ISBL-сценариев на отдельных серверах. Для каких задач полезны серверные события, как их использовать и как они работают – читайте в статье.
Для чего использовать серверные события?
Серверные события – это основа для автоматизации сквозных процессов и реализации взаимодействия с другими системами в рамках концепции управляемой распределенной архитектуры. Серверные события решают следующие проблемы при автоматизации сквозных процессов:
- вычисления по подготовке и передаче данных в другую систему зачастую «тяжелые» и существенно замедляют пользовательские операции;
- взаимодействие со сторонним ПО, например, учетными системами, увеличивает время отклика системы на действия пользователей, требует установки этого ПО на клиентские компьютеры и предъявляет требования к настройкам безопасности. А это не всегда бывает оправданно.
Серверные события также можно эффективно использовать для решения других задач, примеры которых приведены ниже:
- при сохранении записи справочника или карточки документа происходит синхронизация данных в другой справочник, при этом нет необходимости выполнять ее в той же транзакции. В стандартной поставке DIRECTUM 5.4 c помощью серверного события при создании договорных документов создается запись справочника Договоры и синхронизируются значения полей из карточки документа в запись справочника. Запись справочника Договоры сохраняется быстрее, чем в DIRECTUM 5.3;
- иногда служба Workflow использовалась не по прямому назначению, а для того, чтобы выполнить ISBL-вычисления на сервере, а не на клиенте: появлялись дополнительные служебные задачи, увеличивалась нагрузка на службу Workflow. Серверные события позволяют избавиться от лишних вычислений с помощью Workflow;
- чем больше сценариев по расписанию выполняется в системе, тем сложнее администратору управлять расписанием, особенно если используется несколько серверов. Раньше расписание запуска задавалось на тех серверах, на которых сценарии выполнялись. При использовании серверных событий можно задать расписание на одном сервере (по расписанию инициируются серверные события), а сценарии-обработчики будут выполняться на серверах, которые укажет администратор. Некоторые агенты в 5.4 запускаются с помощью серверных событий, например, синхронизация совещаний с MS Exchange.
Как использовать серверные события?
Создайте серверное событие в одноименной компоненте. Затем разработайте сценарии, которые выполняются при обработке события, и в карточке сценария свяжите их с серверным событием.
Остается только запустить серверное событие. Сделать это можно несколькими способами:
- в ISBL-коде с помощью интерфейсов IServerEvent и IServerEventFactory;
- с помощью сценария Запуск серверного события, который можно вызывать через командную строку с помощью SBLauncher или через веб-сервисы интеграции;
- в задании SQL-сервера с помощью хранимой процедуры SBServerEventStart.
После того, как серверное событие инициировано, в очередь на выполнение добавятся сценарии-обработчики события. Эта очередь обрабатывается службой обработки событий. Принцип работы новой службы аналогичен службе Workflow, только вместо задач и заданий она управляет выполнением сценариев-обработчиков, привязанных к серверным событиям.
Отследить запуск событий можно в компоненте История серверных событий. Она содержит информацию о каждом запуске сценария-обработчика, результатах и параметрах, с которыми запускалось событие.
У администратора есть возможность установить службы обработки событий на несколько серверов и настроить, на каких серверах будут обрабатываться те или иные события. Например, приоритетные и ресурсоемкие события можно запускать на более мощном сервере, остальные события – на сервере послабее.
Используйте новые возможности DIRECTUM 5.4! Ждем ваши вопросы и комментарии.
Можно управлять временем когда будет отработано событие? т.е. помещается например оно в очередь по кнопке пользователем, но выполняется через 3 часа
Денис, да. смотрите метод https://club.directum.ru/webhelp/directum/5.4/om_metod_startat_zapustit_servernoe_sobytie_v_ukazannoe_vremia.htm
кол-во таких отложенных событий влияет на скорость работы обработчика событий? например для воркфлоу есть рекомендация не более 20 задач в очереди. Тут есть какие то рекомендации? Или переварит все?
Денис, дайте ссыль на рекомендацию.
Мне видится она частным случаем, когда задачи не отложены, а ждут выполнения здесь и сейчас. И то, это не является большой проблемой, а число будет плавающим в зависимости от мощности сервера.
А с отложенными событиями (worflow) нет никаких причин нагружать систему до наступления времени. Запросом из очереди брать только те события, которые нужно обработать сейчас...
Денис, возможно рекомендация уже устарела, не вижу причин по чему это плохо, служба воркфлоу как и служба обработки событий, должна переварить все.
Служба обработки событий тестировалась, результаты, по-моему, хорошие:
Работала 1 служба с 4 процессами, в очереди были события по созданию задачи, поиску и изменению реквизитов документа, изменения записи справочника, сценарии завершавшиеся с ошибкой, сценарии с большим слипом (чтобы в итоге вылетало по таймауту). С тестовой базой в это время не работали пользователи. Служба была стабильной.
Отложенные события не должны влиять на производительность, так как служба берет только актуальные.
Отчего бы было просто не сделать галочку:
[x] выполнять сценарий на сервере
в карточке "сценарии"
И не городить городки с созданием новой сущности - события, связыванием его с сценарием и "особым" способом получения параметров для этого события.
И еще извините, но пример в обсуждаемой статье - притянут за уши. Создать карточку договора можно и на клиенте это что такая ресурсоемкаяоперация что ее надо на сервере делать?
Что как бы намекает что авторы не совсем понимают "а собственно ну вот мы такое создали а как это применить в реальной жизни?"
Мое имхо: мне бы сильно пригодилась возможность выполнить код на сервере вот прямо сейчас.
мой кейс: нужно сгенерировать тело типового документа в формате __тут вставьте кому что нравится__ - я ставлю на сервере ПО и интеграцию с шаблонами, заряжаю в мастера вызов такого метода (только он нужен мне синхронный желательно,чтоб дождаться выполнения) и показываю результат выполнения кода на клиенте уже готовый.
И да - я хочу просто написать сценарий : "СгенерироватьДокументНаСервере" и поставить галочку
[x] Серверный
и потом еще поставить галочку (совсем хорошо бы)
[x] Ждать завершения сценария( синхронный вызов)
описать параметры как обычно в сценариях, осуществить их прием тем же самым кодом. Который и в стандартных сценариях работает.
Таким образом - чтобы осуществлять управление где выполняется код - мне потребовалось бы просто "установить/снять" галочку в карточке сценария. И все.
И всем профит:
- все будущие счастливые обладатели получают при обновлении просто галочку установив которую они потенциально для существующих процессов получают внезапное и приятное ускорение в виде переноса кода на сервер.
- я в моем кейсе получаю профит от отсутствия геморроя на местах с расстановкой клиентских ПО необходимых для интеграции и генерации всякого...
- система бы получила профит от отсутствия энтропии
- авторы статьи сэкономили бы кучу нажатий на клавиши при написании статей:статья могла бы выглядеть так:
"Мы сделали галочку "выполнять код на сервере" в карточке сценария. Установив которую вы автоматически и без лишних хлопот получаете ускорение за счет переноса выполнения кода на сервере (продолжительные аплодисменты) , а еще мы планируем сделать такую же галочку в карточке функции (бурные аплодисменты).И да - менять в коде ничего не нужно! (бурные и продолжительные аплодисменты переходящие в овацию) Мы с уважением относимся к усилиям на местах и всячески оберегаем вложения времени и денег в инфраструктуру Directum в целом и ISBL в частности. С уважением команда разработчиков" (В зале слышан стук тел падающих от счастья в обморок "разработчиков у клиента на местах" не верящих в чудо и неустанно повторяющих - "разбудите меня кто нибудь,ах это не может быть правдою")
- единственные кто не получил бы профита - сис.программеры в Ижевске которым пришлось бы реально попотеть реализуя вышеназванный подход. Но они в конечном итоге получили бы плюсы в карму от бесчисленных программеров на стороне клиента.
Вот как то так.
Спасибо, высказался, полегчало, отпустило.
Все имхо.
Отчего бы было просто не сделать галочку:
[x] выполнять сценарий на сервере
в карточке "сценарии"
И не городить городки с созданием новой сущности - события, связыванием его с сценарием и "особым" способом получения параметров для этого события.
А если вам надо запускать некоторый сценарий в некоторых случаях на сервере, а в некоторых на клиенте?
А как передавать туда параметры?
Если ориентироваться на iScript.Params, то это не подходит. Если в параметры передадут не простое значения, как строка или число, а объект системы (iReference, IEDocument и т.д.), а так же и вовсе COM объекты сторонних приложений.
Как такие параметры передать на сервер?
- все будущие счастливые обладатели получают при обновлении просто галочку установив которую они потенциально для существующих процессов получают внезапное и приятное ускорение в виде переноса кода на сервер.
Ускорение ли? Генерация документа может быть ресурсоемкой операцией. События работают в рамках очереди. Если придет в один момент много запросов на генерацию документов, а клиенты будут ждать завершения события, то это ожидание может быть дольше, чем если бы документ генерировался на клиенте.
Ну и ещё раз: Как вы планируете передать документ с сервера на клиент?
- система бы получила профит от отсутствия энтропии
Это что за неведомый зверь такой в рамках терминологии информационных систем?
- единственные кто не получил бы профита - сис.программеры в Ижевске которым пришлось бы реально попотеть реализуя вышеназванный подход. Но они в конечном итоге получили бы плюсы в карму от бесчисленных программеров на стороне клиента.
Конечно, ведь перед ними бы тогда стояла задача, которая в полной мере не решается...
И да, они бы получили в карму много плюсов на "первом этапе". До тех пор, пока клиенты не начали бы пробовать данный механизм и не столкнулись бы со множеством введенных ограничений, от которых никак не уйти, которые вероятно были бы не явными, а ты сидишь и гадаешь: "Если я передам в параметры вот это значение, сервер его получит? Сохранится ли контекст этого значения или какие нибудь сопутствующие данные? И т.д.".
Механизмы системы должны быть предсказуемыми. Что бы применяя механизм, я заранее знал, как он себя поведет, мог представить, как он внутри работает.
Предложенный вами механизм не всему этому удовлетворяет...
Игорь Прищепов, мы не сделали галочку "выполнять сценарий на сервере ", прежде всего потому что перед нами не стояла такая задача. Данная служба создавалась в рамках «УРА» и об этом написано в статье, возможно вы не внимательно читали, либо не хотите этого понимать. Она нужна для того, чтобы нечто внешнее (COM, linux, сайт, java и пр.) могло инициировать выполнение ISBL кода (сейчас можно напрямую через SQL, вебсервис интеграции, объектную модель). До этой службы, для решения этих задач надо было устанавливать где-то sbrte и общаться через объектную модель (дернуть веб сервис из javascript проще), запускать сценарии, при этом нет ни логирования, ни надежности в случае зависания, нет контроля памяти, нет нормальной очереди, нет масштабируемости. Помимо этого, служба может быть полезна и не только в «УРА», ситуации описаны в статье.
К сожалению получилось так, что задачи которые описываете вы, и задачи которая решает эта служба, они разные.
Авторизуйтесь, чтобы написать комментарий