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).
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.
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…
In Microsoft Dynamics 365 for Finance and Operations we can execute the CRUD operations from code in two different ways, record-per-record or set-based. Microsoft’s recommendation is to always use set-based operations, if possible, as you can check on the Implementation Best Practices for Dynamics 365: Performance best practices for a successful Dynamics 365 Finance and Operations implementation session from last June’s Business Applications Summit. Why? Set-based Vs. Record-per-record When we run a query in MSDyn365FO…
WARNING! THIS POST IS LONG OUTDATED AND VISUAL STUDIO 2022 IS THE DEFAULT IDE SINCE DYNAMICS 365 FINANCE AND OPERATIONS VERSION 10.0.40 AND THE VHD SINCE APRIL 2024 RELEASE. Tired of developing in Visual Studio 2015? You feel you’ve been left and forgotten in the past? Worry no more, you can use Visual Studio 2017/2019 to develop Microsoft Dynamics 365 for Finance & Operations! What are the advantages? Absolutely none at all! Visual Studio will…