• About

Day 2 Day Dynamics

~ Experiences of a working AX developer

Day 2 Day Dynamics

Monthly Archives: May 2015

Import-AXLabelFile custom PowerShell function

21 Thursday May 2015

Posted by John Hagler in Powershell

≈ 2 Comments

Tags

ALD, ALDImport, Automation, AX, AX 2012, AX Import, AX Label, Build Scripts, Dynamics AX, PowerShell

The Import-AXLabelFile PowerShell function allows you to import an AX label file into an environment.  While getting this function ready for the post, I realized that I had made a mistake in an earlier post.  My current build process was built to handle one layer and one model.  That was all I needed at the time and I had a limited amount of time to get it up and running.  It was always my plan to make this more generic however and to do that I needed to make my functions and build process able to work for multiple layers and models.  This required a few changes.

I needed a way to support what model is opened in AX for both this function and the Import-AXXPO function.  I have done that using the Model parameter.  Using the ConfigFile parameter to control layer and the Model file to control the model in that layer, individual calls have the ability to control the startup model versus using the “Startup model” system parameter that I had been using.  I have updated both the Start-AXAutoRun and Import-AXXPO functions to support this parameter as well as the blog posts regarding these functions.

The Start-AXAutoRun function takes between 5 and 8 parameters

  • ConfigPath (Client configuration for the chosen AX environment)
  • Model (The AX model to open in)
  • LabelFile (The label file to import)
  • Timeout (The value defaults to 10 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
  • Validate the LabelFile parameter location
  • Start the AX client using the aldimport startup command
  • Wait for the timeout period for the AX client to exit
  • Send the success/fail message

This function is extremely similar to the Start-AXAutoRun function.  There are multiple commands to use to start AX and while AutoRun can do multiple things, it can’t import label files.  It is possible to reduce code duplication by dropping the Start-AXAutoRun function and replacing it with a very similar function that takes a command parameter for the AX -startupcmd parameter but I haven’t done that yet.  I hadn’t previously had a function for importing label files.  I was just doing this with a few lines of code in my build process.  Just one of the perils of building this weekly in my spare time.  Optimization through iteration.

Import-AXXPO custom PowerShell function

12 Tuesday May 2015

Posted by John Hagler in Powershell

≈ 3 Comments

Tags

Automation, AX, AX 2012, AX Development, AX Import, Build Scripts, Dynamics AX, PowerShell, XPO

The Import-AXXPO custom PowerShell function allows you to automate the importing of .xpo files.  It is going to look very familiar to people who have read some of my other functions as it follows the same format as Compile-AXCIL and Sync-AXDB.

The Import-AXXPO function takes between 2 and 9 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 20 minutes but can be overridden if desired)
  • ImportFile (The .xpo file to import)
  • Model (The AX model to open in)
  • 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
  • Validate the ImportFile parameter location
  • 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 import the .xpo

Some things to consider with this function.  Where an .xpo is imported is controlled by 3 things.  The configuration file used to open AX will control what layer the .xpo is imported into.  The model is controlled by either the Model parameter or the user option “Startup model” (Tools -> Options -> Development -> Startup model).  This value is stored per user and per layer so make sure you have this value set up in every AX environment that you will be importing .xpos in if you don’t use the Model parameter.

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.

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