SysOperationFramework

[Eldar9x]

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

Создал контроллер, создал контракт данных. Появились два вопроса:

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

[AndyD]

Для начала, почисти кэш

Сервис/Кэши/Обновить элементы

Ну и можешь остальные пункты меню там дернуть

По п.1 - возможно, надо сделать инкрементный CIL
Или отключить его выполнение

[db]

про второй пункт
Microsoft Dynamics AX 2012 White Paper: Introduction to the SysOperation Framework

[Kabardian]

Только недавно бурил тему SysOperation, вопросов больше чем ответов... Поэтому делюсь своими источниками по теме.

Для быстрого погружения советую статьи:

1. AX2012: SysOperation introduction - это оглавление для цикла из трех вводных статей.
2. Business Operation Framework and multi-threading - про многопоточность в пакетной обработке.

Наглядное сравнение SysOperation и RunBaseBatch:

1. From RunBase to SysOperation : Business Operation Framework
2. From RunBase to SysOperation : Business Operation Framework (Cont'd)

Ну и для глубокого погружения во фреймворк рекомендую книгу Microsoft Dynamics AX 2012 Services. Книга про сервисы в AX 2012, очень хорошо гуглится для бесплатного скачивания. Также есть книга для AX 2012 R2.

[АртемМелихов]

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

[gl00mie]

Инкрементный CIL не настолько инкрементный, как может показаться Сборка приложения (Dynamics.Ax.Application.dll) состоит из примерно тысячи отдельных файлов - netmodule'ей, и минимальной единицей инкрементной компиляции CIL является такой netmodule. Ядро старается сделать netmodule'и примерно одинаковыми по размеру и для этого как-то там по-своему распределяет объекты приложения между ними. Таким образом, в общем случае при инкрементной компиляции CIL, во-первых, в netmodule кроме изменившихся объектов приложения попадает еще несколько десятков других объектов, которые не менялись, а во-вторых, если изменившихся объектов приложения много, весьма вероятно, что они попадут в несколько разных netmodule'ей. Из-за этого получается, что при инкрементной компиляции CIL после изменения даже одного объекта ядро перекомпилирует десятки и сотни объектов приложения. Проблемы с не изменившимися объектами при этом, как правило, возникают из-за проблем в компиляции кода X++; лечится это, соответственно, компиляцией кода X++ проблемных объектов либо глобальной компиляцией с помощью той же axbuild.

[АртемМелихов]

После ин.комп. получаю вот такую ошибку "невозможно создать запись в SysXppAssembly (SysXppAssembly). Запись уже существует." Что может помочь?

[gl00mie]

trancate этой таблицы в базе модели и затем полная компиляция CIL

[Logger]

Цитата:

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

Инкрементный CIL не настолько инкрементный, как может показаться Сборка приложения (Dynamics.Ax.Application.dll) состоит из примерно тысячи отдельных файлов - netmodule'ей, и минимальной единицей инкрементной компиляции CIL является такой netmodule. Ядро старается сделать netmodule'и примерно одинаковыми по размеру и для этого как-то там по-своему распределяет объекты приложения между ними.

А мы можем влиять на это распределение ?
Например запихнуть туда объекты из одного проекта или относящиеся к одному конф. ключу. Чтобы фрагментацию уменьшить.

[gl00mie]

М... похоже, что можно В \Classes\SysCompileIL\generateIncrementalIL есть такой код:

// Dump incremental xml files
changeFound = !dumpChanges || SysCompileIL::dumpIncrementalBulk();
if(changeFound)
{
    AppVersionStr = ApplicationVersion::applBuildNo();
    AppVersion = new System.Version(AppVersionStr);

    xppILAppDomain = xApplication::XppILAppDomain();

    parameters = new Microsoft.Dynamics.Ax.Xpp.GeneratorParameters();
    parameters.set_AppVersion(AppVersion);
    parameters.set_AssemblyName(#XppDllName);
    parameters.set_EnableDebugging(true);
    parameters.set_EnumFile(xmlPath + '\\Enums.exml');
    parameters.set_NumberOfModules(#NumberOfModules);
    parameters.set_WritePath(writePath);
    parameters.set_XmlPath(xmlPath);
    parameters.set_OldAssemblyName(xppAssemblyPath);
    parameters.set_GeneratorAppDomain(xppILAppDomain);
    parameters.set_IsDebug(Debug::isDebugOnAOSEnabled());
    parameters.set_LogFolderPath(writePath);

    modifiedModules = Microsoft.Dynamics.Ax.Xpp.XppILGenerator::GenerateIncrementalAssembly(parameters);

Здесь видно, как собственно запускается инкрементная компиляция. А вот в вызываемом методе SysCompileIL::dumpIncrementalBulk() есть такие интересные строчки:

SysModelElement sysModelElementChildren, sysModelElementSameBucket;
SysModelElementData sysModelElementData;
SysCompileILTable sysCompileILTable, sysCompileILTableSelfJoin;

// insert any type that has changed.
insert_recordset sysCompileILTableSelfJoin(Name, ModelElement, ElementType, AxId, GenerateType)
select Name, RecId, ElementType, AxId, generateType from sysModelElementSameBucket
exists join sysModelElementChildren where sysModelElementChildren.ParentModelElement == sysModelElementSameBucket.RecId
    && (sysModelElementChildren.ElementType == UtilElementType::ClassInstanceMethod
    || sysModelElementChildren.ElementType == UtilElementType::ClassStaticMethod
    || sysModelElementChildren.ElementType == UtilElementType::TableInstanceMethod
    || sysModelElementChildren.ElementType == UtilElementType::TableStaticMethod
    || sysModelElementChildren.ElementType == UtilElementType::TableRelation
    || sysModelElementChildren.ElementType == UtilElementType::TableField)
exists join sysModelElementData where sysModelElementData.ModelElement == sysModelElementChildren.RecId && sysModelElementData.ModifiedDateTime >= modifiedDateTime;

// Insert types in same bucket as types that changed
update_recordset sysCompileILTableSelfJoin setting NetModuleId = (sysCompileILTableSelfJoin.AxId / #GroupSize) mod #NumberOfModules;
insert_recordset sysCompileILTable(Name, ModelElement, ElementType, AxId, GenerateType)
select Name, RecId, ElementType, AxId, generateType from sysModelElementSameBucket
where sysModelElementSameBucket.ElementType == UtilElementType::Class || sysModelElementSameBucket.ElementType == UtilElementType::Table
exists join sysCompileILTableSelfJoin where sysCompileILTableSelfJoin.NetModuleId == (sysModelElementSameBucket.AxId / #GroupSize) mod #NumberOfModules;

Самое интересное тут - установка поля SysCompileILTable.NetModuleId:

update_recordset sysCompileILTableSelfJoin setting NetModuleId = (sysCompileILTableSelfJoin.AxId / #GroupSize) mod #NumberOfModules;

Используемые при его вычислении макросы #GroupSize и #NumberOfModules определены в \Macros\XppIL:

#define.NumberOfModules(1000)
#define.GroupSize(10)