In D365 if we need to create a new label and assign that to Label or Help text of an item, we have to create label in the label file and then paste in the object. There is no way by which via the object properties we can create a new label or edit existing one. There should be an ability to create a new label or edit the existing one when we go through object properties where Label or help text is provided.
Please rebuild cross references on the DEV VM before making it available. They currently contain references to modules that aren't included at the box (unit tests) and don't contain xRefs that should be there. For example, I had to rebuild the application to get "Find event handlers" working.
Evaluation of cross-references is very important with such a large code base (for understanding the current solution, for impact analysis and so on). Unfortunately the experience is worse than in previous versions of AX; here are some suggestions:
- Allow filtering and sorting.
- Add filtering options similar to those in Application Explorer (by type, model etc.).
- When I get a list of references, I often want to look at where some references are used. Please make it possible directly from the same window. For example, I could click on a reference and use "Find reference on it". Or I could be able to expand the node and see a hierarchy of references.
- Re-introduce "Reference" field, such as the information where a field is written into. I know it was dropped consciously, but it was really useful. If the standard "Find Symbol Results" doesn't support things like this, it's probably time to move from it.
By the way, when you later decide to switch to SQL Server 2017, wouldn't DynamicsXRefDB form a nice graph database?
Adding a new Workflow Type requires the addition of a number of new supporting artifacts. It also requires changes to existing artifacts, namely the form and the table that is associated with the record for which the workflow type is being created. There are properties that must be changed on the form to enable it for Workflow and you cannot make these changes via an Extension. Instead, you must customize via Overlayering.
The Application is going to be sealed at some point which will prohibit customization via Overlayering. This request is to allow Form Property changes as extensions.
It would be great to make #region (https://docs.microsoft.com/en-us/dotnet/csharp/language-reference/preprocessor-directives/preprocessor-region) also available in X++.
It will make the code more readable, understandable and maintainable.
NuGet packages are extremely useful for adding and updating dependencies to .NET projects, especially in complicated cases. It would makes sense to be able to add NuGet packages to X++ projects in the same way as to C# projects, for instance.
I can recognize several scenarios:
- Traditional NuGet packages with compiled code and other resources, such as resource files and images. For example, let's say I want to add WindowsAzure.ServiceBus to my X++ project. It should support all existing packages with appropriate requirements (version of .NET Framework). It must resolve all packages, copy files to the modelstore and add appropriate references to AOT.
- Packages including source code / metadata ("content"). For example, the package will add an X++ class with a default implementation that can be changed by developers as needed. NuGet supports this scenario. It could also support source code transformations - I don't have any good scenario for it in the moment, but making sure that this NuGet feature doesn't get broken will give us some extra options.
- Deployable packages created from X++ code. For example, an open-source extensible control (in its own model+package) could be distributed as a NuGet package, therefore everybody would be able to add it to their solutions and receive updates from the same source. Installation scripts of the NuGet package would install the deployable package in the usual way. What needs to be addressed are requirements such as a specific minimum version of AX platform.
The implementation should utilize the existing integration to Visual Studio whenever possible, such as respecting custom package sources (Options > NuGet Package Manager > Package Sources).
Complex system integrations commonly rely on change tracking to determine what data should be included in a given execution. Dynamics 365 F&O currently supports change tracking via the data management framework using SQL change tracking on the underlying data entity views. This meets the need when file-based recurring integrations are used to sync D365 F&O with the external system.
However, many scenarios rely on oData endpoints for data entities in D365 F&O to perform the tasks associated with the integration. In this scenario, there is no way to execute the integration on only the data that has changed since the last execution.
There is a need for a "point-in-time" change tracking feature that would allow an external system to call an oData endpoint to select all records that have changed since a given date/time.
Because we deliver deployable packages (Bin) to a customer, there is no 'xpp' and no possibilities to make enhanced extension on that.
Of course, we want to give the opportunity to our customers to make extensions on our functionalities.
But we want to be sure that our code will not be stole by someone who is malicious.
The extension is a wonderful thing, but allow the possibility to easily stole the code if we deliver the content of the models.
I think we are not only ISVs / Partners who be aware of that...
We want to have a way to protect our code but we want to give the possibility to a customer to make extensions based on our code too.
And we want to allow the possibility to debug too. But with the binaries it's complicated.
No possibilities to see some piece of code, only the stack.
It's the same issue for a D365FO app on appsource...
So, it will be very helpful if we have the possibility to make enhanced extensions & debug directly on binaries.
Ever faced performance issues due to parameter sniffing on other columns than DataAreaId or PartitionId?
What if we could have more control over the fact which column is handled as a literal (and not as a parameter) in the query?
Microsoft Dynamics 365 Finance and Operations, Enterprise edition has the functionality to change this for the entire query using forceLiterals, this will overload the queryplan cash with an individual queryplan+compile overhead for each individual query execution.
OR the DataAreaIDLiteral and PartitionIDLiteral than solves the problem for these columns in the application.
What if we would have a table field property to control this behavior? It would avoid coding for each individual query affected by that field.
For example: A customer who has 10 warehouses and uses serial numbers hence high volume of records in the InventDim table, 75% of all InventDim records is in only one warehouse. So if a query plan gets optimized for a small warehouse we create significant performance issues with parameterized queryâ€™s. If we could specify a literal in a query only on the warehouse this would generate 10 query plans which are far more optimized.
(Special thanks go to KevinRoos)