Обсуждение FAQ: Как создать свой класс, который можно запустить по расписанию

[Vadik]

Цитата:

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

измените dialog, getFromDialog и putToDialog так, чтобы пользователь мог вводить значения ваших переменных

а что такого есть в putToDialog(), чего нельзя сделать в dialog() ?

[mazzy]

Спасибо, Vadik.
Или перекройте только два метода: dialog, getFromDialog.

[Maxim Gorbunov]

Цитата:

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

Цитата:

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

измените dialog, getFromDialog и putToDialog так, чтобы пользователь мог вводить значения ваших переменных

а что такого есть в putToDialog(), чего нельзя сделать в dialog() ?

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

[mazzy]

В этой ветке ведется обсуждение FAQ-вопроса отсюда
Как создать свой класс, который можно запустить по расписанию (в пакетном режиме)

[Vadik]

Ну вот, опять "Как лучше" против "Как написана вся Аксапта"
Я специально искал вхождения putToDialog() по классам - их там ровно два

\Classes\RHRMJournalCheckPost\putToDialog
\Classes\SysDataExpImpGroupCreate\putToDialog

Максим, положа руку на сердце - сколько раз ты сам использовал dialog() и сколько putToDialog() ?

[Maxim Gorbunov]

Ну, если честно, Best Practice это в общепринятом смысле не является (то есть, ни в каких документах такая рекомендация не зафиксирована )

Лично я, кстати, никогда не заполняю контролы в методе dialog(), если программирую обработку "с нуля". Всегда пользуюсь putToDialog(). В общем, можете считать это моей Best Practice

[Vadik]

Цитата:

Сообщение от Maxim Gorbunov

Лично я, кстати, никогда не заполняю контролы в методе dialog(), если программирую обработку "с нуля". Всегда пользуюсь putToDialog(). В общем, можете считать это моей Best Practice

"Народный перевод Navision" уже есть. Как насчет запуска "народного Best Practice"?

[mazzy]

народный Best Practice = FAQ?

[Vadik]

нет

FAQ читают после того, как возникла проблема.
Best Practice - для того, чтобы избежать проблем, описываемых в FAQ

[Alks]

Пока mazzy проверит и разместит в собственно FAQ-е помещу сюда... Кому не лень - дополните плиз.

Хочу дополнить теоретической подоплекой.

Класс RunBaseBatch очень важен в Аксапте и буквально красной нитью проходит по всем процессам в ней. Подавляющее большинство menuitem-ов прямо или косвенно запускают наследников этого класса.
И это очень важный момент - в идеологии аксапты любая мало мальски трудоёмкая операция обязана иметь возможность быть отложенной в очередь заданий на пакетную обработку. Под "любой мало мальски трудоёмкой операцией" как правило подразумеваются все действия, которые находятся в менюшках "Журналы" (при выполнении разносок, резервирований и т.п.), "Периодические операции", "Отчёты".
Для пользователя это выглядит следующим образом: при нажатии на кнопку (или пункт меню) начинающую какую либо операцию (например разноску журнала или формирование отчёта) сперва открывается диалог содержащий в себе параметры операции и либо закладку "Пакет" либо кнопку "Пакет". По нажатию на OK операция либо начинается выполнятся сразу, либо (если проставлены соответствующие опции), откладываеся в очередь заданий для пакетной обработки (Основное->Запросы->Пакеты) где будет лежать, до тех пор пока её не запустят оттуда вручную, либо пока её не запустит сервер пакетной обработки (Основное->Периодические операции->Пакет->Режим сервера).
Для программиста в простейшем случае это выглядит так, как описал mazzy выше. Т.е. создаётся класс, наследник от RunbaseBatch по вышеприведенной схеме, и по нажатии на кнопки запускается именно он.
Но схема по которой сделан класс tutorial_RunBaseBatch неудобна, когда параметров в диалоге много и между ними нужно организовать какую нибудь функциональную взаимосвязь (другими словами - "умно" реагировать на ввод пользователя в диалог). Обычный диалог позволяет лишь "накидать на него" поля ввода и по нажатию на OK прочитать их значения.
Когда требуется сложная форма диалога для RunBaseBatch существует возможность задать для этого диалога свою собственную форму, разработанную в AOT - как это делается показано в классе tutorial_RunBaseForm. В методе dialog() помещается примерно следующий код:

public Object dialog()
{
    dialogRunbase   dialog = dialog::newFormnameRunbase(formstr(имя_нашей формы_в_AOT),this);
;
    dialog = super(dialog);
    // Заполнение полей или передача их в форму
    ...
    return dialog;
}

К форме предявляются следующие требования:
1. В ней должен быть Tab с именем Tab - в него автоматически подставится закладка "Пакет" при запуске
2. В ней должна быть группа (Group) с именем dialogStartGrp - в неё будут помещены поля, которые вы добавляете через метод addField
3. Ну и разумеется две кнопки типа CommanButton: OK и Cancel

Существует еще возможность вместо закладки "Пакет" помещать на свою форму только кнопку "Пакет", при нажатии на которую откроется дополнительный диалог с параметрами пакетных заданий и тем самым сэкономить место на форме - для этого надо поместить на форму menuItemButton настроенный на menuItem BatchDialog, и подавить вывод закладки "Пакет" (как это сделать - отдельный разговор, к которому я пока не готов ).

Ну и последнее что остаётся сказать - это RunbaseBatch для отчётов.
Так как формирование отчётов как правило является трудоёмкой операцией отчёты - наипрямейшие кандидаты в очередь пакетных заданий.
Но в самих отчётах такой функциональности нет, и поэтому большинство стандартных menuItem-ов отчётов указывают не непосредственно на сами отчёты, а на классы наследники от RunbaseReport (см. tutorial_RunbaseReport). Самое главное в таком классе-наследнике переопределить метод lastValueElementName так, чтобы он возвращал имя отчёта в АОТ:

identifiername lastValueElementName()
{
    return reportStr(MyReport);
}

Так же как и в других наследниках от RunbaseBatch здесь можно организовывать ввод параметров для дальнешей передачи в отчёт.

[raz]

У нас как то странно работает пакетный режим. Постоянно запущена станция в режиме пакетного сервера, так вот в рабочие дни все ОК, а в выходные пакеты не запускаются. При чем часть пакетов есть ежедневные, но есть еженедельные пакеты назначенные на воскресенье.
Это нормальное поведение?

[Alks]

Цитата:

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

У нас как то странно работает пакетный режим. Постоянно запущена станция в режиме пакетного сервера, так вот в рабочие дни все ОК, а в выходные пакеты не запускаются. При чем часть пакетов есть ежедневные, но есть еженедельные пакеты назначенные на воскресенье.
Это нормальное поведение?

По иронии судьбы мы только что - сегодня решили эту проблему!

На самом деле вы ставите в параметрах диалога повторения периодичность = "День", параметр - "Выполнять каждый день".
Если посмотреть в англоязычной аксапте "Выполнять каждый день" изначально было написано как "Every weekday".
Так вот, видимо (Lingvo мне в помощь) "weekday" в литературном переводе на русский означает не "день недели", а "будни"! Что значит в техническом переводе - "рабочий день"! Другими словами - с понедельника по пятницу. Выходные дни в английском пишутся как weekends.

Т.е. ставьте период "Повторять через указанный интервал" = 1.

P.S.
Мы долго ржали еще с утра над этим, а тут еще вы настроение подняли вовремя.

[raz]

Цитата:

На самом деле вы ставите в параметрах диалога повторения периодичность = "День", параметр - "Выполнять каждый день".

Это мы уже прошли.

Я же писал, что у меня есть пакеты, котрые должны выполняться еженедельно по воскресеньям, но выполняются в понедельник.

[Alks]

Цитата:

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

Цитата:

На самом деле вы ставите в параметрах диалога повторения периодичность = "День", параметр - "Выполнять каждый день".

Это мы уже прошли.

Я же писал, что у меня есть пакеты, котрые должны выполняться еженедельно по воскресеньям, но выполняются в понедельник.

Это надо уже смотреть по коду Batch-формы-обработчика, сейчас не могу, но скорее всего тот же самый принцип проблемы - "everyweek" означает "каждую рабочую неделю", а не "каждую календарную"... или что то в этом духе. В общем надо проверять.

[Zeratul]

А в 2.5 есть возможность создания такого класса, который можно запустить по расписанию (в пакетном режиме) ?

[mazzy]

Цитата:

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

А в 2.5 есть возможность создания такого класса, который можно запустить по расписанию (в пакетном режиме) ?

Да. Насколько я помню, этот механизм существует давно и существенно не менялся.