Last week I took (and passed :P) exam MB-300: Microsoft Dynamics 365: Core Finance and Operations. After taking other older exams I’d like to share my views on MB-300.Continue reading “Exam MB-300: Core Finance and Operations”
It looks like the time has finally come and all new LCS projects will have self-service Tier 2+ environments. If you want to know a bit more about them, I wrote this post about service fabric/self-service environments in Microsoft Dynamics 365 for Finance and Operations.
The last two projects we’ve started at Axazure are on self-service and we’ve had a customer migrated to it. So it’s about time I warn you about one scary thing…
I talked about the LCS Database Movement API in a post not long ago, and in this one I’ll show how to call the API using PowerShell from your Azure DevOps Pipelines.
Basically, automation. Right now the API only allows the refresh from one Microsoft Dynamics 365 for Finance and Operations environment to another, so the idea is having fresh data from production in our UAT environments daily. I don’t know which new operations the API will support in the future but another idea could be adding the DB export operation (creating a bacpac) to the pipeline and having a copy of prod ready to be restored in a Dev environment.
Since last October we’ve been able to try the preview of Microsoft Dynamics 365 for Finance and Operations Database Movement API which allows us to list and download DB backups and start DB refreshes using a REST API.
If you want to join the preview you first need to be part of the MSDyn365FO Insider Program where you can join the “Dynamics 365 for Finance and Operations Insider Community“. Once invited to the Yammer organization you can ask to join the “Self-Service Database Movement / DataALM” group where you’ll get the information to add yourself to the preview and enable it on LCS.
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).
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.
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:
— 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.
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 still go non-responding whatever the version is because it’s the dev tools extension what’s causing the issues.
Of course we get the option to use Live Share, and for screen sharing sessions that’s way better than teams. Hey, and we’ll be using the latest VS version!
Is it difficult?
No, zero mysteries. The first thing we need to do is downloading Visual Studio 2019 Professional (or Enterprise but it won’t make such a difference for D365 development) and install it:
Select the .NET desktop development option and press install. When the installation is finished we log in with our account.
The next step is installing the Dynamics developer tools extension for VS. Go to drive K and in the DeployablePackages you’ll find some ZIP files that have the extension in the DevToolsService/Scripts folder:
An alternative is, for example, downloading a Platform Update package which also has the dev tools extensions, and maybe with some update to them.
Install the extension and the VS2019 option is already there:
Once installed open VS as the admin and…
Don’t panic! The extension was made for VS2015 and using it in a newer version can cause some warnings, but it’s just that, the tools are installed and ready to use:
As I said in the beginning, the dev tools extension is the one causing the unresponsiveness or blocks in VS, and Visual Studio 2019 is letting us know:
But regardless of the warnings working with Visual Studio 2019 is possible. I’ve been doing so for a week and I still haven’t found a blocking issue that makes me go back to VS2015.
Update: it looks like opening a report design will only display its XML instead of the designer. Thanks to David Murray for warning me about it!
Dev tools preview
In October 2019 the dev tools’ preview version will be published, as we could see in the MBAS in Atlanta. Let’s see which new features this will bring us both in a possible VS version upgrade or performance.
First of all… DISCLAIMER: think twice before using this on a productive environment. Then think again. And if you finally decide to use it, do it in the most cautious and light way.
Why does this deserve a disclaimer? Well, even though the docs state that the system performance should not be impacted, I don’t really know its true impact. Plus it’s on an ERP. On one in which we don’t have access to the production environment (unless you’re On-Prem) to certify that there’s no performance degradation. And because probably Microsoft’s already using it to collect data from the environments to show up in LCS, and I don’t know if it could interfere on it. A lot of I-don’t-knows.
Would I use it on production? YES. It will be really helpful in some cases.
With that said, what am I going to write about that needs a disclaimer? As the title says, about using Azure Application Insights in Microsoft Dynamics 365 for Finance and Operations. This post is just one of the “Have you seen that? Yeah, we should try it!” consequences of Juanan (and on Twitter, follow him!) and me talking. And the that this time was this post from Lane Swenka on AX Developer Connection. So nothing original here 🙂
Azure Application Insights
What’s Application Insights? As the documentation says:
Application Insights is an extensible Application Performance Management (APM) service for web developers on multiple platforms. Use it to monitor your blah web application. It will blah blah detect blaaah anomalies. It blah powerful blahblah tools to bleh blah blih and blah blah blaaaah. It’s blaaaaaaaah.
Mmmm… you better watch this video:
So much misery and sadness in the first 30 seconds…
Monitoring. That’s what it does and is for. “LCS already does that!“. OK, extra monitoring! Everybody loves extra, like in pizzas, unless it’s pinneapple, of course.
Getting it to work
The first step will be to create an Application Insights resource on our Azure subscription. Regarding pricing: the first 5GB per month are free and data will be retained for 90 days. More details here.
Then we need the code. I’ll skip the details in this part because it’s perfectly detailed in the link above (this one), just follow the steps. You basically need to create a DLL library to handle the events and send data to AAI and use it from MSDyn365FO. In our version we’ve additionally added the trackTrace method to the C# library. Then just add a reference to the DLL in your MSDyn365FO Visual Studio project and it’s ready to use.
What can we measure?
And now the interesting part (I hope). Page views, capture errors (or all infologs), batch executions, field value changes, and anything else you can extend and call our API methods.
For example, we can extend the FormDataUtil class from the forms engine. This class has several methods that are called from forms in different actions on the data sources, like validating the write, delete, field validations, etc… And also this:
This will run after a form field value is modified. We’ll extend it to log which field is having it’s value changed, the old and new value. Like this:
And because the Application Insights call will also store the user that triggered the value change, we just got a new database log! Even better, we got a new database log that has no performance consequences because there’s no extra data to be generated on MSDyn365FO’s side. The only drawback in this is that it will only be called from forms, but it might be enough to monitor the usage of forms and counter the “no, I haven’t changed any parameter” 🙂
This is what we get on Azure’s Application Insights metrics explorer:
Yes you did, Admin! Ooops it’s me…
We’re storing the AOS name too and if the call was originated in a Batch.
All the metrics from our events will display on Azure and the data can be displayed later in Power BI, if you feel like doing it.
With this example you can go on and add calls to the extended objects where you need it. Batches, integrations, critical processes, etc…
Again, please plan what you want to monitor before using this and test it. Then test it again, especially on SAT environments with Azure SQL databases which perform a bit different than the regular SQL Server ones.
And enjoy the data!
One of the options to integrate MSDyn365FO with external systems is using the data entities with REST services and OData. To use OData the entity must have its IsPublic property set to Yes:
Otherwise, if it´s an standard entity, we´ll need to duplicate it because it´s not possible to change the property value in an extension.
If we´re doing an integration with an external system using OData to create new records in the ERP, we can have an issue when the record has a mandatory ID, as we can see in the Customers V3 entity. If we check the Mandatory property of the CustomerAccount field it´s set to Auto, getting the value from the CustTable where it´s set to Yes.
In this case, if we try to create a customer without an account number the service will fail as it can be seen in the Postman capture below:
Crystal clear error, the customer account field cannot be empty.
This isn´t happening with the Vendors entity. “Hey! But the vendor account is mandatory in the VendTable!” someone may think. Correct, it is, but not in the entity where it´s been overriden:
To see how the standard solves this we need to check the entity initValue method:
The skipNumberSequenceCheck is one of the data methods from the Common class, and it´s a relative of skipDataMethods, skipDataSourceValidateWrite, skipAosValidation, etc… It will always return false unless we tell it not to do so by passing true earlier in the code through the parameter.
The NumberSeqRecordFieldHandler class enableNumberSequenceControlForField will initialize the value of the field we pass in the parameters with the next value from the sequence we select. In this case it´s filling the vendor account field with the sequence set in the vendor parameters (obviously)
So, doing the same as the standard does, we’re going to extend the entity and the initValue method:
Having done this we’ll try again in Postman, this time deleting the CustomerAccount parameter from the body, and…
Success! We’ve got a new customer! Created from an external system and using the number sequence from Dynamics 365.
This is no mistery, it just mimicks what the standard does. As MSDyn365FO developers we must try to do that, always. Always… as long as we can, of course 🙂 Because even though partners always try to apply the standard as much as possible, we all know that in the end, there´ll be some customization done (hopefully, we´re developers!).