• About

Day 2 Day Dynamics

~ Experiences of a working AX developer

Day 2 Day Dynamics

Tag Archives: AX Artifacts

Push-AXModel custom PowerShell function

29 Tuesday Dec 2015

Posted by John Hagler in Powershell

≈ Leave a comment

Tags

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:

  1. Stop the AOS
  2. Clean up unused default layer models using Clean-AXModels
  3. Import the model file(s) using Install-AXModel
  4. Start the AOS
  5. Install any hotfixes using Import-AXXPO
  6. Stop the AOS
  7. Compile the AOT using Start-AXBuildCompile
  8. Start the AOS
  9. Compile any individual items using Compile-AXXppNode
  10. Compile CIL using Compile-AXCIL
  11. Delete the old artifacts using Clean-AXArtifacts
  12. Sync the data dictionary using Sync-AXDB
  13. Refresh the services using Refresh-AXServices
  14. Deploy changes to ports using Refresh-AXAifPort
  15. Deploy reports using Publish-AXReport
  16. 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.

 

 

Build-AXModel custom PowerShell function

23 Wednesday Sep 2015

Posted by John Hagler in Powershell

≈ Leave a comment

Tags

Automation, AX, AX 2012, AX Artifacts, AX Build, AX Deployment, AX Import, AX Label, Build Scripts, CIL, Compile, Dynamics AX, IL, PowerShell, R2 CU7, Synchronize

I apologize for the extra week between posts.  It has been a lot of work to get this function ready to post.  I built the D2DDynamics PowerShell module using cleaned up functions that were based off of the original functions I used to create my build.  Even though I tested all of the functions as I built them, my actual build was still using my old functions.  Getting my new build ready required me to bring my module into my build environment and re-write and re-test my build.  I also wanted to get at least one build done in my environment using the new function before posting it.  Hence, the extra week.

I’m not going to get too in depth regarding the function this week.  I am making it available so people can look at it and try and get an idea of what I’m doing.  I will be covering the specifics of it in future posts.  Also, I will not be including it in the module.  It is possible that a large percentage of users will be able to use the function as-is to create a build but some users will need to modify it to make it work for them and all users will need to modify the variables.  You should add the function to your session using your profile.

I have also updated the D2DDynamics module to version 1.0.1.  This release includes some documentation changes, a new Comment parameter for the Sync-AXTFSWorkingFolder function and I’ve exposed the Send-Email function because I use it in the Build-AXModel function that isn’t part of the module.  To use the Build-AXModel function, you will need to download and setup the latest version of the module (1.0.1).

The Build-AXModel custom PowerShell function takes 3 parameters:

  • BuildNumber (The build identifier)
  • ConfigPath (Client configuration for the AX build environment)
  • VariablePath (Path to a file used to default the parameters/variables)

All 3 variables should be used, although you could specify the ConfigPath in the Variable path file if you’d like.  I have defaulted both values in the function that I use already to make my life simpler.  Feel free to do the same thing in the function that you use.  This function is not designed to be used “out-of-the-box”.  You can customize the defaults and you will need to customize the Build-AXModel_Variables file that is used for the VariablePath parameter for this function to work.  I will get into what/why/how to use the variables in a later post.  For now you can look at the 2 files (Function_Build-AXModel.ps1 and Build-AXModel_Variables.ps1) and get an idea for what is going on.

There are 15 basic steps to the build:

  1. Sync TFS and set the label using Sync-AXTFSWorkingFolder
  2. Stop the AOS
  3. Restore the build environment to vanilla using Restore-AXDatabase
  4. Create the new models
  5. Delete the old artifacts using Clean-AXArtifacts
  6. Start the AOS (Build environment is now clean and ready for the new build)
  7. Generate the combined .xpo files using Combine-AXXPO
  8. Import label files using Import-AXLabelFile
  9. Load the combined .xpo files using Import-AXXPO
  10. Compile and load the VS projects using Start-AXMSBuildImport
  11. Compile the AOT using Start-AXBuildCompile and Compile-AXXppNode
  12. Compile CIL using Compile-AXCIL
  13. Sync the data dictionary using Sync-AXDB
  14. Reload the AX artifacts using Clean-AXArtifacts (This step helps with label file issues when pushing the model)
  15. Export the model file

D2DDynamics custom PowerShell module

31 Monday Aug 2015

Posted by John Hagler in Powershell

≈ Leave a comment

Tags

ALD, AOT, Automation, AX, AX 2012, AX Artifacts, AX Database, AX Import, AX Label, Build Scripts, Compile, DB, Dynamics AX, PowerShell, PowerShell Module, R2 CU7, Server Compile, Team Foundation Server, TFS, XPO

The D2DDynamics custom PowerShell module is finally available in Codeplex.  The 1.0.0 version includes 15 exportable PowerShell functions and 3 internal helper functions.  They are:

  • Get-AXAutoRunXML
  • Start-AXAutoRun
  • Start-AXBuildCompile
  • Compile-AXCIL
  • Sync-AXDB
  • Compile-AXAOT
  • Clean-AXArtifacts
  • Import-AXXPO
  • Import-AXLabelFile
  • Sync-TFSWorkingFolder
  • Restore-AXDatabase
  • Combine-AXXPO
  • Start-AXMSBuildImport
  • Compile-AXXppNode
  • Import-AXVSProject

The 3 internal functions are:

  • Send-Email
  • Clean-Folder
  • Clean-Folders

This module is dependent on the 0.3.5 release of the DynamicsAXCommunity PowerShell module among others.  There are also some variables that should be set up in your profile if you are planning on using the functions.  The profile that I use can be found in Codeplex at Source Code -> Powershell -> Profile -> Modules -> Microsoft.PowerShell_profile.ps1.  Please use this as a reference for setting up your own profile.

To install the module, copy the D2DDynamics folder to the module folder for PowerShell.  On my Server 2012 server, the location is “C:\Windows\System32\WindowsPowerShell\v1.0\Modules”.  After the module is there, you should be able to open PowerShell and add it with the Import-Module cmdlet.

Future posts will include the steps necessary to create a custom build process using the module as well as more functions that can be used for deploying your build to other environments.  Please let me know what you think of the module and if you find any problems with using the functions in your environments.

Clean-AXArtifacts custom PowerShell function

04 Monday May 2015

Posted by John Hagler in Powershell

≈ 4 Comments

Tags

Automation, AX, AX 2012, AX Artifacts, Build Scripts, Dynamics AX, PowerShell

I apologize for missing last week’s post but I’m in the process of moving and my free time has all but gone away.  I discovered the idea for this PowerShell function from a couple of different places.  I first saw the concept of cleaning up “artifact” files in the Build and Deploy Scripts for Microsoft Dynamics AX but I found it much more detailed in the Dynamics AX Admin Utilities.  I was interested in this because I missed the “default fix” that was deleting the application object index in earlier versions of AX.  This isn’t quite the same but it does remove the files that AX generates and stores on the client and server, forcing AX to re-deploy them from code.

The Clean-AXArtifacts function takes between 0 and 3 parameters:

  • ConfigPath (Client configuration for the chosen environment)
  • CleanServer (Switch parameter used to clean artifact files on the server)
  • AllUsers (Switch parameter used to clean artifact files for all users on the client instead of just the current user)

The ConfigPath parameter is only required if the CleanServer parameter is used.  The CleanServer parameter will stop the AOS (if it’s running), delete the server artifacts and start the AOS (if it was stopped by the function earlier).  AllUsers is good for terminal server client servers.  It will allow you to delete the client artifacts for all users that log onto that terminal server.

This function can be found in Codeplex.  This function also uses 2 internal functions that I’ve created, Clean-Folder and Clean-Folders.  These functions allow me to loop through the folders and delete the files.  The steps of this function are:

  • Validate parameters
  • Check if the server needs to be cleaned
    • Get the AX environment info using Get-AXConfig
    • Stop the AOS if it’s running
    • Delete the server artifact files using Clean-Folder
    • Start the AOS if it was stopped by the function
  • Check if all users need to be cleaned
  • Use Clean-Folders for all users or Clean-Folder if not

I use this function during builds and also during pushes.  When I have an environment that has more than one AOS, I generally stop the AOS on the other AOS’s, then run Clean-AXArtifacts on the primary AOS.  While it is running, I log onto the other AOS’s and run the function there.  I also log onto the client terminal server and delete the client artifacts for all users.  When the primary AOS has started again, I start the AOS’s on the other AOS servers.  This function has become my default AOS bounce.  Instead of restarting the AOS, I call Clean-AXArtifacts.

Like all of my other functions, this must be run on the server that you are deleting files on.

Follow Day 2 Day Dynamics on WordPress.com

Day 2 Day Dynamics

  • RSS - Posts
  • RSS - Comments

Follow me on Twitter

My Tweets

Recent Posts

  • Minimizing Database Calls
  • Push-AXModel custom PowerShell function
  • Clean-AXModel custom PowerShell function
  • Get-AXTFSCombinedXpo custom PowerShell Function
  • Refresh-AXAifPort custom PowerShell function

Archives

  • February 2016
  • December 2015
  • November 2015
  • October 2015
  • September 2015
  • August 2015
  • July 2015
  • June 2015
  • May 2015
  • April 2015
  • March 2015
  • February 2015

John Hagler

John Hagler

John Hagler

I am the Dynamics AX Technical Architect at Dealer.com. I have been working with AX since Sep. 2006, starting with Axapta 3.0. I have worked as both a VAR and an AX customer.

View Full Profile →

Blog at WordPress.com.

  • Follow Following
    • Day 2 Day Dynamics
    • Already have a WordPress.com account? Log in now.
    • Day 2 Day Dynamics
    • Customize
    • Follow Following
    • Sign up
    • Log in
    • Report this content
    • View site in Reader
    • Manage subscriptions
    • Collapse this bar