Выравнивание идентификаторов (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 инсталляции (чтобы не пересоздавать ее заново). Но тут немного стрёмно.

[sukhanchik]

Цитата:

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

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

Можно сделать гораздо проще.
Организуем среду (условно) DEV_OLD
DEV / TEST базу обновляем данными с рабочей. А приложение обновляем тоже с рабочей (или со STAGE - разницы нет).
Дальше даём разработчикам условно неделю-две, чтобы перенести незаконченные модификации с DEV_OLD.

Из плюсов - какие-то незаконченные и заброшенные модификации - просто автоматически исчезают из приложения.
Из минусов - приходится периодически напрягаться в плане переноса - у всех же разное количество объектов в проектах. Однако это может быть облегчено тем, что перед обновлением - многие вещи (типа EDT / таблицы) могут вполне уехать на STAGE и жить "мертвым грузом" на PROD никому не мешая с одной стороны, а с другой стороны - сокращая количество объектов, которые приходится восстанавливать через XPO

[Logger]

Цитата:

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

DEV / TEST базу обновляем данными с рабочей. А приложение обновляем тоже с рабочей (или со STAGE - разницы нет).
Дальше даём разработчикам условно неделю-две, чтобы перенести незаконченные модификации с DEV_OLD.

Спасибо. Вполне рабочий вариант. И много где используется.
Но мне теперь ближе свое изобретение. Наверно потому что свое. И потому что экономит время разработчиков.

[sukhanchik]

Цитата:

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

И потому что экономит время разработчиков.

Вот это вот утверждение сильно зависит от компании. Потому что идентификаторы объектов могут храниться в большом количестве таблиц и в большом количестве записей. Перебить все данные в условном SysDataBaseLog - это явно небыстро.
Перебить все данные, где хранится контейнер с сохраненным запросом (Query) - тоже небыстро. Это только навскидку я вспомнил - про места хранения ID-шников.
В итоге получается, что преобразование базы - это долго, а если этого не делать - то скопированная база будет некорректная с т.з. данных прода. Поэтому да, экономия времени разработчиков есть в той части, что им не приходится перетаскивать объекты. Однако я бы конечно предпочёл бы полноценную копию БД - т.к. на ней гораздо корректнее тестировать. Я к тому, что экономя время разработчика - нельзя забывать о времени консультанта. Если его время увеличивается - то это в общем случае не ведет к общей экономии времени разработки.

А компания компании рознь - кто-то может организовать несколько индивидуальных виртуалок с копией рабочей БД, а у кого только бекап 3 дня делаться будет. И в условиях ограниченности возможностей тестирования - конечно выбираешь такой подход, который бы лучше подходил под реалии.

А идея интересная, спасибо!

[Logger]

Цитата:

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

Вот это вот утверждение сильно зависит от компании. Потому что идентификаторы объектов могут храниться в большом количестве таблиц и в большом количестве записей.

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

Насчет Query не понял вашу мысль. Вы имеет в виду что бинарные объекты могут в себе содержать ссылки по идентификаторам и их тоже надо обрабатывать ? Если они хранятся в бинарном виде в базе с бизнесданными (SysLastValue, Batch.Parameters, etc) то тем лучше для нас - нам не придется их трогать. А если в модели, то это может быть проблемой. Придется пересоздать / обновить. Но с таким примером я пока не сталкивался.

Цитата:

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

Перебить все данные в условном SysDataBaseLog - это явно небыстро.

Да! Так мы и не будем этого делать при предлагаемом подходе. Profit !

[sukhanchik]

Цитата:

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

Насчет Query не понял вашу мысль. Вы имеет в виду что бинарные объекты могут в себе содержать ссылки по идентификаторам и их тоже надо обрабатывать ? Если они хранятся в бинарном виде в базе с бизнесданными (SysLastValue, Batch.Parameters, etc) то тем лучше для нас - нам не придется их трогать.

Да, я имел в виду, что Query.pack() хранится в бинарном виде с бизнес-данными и содержит в себе ID таблиц и полей.
Да, их можно не трогать, но тогда мы не сможем (условно на DEV) увидеть распакованные эти бинарные данные. Безусловно, конкретно для Batch / SysLastValue / SysDataBaseLog эта информация может быть и не нужна, но теоретически могут быть ситуации, когда для целей разработки эта информация может понадобиться. Собственно именно поэтому я ратую за полную копию данных и приложения - в этом случае гарантированно получается полная копия рабочей среды и любые какие-бы ни были задачи для разработчиков - они всегда заведомо могут быть реализованы на данных DEV-системы в условиях, максимально приближённых к реальности

[Logger]

Цитата:

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

Да, их можно не трогать, но тогда мы не сможем (условно на DEV) увидеть распакованные эти бинарные данные.

Мне кажется здесь какое то недопонимание.
Мы не сможем их увидеть распакованными на DEV если идентификаторы в DEV модели отличаются от идентификаторов Prod-модели.
Так я с этого и начал обсуждение - чтобы выравнивать идентификаторы DEV и PROD моделей. Если их выровнять как я предложил то и проблем с распаковкой не будет.

[sukhanchik]

Цитата:

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

Мне кажется здесь какое то недопонимание.
Мы не сможем их увидеть распакованными на DEV если идентификаторы в DEV модели отличаются от идентификаторов Prod-модели.
Так я с этого и начал обсуждение - чтобы выравнивать идентификаторы DEV и PROD моделей. Если их выровнять как я предложил то и проблем с распаковкой не будет.

А... я понял... Т.е. мы обновляем БД PROD-> DEV, а ID-шники меняем в DEV_model на "продовские"

Если так - то всё ок. Действительно у меня было недопонимание.

Единственное что в таком случае интересно... так это ситуация типа внешних кодов ExtCode*-таблицы, когда в релейшне прописывается код таблицы. Я то в таких случаях как делал.... Писал код на DEV, затем переносил на STAGE и там менял ID-шники таблицы в Relation. Затем STAGE "уезжал" на PROD, а когда DEV (приложение + БД) заменялось полностью с PROD-а - то само собой - эта проблема меня уже не беспокоила.

В Вашем скрипте - эта ситуация точно не учтена и изменение IDшников объектов не поменяет значения в релейшнах. Ну... насколько я понял. Верно?

[Logger]

Цитата:

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

Т.е. мы обновляем БД PROD-> DEV, а ID-шники меняем в DEV_model на "продовские"

Да, именно так.

Цитата:

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

Единственное что в таком случае интересно... так это ситуация типа внешних кодов ExtCode*-таблицы, когда в релейшне прописывается код таблицы. Я то в таких случаях как делал.... Писал код на DEV, затем переносил на STAGE и там менял ID-шники таблицы в Relation. Затем STAGE "уезжал" на PROD, а когда DEV (приложение + БД) заменялось полностью с PROD-а - то само собой - эта проблема меня уже не беспокоила.
...
В Вашем скрипте - эта ситуация точно не учтена и изменение IDшников объектов не поменяет значения в релейшнах. Ну... насколько я понял. Верно?

Если там использован тип связи "Field fixed" или "Related field fixed" то, конечно, ничего не поменяется и будет проблема. Тут вы правы.

Но, если связь сделана как ExtCode* табличках (а там использован Normal relation, просто связь идет на фиктивное поле TableId связанной таблички) то думаю, что все будет хорошо. Надо будет протестировать конечно. Но должно быть норм.
А зачем вы явно константу ставили вместо ссылки на поле TableId ? Какой-то баг обходили ?

Скрипт на самом деле не совсем мой. Я просто взял стандартный код и исправил в нем ошибки. Но конечно сильно все перепахал. Так что как бы и мой теперь.

[sukhanchik]

Цитата:

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

Но, если связь сделана как ExtCode* табличках (а там использован Normal relation, просто связь идет на фиктивное поле TableId связанной таблички) то думаю, что все будет хорошо. Надо будет протестировать конечно. Но должно быть норм.

Да, это я затупил - там нет констант. Почему-то был уверен, что там константы.

Константы я использовал в Relation-ах тогда, когда хотел вывести в параметры модуля внешний код для такой-то таблички. Ну, к примеру, "Внешний код спецификаций". Т.е. нужен лукап, который бы фильтровал по коду таблицы.

Но по факту - такие лукапы наверное удобнее делать через код и tablenum(), нежели прописывать в явном виде код таблицы в Relation. Хотя для стандартных таблиц - ID таблицы-то единый - поэтому в принципе критического ничего нет.

Вот, к примеру - таблица из стандартного функционала


А если открыть стандартную табличку AifEndpointActionValueMap - то там вообще страсти...

[Logger]

Ну тем более надо ид-ники выравнивать. Чтоб все было одинаково, строем и с песнями...

[Logger]

Небольшая поправка
в строке

EXEC [dbo].[XU_SetDirtyFlag] 1

лучше поставить параметр 0 т.е.

EXEC [dbo].[XU_SetDirtyFlag] 0

тогда в автоматизированном режиме при запуске из SQL джоба клиент аксапты не должен задавать вопросов про новые установленные модели.

[Logger]

Ха-ха
\Classes\SysUpgradeExportIds_MRC\new
не содержал вызов

super();

для работы в пакете нужно поправить.