As you might know MSDyn365FO’s data access layer pretty different from T-SQL. This means that if you copy a query on AX and paste it in SSMS it won’t validate in the 99% of the cases (the other 1% being a select * from table).
You can read my complete guide on Microsoft Dynamics 365 for Finance & Operations and Azure DevOps.
I’ve already written some posts about development Application Lifecycle Management (ALM) for Dynamics 365 for Finance and Operations in the past:
The possibility of doing real CI/CD is one of my favorite MSDyn365FO things, going from “What’s source control?” to “Mandatory source control or die” has been a blessing. I’ll never get tired of saying this.
This past weekend I’ve attended my third 365 Saturday, this time in Barcelona, as a speaker. As you can see in the post title, my session has been about creating inventory counting journals using AI Builder with the Power Platform.
First Microsoft Dynamics 365 for Finance and Operations Retail post! I hope more will come.
As you might know, one of the setbacks of the database refresh from production in LCS is that some data doesn’t get copied. This is a safety feature that prevents, among others, that emails are sent or batches run accidentally after a DB restore.
Some time ago I had to create an interface between MSDyn365FO and a web service that returned data as XML. I decided to use X++’s XML classes (XmlDocument, XmlNodeList, XmlElement, etc…) to parse the XML and get the data. These classes are terrible. You get the job done but in an ugly way. There’s a better method to quickly parse XML or JSON in MSDyn365FO.
Feature management has been around in Microsoft Dynamics 365 for Finance and Operations for some time now. Before that features were enabled through flighting running a SQL query on dev and UAT boxes (and the DSE team would do it on production).
Now we have a nice workspace showing all the available features and flighting is still around too. The main difference between flighting and features is that flighting is enabled to a selected group of customers, like a preview of a feature.
You can read my complete guide on Microsoft Dynamics 365 for Finance & Operations and Azure DevOps.
During this past night (at least it was night for me :P) the new tasks for Azure DevOps to deploy the packages and update model versions have been published:
The official @AzureDevOps task to deploy @MSFTDynamics365 F&O customizations is now added to our marketplace extension! Hot off the press! https://t.co/ExXJ3CKbUW https://t.co/q4qOScg6vv#FinOpsDevOps
— Joris de Gruyter (@jorisdg) May 1, 2019
There’s an announcement in the Community blogs too with extended details on setting it up. Let´s see the new tasks and how to set them up.
Unless you’ve been working for an ISV there’s a high percentage of probabilities that you’ve never cared about Dynamics Best Practices (BP), or maybe you have. I haven’t worked for an ISV myself but back when I started working with AX I was handed the development BP document (and you can download the old Microsoft Dynamics AX 2009 development best practices white paper PDF from here) and I’ve tried to follow most of them when…
Right now Microsoft Dynamics 365 for Finance and Operations has an old style monolithic architecture, even it’s now in Azure’s cloud, what we really have is a single (or multiple for Tier 2+ environments) VM that runs everything: the AOS/IIS, Azure SQL Server, the Batch service, MR, etc. Exactly the same as AX 2009/2012. This is going to change in the coming months with the self-service deployments. We’ll move from the monolithic architecture to microservices…