Как понять что пакетник (BatchRun) не работает.

[Perc]

Dax4 еще.
В пакетной обработке запущенной на ночь случается падают задания. Возникают ошибки которые не ловятся в try..catch в runJob. Соответственно останавливается пакетная очередь и к утру ничего что стояло в дальнейшей очереди не выполнено.

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

[KiselevSA]

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

[KiselevSA]

Пример такого задания, написанного одним из моих коллег, во вложении.

[Perc]

Цитата:

Сообщение от KiselevSA

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

а почему здесь нужен sql? Не-е, sql нам не нужен. Да и с такими допущениями, задача и аксаптой удобнее решается. Такой эвристический анализ не хотелось бы использовать) Хочу точно знать. А еще хотелось бы зависшее сбросить в ошибки, а пакетную обработку запустить далее. Иначе как поможет письмо на мирно спящего оператора?)

[Logger]

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

[Perc]

Цитата:

Сообщение от Logger

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

Ну вот и вопрос. А какие это критерии? Если упал в ошибку понятно, если не запустился понятно. А если запустился, нов ошибку не упал Просто из-за ошибки в каком то из пакетов прервалась сама пакетная обработка? И все мирно лежит в выполнении. Хотя ничего на самом деле не исполняется

[Logger]

Ну критерии вы сами определяете.
У нас все пакеты за которыми следят запущены от одного пользователя.
Смотрят за такими пакетами и их статусом и ожидаемым временем старта.

[gl00mie]

Цитата:

Сообщение от Logger

У нас все пакеты за которыми следят запущены от одного пользователя. Смотрят за такими пакетами и их статусом и ожидаемым временем старта.

Так то в 2009-й, а тут речь про 4.0, где AOS еще не умеет быть пакетным сервером.

Цитата:

Сообщение от Perc

А если запустился, но в ошибку не упал Просто из-за ошибки в каком то из пакетов прервалась сама пакетная обработка? И все мирно лежит в выполнении. Хотя ничего на самом деле не исполняется

Ну как это обработка прервалась, а пакетное задание осталось в выполнении? Клиент и по совместительству пакетный сервер (коль скоро речь о 4.0) висит с модальным MsgBox'ом и сообщением "шеф, всё пропало"? Так запускайте его с параметром

-internal=nomodalboxes

тогда клиент так делать не будет и сразу закроется, а его сессия на AOS'е завершится. В задании прописан код сессии, в которой оно выполняется: если сессия жива, значит, ничего не прервалось и не упало - максимум зависло, а если сессии такой среди живых нет, значит, пакет реально упал, и статус ему надо поменять. Это можно даже в 4.0 реализовать с помощью описанного выше пакета-надсмотрщика

[KiselevSA]

Если произошло что-то с самим пакетным сервером, то при организации проверки через пакетные задания из Аксапты, долго будете ждать у моря погоды. Можно, конечно, вклиниться в рассылку оповещений, но у меня нет уверенности в том, что эта рассылка не использует пакетный сервер. Обычно, любой проверочный механизм работоспособности организуется в параллельном сервисе, а не в самом сервисе, т.к., если сервис не работает, он заведомо не может сообщить об этом. А проверка на уровне SQL еще и диагностика того, что AOS не остановили или, для 4, что не забыли пакетник запустить.

[Logger]

Цитата:

Сообщение от KiselevSA

Если произошло что-то с самим пакетным сервером, то при организации проверки через пакетные задания из Аксапты, долго будете ждать у моря погоды.

Это да.
Ну каждый извращается как может. Нам такого достаточно для большинства случаев (как правило пакетный сервер был жив, просто с конкретными заданиями проблемы бывают).
На крайняк можно виндовый шедулер настроить который будет периодически стартовать клиента аксапты и делать ту же самую проверку, а в случае ошибки тоже письмо слать, но виндовые средствами - что не получилось проверить

[Perc]

Цитата:

Сообщение от gl00mie

Ну как это обработка прервалась, а пакетное задание осталось в выполнении? Клиент и по совместительству пакетный сервер (коль скоро речь о 4.0) висит с модальным MsgBox'ом и сообщением "шеф, всё пропало"? Так запускайте его с параметром

-internal=nomodalboxes

тогда клиент так делать не будет и сразу закроется, а его сессия на AOS'е завершится. В задании прописан код сессии, в которой оно выполняется: если сессия жива, значит, ничего не прервалось и не упало - максимум зависло, а если сессии такой среди живых нет, значит, пакет реально упал, и статус ему надо поменять. Это можно даже в 4.0 реализовать с помощью описанного выше пакета-надсмотрщика

Параметр nomodalboxes честно говоря не помнил. Но ошибка не модально висит. Ошибка в окне инфолога. Что-нибудь про "Ошибка времени выполнения" и стеком вызовов где упало. Пакетная обработка останавливается, форма пакетной обработки с картинкой выполнение остается, но ничего фактически не делает. Но клиентская сессия в которой упала пакетная обработка вполне себе жива не зависла.
Была мысль все запускать в runAs - ну типа там своя сессия, сохранять ее в Batch вместо родительской, как сейчас. И вот сессия runas как раз при таких ошибках тоже завершается. ну и потом в параллельной пакетной обработке проверять живость сессии записанной в выполняемом пакете. Но вот интересуюсь, а кто как выпутывались?

[Perc]

Цитата:

Сообщение от KiselevSA

Если произошло что-то с самим пакетным сервером, то при организации проверки через пакетные задания из Аксапты, долго будете ждать у моря погоды. Можно, конечно, вклиниться в рассылку оповещений, но у меня нет уверенности в том, что эта рассылка не использует пакетный сервер. Обычно, любой проверочный механизм работоспособности организуется в параллельном сервисе, а не в самом сервисе, т.к., если сервис не работает, он заведомо не может сообщить об этом. А проверка на уровне SQL еще и диагностика того, что AOS не остановили или, для 4, что не забыли пакетник запустить.

Мы наверное все-таки про разные версии аксапты. Как в высших версия аксапты реализован пакетный сервер не знаю. А в 4-ке это просто клиентская сессия с запущенным batchRun который все по порядку из очереди выгребает и запускает. никаких спецсервисов нет)

[KiselevSA]

Цитата:

Сообщение от Perc

Мы наверное все-таки про разные версии аксапты. Как в высших версия аксапты реализован пакетный сервер не знаю. А в 4-ке это просто клиентская сессия с запущенным batchRun который все по порядку из очереди выгребает и запускает. никаких спецсервисов нет)

Я как раз про четверку и говорю. Для того, чтобы они обрабатывались, надо где-то запустить клиентскую сессию, и оттуда запустить обработчики. Причем для каждой группы заданий обработчик может быть свой. Перегрузили сервер, на котором сессия крутиться. В какой момент администратор Аксапты узнает о том, что про запуск клиентской сессии от имени специального пользователя забыли?

[Perc]

Цитата:

Сообщение от KiselevSA

Я как раз про четверку и говорю. Для того, чтобы они обрабатывались, надо где-то запустить клиентскую сессию, и оттуда запустить обработчики. Причем для каждой группы заданий обработчик может быть свой. Перегрузили сервер, на котором сессия крутиться. В какой момент администратор Аксапты узнает о том, что про запуск клиентской сессии от имени специального пользователя забыли?

Как раз эту проблему нам админ виндуса как-то решил благополучно. Если падает сервер или АОС, падают клиенты соотвественно, и админ настроил что потом все аксапты запускается снова в автомате в режиме пакетной обработки. Если задание затряло в этот момент в выполнении, то стандартный алгоритм понимает что той сессии которая запустила уже нет перекидывает в ожидание и все продолжается. Так что этот вариант паднения у нас окей обрабатывается)

[Perc]

Цитата:

Сообщение от gl00mie

.. Так запускайте его с параметром

-internal=nomodalboxes

тогда клиент так делать не будет и сразу закроется, а его сессия на AOS'е завершится.

Вопрос не по теме, но из контекста)

А кто-нить пользовался этим параметром -internal=nomodalboxes ? Как он работает? У меня как я себе вообразил ничего не вышло.
В командной строке запуска добавляю в конце -internal=nomodalboxes. Запускаю аксапу.
Запускаю класс в run которого:

Box::okCancel("блабла", DialogButton::Ok);

и все работает как обычно. Появляется модальный диалог с сообщением. жмешь ок. И все. Никаких обвалов.
И да.. DAX4

[Logger]

Не пользовался этим ключом, но предположу что он влияет на мессиджбоксы, генерируемые ядром, а не из X++.

По поводу вопросов из диалогов - в стандартном коде часто замечал проверки - не работает ли код в пакете, если в пакете то диалог не выдается и используется какой-то предполагаемый ответ. может быть вам также сделать ? Кстати аналогичные азплатки можно понатыкать в статические методы класса Box. Их там немного. Около десятка.