На кассе Вин шедулер по расписанию запускает батник, запускающий файловую 1С для работы рег.заданий - РегламентныйЗапуск. Когда приходит кассир и запускает рабочее место кассира, то лишний РегламентныйЗАпуск приходиться убивать при помощи taskkill, чтобы не жрал ресурсы (компы слабые), а планировщик рег.заданий забирает на себя кассовый запуск. Есть ли какой либо способ дать знать запущенной 1С, что можно завершить работу, как-то вызвать срабатывание ОбработкаВнешнегоСобытия, или может еще что есть. Пока в голову приходит костыльный метод, создать гденить файл и проверять его наличие, при наличии завршать работу РегламентногоЗАпуска.

или в Регламентном запуске проверять список активных пользователей, при наличии в списке сессии  запущеной с этой же машины завершать работу.

Вот меня интересует, можно ли скриптом послать сообщение определенного формата, как в описании к методу.

ОбработкаВнешнегоСобытия (ExternEventProcessing)
Синтаксис:
ОбработкаВнешнегоСобытия(<Источник>, <Событие>, <Данные>)

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

А не проще ли было бы сделать чтобы рег. задание по завершению завершало бы и сеанс?

или в батнике запуска рабочего места кассира убить регламентный запуск

Тупо файловый флаг, в р/з проверять и завершать

(3) (5) У нас регулярный обмен с розницей идет, каждые 5 минут, в свободное время, когда нет кассира может всякая служебная инфа прилетать - улетать, синхронизация справочников.

(4) Не хотелось бы тасккилл использовать, периодически у нас падает планировщик заданий, задания перестают исполняться с ошибкой "Недопустимое состояние объекта [dbgtgt - d:\jenkins\ci_builder\windowsbuild2\platform\src\dbgtgt\src\seancedebugtarget.cpp (219)], соответственно падает обмен и все такое прочее завязанное на рег. задания. у нас есть теория, что это как раз из-за тасккилла, типа процесс завершается нестандартно, где-то в недрах платформы что то ломаеться, передача управления рег.заданиями новому процессу происходит не корректно и обмен лежит.

Т.е. когда кассир работает обмен прекращается? А если он ушел и сеанс оставил незавершенный?

А если запускать регзадание от кассира, в его же сеансе?

Из жизни большой розницы:
На каждой точке есть компуктер с апачем и обмен стучится в веб сервис. И это прекрасно работает.
Естественно речь идёт о файловой базе

(7) Планировщик мигрирует от сесси к сессии. Если оставил сеанс то все нрормально работает, если закроет, то батник обнаруживает отсутстве процесса 1cv8 b запускает програмно сессию для обмена.

(8) 700 точек планируется, где нить окажется кассир закрывший сессию свою, с утра получит очередь рег. заданий и сообщений в "Rebbit MQ" плюс есть критичные вещи на испольнение только ночью, например обновление локальной конфигурации. Сисия всегда должна быть запущена хоть одна.

(9) вот ту подробнее можно, я так понимаю что планировщик рег. заданий для файловой базы может работать только под запущеной сессией, файловой или веб через апач, сам по себе апач не может рег задания исполнять как напрмиер сервер 1С. До кучи как мы думаем, Апач однопоточен, все запросы складываются в один потом и стоят в очереди, поэтому сессия кассира и исполнитель рег заданий у нас на отдельном ФАЙЛОВОМ запуске, что бы фронт мог максимально быстро работать с базой(выжимаем последние граммы производительности :) а через апач уже работает вторая касса и пара складских запусков.

+(10)Управление запуском регламентных заданий. Регламентные задания начинают выполняться на первом запущенном по порядку клиенте, у которого не /AllowExecuteScheduledJobs –Off. После завершения сеанса этого клиента, выполнение переходит к какому-либо из других запущенных сеансов. Если запускается сеанс с /AllowExecuteScheduledJobs –Force, то регламентные задания начинают выполняться на нем, не зависимо от наличия других сеансов.