Today we have a quick and easy X++ post where we’ll learn how to create an encrypted field in Dynamics 365 Finance and Operations.
Creating an encrypted field in Dynamics 365 Finance and Operations is a simple process that can help secure sensitive information in your application. By using an encryption key to encrypt the data, it ensures that the data remains safe even if it is accessed by unauthorized users.
It’s been a while since I first wrote about the Application Checker in 2019, and here I am again. In this blog post, I’ll talk about SocrateX and XQuery too, and I’ll also show how to generate the files and databases used to analyze the code.
If you want to know more about App Checker or SocrateX, you can read these resources in addition to the post I’ve linked above:
We’re finally getting a throttling functionality for OData integrations!
It’s one of the most common requirements from a customer: the need to integrate Dynamics 365 with other systems. With the (back in the day) new AX7 we got a new way of integrating using the OData REST endpoint and the exposed Data Entities.
But integrations using the OData endpoints have low performance and for high-volume integrations, it’s better to use the Data management package REST API. A (not so) high volume usage of the OData REST API will translate into performance issues.
The throttling functionality is in preview starting version 10.0.13 which is currently in PEAP. It will be enforced starting April 2021. You can join the Data Management, Data Entities, OData, and Integrations Yammer group for more info. Remember you need to join the Insider Program for Dynamics 365 first to be able to access the Yammer group.
If you want to learn more about OData and throttling you can check these resources:
A short one! Some time ago I explained how to add a multi selection lookup to a SysOperation dialog and in this post I’ll explain how to add a Menu Item as a Function button to the SysOperation dialog.
Before the SysOperation Framework was introduced in AX2012, we used the RunBase Framework, and maybe doing these things looked easier/quickier with RunBase because all the logic was in a single class. But in the end what we need to do is practically the same but we have to do it in the UIBuilder class.
Let me show you and explain all the code. I’ll only show the DataContract and UIBuilder classes as they’re the only important ones in this case.
Compiler warnings. Warnings. They’re not errors, only warnings. You can just overlook and forget them, right? Well, I hope you aren’t.
“But even the standard code done by Microsoft throws warnings!”, you could say. And that’s true, but that’s not your code, it’s Microsoft’s. If a functionality you’re using breaks because they didn’t care about their warnings, you can open a support request and it’s Microsoft’s job to fix it. If your code breaks some functionality because you didn’t care about a warning, it’s your job to fix it, and your customer will want it as fast as you’d want Microsoft to fix their error.
That’s why we should be warned about warnings (badum tss).
With the latest Dynamics 365 for Finance and SCM 10.0.10 version, we’re getting a new feature that will allow us to add actions to the message bar, using the Messaging API like we used to do in AX2012 with the SysInfoAction class.
Remember this is in the latest preview version. You can access the preview versions joining the Dynamics 365 Insider Program.
First 2020 post! Happy new year! Yes, I know it’s already past mid January…
When you add a field to a SysOperation Framework Data Contract the lookup that the framework creates (if the EDT has a lookup) is a simple, single select lookup. Let’s see how to create a multi select lookup in MSDyn365FO.
But first of all a bit of an introduction! The SysOperation Framework was introduced in Dynamics AX 2012 to replace the RunBase Framework, and is used to create processes that will be run by the batch server. The RunBase classes are still around in Dynamics 365 for Finance and Operations. Some standard processes still use it while others use it to later call a SysOperations Framework class.
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).
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.
