Выравнивание идентификаторов (Prod --> Test --> Dev и Prod --> Stage) в Axapta 2012 R3

[Logger]

Всем привет.

А кто-нибудь пробовал применять axUtil.exe idkeep
для выравнивания идентификаторов между окружениями аксапты ? (Prod --> Test --> Dev)

Зачем...

В 2012-й аксапте используется "Installation-Specific Element IDs" (https://learn.microsoft.com/en-us/dy...lement-handles)
т.е. идентификаторы в каждой инсталляции свои.

Это создает ряд проблем.
Например,
1. если хотим в дев / тест базу перенести данные из рабочей, то приходится в куче мест (в стандартном коде) перебивать идентификаторы, так как в базе с данными остается много мест, где связь идет по идентификатору таблицы, поля, в пакетных обработках и прочих местах ссылка идет по идентификатору класса. В номерных сериях по номеру EDT, в SysDataBaseLog ... в общем лучше не заглядывать. Т.е. как обычно новую концепцию внедрили, но в стандартном коде все не "причесали".

2. если у нас есть Stage инсталляция для подготовки релизов на рабочую, то идентификаторы в ней должны быть такие же как в рабочей. Иначе при синхронизации после релиза можно потерять данные.
подробнее как с этим обращаться описано в документе "Deploying customizations across Microsoft Dynamics environments"

А если идентификаторы у Prod и Stage стали отличаться ? (этого легко достичь, например, если при помощи xpo накатить проект из теста на рабочую, так как идентификаторы при переносе через xpo или через модель не сохраняются. Также не помогает если из теста сперва перенести на Stage, а из Stage на Prod. Для 2012-й это не помогает. (Для 2009-й и предыдущих версий помогало))

Что же в таком случае предлагает официальная документация ?
https://download.microsoft.com/downl...vironments.pdf

Цитата:

If you use model store files to move metadata between two environments, it is critical to preserve common element IDs between both environments. To preserve common IDs between staging and production, adhere to the following guidelines:
• Initialize the model store of the staging system by importing the model store file from the production environment.
• Do not import new elements (by using XPOs or model files) or create new elements on the production system; otherwise, they will have a different element ID than they have on the staging system.
• Do not delete and re-import models to avoid generating new element IDs. Instead, import models without deleting the existing ones to update the metadata.
• Do not import a model store to the staging environment from a source other than the production system’s model store.
If you do not follow these guidelines, you will have to recreate the staging environment from the production environment.

В общем, куча запретов, а лекарство одно - пересоздать Stage модель экспортом из рабочей через .axmodelstore
(Кто придумал отказаться от идентификаторов в xpo ? Поубивал бы )


При этом когда обновляешь приложение с Ax4 или Ax2009 на Ax2012 то в "code upgrade checklist" есть пункты
1. Export baseline element IDs
Creates a CSV file containing baseline IDs. See Help for instructions on using AxUtil to preserve the IDs during upgrade.

2. Preserve legacy element IDs
Shut down the AOS, run AxUtil to set legacy IDs using the CSV file containing baseline element IDs, and perform a kernel compile. Click the Help link for more information.

1-й пункт выгружает в csv файл информацию об идентификаторах из aod файлов 4-ки/2009-й аксапты загруженных в baseLine модель. (используется класс SysUpgradeExportIds)
2-й содержит описание как при помощи axUtil.exe idkeep загрузить идентификаторы элементов из сформированного csv файла в приложение ax2012. (реально запускается хранимка XU_IdAndRenameFixup из базы модели, а эта хранимка перезаписывается каждый раз при выполнении axutil.exe schema - текст берется из ресурса Microsoft.Dynamics.AX.Framework.Tools.ModelManagement.Scripts.AX_SQL_IdAndRenameFixup.sql из файла ..\ManagementUtilities\AXUtilLib.dll )

Т.е. на первый взгляд делает то, что нам нужно. Странно только почему такой способ не предлагался в документе "Deploying customizations across Microsoft Dynamics environments"

Попробовал сделать так. Выгрузил из рабочей идентификаторы. Импортировал в DEV модель.
Идентификаторы выровнялись!

Но! Начал падать аос ) (поработает 1-3 минут и валится)

Стали разбираться.
Оказывается, хранимка XU_IdAndRenameFixup содержит ошибку. При перебивке идентификаторов в DEV модели она сперва находит конфликтующие идентификаторы в полях таблиц (одинаковые идентификаторы, но разные имена полей) и меняет идентификаторы в дев модели загоняя их в свободные значения, чтобы тем самым избежать конфликта. Но выделение новых номеров сделано с ошибкой, должен вестись отдельный счетчик идентификаторов для каждой таблички (там так и пытались сделать), но из-за ошибки счетчик получился глобальный и при большом числе конфликтующих полей идентификатор загоняется в значения >61440 т.е. в область системных значений. Аос такие поля перестает "видеть", а потом вообще валится.
Стало понятно почему в ресурсе
Microsoft.Dynamics.AX.Framework.Tools.ModelManagement.Scripts.AX_SQL_IdAndRenameFixup.sql
в AXUtilLib.dll
в тексте sql скрипта было написано
-- =================================================================================
-- Procedure Name : XU_IdAndRenameFixup
-- Summary : Handles retain ID for current installation based on id fixup and rename fix information
-- : *This store procedure is developed solely to support upgrade scenario from pre-AX6 to AX6*
-- =================================================================================

Видимо авторы понимали багованность этой хранимки (там в коде еще разные костыли есть, здесь уже не описываю) и поэтому не рискнули ее рекомендовать к использованию для всех случаев.
А как же мы смогли успешно с 4-ки конвертнуться ? Похоже или повезло или изначально при инсталляции 2012-й идентификаторы полей таблиц легли так что конфликтов с нашим приложением от 4-ки было мало и поэтому счетчик не вынесло до значения 61440 (начинает считать он от 60001 т.е. число конфликтов было меньше чем 1440)


Но ведь если нельзя, но очень хочется (очень надо), то можно ?

В общем, я исправил найденные ошибки в хранимке. Попробовал, все работает. Идентификаторы не уходят в системную область, аос не падает, все работает.

Как предполагается использовать.

А. Перенос бизнес данных из Prod на Test
примерный порядок действий :
1. Sql скрипт выкладывает бекап рабочей на шару.
2. Пакет аксапты выкладывает csv файл с идентификаторами из рабочего приложения на шару. (по мотивам SysUpgradeExportIds написали свой пакет SysUpgradeExportIds_MRC с некоторыми оптимизациями. Самое главное, что работает с текущим приложением, а не baseLine и выгружает только идентификаторы usr слоя, так как остальные слои у нас и так одинаковые во всех средах)
3. Стопим Test аос
4. Поднимаем бекап с бизнесданными
5. Запускаем в базе модели XU_AllFixes_MRC.sql (Он пересоздает хранимку XU_IdAndRenameFixup, исправляя в ней баги, досоздает вспомогательные хранимки)
6. Запускаем AXUtil.exe idkeep /idfile:SysUpgradeExportIdMap /renamefile:renameFile /s:YoureSQLServerName /db:Your_Test_model /verbose /noPrompt
(здесь нужно подставить путь к шаре с csv файлом SysUpgradeExportIdMap.csv который сформировал пакетник на шаге 2. Также нужно подложить пустой файл renameFile.csv
в моем случае перебивка длилась минут 25 (для размера SysUpgradeExportIdMap.csv примерно в 13 мегабайт). При этом SQL немного подвисал, так что не всегда можно было обратиться к метаданных. Аналогичное поведение было при конвертации базы. Это нормально.
7. Выполнить в базе с бизнесданными код delete [dbo].[SYSSQMSETTINGS]
это очень важно, так как эта запись содержит guid, который подставляется в имя кэш auc файлов. После перебивки идентификаторов их надо очищать, но проще очистить табличку SYSSQMSETTINGS, тогда все эти кеши инвалидируются.
8. Делаем глобальную компиляцию в многопотоке через AxBuild (аос не стартуем, так как в случае наших кастомизаций на системных классах, поведение может быть непредсказуемым. Когда в коде стоит вызов Myclass::MyMethod то реально в байткоде виртуальной машины вместо Myclass хранится его идентификатор, который мог измениться и поэтому может вызваться непонятно что, в лучшем случае просто ошибка времени выполнения. Поэтому если аос стартует, то надо его запускать с ключом -noauto а это как раз и присходит при AxBuild
Также лучше в \Classes\Application\new закомментировать вызов this.syncApplTables();
9. Запускаем аос.
10. Проверяем возможные проблемы компиляции, докомпиляем что надо.
11. Сбрасываем кеш (запускаем менюитем SysFlushAOD - это важно так как чистит SysExtensionCache который хранится в SysLastValue)
12. Собираем CIL
13. Радуемся.

Если решили просто выровнять идентификаторы в приложении без переноса данных с рабочей, то все немного сложнее, так как в базе с данными уже есть идентификаторы, соответствующие тестовой модели и их надо перебить.
Были темы на форуме как это делать
Программное воссоздание записей SqlDictionary для определенной таблицы
Также можно воспользоваться классом SysStartupCmdRestorePost_MRC (он корректно обрабатывает таблички с наследованием)


Как это тестировалось
1. примерно 4-5 прогонов на специальном окружении (модель взята из разработки, база с бизнесданными пустышка, идентификаторы из рабочей)
2. один раз сконвертировали приложение в тесте одновременно с переносом базы с бизнесданными из рабочей.

Вижу много плюсов для себя. Удобнее после этого обращаться с тестовой базой, когда идентификаторы такие же как в рабочей.
Также время перебивки идентификаторов фиксировано (по времени похоже проще перебивать идентификаторы в приложении чем в базе с бизнесданными, которая может быть намного больше по объему)

Что еще будем проверять
1. Вариант, когда выгружаются идентификаторы не со всего usr слоя рабочей базы, а для элементов, созданных позже какой то даты (должно сильно уменьшить объем и ускорить процесс.) Класс выгрузки SysUpgradeExportIds_MRC - поддерживает такой режим. Просто руки не дошли.
2. Попробуем перебить идентификаторы в Stage инсталляции (чтобы не пересоздавать ее заново). Но тут немного стрёмно.