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.
So three days ago I took a look at the new 10.0.25 features currently in the PEAP program, calmly scrolling through until I saw something about custom scripts on prod, something that read:
You can imagine my face when I read this. At the beginning I was confused, then surprised and then confused again. After reading the description, the situation wouldn’t get better:
This feature lets you upload and run deployable packages that contain custom X++ scripts without having to go through Microsoft Dynamics Lifecycle Services (LCS) or suspend your system. Therefore, you can correct minor data inconsistences without causing any disruptive downtime.
Are we getting a way to run custom code in production without having to deploy it? Yes we are. As many people have said these past two days: “X++ jobs are back!”. And there are a lot of discussions going on about the custom scripts feature.
QR codes are very present in our daily lives as a way to share information, URLs, or other data quickly.
I’ve got the power! (To generate QR codes)
In this post, we’ll learn how to display one in a Dynamics 365 form or a SSRS report using a library which is included in our development VMs: QRCoder.
Need to get the price of an item that has a sales or purchase agreement? The PriceDisc class is here to save us!
Trying to catch the best price using the PriceDisc framework
This is one of those reference posts that I’m writing for the Adrià of the future, because it’s something I forget about a lot.
PriceDisc magic!
There’s an obsolete method, I think it was findItemPriceAgreement, to get the price, but it’s obsolete, as I’ve just said. So the easiest way to get a price is to use the PriceDisc class that replaces the obsolete method.
To use it, just instantiate a PriceDiscParameters object and call all the parm methods you need. Finally, create a PriceDisc object using the newFromPriceDiscParameters method and passing the PriceDiscParameters, and… well take a look at the code below:
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.
This is a fakeX SocrateX
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:
I bet that most of us have had to develop some .NET class library to solve something in Dynamics 365 Finance and Operations. You create a C# project, build it, and add the DLL as a reference in your FnO project. Don’t do that anymore! You can add the .NET project to source control, build it in your pipeline, and the DLL gets added to the deployable package!
I’ve been trying this during the last days after a conversation on Yammer, and while I’ve managed to build .NET and X++ code in the same pipeline, I’ve found some issues or limitations.
If you want to know more about builds, releases, and the Dev ALM of Dynamics 365 you can read my full guide on MSDyn365 & Azure DevOps ALM.
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.
If you’re working with the (not so) new self-service Tier 2 environments in Dynamics 365 for Finance and Operations you might have already noticed this: the reports in Tier 2+ and production environments aren’t using the SSRS report viewer, instead they’re being displayed in a beautiful PDF preview form.
But what happens on your development box?
If you want to know more about self-service environments you can read these posts I wrote a while back:
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.