• About

Day 2 Day Dynamics

~ Experiences of a working AX developer

Day 2 Day Dynamics

Tag Archives: AX Services

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.

 

 

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.

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