Немного о CIL

В Microsoft Dynamics AX код может быть откомпилирован в CIL и запущен в .NET CLR. 

Разберемся по порядку что это значит.

Компиляция – интерпретация исходного кода в машинноисполняемый формат, который может быть исполнен на сервере или клиенте.

CIL (Common Intermediate Language) – единый переходный язык, работающий совместно с CLI (Common Language Infrastructure) – многоязыковой инфраструктурой, базирующейся на наборе правил языков программирования, которые компилируются в CIL. Одним из самых важных свойств CIL является набор инструкций, не зависящих от платформы и ЦП, что позволяет выполнять код в разных средах.

На рисунке ниже показано, как языки первично компилируются в CIL после чего CLR (многоязыковая среда выполнения) компилирует платформонезависимый код CIL в код, читаемый машиной:

Многоязыковая среда выполнения (CLR – Common Language Runtime) понимает CIL и знает как выполнять этот код. CLR не нужно понимать все языки (C#, VB или F#), ей достаточно знать только один язык, т.к. все они преобразуются в CIL.

Microsoft Dynamics AX может преобразовывать откомпилированный X++ код в код CIL, соответственно, может запускать код X++ в CIL. Необходимо не забывать про CIL при разработке, т.к. код, запускаемый на сервере, такой как пакетные задания и службы, будет запускаться в CIL и, соответственно, такой код X++ нужно предварительно откомпилировать в CIL.

Т.к. компиляция в CIL требует времени, то она не выполняется автоматически при компиляции X++. Необходимо выполнять ее вручную при изменении кода, используя кнопки компиляции на рабочем интерфейсе разработчика.

Можно запустить полную или инкрементную CIL-компиляцию. Основная разница между ними в том, что инкрементная компиляция выполняется только для объектов, измененных со времени последней компиляции, а полная компиляция выполняется для всех объектов. Инкрементная компиляция выполняется быстрее, чем полная, но необходимо понимать, что не всегда достаточно инкрементной компиляции.

Итак, CIL-компиляция выполнена. Но что изменилось и где можно найти результаты этого процесса? Ответ на этот вопрос можно найти в папке bin на сервере. По умолчанию она находится здесь: %ProgramFiles%\Microsoft Dynamics AX\60\Server\<Server Name>\bin\XppIL. 

В этой папке можно найти итоговый файл сборки Dynamics.Ax.Application.dll вместе со списком файлов *.NetModule. Файлы *.NetModule отличаются от сборок .Net, - они не содержат манифеста сборки. Файлы *.NetModule содержат только типовые метаданные и откомпилированный код. Также в этой папке можно найти файлы с разрешением .xpp - эти файлы содержат исходный X++ код и могут использоваться при отладке кода X++ в Visual Studio, таким образом редактор и отладчик могут показывать актуальный исходный код.

Примечание: если установлено несколько экземпляров AOS, то необходимо остановить все экземпляры, и затем перезапустить их. Это необходимо для того, чтобы экземпляры AOS загрузили обновленную сборку.

ПС: если в материале есть какие-либо неточности, то прошу поправить в личном сообщении или в комментарии.

Happy DAXing!

Синхронизация словаря данных

В работе с АХ крайне важным является выполнение синхронизации словаря данных [Data dictionary]. Если не понимать, что это за процесс и для чего он нужен, то в какой-то момент можно столкнуться с проблемами, связанными с синхронизацией.

Запускается синхронизация словаря данных из AOT:

Попробуем разобраться что же такое "синхронизация словаря данных".

Рассмотрим как АХ работает с SQL-сервером. Определения таблиц (имя таблицы, имена столбцов, их тип, длина и т.п.) хранятся в AX. Однако, так или иначе эти данные должны содержаться на SQL-сервере, иначе невозможно будет хранить данные в БД. 

Для этого и используется синхронизация словаря данных. Синхронизация происходит в случае, если таблица еще не существует на SQL сервере, если же таблица существует, то при синхронизации происходит поиск изменений в таблице и АХ пытается внести эти изменения на SQL-сервер. 

На самом деле все довольно просто. Вы просто запускаете синхронизацию таблицы, которую создали, и АХ обработает расхождения. После запуска процедуры синхронизации SQL получит все необходимые данные по физической таблице и сервер сможет работать с данными.

SQL Словарь

Теперь рассмотрим идентификаторы объектов (ID) и SQL-словарь таблиц на SQL-сервере. Каждый объект в АХ получает идентификатор. В АХ идентификатор присваивается объекту в момент его создания (также в момент импорта *.xpo или нового объекта в AOT, или импорта модели).

Разберем как АХ работает с таблицами на SQL сервере. Система берет параметры таблицы в AOTе и переносит их (поля, их названия, длину, тип и т.п.) на SQL. Как же АХ отслеживает, что хранится на SQL сервере? Будет ли достаточно проверки имен объектов? 

Таблица на SQL может быть проверена по имени в AOT. Итак, представим, что изменилось имя поля таблицы с columnA на columnB. Таблица, которая изменилась, не содержит никаких пометок, что ее поля были изменены.

Что же произойдет на SQL сервере, когда будет выполняется синхронизация словаря данных по таблице? Останется старое поле columnA и создастся новое поле columnB? Удалятся ли значения в исходном поле?

Для этого используются «системные» таблицы AX, в которых хранится информация о том, что АХ записала на SQL сервер. Таблица SQLDictionary содержит имена объектов АХ, их имена на SQL сервере и их ID в AX.

ID объектов АХ не могут быть изменены разработчиком вручную в IDE (Integrated Development Environment - интегрированной среде разработки), таким образом, это значение может использоваться для идентификации объекта в случае изменения его имени. Итак, теперь можно дать ответ на вопрос, указанный выше: если изменится имя столбца, то АХ будет искать в SQLDictionary запись, соответствующую столбцу и, если найдет, то обновит ее (заменив старое имя на новое), а если не найдет, то создаст новую запись с новым именем.

Happy DAXing!