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.
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.
The year 2021 has almost come to an end, and it’s time to review the changes we’ve had this past year.
So in case you’ve missed something, I hope you can find it here, although I won’t include all new or changed Dynamics 365 Finance & Operations features, only some of them, the ones I’ve found more interesting.
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:
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.