Transcript
Dynamics 365
FastTrack Tech Talk
AX2012 to Finance and
Operations Apps Upgrade
Ankur Srivastava
Mo Alawa
About this Tech Talk
Objectives of this Tech Talk
Understand the end to end process for upgrading from AX 2012 to
Finance and operations apps including:
• Upgrade overview
• Code upgrade estimation and execution
• Data upgrade execution
• Key upgrade considerations and best practices
• Validation
What it doesn’t cover
• D365 Commerce / Retail SDK upgrade
• Data migration approach from AX 2009 / AX 2012
• Extensibility patterns deep dive
Contents
Source system preparation task5
2
Data upgrade preparation (source system)3
Execute4
Availability & Upgrade overview1
Data upgrade troubleshooting steps6
Validate7
Special considerations8
Analyze
9 Resources
Availability & upgrade overview
Availability
▪ Upgrade customers from AX 2012 R2 and
R3 to Finance and Operations apps (10.0.x).
▪ Upgrade from Dynamics AX 2012 RTM isn’t
yet supported.
Tool: Upgrade tools are managed through
LCS.
Upgrade overview
Code upgrade and Data upgrade
ValidateAnalyze
• Fit/Gap analysis
• Estimate code and
data upgrade/
migration tasks
• Create project plan
• Code upgrade
• AX 2012 database
preparation (pre-upgrade
checklist)
• Data upgrade
• Upgrade validation
• Functional test pass
• Cutover testing
• Go-Live
Execute
Source system – AX 2012Target system – Finance
and Operations apps
Analyze
Analyze Process
AX2012 Upgrade Overview
Run the
upgrade
analyzer
Sign up for
LCS
Select the
upgrade
methodology
Create
project plan
Run the Code
upgrade toolFit/Gap
analysis
Analyze – Sign up for LCS
Sign up for a Lifecycle Services trial or partner project
https://lcs.dynamics.com
To perform Analyze activities before you purchase
Finance and Operations, you need to sign up for a
Microsoft Dynamics Lifecycle Services (LCS) trial or
partner project. This lets you deploy your own
Finance and Operations environments. It also gives
you access to the tools in LCS that are used to
evaluate your AX 2012 environment and your
existing custom code.
If you have an existing LCS project for AX 2012, you
must still sign up for an additional LCS project for
Finance and Operations.
Select the upgrade methodology
In your new LCS project, set the project methodology
to Upgrade AX 2012 to Finance and Operations apps
This methodology is made specially for AX 2012
customers who are upgrading
It describes the three phases in detail and provides
links to all the supporting documentation about
the process
Analyze – LCS Project Methodology
Upgrade AX 2012 to Finance and Operations apps
Analyze – LCS Project Methodology in Implementation project
Run the upgrade analyzer
Upgrade Analyzer – AX 2012 pre-prod environment
Against AX2012 Pre-Prod environment
Identifies potential maintenance activities and deprecated features
Gathers data from your AX 2012 environment as part of the regular System diagnostic
service in Microsoft Dynamics Lifecycle Services (LCS).
Upgrade Analyzer Tool Enable strong cryptography
In case of connectivity issues between your AX 2012 environment and LCS, make sure
to verify if strong cryptography is enabled on your AOS machines.
You can view the results of the System diagnostic service in a Microsoft
Power BI report in LCS
To access the Upgrade analyzer report, go to
https://diag.lcs.dynamics.com/UpgradeAnalysisReport/Report/"ProjectID“
Upgrade Analyzer Report
(Replace "ProjectID" with your current project ID, which is an integer that can be found in the URL of your current LCS project).
Upgrade Analyzer Report
Upgrade analysis report Upgrade analysis
Analyze – code upgrade
LCS Service
Service that upgrades code to Finance and Operations apps.
Produces Excel Reports
Use it to estimate code upgrade effort.
Converts code and resolves most issues automatically with respect to over layering.
Run the Code upgrade tool
Analyze – code upgrade
Run the Code upgrade tool – continue….
Sign up for DevOps
Create code upgrade job, “Estimation Only”
Configure code upgrade in LCS
Run “Analyze code”
Upload model store to LCS
Review the report
Analyze code upgrade Configure for code upgrade
Analyze – Migration summary report
In analysis phase, use it to estimate
effort – Still not released yet.
Code analysis summary, including
customization information and remaining
over-layering details.
Analyze – code upgrade
Service which upgrades
code to D365 format
During run if “Estimation Only” is unmarked then
overlayered upgraded code will be
checked-in to DevOps.
Excel report
generated
Code checked into
DevOps
LCS codeupgrade service
Convert
to <XML>
Convert to
overlayering
Merge and
model split
Run auto
migration rules
Output
summary
Automatically Check-in
to DevOps
Deploy VM
via LCS
Map DevOps
to VM
Overlayering to
extension conversion
What does code upgrade tool do?
AX model upgrade overview
Run the Code upgrade tool
Analyze – code upgradeRun the Code upgrade tool – continue….
Verify overlayered upgraded code into DevOps
This is work in progress and will be made available soon. Until that’s released, reach out to Dynamics
365 Migration Programme to get similar assessment done.
In analysis phase we use it to estimate effort (Bucketing concept)
Bucket Type Definition
Small Extension is possible
MediumCan be converted to extensions – traversal is required
If needed, raise extension request
Large All report elements are defined as Large
Not in scope Extension is not possible – traversal is required
TBD Undefined – need to define the bucket size
Analyze – code upgrade
Extensibility request:
Run the Code upgrade tool – continue….
Why extension request are needed?
• Finance and Operations applications exclusively use extensions to customize the product.
• You will discover that some customizations, which were possible with over-layering,
cannot be done through extensions.
• To enable the same business requirements without over-layering, we have added many
extension capabilities and expect to add more going forward.
• If you encounter situation when extension is not possible, you will need to log extension
requests from LCS.
• As a pre-requisite to raising your extension request, make sure to go through the
extension tips blog post. In case you skip this part, your extension requests might be
rejected. You can find more details on FAQ.
Extensibility Requests Tips for logging extensibility requests Extensibility FAQ
Analyze – code upgrade
If you have 3rd party solutions/ISV solutions:
Run the Code upgrade tool – continue….
Ignore the code upgrade output for them
Contact the 3rd party for newer version for Finance and Operations apps.
Analyze – Fit/GapFit/Gap analysis
Use LCS to deploy sandbox environments of Finance and Operations apps.
In LCS preview project: Deploy a demo environment in your own subscription after
setting up a Microsoft Azure connector.
In LCS customer implementation project: Simply deploy
Perform Fit/Gap analysis, especially around new and deprecated features
Deploy demo environment for analysis
Analyze the data – Upgrade v/s Migrate
Upgrade
Data upgrade tool
Upgrade complete data
Use data management framework
Migrate reference, master and document data from legacy or external systems.
Migration
Analyze - Data upgrade preparation (source system)
2
Virtual company3
Data partitions4
Collation1
Database and file share storage for attachments
Data upgrade preparation (source system)
Collation
• AX 2012 supported various database collations
- Checking collation on AXDB: SELECT name, collation_name FROM sys.databases
- If collation doesn’t match SQL_Latin1_General_CP1_CI_AS , you must go through this process to change it.
• Finance and Operation apps support a single database collation (SQL_Latin1_General_CP1_CI_AS)
• Changing database collation (Full details published on Yammer)
- Import the bak file into the D365 dev env
- Export SQL Database (bak format) to bacpac format.
- Make a copy of the .bacpac file, rename it to .zip and then unzip it.
- Edit the Model.xml file.
- Change all Collation values to SQL_Latin1_General_CP1_CI_AS. Update CollationLcid to “1033”.
- Import SQL Database using the modified model.xml file
Database and file share storage for attachments
• AX 2012 offered either database or file shares storage for attachments
• Finance and Operation apps offers blob storage for attachments as a replacement
- Files share storage is no longer supported because cloud-hosted environments cannot communicate with local file shares.
- Database storage has been deprecated in favor of Azure Blob storage.
• Moving attachments to blob storage
- Move document files from on-prem shared location to database by running a script at source. Here is the GitHub link to
get script.
- Post upgrade use migrate option as documented here.
Virtual company• AX 2012 offered virtual company feature to share tables with set of companies
• Finance and Operations apps offers cross company data sharing as an alternative feature
- Virtual companies feature is no longer supported
- Switching tables from company specific to global or vice versa (i.e. Save Data Per Company property) is not allowed through
extensions
• Cross-company data sharing (More details can be found on docs article)
- Cross-company data sharing lets you replicate (share) reference and group data among companies
- Doesn’t offer full parity with virtual company feature
- Documented limitations needs to be considered during design, including data / table groups allowed, maximum allowed
volumes and number of shared companies
- Data upgrade tip: If data was previously shared in virtual company (or table made global), data should be moved to one
company during post sync and cross-company data sharing should be used – More details available in Appendix
Data partitions
• AX 2012 introduced Data partitions starting with R2 to enable data isolation.
• Finance and Operations apps uses database as the isolation container
• Data partitions replacement
- Customers using data partitions must use multiple instances of Finance and Operations if database level separation is a
critical issue.
Analyze – project plan
Project plan template provided in
LCS methodology.
Create project plan
Migration summary + Bucketing – Estimate
extension conversion based on samples
Upgrade analyzer – estimate AX 2012
preparation effort
Sandbox environment – First Fit-Gap
analysis – new customizations may be
needed
Use output from
Execute
Execute
Source system –
AX 2012
Run
pre-upgrade
checklist on
source system
Code upgrade
Source system
preparation tasks Data upgrade
Export
and import
database to
target system
Target system – Finance
and Operations apps
Execute – Switch to the LCS implementation project
The public preview project that you used for the Analyze phase has served its purpose. You can now discard it. For the remaining steps, you require only the project plan that you created in the final step of the Analyze phase.
When you purchase a subscription, you will receive details about how to sign
up for a new LCS project. This project is known as an implementation project
and will be the new permanent LCS project for your subscription, for as long
as you have that subscription. This project differs from the public preview
project in that it's managed by Microsoft. Therefore, this project has these
characteristics –
- All environments in the project are hosted in Azure.
- The Azure subscription that is associated with the project is managed by
Microsoft. Therefore, there is no separate billing for Azure costs. The
costs are covered by your subscription.
- The production environment in the project is maintained by Microsoft.
Therefore, code deployments, upgrades, and infrastructure maintenance
are run directly by Microsoft, not by customer \ partner staff.
LCS Project onboarding
Upgrade AX 2012 to Finance and Operations apps
When you first sign in to your LCS implementation
project, you're guided through the Project
Onboarding wizard. You can always visit the Project
Onboarding wizard later using the navigation menu next
to Project Settings in your project.
While on the Project Onboarding wizard, in the Project
Scope section, you can use the Legacy System field to
identify the project as an AX 2012 upgrade. It's crucial
that you identify the project in this way, so that the
sandbox infrastructure that is deployed is compatible
with the upgrade process that is outlined here. If this
step isn't completed early in the project, you might
accidentally deploy your Sandbox on a newer
infrastructure that is incompatible with this process. In
that case, the upgrade effort might be delayed.
Execute – code upgrade
Complete the tasks that were planned during the code upgrade estimation step of the
Analyze phase.
From this point onward, code changes in AX 2012 should be frozen. Only emergency code
changes should be allowed in AX 2012. If a change is made, it must be ported manually to
the new code base.
Owner of the intellectual property (IP) should own the DevOps account.
During code upgrade consider proper branching in Devops related to dev\Main\Release.
Draft and always follow naming convention during converting code from overlayering to
extension.
Code upgrade
Get new versions of ISV solutions
Refactor customizations (over-layering) to Extensions
• Start with platform model, then foundation and continue upwards because they reference each other
• Start with database schema objects (EDT, Enums, Tables, View) then move to other sets of objects (Class,
Forms, Query, Menu Items, Menus, Reports). Most importantly, start working on the data upgrade as
early as possible by separating database schema related things in the code upgrade from the rest and
start working on data upgrade in parallel.
• While working on each object during converting them to extension, complete it fully.
• While converting objects to extension, based on complexity of changes either customer can use F&O
Compare tool, or they can use AX 2012 compare tool to identify their customizations.
Redesign deprecated features (AIF & Integration \ Analytics \ Enterprise portal etc…)
Complete code upgrade and compile your extension package.
Do not use Visual Studio to create deployable packages.
Push your latest compiled code to a clean branch and configure DevOps build pipelines
against the clean branch to produce all-in-one deployable packages.
Find out more in this docs article.
Code upgrade – data upgrade script
There are 2 kinds of data upgrade
scripts
In general, we need to write an Upgrade Script when:
Schema ChangeHow to write upgrade scripts
for these changes
New unique index added New unique indexes
Enum Value change Enum values changed
Table/Field deleted Deleting a Table/Field
A new feature is added that requires data to be populated
so that the feature can be used
In case there is corrupted data and needs to be cleaned up
Major Version Data Upgrade scripts
(AX 2012 – D365 v10.0.x)
Minor Version Data Upgrade scripts
(AX7X – D365 v10.0.x)
A breaking schema change is introduced
Appendix (Page 60-64)
Execute – Source system preparation task
Execute – Perform the AX 2012 preparation tasks
• Complete the tasks that the upgrade analyzer tool discovered on source system and that
were documented in your upgrade project plan
• Collation – this activity can be done during importing bacpac database on target system
as explained in analyze phase.
• Use the pre-upgrade checklist to enter data that will be required for the upgrade
procedure.
Execute – Pre data upgrade checklist
• If upgrading from AX 2012 R3, install KB 4035163
• If upgrading from AX 2012 R2, install KB 4048614
• Validate baseline version
• Prepare model metadata
• Prepare security role metadata
• Set up user mapping
• Archive retail salt data
Run and execute all pre-upgrade checklist steps
Install a hotfix in AX2012 (pre-upgrade checklist)
Data upgrade deployable package
Tool: Data upgrade deployable package is
managed through LCS.
• Sign in to LCS.
• Select the Shared asset library tile.
• In the Shared asset library, under Select asset type,
select Software deployable package.
• In the list of deployable package files, find the data
upgrade package that corresponds to your upgrade.
- If you're upgrading from AX 2012, the package name
starts with AX2012DataUpgrade. Select the package
that corresponds to the release you are upgrading to.
For example, AX2012DataUpgrade-10-0.
• Select the package that corresponds to the release that
you are upgrading to.
• After you download the zip file, right-click it, and then
select Properties. Then, in the Properties dialog box, on
the General tab, select Unblock to unlock the files.
Data upgrade deployable package
• Data upgrade deployable package consist
- AXUpdateInstaller
- Runbook
• If you are upgrading a database on a development \ sandbox environment, you can instead execute the data upgrade
package directly from the LCS environment page, using the Maintain > Apply Updates servicing functionality. This
option was not available for sandbox environment earlier but recently it has been incorporated.
• Prefer way is to execute the package manually from the command line via Remote Desktop on the AOS Development
VM.
https://docs.microsoft.com/en-us/dynamics365-release-plan/2019wave2/finance-operations-crossapp-
capabilities/apply-data-upgrade-packages-ax-2012-customers-sandbox-environments#feature-details
Execute deployable packages from the command line (open Command Prompt window as an
administrator)
• Collect topology configuration data
- Extract the files
- In the folder where you extracted the deployable package, find and open the file that is named DefaultTopologyData.xml.
You must specify the VM name and the installed components in this file.
- Go to the extracted folder and run the following command to see a list of all the components that are installed on the
computer. Execute AXUpdateInstaller.exe list and get list of components.
- Update the DefaultTopologyData.xml file with the list of components.
• Generate a runbook from the topology
- AXUpdateInstaller.exe generate -runbookid=[runbookID] -topologyfile=[topologyFile] -
servicemodelfile=[serviceModelFile] -runbookfile=[runbookFile]
• Import the runbook
- AXUpdateInstaller.exe import -runbookfile=[runbookFile]
• Execute the runbook
- AXUpdateInstaller.exe execute -runbookid=[runbookID]
https://docs.microsoft.com/en-us/dynamics365/fin-ops-core/dev-itpro/deployment/install-deployable-
package#generate-a-runbook-from-the-topology
What does data upgrade package do?
Data upgrade package has various steps which includes pre-req, pre-sync, database sync, post-sync, final database sync, stopping and starting various services and many more.
Pre-req• Preparing source database for upgrade process
Pre-Sync and Post-Sync• A lot of new changes happened in metadata from AX 2012 to v10.x as part of standard changes.
• Changes could be anything (Made a field obsolete, bring a unique index on table, populating default values to any new config
tables, any Enum element change etc.), so in these cases we need scripts in place to handle these specific changes. These scripts
are part of standard package and you can find same in application as (ReleaseUpdateDB* classes).
• These scripts run as part of pre-sync and post-sync steps.
Database sync and final database sync• Database Sync is the process of synchronizing the AX metadata (tables, views, entities) of v10.x version into the SQL database of
AX 2012 version. It uses some internal tables (SqlDictionary) in the database to track the state of the metadata as persisted in
the DB and compares it with the new metadata that is being deployed. When changes are detected, modifications are made to
the Sql in order to bring the DB in sync with the metadata.
Execute - Data upgrade troubleshooting steps
Troubleshooting data upgrade script errors while executing runbook manually
• Rerun the runbook after a data upgrade script failure
- AXUpdateInstaller.exe execute -runbookid=[runbookID] -rerunstep=[stepID]
- When you're debugging, you don't have to rerun the whole data upgrade piece and database synchronization. You can keep
rerunning just the script that fails.
• View more details about a script error
- Upgrade scripts run in X++ by using a batch process that the runbook installer starts. In Application Explorer in Visual Studio,
some classes that you can view are prefixed with ReleaseUpdate. If an upgrade script fails during the runbook process, you
can learn more about the reason for the error by opening Microsoft SQL Server Management Studio and running the
following code to query ReleaseUpdateScriptsErrorLog.
- select * from RELEASEUPDATESCRIPTSERRORLOG
• Skip failed scripts –
- This process is intended to be used only in a development scenario.
- You can skip all scripts that have failed a specific number of times and move to the next viable scripts. This functionality helps
with the troubleshooting process. By design, the process is very manual, so that you're less likely to unintentionally skip
scripts.
Troubleshooting data upgrade script errors while executing runbook manually
• Monitor the duration of scripts that are run
- Every script that is successfully run records the number of minutes that it took in
the ReleaseUpdateScriptsLog.DurationMins column. Therefore, you can easily identify the longest-
running scripts when you're trying to tune the performance of the data upgrade process. Note that
the duration is the amount of time that each script takes to run. However, because multiple scripts run
in parallel, the sum of values in the DurationMins column will exceed the overall duration of the
upgrade process.
• Event viewer – to track progress and failure
- Event Viewer > Applications and Services Logs > Microsoft > Dynamics > AX-DataUpgrade
Pre-Sync and Post-Sync script details are logged in this section of event viewer.
- Event Viewer > Applications and Services Logs > Microsoft > Dynamics > AX-DatabaseSynchronize
Database sync and final database sync details are logged in this section of event viewer.
Data upgrade development \ sandbox environment
Data upgrade on development environment Data upgrade on sandbox environment
• It provides local data that developers can write and test their
custom data upgrade scripts against.
• It helps reduce the overall time that is spent on iterations of the
data upgrade process. In a development environment, an issue
can be debugged immediately, code can be adjusted, and the
upgrade can be rerun within minutes.
• Cloud hosted \ Development environment uses Microsoft SQL
Server.
• This process needs bak file to be import on cloud hosted \
development environment.
• Sandbox refers to a Standard or Premier Acceptance Testing
(Tier 2/3) or higher environment connected to a SQL Azure
database. On this environment business users and functional
team members can validate application functionality. This
functionality includes customizations and the data that was
brought forward from Microsoft Dynamics AX 2012.
• A sandbox environment uses Microsoft Azure SQL Database for
data storage.
• This process needs bacpac file to be import on sandbox
environment.
Data upgrade in development environments
Target as cloud hosted environment
Target as cloud hosted environment
• Back up your AX 2012 database as bak file format
• Upload the backup to Azure Storage
• Download and restore the backup to the development environment (cloud-hosted
environment)
• Run the data upgrade deployable package
- Execute the package manually
- Execute the package through LCS
• Cloud hosted \ Development
environment uses Microsoft SQL
Server.
• This process needs bak file to be
import on cloud hosted \
development environment.
Data upgrade in sandbox environments
Target as sandbox environment
Target as sandbox environment • Turn off the AX 2012 AOS instances
• Create a copy of the AX 2012 database
• Run the T-SQL script to prepare the database
- This is important if your AX 2012 R2 or R3 application was upgraded from AX 2012 RTM.
- This script prepares the database by removing users, removing procedures related to the
AX 2012 RTM model store, cleaning up schemas, dropping views, and dropping
references to tempDB
• Export the copied database to a bacpac file by using a SQLPackage.exe tool
• Upload the bacpac file to Azure storage or the LCS Asset Library
• Import the bacpac file into SQL Database
• Run the following script against the imported database. The script performs following actions
- Recreates database users
- Sets the correct performance parameters
- Enables the SQL Query Store feature
• Run the appropriate data upgrade package against the imported database through LCS
• A sandbox environment uses
Microsoft Azure SQL Database for
data storage.
• This process needs bacpac file to be
import on sandbox environment.
Validate
Data upgrade and application validation:
Smoke test to answer these questions
Validate
Did all the services start?
Are all application components accessible?
Number of records in important tables?
Is the expected data there?
Does General Ledger reconcile to AX 2012?
Does Inventory reconcile to AX 2012?
Application functional validation
Data validation workspace
Validate
Final steps:
Perform cutover testing: Technical and functional
Complete functional testing (Functional test pass)
Smoke test to answer these questions (Prepare for Go-Live)
Create cutover plan
Project template available in methodology
Code freeze
Application configuration freeze
Final cutover test
Upgrade cut-over testing App validation process Upgrade functional validation Upgrade go-live prep
Go live
Start
Perform
smoke testEndAllow users
back in
Complete
application
setup
Downtime
Copy database
to production
Turn off AX2012
AOSes
Backup your
AX2012 DB &
run TSQL
against original
Export to
bacpac, upload
to AOS machine
Import
the bacpac
to sandbox
environment
Execute data
upgrade
2012 Upgrade Cutover
Special considerations
Special considerations
Transactional replication
• Transactional replication (For large database)
- Transactional replication is the automated periodic distribution of changes between databases. Data is copied in (or near)
real-time from the primary server (publisher) to the receiving database (subscriber). Thus, transactional replication offers an
excellent backup for frequent, daily databases changes.
• Cutover time
- Cutover testing (Mock cutover) - The purpose of upgrade cutover testing (mock cutover) is to practice the cutover process,
to help guarantee a smooth experience for everyone who is involved during the actual cutover to Go-Live.
- Cutover (Go-Live) - Cutover is the term that we use for the final process of getting a new system live. This cutover process
consists of the tasks that occur after Microsoft Dynamics AX 2012 is turned off but before Finance and Operations is turned
on. Before you plan your final cutover, you need to successfully complete one successful mock cutover as described
in Cutover testing.
• Upgrade timing
- Data upgrade timings on Tier-1 environment or Tier-2 environment(s) varies based on database to database level as every
database is unique and different from others. So if you trying to predict actual data upgrade during cutover planning then
possible prediction can be done once you successfully complete data upgrade on Tier-1 and Tier-2 environment based on
your volume. Also in actual production upgrade run take extra 20-30% buffer time what it took in Tier-2 environment.
Resources
AX2012 Upgrade Overview
Upgrade Analyzer Tool
System Diagnostics Services
Analyze code upgrade
Configure for code upgrade
Extensibility Requests
Deploy demo environment for analysis
Prepare to migration code
Configure VSO Solution
Extensibility
Target as cloud hosted environment
Target as sandbox environment
Data upgrade on development environment
Data upgrade on a sandbox (Tier2+)
environment
Data validation workspace
Upgrade cut-over testing
App validation process
Upgrade functional validation
Upgrade go-live prep
2012 Upgrade Cutover
Upgrade document management
Transactional replication
Partitions
Thank you.
Setting up the Script Class
• Create a new class – Name convention
- ReleaseUpdateDB<Release>_<CustomerPackageName>
• Ensure the class extends the ReleaseUpdateDB class
• Override the moduleName and myVersion methods
• Upgrade Scripts are composed of the following parts
- Upgrade Attributes - tell the upgrade framework how and when to schedule the script during the Upgrade Process.
- Upgrade Script body - does the actual data manipulation.
Appendix 38
Upgrade Script Attributes• Upgrade Stage - Major Version Upgrade Stages
- UpgradeScriptStageAttribute(ReleaseUpdateScriptStage::PreSync) - Tells the Upgrade framework to schedule the script
during the PreSync step of a Major Version Upgrade
- UpgradeScriptStageAttribute(ReleaseUpdateScriptStage::PostSync) - Tells the Upgrade framework to schedule the script
during the Post-Sync step of a Major Version Upgrade
• Script Type
- UpgradeScriptTypeAttribute(ReleaseUpdateScriptType::SharedScript) - Tells the Upgrade Framework to schedule the
script as a Shared Script. The script will run only once. Use this when the SaveDataPerCompany and SaveDataPerPartition
properties on the table being accessed by the script are both set to No
- UpgradeScriptTypeAttribute(ReleaseUpdateScriptType::StandardScript) - Tells the Upgrade Framework to schedule the
script as a Standard Script. The script will run once for each company (DataArea) in the System. Use this when the
SaveDataPerCompany property on the table being accessed by the script is set to Yes
- UpgradeScriptTypeAttribute(ReleaseUpdateScriptType::PartitionScript) - Tells the Upgrade Framework to schedule the
script as a Partition Script. The script will run once for each Partition in the System. Use this when the SaveDataPerPartition
property on the table being accessed by the script is set to Yes and the SaveDataPerCompany property is set to No
• Script Dependencies - In some instances, we need to ensure a script runs after another script. We
have the following attributes to deal with this:
- UpgradeDependsOnTaskAttribute: Used to specify dependencies between scripts within the same class
- UpgradeDependsOnModuleAttribute: Used to specify dependencies between scripts that live in different classes
- UpgradeDependsOnVersionAttribute: Used to specify dependencies between scripts that live in different classes and whose
myVersion() method returns different versions
Code upgrade – data upgrade script Example 1
PaymSchedLine – Compare to AX 2012, we added a unique index
“NameLineNumIdx” in F&O apps
- Added logic in PreSync to disable unique index
- Update PaymSchedLine table to include NameLineNumIdx{Name, LineNum} as
unique key during PostSync process
Code upgrade – data upgrade script Example 2
WHSContainerType – In AX 2012, as part of customization, customer changed table property
“SaveDataPerCompany” to “No”
- In Finance and Operations apps extension, we can not change table property “SaveDataPerCompany”. In database coming from AX
2012, due to customization there will be no dataareaId on table. But with respect to Finance and Operations apps during first
database synchronization in upgrade run dataareaId will be defaulted with ‘DAT’ company. So with PostSync process move data to
one company and then use cross-company data sharing
Code upgrade – data upgrade script Example 3
A new feature is added that requires data to be populated so that the feature can be used
- In F&O apps there is a new field (fileId) added to DocuValue table. We have a PostSync script for populating the FileId column with a
unique GUID on each row.
Appendix 38
top related