Sync-AXDB custom PowerShell function

12 Sunday Apr 2015

Posted by in Powershell

≈ 3 Comments

Tags

, , , , , , , , ,

The Sync-AXDB custom PowerShell function will allow you to synchronize the AX DataDictionary from PowerShell.  If you compare this function/post against the Compile-AXCIL function/post, you will see that they are almost identical.  I had thought of creating a single Start-AXAutoRun function but eventually scrapped that idea in favor of simplicity for the user.  I may look at creating an internal function for the AX call at some point in the future to remove the code duplication.

The Sync-AXDB function takes between 1 and 7 parameters:

  • ConfigPath (Client configuration for the chosen AX environment)
  • LogFile (The value defaults to the temp folder but can be overridden if desired)
  • 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)

I use the VariablePath parameter the same way that I do in the other functions I’ve posted that use it.  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 Synchronize AX AutoRun xml using the Get-AXAutoRunXML function
  • Call the Start-AXAutoRun function to synchronize the database

This function should also only be run on the AOS server.  It has been tested using AX 2012 R2 CU7 but should also work for R3.  I have added the Version parameter to this function but it was initially missing from the Compile-AXCIL function/post.  I have gone back and added it to the earlier post as well to reflect the code change in TFS.

Compile-AXCIL custom PowerShell function

06 Monday Apr 2015

Posted by in Powershell

≈ 3 Comments

Tags

, , , , , , , , ,

The Compile-AXCIL custom PowerShell function will allow you to generate the AX CIL.  This doesn’t add anything really new to what is existing, as the DynamicsAXCommunity PowerShell module has a Compile-AXIL function.  I have only re-written this because of my desire to allow emails to be sent from these functions.

The Compile-AXCIL function takes between 1 and 7 parameters:

  • ConfigPath (Client configuration for the chosen AX environment)
  • LogFile (The value defaults to the temp folder but can be overridden if desired)
  • 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)
  • Version (The AX version.  It defaults to 6.)
  • VariablePath (Path to a file used to default the parameters/variables)

I use the VariablePath parameter the same way that I do in the other functions I’ve posted that use it.  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 CompileIL AX AutoRun xml using the Get-AXAutoRunXML function
  • Call the Start-AXAutoRun function to compile the IL

This function should also only be run on the AOS server.  It has been tested using AX 2012 R2 CU7 but should also work for R3.

Get-AXAutoRunXML custom PowerShell function

29 Sunday Mar 2015

Posted by in Powershell

≈ 1 Comment

Tags

, , , , , ,

The obvious posts following the Start-AXBuildCompile post would be to talk about the AOT client compile, compiling IL and synching the AX data dictionary.  However, all of these processes rely on the AX SysAutoRun functionality.  To prep for these upcoming PowerShell functions, I will walk you through the Get-AXAutoRunXML function.

The SysAutoRun class is a class in AX that allows you to run functionality in AX at startup.  This becomes the entry point for most, if not all of the processes that you want to automate in AX.  The Get-AXAutoRunXML function allows you to build an AxaptaAutoRun xml very easily that can then be used to run different processes in AX for your automation.

The Get-AXAutoRunXML takes 3 parameters:

  • ExitWhenDone (If this parameter is passed, AX will run the process and exit afterwards)
  • LogFile (Determines if the process makes the infolog available for output and where that file is saved)
  • Command (This parameter is used to choose what process AX runs at startup)

This is a very straightforward function that can be found in Codeplex.  It takes the parameters and returns an AxaptaAutoRun xml that can then be passed into AX to allow multiple AX processes to be automated (e.g. client compile, IL compile, data dictionary sync).

If you examine the function, you will see that the xml has a version property in the header.  I struggled with whether or not to make this property a parameter of the function.  Ultimately, I decided that if the AxaptaAutoRun version is changed, I would more than likely have to update this function to account for changes in the xml.  For this reason, I decided to leave it as a hardcoded value but this could change in the future.

Start-AXBuildCompile custom PowerShell function

22 Sunday Mar 2015

Posted by in Powershell

≈ 4 Comments

Tags

, , , , , , , , , ,

This function was created to allow you to run a server compile from PowerShell.  I will apologize upfront to anyone on an earlier version of AX 2012 than R2 CU7.  This PowerShell function will only be useful if you are running a version of AX 2012 that is R2 CU7 or greater.  The reason being that R2 CU7 introduced the AxBuild.exe server compile.  There is a lot of information in the link regarding this process but for my purposes, the most important part was the difference in compile time.  Compilation time in my standalone development environment decreased from 4+ hours for the client compile to about 20 minutes when using the server compile.  I have other PowerShell functions that I will discuss in future posts that allow you use the client compile that is available in earlier versions but this one uses the server compile.

This function is also the main reason why I originally customized the Get-AXConfig function made available from the DynamicsAXCommunity PowerShell module that I discussed in an earlier post.  I needed the ServerBinDir for access to the AxBuild.exe server compile and the ServerLogDir for access to the compilation results file.  You will need to have the DynamicsAXCommunity PowerShell module installed and loaded in your session to use this function.  You should add the loading command for it to your profile.

  • Import-Module DynamicsAXCommunity -DisableNameChecking

The Start-AXBuildCompile function takes either 1 parameter or a mix of up to 8 parameters:

  • ConfigPath (Client configuration for the chosen AX environment)
  • AXVersion (This should be 6 but I’ve included it in anticipation for AX 7)
  • LogPath (Used to override the default location of the AXCompileAll.html file)
  • NoCleanup (Tells the program to keep the temporary files it writes under the %TEMP% directory)
  • StopAOS (In certain scenarios, the AxBuild.exe service might provide outdated metadata or outdated p-code to the compile process if the AOS is running)
  • SMTPServer (SMTP server to use to send the email)
  • MailMsg (Net.Mail.MailMessage object used to send the email)
  • VariablePath (Path to a file used to default the parameters/variables)
  • Workers (Used to force the number of workers used to compile from the default used by AXBuild.exe)

The VariablePath variable is being used in my functions to default variables.  It saves me time when running things in each environment to set up the variables beforehand and then I pass in the location of my D2D_PSFunctionVariables.ps1 file as this parameter.  This allows me to use these functions without filling out all of the variables in my PowerShell function calls.  You can find my D2D_PSFunctionVariables.ps1 file and the Start-AXBuildCompile custom PowerShell function in Codeplex.

The steps of this function aren’t overly complicated.  They are:

  • Load the variables if a VariablePath parameter is used
  • Get the AX environment info using Get-AXConfig
  • Stop the AOS if the switch parameters is passed
  • Build the command parameters for AXBuild.exe
  • Call the command using Invoke-Expression
  • Start the AOS if it was previously stopped
  • Get the file with the results of the compilation
  • Send an email with the compilation results file attached if a valid MailMessage variable is set up.  If one isn’t set up, you will need to navigate to the default location for this file on the AOS server to view it.

A couple of final things.  This function needs to be run on the AOS server.  It has not been built to allow remote functionality.  Also, I have only tested this function on AX 2012 R2 CU7 but I would expect it to work on R3 as well.  Please comment if there are any issues on R3.

Send-Email custom PowerShell function

13 Friday Mar 2015

Posted by in Powershell

≈ 5 Comments

Tags

, , , , , , ,

When looking at automating my AX 2012 processes, the first thing I was interested in was the ability to send emails when steps were completed.  This would allow me to kick off my process and walk away, tracking it on my phone if necessary.

The function I created for this is Send-Email and can be found on Codeplex.  It takes 7 parameters:

  • SMTPServer (SMTP server that will send the email)
  • From (Who the email is from)
  • To (Who the email is to)
  • Subject (Email subject)
  • Body (Email body)
  • Priority (Email priority)
  • FileLocation (Allows you to attach a file if used.  I primarily use this to attach my log files)

This function uses the Net.Mail.MailMessage and Net.Mail.SmtpClient to send an email message.  I usually default some of these parameters in the scripts I use to call these functions but we’ll get into that when I walk through my build function.  You can view the code in this function using PowerShell ISE.

The way that I currently test and run these standalone PowerShell functions is to use my profile.  In my profile, I include a link to a PowerShell script that holds my function locations.  I do this so that when I add new functions, I can just include them in my D2D_PSFunctions.ps1 script and they will be automatically included by my profile the next time I open up PowerShell.  You can get more info on what I’m doing in an earlier post as well as Codeplex.

Please take a look at this function to get an idea of what is going on.  There may be optimizations or better ways to do things in PowerShell but I was teaching myself PowerShell while I wrote all of this.

DynamicsAXCommunity PowerShell module plus changes

04 Wednesday Mar 2015

Posted by in Powershell

≈ 2 Comments

Tags

, , , , ,

When I first started looking at creating an automated build process, I settled on PowerShell primarily because of 2 resources; the DynamicsAXCommunity PowerShell module and the Build and Deploy Scripts for Microsoft Dynamics AX 2012.  While I was ultimately unable to get the B&D Scripts running in my environment, I did learn a lot about PowerShell and the direction I needed to go to get a build process going.  I ended up using a lot of the ideas in my own processes.

The DynamicsAXCommunity Powershell module became the first brick in my process.  I started out using most of the functions available but eventually rewrote some of them to incorporate email functionality.  The three that I still use regularly are Get-AXConfig, Start-AXAOS and Stop-AXAOS.  I have also modified some of the code used in the Get-AXConfig method to return some values from the configurations that I needed.

My changes to the module are on the alpha version.  There appear to be 2 newer versions of this module, a beta and 0.3.4 but I have not integrated my changes into either of these.  You can find both the original alpha version and the version with my code changes in Codeplex based on the check-ins.  I plan to either integrate my changes in the newest version or add the three functions that I use from the DynamicsAXCommunity module into my functions at some point in the future.  For now, the alpha version has been used with my scripts for the last year and half and I feel comfortable that it works.

I have added three values that are returned from the Get-AXConfig function.

  • ServerBinDir
  • ServerLogDir
  • AosName

DynamicsAXCommuntiyChanges

The two directories are used to get executables and compile logs and the AOS name is used in some of the standard AX PowerShell functions installed with the Management Utilities.

This post and my last one have laid the groundwork for what is necessary to start using my functions.  In my next post, we will start looking at them.

Setting up your PowerShell environment

27 Friday Feb 2015

Posted by in Powershell

≈ 2 Comments

Tags

, , , ,

Since the majority of my upcoming posts will revolve around PowerShell, I’ve decided to post about setting up your environment.  All of the things I will discuss can be found elsewhere and I will link to some of the sources that I’ve used but I’m hoping to give enough information that anyone can repeat my steps using only this blog. Also, in case anyone has issues or is just interested to know, I am using PowerShell version 3.0.

The first thing that you will need to do is set the execution policy of your environment.  The default execution policy is Restricted, meaning you will be unable to run any PowerShell scripts.  The most restrictive setting that you can have that will still enable you to run my scripts is RemoteSigned.  You can find more information here.

  • Set-ExecutionPolicy RemoteSigned

PS_Set-ExecutionPolicy

The next step is to get a profile set up.  PowerShell is largely session dependent and most things that you want to use need to be loaded into your session before they are available.  Setting up a profile gives you the ability to load things into a session by default.  The PowerShell commands that I use to set up my profile are below and you can find more information here.

  • Test-Path $profile
  • New-Item -path $profile -type file -force
  • notepad $profile

PS_CreateProfile

Most, if not all of the things that I am going to be talking about in the future start with the AX 2012 Management Utilities.  This is something that can be installed using your AX 2012 installation media and is required to be installed on the server where you will be running these scripts.

Installing the AX 2012 Management Utilities gives you access to the Microsoft Dynamics AX 2012 Management Shell.  You can find more information here.  This is another PowerShell client with some things preloaded and some UI changes.  I prefer to use the standard PowerShell client so I preload the same things using my profile.

The script that is used by the AX 2012 Management Shell is saved by default to “C:\Program Files\Microsoft Dynamics AX\60\ManagementUtilities\Microsoft.Dynamics.ManagementUtilities.ps1”.  Adding this to your profile, prefixed with a period, will call this script and load the necessary modules into your PowerShell client session the next time it is started.  An example of my profile can be found here.  This example will also be updated with future posts so make sure you only grab what is necessary for you when downloading it.

PS_ManagementUtilities

This is as far as I plan to go today. I just wanted to walk you through the steps that are prerequisites for using the PowerShell functions that I will be talking about in later posts. Also, if you plan on using the PowerShell IDE client for examining these functions, be aware that the IDE client uses a separate profile so you will need to duplicate the profile steps for the IDE client as well.

Introduction

20 Friday Feb 2015

Posted by in Uncategorized

≈ Leave a comment

Over the last year and a half, I have spent many hours learning Powershell and researching automated builds for Dynamics AX 2012.  I have found some amazing resources online that have gotten me to a working process:

There are many more resources out there now, these are just the main ones I used to arrive at my build process.  In fact, the DynamicsAXCommunity Powershell module is required for some of my build functions.

Over the next few months I will be documenting my custom Powershell functions and eventually creating a module for them.  I will also attempt to integrate the latest version of the DynamicsAXCommunity module with them as the version I’m using has been customized.  I’m hoping that this documentation may help other developers out there who are trying to create an automated build for AX 2012.

All of the code that will be discussed in this blog can be found in Codeplex.