• About

Day 2 Day Dynamics

~ Experiences of a working AX developer

Day 2 Day Dynamics

Tag Archives: AOT

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.

 

 

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.

Compile-AXXppNode

07 Friday Aug 2015

Posted by John Hagler in Powershell

≈ 4 Comments

Tags

AOT, Automation, AutoRun, AX, AX 2012, Build Scripts, Compile, Dynamics AX, PowerShell

The Compile-AXXppNode function is the first of 2 functions to support more complicated VS project scenarios.  I have taken this approach from here.  I don’t personally use this approach in my build as my current environment doesn’t require it but this function along with my next post should allow a user that does have these complicated scenarios to import VS projects for a build.

This function can return the compile results in an email but it requires a code change in the SysAutoRun.execCompileApplication() class method.  When compiling everthing, the SysCompileAll::compile() class method calls the SysCompilerOutput::exportLog() class method.  This exports the log to the user’s “C:\Users\..\Microsoft\Dynamics Ax\Log\” folder.  If you want this log to be available, you need to add the SysCompilerOutput::exportLog() class method call to the node compile section of code.  I realize that this is a chicken and egg type thing as this custom code would need to be imported into the build environment before importing and compiling VS projects but it is possible to implement.

The AutoRun xml does have the ability to specify a log file as well but this log file will only show you what nodes were compiled.  There is no message regarding the results of the compile in it.  Because of this limitation, I didn’t used this log in the function.

SysAutoRunCompileLogChange

The Compile-AXXppNode custom PowerShell function takes between 2-7 parameters:

  • ConfigPath (Client configuration for the chosen AX environment)
  • Node (The AX node to compile)
  • Timeout (The value defaults to 90 minutes but can be overridden if desired)
  • SMTPServer (SMTP server to use to send the email)
  • MailMsg (Net.Mail.MailMessage object used to send the email)
  • AXVersion (The AX version.  It defaults to 6.)
  • VariablePath (Path to a file used to default the parameters/variables)

This function can be found in Codeplex.  The steps of this function are:

  • Load the variables if a VariablePath parameter is used
  • Get the AX environment info using Get-AXConfig
  • Get the Compile node AutoRun xml using the Get-AXAutoRunXML function
  • Call the Start-AXAutoRun function to compile the node
  • Send the success/fail message

As I said in the last post, I have been in contact with Martin Drab.  He is developing the DynamicsAXCommunity PowerShell module that I piggyback off of.  He has incorporated the last change that I needed for my functions to work in the latest build of the module (0.3.5).  I haven’t tested it out yet, but my functions should now work with his module with no customizations.

Compile-AXAOT custom PowerShell function

20 Monday Apr 2015

Posted by John Hagler in Powershell

≈ 1 Comment

Tags

AOT, Automation, AutoRun, AX, AX 2012, Build Scripts, Compile, Dynamics AX, PowerShell

The Compile-AXAOT custom PowerShell function will allow you to compile the AOT using the client compile.  I would recommend using the Start-AXBuildCompile function that uses the server compile if you are on AX 2012 R2 CU7 or higher as this function will compile much faster but this one will accomplish the same thing if you aren’t.

The Compile-AXAOT function takes between 1 and 6 parameters:

  • ConfigPath (Client configuration for the chosen AX environment)
  • TimeOut (The value defaults to 2 hours but can be overridden if desired)
  • SMTPServer (SMTP server to use to send the email)
  • MailMsg (Net.Mail.MailMessage object used to send the email)
  • AXVersion (The AX version.  It defaults to 6.)
  • VariablePath (Path to a file used to default the parameters/variables)

You might notice that this function doesn’t take a LogFile parameter.  That is because the client compile stores the log file in specific location and changing that value would not allow you to receive the compile log.  This function can be found in Codeplex.  The steps of this function are:

  • Load the variables if a VariablePath parameter is used
  • Get the AX environment info using Get-AXConfig
  • Get the CompileApplication AX AutoRun xml using the Get-AXAutoRunXML function
  • Call the Start-AXAutoRun function to compile the AOT

This function should also only be run on the AOS server.  It has been tested using AX 2012 R2 CU6 and CU7 but I would expect this to work for any version of AX 2012.

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
 

Loading Comments...