Сводное планирование прерывается в batch AX 2012R3

[AK-76]

Добрый день,

AX 2012 R3 CU11 kernel, app 6.3.4000.127, SQL 2014, 3 АОСа в Azure

Достаточно простое по настройкам сводное планирование и странный глюк. При запуске расчета в режиме batch, происходит следующее. Для некоторых единиц номеклатуры выводятся предупреждения

Coverage planning of item XXXXX has been canceled.

Иногда, сводник завершается в произвольном месте.

Если запустить перерасчет пользовательском режиме - все ок, как и из job типа такого для всех номенклатур в цикле.
reqCalcScheduleItem = ReqCalcScheduleItem::newItemId(itemId,reqPlanId);
reqCalcScheduleItem.run();

Что испробовано:
1. Отдельная батч группа - привязанная к одному серверу
2. Количество хелперов 0, 1, 8, 25

На основании документа [https://blogs.msdn.microsoft.com/axi...mance-of-mrp/] - менять настройки, при определенном стечении - становится меньше warnings, становится больше время выполнения, но проблема не решается.

Для теста установлен последний на текущий момент KB то есть kernel 6.3.6000.214, app 6.3.5000.133 там есть изменения в классах ReqCalc, но результат прежний.

Спасибо за идеи.

[fed]

Это у вас срабатывает generic warning, который случается при возникновении произвольной ошибки где-то в RecCalc.covCalcitem().
Я бы это решал так: тупо бы убрал try{}catch блок в этом методе (и пожалуй что еще в ReqCalc.processTask(), которая его вызывает) и ждал бы настоящих сообщений об ошибках.
У вас конечно сводное будет останавливаться при каждой ошибке, но вы просто запускайте его где-нить в тестовом окружении. (Ну или как вариант - запускайте в реальной рабочей среде, но на каком-то второстепенном плане).

P.S. Кстати - не понимаю почему корусовцы (и бывшие и нынешние), называют сводное планирование "сводником". И в Английском и в Турецком - pimp/puşt - достаточно серьезные ругательства...

[AK-76]

Спасибо, Денис, обязательно попробую. А есть идеи, почему в клиентской сессии, не батч это срабатывает без ошибок?

Сводник, ну да, ок, переводил с англ для форума - первое что всплыло.

[fed]

Цитата:

Сообщение от AK-76

Спасибо, Денис, обязательно попробую. А есть идеи, почему в клиентской сессии, не батч это срабатывает без ошибок?

Сводник, ну да, ок, переводил с англ для форума - первое что всплыло.

Единственное что приходит в голову - какие-то проблемы с инфраструктурой батч-сервера. По логике вещей, если запускать батч с числом хелперов==0, то должно работать так же как и в клиентской сесии. То есть - логика параллелизации сводного отрабатывает при условии maxChildThreads!=0.

[AK-76]

Добрый вечер, нашлась интересная деталь. Процесс стал падать и в клиентской сессии, место падения -
class ReqTraceCrimsonLogger.init() line 5 Microsoft.Dynamics.AX.Planning.JobScheduling.JobSchedulingEngineInteropFactory::EnsureLoggerSink();
Какие параметры могут влиять на это? Еще момент, у нас 24/7 работает склад, сводное планирование достаточно простое - склады второго уровня покрываются с главного склада. Возможно ли совмещение?

[fed]

Насколько я помню, если поковырать какие-то настроечные ключи в ax32serv.exe.conf, то этот самый crimson может писать логи планирования ресурсов (в смысле - раскладки операций по рабочим центрам). Еще он глубоко не совместим с hot-swap. Вы там посмотрите - у вас случайно hot-swap на сервере не включен ?

[AK-76]

Hot swap не включен, а какие приблизительно ключи поковырять?

[AK-76]

Цитата:

Сообщение от AK-76

Hot swap не включен, а какие приблизительно ключи поковырять?

В конфигурации АОС ничего похожего найти не удалось.
Все работает если отключить logging таким топорным способом.
(

public boolean loggingEnabled()
{
    return false; //logKeywordEnabled;
}

)

Правильно я понимаю что этот параметр тянется в ReqTraceCrimsonLogger. из класса ReqCalc.parmEnableTableTraceLog(), но даже с помощью ссылок мне не удалось найти его связь с параметрами, доступными для пользователя в параметрах MRP, параметрах плана и параметрах группы покрытия.
Вопрос, можно ли отключить логгинг нормальным способом и на что это может повлиять?