There are a couple of great books on Microsoft Dynamics AX 2012 and this is one of them, Microsoft Dynamics AX 2012 Services. I read this book as a preparation for an internal course I did not long ago, and because I already knew SOA (Service Oriented Architecture) is now heavily supported in Dynamics AX 2012. I had also read Michael Fruergaard Pontoppidan's review and got even more encouraged to get myself a copy.
The first part of the book introduce you to SOA and how this is solved through Windows Communication Foundation. Basic concepts, programming patterns and terminology are very well explained, building up to how AX 2012 and its new Application Integration Framework presents these mechanisms for us as developers and technicians. You will learn about all the prebuilt and ready to use services. The book also discuss how CIL works in AX2012, which is a very important topic for any AX2012 developer.
The book also discuss a topic that might seem to be unrelated to Services, the Business Operation Framework, also known as SysOperationFramework. It is included due to its relation to how Services is implemented, but as most of us AX2012 developers know, the SysOperationFramework is central to AX 2012 regardless to whether or not you are planning to use it for external services. These chapters should be read by all AX 2012 developers.
The last part of the book takes you through various examples of implementations using Services, both providing them and consuming them. I really liked the examples showing SysOperationFramework and how we as developers can take advantage of this new replacement for RunBase(Batch).
I found the chapters easy to read and understand, and being the geek I am it was hard to put the book away. While building my course presentation I eventually restructured some of the content compared to the order in the book, but mainly due to my own OCD preference. It is definitely a good book to have on your tablet/surface while traveling between locations and want something interesting to read.
I would highly recommend this book for any AX2012 developer. Even if you're not planning on developing integration services right now, if you follow the basic recommended guidelines (ie MVC) while building the business operations in AX2012, you risk creating application blocks that is already prepared for SOA - which is golden!
Available at Packt Publishing directly or at Amazon Online Bookstore.
Wednesday, February 27, 2013
Wednesday, February 20, 2013
Deploy Modelstore with less downtime
Introduction
Everyone working with deployment of code in AX2012 should by now be familiar with the concept of a modelstore, and the importance of making sure you move the complete modelstore from your source to your target environment.
Now the time it takes to export and import a modelstore can be several minutes. Content is being read from disk and injected into model database on the SQL Server. We also know the AOS needs to be down while the AOT is getting its modelstore updated with new content, otherwise bad and unforeseen issues will eventually happen.
In order to reduce downtime while establishing an updated application, Microsoft offers tools for us to inject the modelstore into a temporary database Schema, and when all the content has been read of the disk and injected into the SQL Server database, the last operation of moving it from the temporary Schema to "dbo" can be done in just a matter of seconds. Essentially, you can get away with just the time it takes to synchronize the Data Dictionary after the new modelstore is applied to the environment.
The steps involved are already fairly well documented on MSDN, but perhaps this little Powershell script is enough to get you going.
The Code
Now all you need to do to run this code is to change the variables at the top, and save it as a ps1 file somewhere, and finally run it. I have added a "press any key"-pause just before the modelstore gets applied, so you can head over to Services and Stop the AOS before it gets applied. Finally the temporary Schema gets dropped and the only thing you need to do is to start the AOS, open a developer workspace and make sure the Data Dictionary gets synchronized.
Everyone working with deployment of code in AX2012 should by now be familiar with the concept of a modelstore, and the importance of making sure you move the complete modelstore from your source to your target environment.
Now the time it takes to export and import a modelstore can be several minutes. Content is being read from disk and injected into model database on the SQL Server. We also know the AOS needs to be down while the AOT is getting its modelstore updated with new content, otherwise bad and unforeseen issues will eventually happen.
In order to reduce downtime while establishing an updated application, Microsoft offers tools for us to inject the modelstore into a temporary database Schema, and when all the content has been read of the disk and injected into the SQL Server database, the last operation of moving it from the temporary Schema to "dbo" can be done in just a matter of seconds. Essentially, you can get away with just the time it takes to synchronize the Data Dictionary after the new modelstore is applied to the environment.
The steps involved are already fairly well documented on MSDN, but perhaps this little Powershell script is enough to get you going.
The Code
import-module "C:\Program Files\Microsoft Dynamics AX\60\ManagementUtilities\Microsoft.Dynamics.ManagementUtilities.ps1"
#region Variables
$sourceserver = "sql2012\test"
$targetserver = "sql2012\prod"
$sourcedb = "AX2012_Test_model"
$targetdb = "AX2012_Prod_model"
$modelstorepath = "c:\Modelstores\"
#endregion
#region Work
$dte = get-date -format s
$dte = $dte.tostring() -replace "[:\s/]", ""
$backFileName = "$modelstorepath" + $dte + ".axmodelstore"
Export-AXModelStore -Server $sourceserver -Database $sourcedb -File $backFileName
Initialize-AXModelStore –Server $targetserver -Database $targetdb –SchemaName Temp
Import-AXModelStore -Server $targetserver -Database $targetdb -SchemaName Temp -File $backFileName -NoPrompt
# Only works in Console
if (!$psISE)
{
Write-Host "Press any key to when you have stopped the AOS to continue the Import..."
$null = $Host.UI.RawUI.ReadKey("NoEcho,IncludeKeyDown")
Write-Host ""
}
Import-AXModelStore -Server $targetserver -Database $targetdb -Apply Temp -NoPrompt
Initialize-AXModelStore -Server $targetserver -Database $targetdb –Drop Temp -NoPrompt
"Completed!"
#endregion
Now all you need to do to run this code is to change the variables at the top, and save it as a ps1 file somewhere, and finally run it. I have added a "press any key"-pause just before the modelstore gets applied, so you can head over to Services and Stop the AOS before it gets applied. Finally the temporary Schema gets dropped and the only thing you need to do is to start the AOS, open a developer workspace and make sure the Data Dictionary gets synchronized.
Saturday, February 16, 2013
Upgrading AX2012 to AX2012 R2 Part 2
Two months ago I wrote a few words around the in-place upgrade from AX2012 RTM (v6.0/v6.1) to AX2012 R2 (v6.2). While working with this upgrade, I found that the guide did not tell the whole story. In fact there were several steps that would seem impossible to complete. After a lot of testing, communication with Microsoft Partner Support and with participants at the the Community Forum, I feel I finally can say the upgrade works. I hope it helps to hear this from someone who merely followed the guide, struggled some but finally got through.
The AX Support Blog asks us to be sure to follow the guide that is dated 12th of February or later.
MSDN Version
Technet Version
While the guide is covering a lot of the steps involved in a successful upgrade, I still would like to share some of my own experience. There are still things with the guide that needs to be updated/changed. Anyone who wants to attempt this upgrade should be prepared to see several errors and issues they can safely ignore, but then again there will be some things which will be symptoms of a bigger problem.
Check your setup logs while upgrading and keep an eye on the Event Log. Setup logs are always located in the same folder, normally under \Program Files\Microsoft Dynamics AX\60\Setup Logs\. If you get in trouble, these logs will be one of the first places to look.
Upgrading the code
Before you start your code upgrade, you need to make sure the RTM version both compiles X++ code and CIL compile. This will ensure that you know later on if compilation errors during the code upgrade is due to own customization and not something you brought with you from your source environment. Obviously, any change to the code in the source after you have duplicated PROD to TEST and DEV will have to be reproduced after the upgrade is done. I would simply recommend freezing the RTM code during the upgrade.
You also need to understand that as soon as you run the R2 Setup against your database, and you install the R2 Microsoft models, you have introduced a lot of new elements which will have environment unique IDs. This means you will have a new modelstore that is your single source for the code upgrade process. During installation against the RTM database, your old modelstore will remain in the database, and the new R2 modelstore will be installed in a new database. The guide explains all of this, but just understand that during this split, your new R2 modelstore is unique for this customer environment. To put it another way, if you upgrade the database twice, the first modelstore will be incompatible with the business data in the second one. The guide also seem to convey that there will be multiple Microsoft layers, but in fact a lot of the old code in FPK and SYP will be moved to SYS. There are exceptions though, like the beta version of Data Migration Framework.
The AX Support Blog asks us to be sure to follow the guide that is dated 12th of February or later.
MSDN Version
Technet Version
While the guide is covering a lot of the steps involved in a successful upgrade, I still would like to share some of my own experience. There are still things with the guide that needs to be updated/changed. Anyone who wants to attempt this upgrade should be prepared to see several errors and issues they can safely ignore, but then again there will be some things which will be symptoms of a bigger problem.
Check your setup logs while upgrading and keep an eye on the Event Log. Setup logs are always located in the same folder, normally under \Program Files\Microsoft Dynamics AX\60\Setup Logs\. If you get in trouble, these logs will be one of the first places to look.
Upgrading the code
Before you start your code upgrade, you need to make sure the RTM version both compiles X++ code and CIL compile. This will ensure that you know later on if compilation errors during the code upgrade is due to own customization and not something you brought with you from your source environment. Obviously, any change to the code in the source after you have duplicated PROD to TEST and DEV will have to be reproduced after the upgrade is done. I would simply recommend freezing the RTM code during the upgrade.
You also need to understand that as soon as you run the R2 Setup against your database, and you install the R2 Microsoft models, you have introduced a lot of new elements which will have environment unique IDs. This means you will have a new modelstore that is your single source for the code upgrade process. During installation against the RTM database, your old modelstore will remain in the database, and the new R2 modelstore will be installed in a new database. The guide explains all of this, but just understand that during this split, your new R2 modelstore is unique for this customer environment. To put it another way, if you upgrade the database twice, the first modelstore will be incompatible with the business data in the second one. The guide also seem to convey that there will be multiple Microsoft layers, but in fact a lot of the old code in FPK and SYP will be moved to SYS. There are exceptions though, like the beta version of Data Migration Framework.
If you don't get the installation wizard step that allows you to chose between export or import of the R2 modelstore, it is most likely due to the installer not finding either a reference to a RTM AOS or Client on the system. I found that the reference to a RTM Client is the same as for a R2 Client, from the setup perspective. In other words, this step will pop up if there is either a RTM AOS or Client on the system, or you if you have a R2 Client installed. Just so you know.
The in-place upgrade guide starts off with duplicating PROD to TEST, and later to duplicate TEST to DEV. I had TEST and DEV on the same server, which worked fine for me. The guide further tells us to run a kernel compile after the R2 TEST AOS is installed against the R2 TEST database. Some have asked "What does kernel compile do?" I got this answer from Microsoft Support:
"Unlike what may be interpreted from some documentation pages (“Perform a full kernel compilation by using the following command: Ax32.exe -startupcmd=kernelcompileall”), this command does not compile the kernel; it does a full AOT compilation, i.e. it compiles the application. However, instead of using X++ classes to control that compilation and log the results, this operation is done by a kernel function. During minor version upgrade, majority of the class required to be recompiled, including many system class/compiler related class. The kernel compile is required for minor version upgrade as it force a full compile on every class in AOT, including those system/compiler class, and are executed on server tier. Without running the kernel compiler ax won’t even function properly as the base application class are not even compiled to begin with."
So basically after running setup against the database and having the R2 models installed, our modelstore is in such a bad shape, it is crippled and will not even be able to compile using its own system classes. Using kernel compile, we can get those system classes compiled and ready for the next steps in DEV. The whole process takes extra time, which I assume is mostly due to all the errors and issues the compiler will find. You are also asked to restart the AOS before and after doing the kernel compile. Please do.
The in-place upgrade guide starts off with duplicating PROD to TEST, and later to duplicate TEST to DEV. I had TEST and DEV on the same server, which worked fine for me. The guide further tells us to run a kernel compile after the R2 TEST AOS is installed against the R2 TEST database. Some have asked "What does kernel compile do?" I got this answer from Microsoft Support:
"Unlike what may be interpreted from some documentation pages (“Perform a full kernel compilation by using the following command: Ax32.exe -startupcmd=kernelcompileall”), this command does not compile the kernel; it does a full AOT compilation, i.e. it compiles the application. However, instead of using X++ classes to control that compilation and log the results, this operation is done by a kernel function. During minor version upgrade, majority of the class required to be recompiled, including many system class/compiler related class. The kernel compile is required for minor version upgrade as it force a full compile on every class in AOT, including those system/compiler class, and are executed on server tier. Without running the kernel compiler ax won’t even function properly as the base application class are not even compiled to begin with."
So basically after running setup against the database and having the R2 models installed, our modelstore is in such a bad shape, it is crippled and will not even be able to compile using its own system classes. Using kernel compile, we can get those system classes compiled and ready for the next steps in DEV. The whole process takes extra time, which I assume is mostly due to all the errors and issues the compiler will find. You are also asked to restart the AOS before and after doing the kernel compile. Please do.
When the modelstore is compiled by the kernel, you will export it as a base for your DEV environment. This is the fun part, going through each layer and make sure they get R2 compatible. The guide explains how to do this in a good way, just make sure you follow it. Since this is DEV, you are not too worried about loss of business data. You also want to set all batchjobs to STATUS = 0 in the database. This will hinder them from creating disturbing errors here and there. There will be a lot of errors and warnings from the database, but all you care about is getting the code and metadata free of compile errors. Even though the code upgrade check list has several steps, you will most likely not complete all of them. Some steps will not be marked as finished. Just focus on getting the AOT to compile and finally CIL to compile, all while making sure your element IDs remain the same throughout the process. Any AX2012 developer should by now understand how to make sure element IDs remain the same in a modelstore.
One final important step when the modelstore is done, is to set the "installmode" on the modelstore. This is crucial for success. Make sure you set the "installmode" on the correct modelstore.
Upgrading the data
When you are done upgrading and preparing the R2 modelstore, it is time to test the data upgrade. You will start off by upgrading TEST and if everyone in your team is happy with the upgraded data, you can plan to upgrade PROD. You will use the same modelstore for both. Again, it is crucial that the modelstore is in "installmode" or you can forget about getting a successful data upgrade in production. The installation of the AOS will fail, and when you try open the client you will see several hundreds of errors in the event log.
One thing the guide barely mentions is the new R2 database will have a different type of table per type inheritance mode. During the data upgrade the database will be in a Table-Per-Type mode. This makes the data upgrade scripts work properly. If you want to learn more about what this is, please have a look at this blog post for starters. You can check if your business database is in the right mode by looking for the stored procedure named TABLEPERTYPEINHERITANCEMODE. During data upgrade, you will be prompted to run a huge SQL-script, and this script will at the end set the inheritance mode to it's correct state after the data has been successfully upgraded. Eventually the R2 business database will have a Table-Per-Hiearchy mode. If you wonder how this stored procedure got into the database in the first place, I can reveal it happens during installation of the R2 AOS. Setup will figure out if the underlying database is on an older version (6.0/6.1) and create it in the database. The in-place guide seems to claim that you need to explicitly be in an upgrade mode when you are installing the AOS, but my testing shows that setup will discover the version of the database schema and add the procedure if the underlying database is pre-R2.
In other words, there is a phase where you have a business database in the "wrong" table per type inheritance mode. This phase starts when the AOS installs the procedure and ends somewhere late in the data upgrade check list.
During data upgrade, a series of jobs will be run by the batch framework. To save you some trouble, you should update the tables BATCH and BATCHSERVERGROUP with correct AOSID values. You can however get around this before running the jobs by modifying their settings in the upgrade cockpit. I prefer running a SQL skript that fix batch before I start.
The guide also mentions that you should change Recovery mode on the model database to "Simple" while upgrading. This will prevent SQL to log every single transaction to the model database. I would argue having the recovery model to "Full" on this database is only necessary for a development environment, depending on your overall backup and recovery strategy.
Summary
Sorry for the wall of text. Here is a "brief" summary:
- Make sure your RTM code compiles, CIL compiles and database is synced.
- Freeze the RTM code when you start the R2 upgrade.
- When installing the R2 models the first time, this can not be redone later on without having to do another full code upgrade and data upgrade.
- Follow the guide when upgrade the models to ensure that the element IDs remain unchanged within the modelstore, or be prepared for loss of business data. Those who do not care for the business data can upgrade layers without having to reimport the "broken" modelstore between each layer upgrade.
- The compile and synchronize steps while doing code upgrade will not be marked as complete. Ignore this and just focus on getting the code to compile.
- When you have prepared the modelstore, make sure to set the installmode and export a backup of the modelstore. This modelstore will be the one you import back to TEST and later on to PROD.
- Always stay aware of what modelstore you are working against. Don't be fooled by the modelstore that is also located in your business database.
- Make sure your batch settings are prepared before you initiate the jobs that will upgrade your business data.
- Follow the data upgrade checklist so you don't lose business data.
- If you get stuck, ask for help!
I would estimate less than a week for the whole process on a AX2012 RTM without any customization, but you could probably manage to pull it off in just a couple of days with some practice. However, with enough code customization and dependencies to external services, the process will take longer.
I would like to congratulate Microsoft on a well made in-place upgrade. It must have been a lot of hard work to get it where it is today. Hopefully we will see most RTM versions of AX2012 be upgraded to R2 during this year.
Subscribe to:
Posts (Atom)