• About

Day 2 Day Dynamics

~ Experiences of a working AX developer

Day 2 Day Dynamics

Tag Archives: AutoRun

Refresh-AXAifPort custom PowerShell function

12 Thursday Nov 2015

Posted by John Hagler in Powershell, X++

≈ 1 Comment

Tags

AIF, Application Integration Services, Automation, AutoRun, AX, AX 2012, AX Services, Dynamics AX, PowerShell

The Refresh-AXAifPort custom PowerShell function is very useful if you have customized AIF services.  It will allow you automatically push modifications to these services when you run it after Refresh-AXServices.

This is the first PowerShell function that I’ve published that requires AX code to work.  This function calls a custom Class\Static Method called D2DAutoRunHelper::AifPortRefresh().  This class automates the steps available from the AifInboundPort form.

AifInboundPortForm

The D2DAutoRunHelper class is available in Codeplex as an .xpo.  It must be imported into your environment for this PowerShell function to work.  The steps of the AifPortRefresh function are:

  • deactivates the port specified using the AIFPort parameter
  • removes all of the service class operations specified by the ServiceClass parameter
  • re-adds all existing operations minus the operations passed in the DisabledOperations parameter
  • disables then re-enables all fields minus the fields passed in the DisabledFields parameter
  • marks any fields required that are passed in the RequiredFields parameter
  • reactivates the port specified using the AIFPort parameter

Some things to be aware of:

  • you can’t disable a field that is required by the design of the service
  • you don’t need to mark required any fields that are required by the design of the service
  • for most services, you won’t need to pass DisabledOperations, DisabledFields or RequiredFields parameters as it will automatically deploy a service based on the design that exists in the AOT
  • the XPath value for fields should be used in the “Fields” parameters separated by commas (no spaces)

The Refresh-AXAifPort function takes between 1 and 12 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 30 minutes but can be overridden if desired)
  • AIFPort (The name of the AIF inbound port where the service is deployed)
  • ServiceClass (The name of the service class that is being exposed)
  • DisabledOperations (A comma delimited list of operations that aren’t exposed)
  • DisabledFields (A comma delimited list of fields that aren’t enabled)
  • RequiredFields (A comma delimited list of fields that are required)
  • 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 D2DAutoRunHelper::AifPortRefresh AutoRun xml using the Get-AXAutoRunXML function
  • Call the Start-AXAutoRun function to re-deploy the service

This function is being released as a stand-alone function as well as part of the 1.0.3 release of the D2DDynamics module.  The 1.0.3 release also includes a change to the Restore-AXDatabase function and Build-AXModel_Variables.ps1 to change the timeout parameter to use minutes like every other function in the module does.

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

Refresh-AXServices custom PowerShell function

23 Friday Oct 2015

Posted by John Hagler in Powershell

≈ 1 Comment

Tags

AIF, Application Integration Framework, Automation, AutoRun, AX, AX 2012, AX Services, PowerShell, R2 CU7, RegisterServices

Now that we have a working build, I’m going to be focusing on the functions that I use to manage my environment and code pushes. I will be releasing these functions as both stand-alone functions and to the D2DDynamics module.  You can integrate them into your environment either way.

The Refresh-AXServices custom PowerShell function allows you to automate service refresh functionality in AX.  This function looks just like all of the other functions that use Start-AXAutoRun.  It is a template you will see over and over again.

The process it is automating is navigating to the Services node in the AOT, expanding the node and then right clicking on a service and choosing Add-ins -> Register services.

RegisterServicesAlt

This process opens an AIF Services form that allows you to see information regarding your AX service classes.  It also has a button to allow you to refresh your services when there are code changes.  This is the process that is automated.

ServicesReresh

The Refresh-AXServices 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 30 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)

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 AIFServiceGenerationManager::registerServices AutoRun xml using the Get-AXAutoRunXML function
  • Call the Start-AXAutoRun function to refresh the services

This function uses the ability that the AutoRun process has of calling static methods in AX.  While this particular function is being used to call the AIFServiceGenerationManager::registerServices() static method, AutoRun allows you to call any static method inside of AX.  If you get really creative with it, you can build your own static methods inside of custom classes to automate non-static method processes inside of AX.  The AutoRun functionality is very powerful and can probably be used to automate just about any process inside of AX.

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

Import-AXVSProject custom PowerShell function

18 Tuesday Aug 2015

Posted by John Hagler in Powershell

≈ 1 Comment

Tags

Automation, AutoRun, AX, AX 2012, AX Project, Build Scripts, Compile, Dynamics AX, PowerShell, Visual Studio

The Import-AXVSProject function is the second of 2 functions to support more complicated Visual Studio 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 earlier post should allow a user that does have these complicated scenarios to import VS projects for a build.

This function uses a system class to import the VS project.  The AX SysAutoRun functionality allows users to call a static method of a class in AX.  The AX system class SysTreeNodeVSProject has a static method called importProject() that takes an argument of a VS project file and imports it into AX.

Using the Import-AXVSProject function in conjunction with the Compile-AXXppNode function will allow you to import VS projects and compile them in any order that you need to.  If you have projects that are dependent on AX code to compile correctly, you can compile the AOT or specific nodes of the AOT before importing and compiling the project.  If the AX code or another VS project is dependent on the VS project, you can change that order.  These functions allow you to import and compile in a manner that gives you control over order and saves time from a full AOT compile.

The Import-AXVSProject custom PowerShell function takes between 1-8 parameters:

  • ConfigPath (Client configuration for the chosen AX environment)
  • VSProject (The VS project to import)
  • LogFile (The logfile for SysAutoRun.  Has a default value so you only need to specify if you want to change the location.)
  • 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
  • Set up the AutoRun xml command
  • Get the AutoRun xml using the Get-AXAutoRunXML function
  • Call the Start-AXAutoRun function to compile the node
  • Send the success/fail message

This is the last function necessary to create an automated build process.  In the coming weeks I will be cleaning up my current posts to fit with some changes I have made to the existing functions and I will post a blog about putting these functions together to allow you to automate your build.  I will also be releasing a module to Codeplex in the next month that will have all of the functions packaged up for easy deployment.

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.

Start-AXAutoRun custom PowerShell function

20 Monday Apr 2015

Posted by John Hagler in Powershell

≈ 1 Comment

Tags

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

This blog post is an extra this week.  In my last blog post, I discussed my desire to clean up the duplicate code in my functions that were calling the AXAutoRun process.  This function is putting that duplicate code into a single function that my other functions will call.  I will update the code and blog posts to reflect this change.  I apologize for the changes but these functions are a work in progress.  I have been using them for over a year but one of the main reasons I wanted to blog about them was so I could clean them up and package them for others.

The Start-AXAutoRun function takes between 5 and 8 parameters

  • Ax (The PSObject returned from the Get-AXConfig DynamicsAXCommunity function)
  • Model (The AX model to open in)
  • XMLFile (The xml generated from the Get-AXAutoRunXML function)
  • LogFile (The location of the log file)
  • Process (A description of the process being run that is used for notifications)
  • Timeout (The timeout value for the process in seconds)
  • SMTPServer (SMTP server to use to send the email)
  • MailMsg (Net.Mail.MailMessage object used to send the email)

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

  • Start the AX client using the AutoRun xml
  • Wait for the timeout period for the AX client to exit
  • Send the success/fail message

The first 5 parameters are required.  The last 2 are only necessary for emailing the results.  I’m not expecting that most users would be using this function as it is intended to be an internal function used by my custom functions that call AXAutoRun.  Using this in hand with Get-AXAutoRunXML would allow you to build any custom AXAutoRun functions that you would like however.

Sync-AXDB custom PowerShell function

12 Sunday Apr 2015

Posted by John Hagler in Powershell

≈ 3 Comments

Tags

Automation, AutoRun, AX, AX 2012, Build Scripts, Database, DB, Dynamics AX, PowerShell, Synchronize

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 John Hagler in Powershell

≈ 3 Comments

Tags

Automation, AutoRun, AX, AX 2012, Build Scripts, CIL, Compile, Dynamics AX, IL, PowerShell

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 John Hagler in Powershell

≈ 1 Comment

Tags

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

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 John Hagler in Powershell

≈ 4 Comments

Tags

Automation, AutoRun, AX, AX 2012, Build Scripts, Compile, Dynamics AX, PowerShell, R2 CU7, R3, Server Compile

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.

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...