AIF, AOT, Application Integration Framework, Automation, AX, AX 2012, AX Artifacts, AX Deployment, AX Model, AX Report Deployment, AX Services, CIL, Compile, Dynamics AX, IL, PowerShell, R2 CU7, Synchronization, XPO
This is potentially the last of my PowerShell posts. This function wraps up what I currently use in my environment to build and deploy for AX. This function uses some of the same functions used by the Build-AXModel function as well as some of the functions that ship with AX and also the custom functions that have been added since the build post.
As with the Build-AXModel function, I will not be including this one in the module either. I am hoping that most users will be able to use the function as-is to create a push process but some users will need to modify it to make it work for them and all users will need to modify the variables. Please feel free to change this function to fit your needs. I have built the template I have to fit mine, although I have added looping to certain function calls to try and make it as re-usable as possible. You should add the function to your session using your profile as you’ve done for the build function.
The Push-AXModel custom PowerShell function takes 3 parameters:
- ModelFile (The model file to push)
- ConfigPath (Client configuration for the AX environment to push to)
- VariablePath (Path to a file used to default the parameters/variables)
All 3 variables should be used, although you could specify both the ModelFile(s) and the ConfigPath in the Variable path file if you’d like. I am not expecting another blog post explaining the variables file as all of the concepts that I used for the build variables will apply to this variable file as well.
This function can be found in Codeplex in the Standalone functions section. There are 16 basic steps to my push:
- Stop the AOS
- Clean up unused default layer models using Clean-AXModels
- Import the model file(s) using Install-AXModel
- Start the AOS
- Install any hotfixes using Import-AXXPO
- Stop the AOS
- Compile the AOT using Start-AXBuildCompile
- Start the AOS
- Compile any individual items using Compile-AXXppNode
- Compile CIL using Compile-AXCIL
- Delete the old artifacts using Clean-AXArtifacts
- Sync the data dictionary using Sync-AXDB
- Refresh the services using Refresh-AXServices
- Deploy changes to ports using Refresh-AXAifPort
- Deploy reports using Publish-AXReport
- Restart the AOS
Install-AXModel is a function that is part of the AXUtilLib.Powershell module. You should definitely check out the link and make sure that you understand what the Conflict parameter does. Your specific environment may dictate that you change this value when importing your model(s). There is also a NoOptimize parameter that can be used when importing multiple model files. I did not go this route as I only have one model but it may be worth looking into.
I did want to discuss my hotfix solution in step 5 very quickly. I have added the ability to import .xpos in my build push as we very often discover issues during regression testing. Depending on the issue, we create hotfixes instead of a new build. I export these hotfixes out of TFS and add them to a “hotfixes” folder located in the same location as the model file being imported. The Push-AXModel function will loop through and import all .xpos located in this folder, sorting by LastWriteTime. Make sure you create the .xpos in the order that you want them imported.
Publish-AXReport is a function that is part of the Microsoft.Dynamics.AX.Framework.Management module. The variables file is defaulting the ReportName value to the wildcard for “all”. I personally don’t do this in my environments because we only have a handful of reports that have been modified/created so I just create an entry for each one. It is faster to deploy the few indiviual reports that I have. Since I also manage our builds, I can add new reports to the variable files in each environment if necessary.
I still have one manual process to accomplish when pushing my models. I have no function for deploying cube changes I don’t currently have a strategy to accomplish this in PowerShell. As we very rarely make cube changes, it hasn’t been a big issue. There may be other push processes that are specific to your environment that you may need to automate as well. If there are, I would be interested in hearing what they are and how you accomplished it.
One last thing, I have cleaned up all of the standalone functions in Codeplex. The only standalone functions that are in there now are Build-AXModel and Push-AXModel. Everything else is part of the module.