Обработка входящих сообщений

[raniel]

Добрый день! У меня есть один вопрос. Как поймать входящее сообщение на Axapta 3.0(3-хзвенная архитектура)
Суть задачи заключается в следующем. Необходимо чтоб приложение на клиенте запускало определённый скрипт(класс) по первой же необходимости. Запуском должен заниматься не пользователь, а администратор. Ничего лучше как поймать входящее сообщение и анализа его я не придумал. Но вот вопрос. Где его перехватить?

[sukhanchik]

Дурацкий вопрос. А пакетный сервер чем не угодил? Он же собственно говоря именно для этого и предназначен...

[raniel]

Вопрос не дурацкий. Суть в том что запуск должен происходить не по графику, а произвольно...по первому требованию. Была идея использовать для этих целей таблицу, и постоянно проверять её на наличие команды, но идея тоже не совсем подходит....постоянные нагрузки на сервер. И скорость реакции не высокая.

[sukhanchik]

А пакетный сервер не обязательно по графику запускает. Это как настроите конкретное задание.
По умолчанию - оно настроено на немедленный запуск. Т.е. Вы нажимаете ОК в диалоге периодической операции, задание добавляется в очередь и если пакетник свободен - то он выполняет задание. Если пакетник занят - то задание выполняется не сразу - а как только пакетник освободится. Если не хотите ждать - то можно запустить несколько пакетников одновременно - и тогда обработка очереди будет быстрее

[raniel]

sukhanchik хорошо. Представим так. Человек работает. Но вдруг администратору необходимо запустить обработку(дистанционно) именно сейчас...и заранее сервер пакетной обработки он не настраивал.... как тут быть?

[sukhanchik]

Цитата:

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

Человек работает. Но вдруг администратору необходимо запустить обработку(дистанционно) именно сейчас...и заранее сервер пакетной обработки он не настраивал.... как тут быть?

Ммм.. у меня такое ощущение - что Вы не представляете что такое сервер пакетной обработки. Сервер пакетной обработки - это та же аксапта, только постоянно запущенная и ждущая когда ей скажут "работай". Сказать ей могут по-разному. Могут сказать: "каждый день в 8 утра запускай эту обработку". А могут сказать: "Мне тут нужно запустить обработку именно сейчас - запусти ее".
Обе команды даются так: запускается из меню нужная периодическая операция (с диалогом и вкладкой пакет). На вкладке пакет жмется галка "Пакетная обработка" и если нужно чтобы обработка запустилась именно сейчас - больше ничего не делают и жмут ОК. Для настройки повторения нужно нажать на кнопку "Повторение".

Собственно говоря - все. Т.е. один раз нужно запустить аксапту с ключиком batch, проверить, убедиться и дальше пользоваться. В общем-то тоже самое - как и при разработке - сначала написать, затем проверить, убедиться и пользоваться. Т.е. не нужно при каждом запуске настраивать сервер пакетной обработки.

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

[Maximin]

В руководстве по администрированию. Раздел "Processing batch jobs". Все толково описано.
raniel
А насчет этого - есть у меня некий очень интересный проектик... где-то под НГ, наверное, доведу до ума и выложу.

[raniel]

Maximin с нетерпением буду ждать... Поседний встречный вопрос. Пакетную обработку можно запустить дистанционно на машине клиента? Я всё правильно понял?

[Maximin]

Цитата:

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

Maximin с нетерпением буду ждать... Поседний встречный вопрос. Пакетную обработку можно запустить дистанционно на машине клиента? Я всё правильно понял?

Пакетная обработка будет работать на клиенте, предназначенном для пакетной обработки заданий (aka пакетном сервере). Не имеет значения, на какой машине он расположен. По сути, "пакетный сервер" - всего лишь машина, выделенная для выполнения клиента Axapta, с запущенным обработчиком какой-либо пакетной группы.
А насчет дистанционного запуска - это как раз - одна из функция моего проекта.

[raniel]

Maximin в моём случае... значит все машины на которых работает Axapta должны быть настроены как сервера пакетной обработки(все компьютеры бухгалтерии, кадровиков, экономистов и т.д)? если это так, то мне не кажется это решение некрасивым. Хотя возможно это единственный выход... Всё же интересно, Можно ли каким либо образом перехватить входящее сообщение? Какие классы инициализируются? Сколько я работаю с Axapta всегда поражался её гибкостью....всё реализовано через приложение, и его без проблем можно доработать/изменить. И как то не верится что такая вещь как приём сообщения и вывод его на экран сделано иначе.

[Maximin]

raniel
Вы б сначал тогда прочитали про пакетную обработку - думаю, что вы не представляете, что это такое.
Да и неплохо бы услышать решаемую задачу. Думаю, все можно сделать проще.
Настраивать все машины как сервера пакетной обработки бессмысленно - это не для тех целей предназначено.
Если стоит задача, чтобы администратор мог запустить на любом клиенте некий класс в произвольное время, то пакетная обработка здесь непригодна. В 3ке подобное получалось сделать, используя небольшую табличку, полностью кэшируемую (Cachemode:EntireTable) на AOS + таймеры, висящие на постоянно используемых формах. Период опроса стоит ставить не менее 30 секунд и при большом кол-ве записей будет не очень хорошо - при любом изменении записей клиенты будут её перечитывать.
Причем в табличке должно храниться как можно меньше информации. Т.е. буквально к примеру, userid и флаг наличия сообщения. Всё остальное клиент должен читать уже из другой таблицы при появлении подходящей записи.
На 4ке же, можно включиться в стандартный механизм сообщений - там всё легче. Или же, посмотрев, содрать её в 3ку. Но, по сути, оно во многом подобно.

[sukhanchik]

А зачем настраивать все машины бухгалтерии? А нельзя настроить одну отдельно взятую машину и все делать на ней?

И еще. Так Вам что нужно? Запустить из командной строки конкретный кусок кода (запустив Аксапту и завершив ее работу по выполнении) или запускать периодически (по требованию администратора) операцию на отдельном сервере?

Зачем мучать КАЖДУЮ машину?

[raniel]

sukhanchik в том и дело что нет. Скрипт может/должен запускаться на любом клиенте, в любое время, а может и сразу везде.

[sukhanchik]

Цитата:

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

sukhanchik в том и дело что нет. Скрипт может/должен запускаться на любом клиенте, в любое время, а может и сразу везде.

Прям вирус какой-то А можно узнать хотя бы в общих чертах - какое действие этот скрипт будет выполнять?
Просто если речь идет об обработке данных в АХ - то тогда нет смысла эту обработку запускать на всех компьютерах - заняться обработкой данных может и отдельно взятый сервер.
Если речь идет об обработке каких-либо данных вне АХ (на компьютере клиента) - то тогда зачем АХ?

Если речь идет о периодической загрузке(выгрузке) данных в(из) АХ с компьютера клиента, то гораздо проще исходные данные положить куда-то централизованно и опять-таки не мучать каждую машинку.

[HorrR]

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

[raniel]

HorrR аллерты это всплывающие сообщения? Те самые сообщения которые выводятся командой info? Если это реализовано через таблицу то через какую? Я чтото ничего подобного не видел. Возможно не туда смотрел...

[HorrR]

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

[Владимир Максимов]

Все, абсолютно все, "ждущие" ("слушающие") системы основаны на таймере. И пакетная обработка в том числе. Просто все настолько "тонет" во всяких "умных" словах и настройках или скрыто внутри "системного" кода, что добраться до сути становится проблематично...

Т.е. по таймеру, через определенные интервалы времени, запускается некий код, который проверят нет ли чего для выполнения. Далее - по ситуации.

В Axapta, основой для ручного создания таймера, является метод setTimeOut(), который есть у любого класса, поскольку это метод "базового" ("родительского") класса Object. Соответственно, если нужен "глобальный" слушатель, то следует вызвать setTimeOut() глобального же объекта. Удобнее всего это сделать в глобальном классе Info.

Общая схема примерно такая:

1) В классе Info создается собственный метод, например info.MyMethod(), в котором и производится анализ того, не надо ли что-то сделать.

2) В методе info.executeUserOptions() организуется вызов этого метода по таймеру примерно так

this.setTimeOut(identifierstr(MyMethod), 30*1000, false);

3) В самом методе в самом конце также организуется "самовызов" по тому же таймеру

this.setTimeOut(identifierstr(MyMethod), 30*1000, false);

Далее уже "техника". У Вас есть метод info.MyMethod(), который автоматически запускается при запуске Axapta и периодически, с некоторым интервалом, запускается в процессе работы. Вам остается только организовать "чтение" некой служебной информации (таблицы) и запуск других классов и методов, на основе этой информации.

Правда, возникает дополнительная проблема "совместного доступа". Т.е. чтобы два (или более) сеанса не начали выполнять одно и то же задание. Как это "разрулить" решается в каждом конкретном случае. В зависимости от того, что именно должно быть сделано.

Да, кстати, если обмен директивами идет через таблицу, то ее ни в коем случае не надо кешировать. Вам ведь надо всегда читать актуальную информацию, а не то, что сохранено в кеше.

==============================================================

Но, вообще-то, присоединяюсь к sukhanchik. Сначала ответьте самому себе ЧТО Вы собираетесь выполнять таким способом? Не "общими словами" вроде "администратору захотелось", а именно вполне конкретно. Например: администратору надо сделать перезагрузку AOS.

Далее попробуйте уточнить, обязательно ли для этой обработки запускать для ВСЕХ клиентов или достаточно, чтобы работал хотя бы один клиент? А нельзя запустить этого одного именно тогда, когда "администратору захотелось"?

[Maximin]

Цитата:

Да, кстати, если обмен директивами идет через таблицу, то ее ни в коем случае не надо кешировать. Вам ведь надо всегда читать актуальную информацию, а не то, что сохранено в кеше.

Еще как надо! Это сильно разгружает БД. Далее.. При режиме кэширования EntireTable таблица лежит на AOS и в остальном ведет себя как при режиме кэширования Found. Соответственно, скэшируются результаты поиска только найденных строк для сообщений, итак предназначавшихся конкретному клиенту. А раз так - то при нахождении такой записи и обработке сообщения его сразу же удалят и кэши буду сброшены.

Что же касается использования Info для обработки таймаутов - то поддерживаю. У нас использовались обработчики на формах только из-за небходимости отображать сообщения там же - в формах.

[Владимир Максимов]

Цитата:

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

Еще как надо! Это сильно разгружает БД. Далее.. При режиме кэширования EntireTable таблица лежит на AOS и в остальном ведет себя как при режиме кэширования Found. Соответственно, скэшируются результаты поиска только найденных строк для сообщений, итак предназначавшихся конкретному клиенту. А раз так - то при нахождении такой записи и обработке сообщения его сразу же удалят и кэши буду сброшены.

Ну, у меня прямо противоположные выводы Вы сделали ряд допущений, о которых автор темы вообще-то не говорил.

1. Какие основания есть предполагать, что после "обработки" запись будет удалена и кеши будут сброшены? Историю сохранять не надо? У автора речь идет вовсе не о сообщениях, а о некоем "запуске класса" (понимай - обработке), что просто в обязательном порядке требует журналирования.

2. Какие основания есть предполагать, что все происходит на одном AOS? Если с одной и той же базой работают несколько AOS, то кеширование таблиц - это "смерть" подобной системы. Один AOS просто не увидит модификаций, сделанных другим AOS.