Привет братьям по разуму! Кто знает, как из одного сеанса 1С вызвать событие "ВнешнееСобытие()" второго сеанса 1С ? Находил на ИнфоСтарте ВК которые имели в своем наборе генераторы внешних событий, но вызов "внешнего события" происходит в том же сеансе что и вызывает его. Рассматриваю в том числе написание ВК самому (нашел некий материал описывающий написание ВК в Delphi). Вообще возможно ли реализовать мою задумку или же это правило неизменно (вызывается событие в том же сеансе)? Спасибо за любую помощь

Почему именно "Внешнее событие"? Что у Вас за задача такая?

Да, оба сеанса одной конфигурации и предвижу совет менять накий флаг в одной из таблиц 1С, но так это у меня сейчас и происходит. Т.е. один сеанс выполняет роль менеджера, который запускает сеансЫ 1С выполняющих роль исполнителей, как только "исполнитель" завершил свою работу, "менеджер" запускает следующего "исполнителя". Но запрос приходится вызывать довольно часто и это нагружает систему, хотел бы инициировать следующий запуск "исполнителя" по внешнему событию (тобишь перед окончанием "исполнитель" посылает вызов "менеджеру" об своем завершении)

Ветка подымись...

Что мешает "менеджеру" выполнить процедуру ОбщегоМодуля "Клиента"?

(2) на мой взгляд - экономия на спичках, да и ВнешнееСобытие не для этого предназначено.
Что там за запрос такой, который нагружает систему?

как внешнее событие может ускорить выполнение запроса?

(6) т.е. как замена запроса на внешнее событие разгрузит систему? там такой страшный запрос у вас?

(6) Внешнее событие никак не ускоряет выполнение запроса, она его заменяет чтоли. Т.е. либо каждые 20 сек выполнять запрос (а не освободился ли один из исполнителей, чтобы запустить нового), либо "менеджеру" дадут пня под зад, молв запускай нового "исполнителя".
(5) Запрос сам по себе довольно увесистый, а самое главное все дело происходит на 20 одновременно работающих виртуальных машинах. В общем экономия будет точно не на спичках.

(7) Внешнее событие НЕ замещает запрос, оно является инициатором выполнения запроса.

я бы написал этого "менеджера" на вк, который в цикле запускал com объекты 1с с "исполнителями". возможно, массив этих объектов. в конце выполнения исполнитель передает менеджеру спец.переменную типа "я_отработал_ололо_ура", что служит признаком для его уничтожения и инициализации нового объекта

в (8) и (9) вы противоречите самому себе:
Внешнее событие никак не ускоряет выполнение запроса, она его заменяет чтоли...

и

Внешнее событие НЕ замещает запрос, оно является инициатором выполнения запроса....

(11) Заметил уже. Но я удмаю все поняли что я имел в виду

(10) как вариант кстати. Но если вариант с внешими событиями возможен, то он был бы чуть оптимальнее, нет необходимости в цикле запрашивать "исполнителей", завершили ли они свои черные дела.

(13) не значю что вы имеете ввиду под "запрашивать", но я очень сомневаюсь что вы выиграете в оптимизации, заменив простую проверку переменной на равенство "я_отработал_ололо_ура" на внешнее событие.

ведь эту проверку можно делать с периодичностью 5 сек, например, и для системы это будет точно не в тягость. каждые 5 секунд проверять массив из 20 элементов. тип которых можно сделать вообще булевым. не знаю куда быстрее

(14) Тоже верно и вообще довольно не плохой вариант решения. Но все же, кто имел дело с внешними событиями, может ли один сеанс инициировать внешнее событие второго сеанса или это в принципе невозможно ???

(16) Почему нет ответа на (4)

(17) Зачем запускать менеджеру процедуры сеанса "исполнителя", для того архитектура так и построена, что есть центр - "менеджер" и сами "исполнители". Вот они пусть и запускают свои процедуры.

И как (18) противоречит (4).
Вчитайтесь в то, что я сказал в (4), вы меня правильно понимаете?

(19) Тут 2 вариант понимания Вашего совета:
1) Не запуская "исполнителя", менеджер вызовет процедуры что должен был вызвать "исполнитель". Не вариант потому что каждая такая процедура по времени может проходить по 10 минут (происходит взаимодействие с внешним ПО), во вторых отсутствие паралельности выполнения (а так каждый исполнитель выполняет свои действия паралельно)
2) "Менеджер" запускает сеанс "исполнителя" через СОМ коннектор и вызывает вызов процедур на клиенте (через внешнее соединение тобишь). Тут просто не вижу преимуществ и надо уточнить, пока выполняется такая процедура, не залипает ли исполнение менеджера.

Если не так понял то прошу уточнения Вашего совета

Да, наверное надо было сразу написать. Здесь полный автомат, без взаимодействия с пользователем.

Зачем нужен менеджер?
Запустить "клиентов" по числу Внешнего ПО и пусть они крутят циклы обмена с этим ПО.

(0)
>> как только "исполнитель" завершил свою работу, "менеджер" запускает следующего "исполнителя"
это элементарно реализуется штатными средствами фоновых заданий

Менеджер для того чтобы менять ip текущей вирт машины и контролировать работу исполнителей. Исполнитель может повиснуть или просто отвалиться, в таком случае менеджер отрабатывает такие случаи и снова запускает исполнителя. И так по циклу до завершения

фоновые задания крутятся на сервере, никак не вариант

(23) в процедурах "исполнителя" происходит взаимодействие с окнами, софтом, визуальным состоянием рабочей области экрана и с курсором мыши. Фоновые к сожалению тут не помогут.Тоже изначально хотел через них реализовать

(26) Отдельную файловую конфу исключительно для обмена

(27) Тут ведь обмена как такового нет, не совсем понял суть совета

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

(29) верно, менеджер как руководитель конкретной вирт машины, т.е. по одному менеджеру на машину. Признаться есть еще один сеанс - Административный, уже над самими менеджерами, если вдруг "менеджер" отвалится, ну и еще одну роль выполняет, помогая каждому исполнителю.

"Бубка Гоп", я вот обдумываю твой вариант. А ежели исполнитель пока выполняет свою долгую процедуру, менеджер запросит через сохраненную COM связь значение флага (признак завершения). Я так понимаю что ответ он не получит и скорее всего произойдет зависончик ?!

В общем проверил я вариант предложенный от "Бубка гоп" - не подходит и вот почему:
Если через СОМ коннектор, то при запуске "исполнителя" сразу же начинается выполнение его процедуры и пока не выполнится, мой менеджер не отлипнет от этого запуска, а внешнее соединение не поддерживает "ПодключитьОбработчикОжидания" чтобы освободить менеджера и через секунду начать выполнять свою процедуру.
Если же через "ОЛЕ автомат" и при начале работы исполнителя открывать форму, в которой через "ПодключитьОбработчикОжидания("МояПроца", 1)" запускается процедура, то "Менеджер" сразу же отлипает от запуска, но вот если посмеит спросить каково значение глоб переменной в сессии "исполнителя", то уходит в зависон. В общем вопрос по поводу внешнего события все так же актуален.

(2) для этого существуют бизнес процессы. Роботы тоже могут выполнять задачи бизнес процессов.

(33) Можно поподробне и заодно ап. (вопрос открыт)

(34) имеются в виду объекты 1С БизнесПроцесс и Задача

(35) Это я понял, мне только не понятно каким образом мне это поможет. Тот же запрос будет к БД, так у меня сейчас и работает. Просьба помочь только по теме ветки - через "ВнешнееСобытие()"

(36) описанное тобой - это типичный бизнес процесс и задачи. Только задачи выполняются роботами. Выкинуть в жопу все флаги и сделать бизнес процесс, задачи которого обрабатывают роботы, и будет счастье

"ЛефМихалыч", я думаю Вы уже поняли как у меня построена архитектура проекта и каким образом построено взаимодействие. Ну причем тут Бизнес-процессы, ну сделаю я их, ну будут роботы выполнять задачи бизнес-процессов, что от этого поменяется? Система будет более отказоустойчива, она решит проблему возможных блокировок или просто оптимизирует выполнение алгоритмов ? На сколько я понимаю нет, а тем более мой вопрос по сабжу (цель которого уменьшить количество запросов с учетом паралельных сеансов)

Вы наверное имеете в виду что менеджер заранее построит список задач через бизнес-процессы, а далее все по составленному плану будет выполняться в порядке очереди. Честно я не работал с Бизнес-процессами и пока для меня это не оптимальный выход. Да, в случае Вашего решения, кто будет решать когда нужно запуститься роботу на выполнение ?

Ап

(39) удачи

Ап. Вопрос открыт