Вопрос по multi-thread batch posting SO. DAX 2009

[HorrR]

Здравствуйте,

Возникла задача в конце батч постинга сейлз ордеров(picking list) выполнять некоторые свои действия(то есть, после того как постинг был выполнен для ВСЕХ ордеров).
Собственно переход к multi-thread батч постингу виден в SalesFormLetter.run().
Там для каждого sales хедера попавшего под условия запроса(query) добавляется runtime task в виде экземпляра FormLetterMultiThread.
Проблема в том, что я не уверен насчет того, в какой последовательности эти таски потом отрабатывают. То есть, есть догадки, но нет точного знания.
Интуиция подсказывает, что, скорее всего, мой код нужно добавлять в SalesFormLetterEndMultiThread, а то, что в SalesFormLetter.run() его инстанс добавляется ДО добавления индивидуальных FormLetterMultiThread инстансов наталкивает на мысль о стэке тасков в батче(LIFO). Ну и, скорее всего, потом эти таски вынимаются на параллельное выполнение из батч хэдэра бандлами по N штук, где N - параметр количества батч потоков на сервере.

НО, во-первых, это только догадки, и всё же хотелось бы спросить умных и опытных людей на сколько они близки к правде.
Во-вторых, можно ли как-то явно указать, чтобы таск добавленный в батч хэдер был выполнен обязательно ПОСЛЕ всех остальных тасков или же этого можно добиться только порядком добавления таска в батч хэдэр? Если второе, то каким образом гарантируется, что SalesFormLetterEndMultiThread не будет выполнен параллельно с одним из FormLetterMultiThread или параллельность в таком случае зависит от classID процесса?

П.С. Заранее прошу прощения за вопросы, которые кому-то, возможно, покажутся ламерскими. Уповаю на вашу снисходительность и опыт

[Maximin]

Добавить runtime task с зависимостями от всех остальных runtime task разносок. Место где пилить указано верно.

[fed]

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

   if(printout == Printout::After)
          {
                        batchHeader.addDependency(salesFormLetterEndMultiThread,formLetterMultiThread,BatchDependencyStatus::FinishedOrError);
          }

Так что гипотеза про бандлы и LIFO - не верна. Система просто тупо запускает (по крйней мере - переводит в статус Ready) все задачи у которых либо нету зависимостей либо все зависимости уже завершились. Если есть большое желание, можно самостоятельно раскопать логику активации задач в классе BatchRun::ServerProcessDependencies...

[HorrR]

Цитата:

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

Добавить runtime task с зависимостями от всех остальных runtime task разносок. Место где пилить указано верно.

Спасибо за быстрый и обнадеживающий ответ!
По поводу dependencies это то собственно и смущало, это ж, стало быть, если постятся 200 ордеров то (допустим, что у нас не summary update, но и не split by delivery information) это 200 dependencies для одного моего таска. Эффективно ли для системы будет каждый раз при взятии на обработку нового бандла тасков проверять эти зависимости. Так что попробую модифицировать SalesFormLetterEndMultiThread. И уж если не получится, тогда создам свой батч и добавлю к нему зависимости через BatchHeader.addDependency.

[HorrR]

Цитата:

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

В SalesFormRun зависимости создаются вызовом:

   if(printout == Printout::After)
          {
                        batchHeader.addDependency(salesFormLetterEndMultiThread,formLetterMultiThread,BatchDependencyStatus::FinishedOrError);
          }

Вы про SalesFormLetter.run? Если да, то в 2009 такого когда в run нет. Возможно это справедливо для 4ки или 2012, которых у меня под рукой нет.
То есть между salesFormLetterEndMultiThread и formLetterMultiThread никаких зависимостей в коде SalesFormLetter не устанавливается. Более того, в 2009 salesFormLetterEndMultiThread выполняется только один раз за весь постинг. То есть, создается всего один инстанс и ДО создания индивидуальных formLetterMultiThread инстансов(под каждый salesParmTable).

[fed]

Цитата:

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

Вы про SalesFormLetter.run? Если да, то в 2009 такого когда в run нет. Возможно это справедливо для 4ки или 2012, которых у меня под рукой нет.
То есть между salesFormLetterEndMultiThread и formLetterMultiThread никаких зависимостей в коде SalesFormLetter не устанавливается. Более того, в 2009 salesFormLetterEndMultiThread выполняется только один раз за весь постинг. То есть, создается всего один инстанс и ДО создания индивидуальных formLetterMultiThread инстансов(под каждый salesParmTable).

Код взят из SalesFormLetter.run(), DAX2009CU8. На голом SP1 похожий код тоже есть, просто перед ним нету if()

[HorrR]

Цитата:

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

Код взят из SalesFormLetter.run(), DAX2009CU8. На голом SP1 похожий код тоже есть, просто перед ним нету if()

Хм, что-то крайне странное. Сравнил компаратором SYS и SYP.

В итоге на SYP пропала строчка(именно та, о которой вы говорите)

batchHeader.addDependency(salesFormLetterEndMultiThread,formLetterMultiThread,BatchDependencyStatus::FinishedOrError);

Зато появилось следующее:

ttsbegin;
    batchHeader.save();
ttscommit;

Версия Ax - 5.0.1500.3761 Dynamics AX 2009 SP1 RU-6 (Rollup 6)

P.S. Кажется, я понял причину. На голом SP1 обязательно добавлялся депенденси, чтобы выполнять salesFormLetterEndMultiThread всегда последним. Где-то между голым SP1 и 6 ролапом оказалось, что не всегда, ведь это зависит от того, какое значение у PrintOut. Понять поняли, а пофиксили коряво, просто убрав добавление зависимости. Где-то между 6 и 8мым ролапом одумались и добавили условие с PrintOut

[gl00mie]

Цитата:

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

если постятся 200 ордеров то это 200 dependencies для одного моего таска. Эффективно ли для системы будет каждый раз при взятии на обработку нового бандла тасков проверять эти зависимости.

Нормально там все отрабатывает... 200 зависимостей - это просто 200 записей в BatchConstraints; логика запуска пакетных заданий явно их в любом случае не перебирает, а просто использует запросы обновления статусов пакетников с exists join/notexists join по этой таблице.

[HorrR]

Цитата:

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

Нормально там все отрабатывает... 200 зависимостей - это просто 200 записей в BatchConstraints; логика запуска пакетных заданий явно их в любом случае не перебирает, а просто использует запросы обновления статусов пакетников с exists join/notexists join по этой таблице.

Да, Вы правы.