Torben Nehmer Hitachi Solutions Germany Technical Director, Fast Track Recognized Solution Architect

Activity Search does not allow you to search for the SQL SPID, the column is not taken into account when looking for results. It would be very important to have this information when trying to debug sql blockings. Often, the headblocker is not visible in the active queries just its victims. Main reason is, that the head blocker needs to execute something to become visible, which is not always the case.

Without the head blocker data, it is not possible to track down the actuall blocking processes activity id etc. to get more insights into what was going on.

The only workaround currently is to log onto the sql server, use sys.dm_exec_sessions to get the host process id and query that one. This will not work on production, of course, where this help would be most important!

Right now, it is challenging to track delays induced by bad network behavior or bad client systems for the F&O web client, specifically:

• Latency on the network level
• Latency due to browser rendering
• Memory pressure on the client
• CPU pressure on the client
• Timeouts on connections
• Network connection type (wired, wireless, with or without VPN)

There are possibly more ideas on client telemetry, the WHS mobile app telemetry is a great example of this. It would make debugging potentially slow clients much more apparent. In the past, we had several instances of random performance issues, which turned out to be bad clients or networking.

Right now, all DLL dependencies (.NET assemblies) in a D365 package get loaded into the same process space as the whole AOS server. This has several drawbacks as it leads us in a DLL hell. If a DLL is included by the AOS or any default package, one must not add another version of the DLL, especially since it is often undefined, which DLL gets lucky enough to get loaded first. This kan wreak all kind of havoc, as the problems are not always reproducible.

This is especially critical with some of the Azure standard DLLs deployed by the standard. If - for whatever reason - you require another (mostly newer) DLL instead, you can't do so (usually leading to Azure Function micro-services or similar constructs).

Beyond that, if you have two ISVs with contradicting dependencies (been there in the past), you are at the whim of the ISV distributors to unify their packages to a compatible dependency version.

As a solution, custom DLL dependencies could be isolated in AppDomains. As a primary solution in .NET to isolate applications or extensions from each other, the AOS should formally support this. Ideally, all non Microsoft packages should use such a mechanism to avoid conflicts (you could check this in ISV / AppSource validations even).

While I'm aware that we can do this at the C# level ourselves, it is a rather deep change we would be doing there. Thus, a standard approach to introducing a new AppDomain with a depending assembly would be important, plus enforcing AppSource packages to use this.

Having the AOS kernel team support this, is therefore paramount.

In a perfect world, there would be an automatic proxying between X++ code and DLLs in their AppDomains.

Current FormRun telemetry is too limited in the information it provides. To make more effective use of it, please add customization information:

• Is a saved view applied?
• If so, which one, and on which level (personal or shared) was the view created
• Has the query been manipulated?
• If so, provide the query details (preferrably SQL) when startup exceeds a certain threshold, for example log it above 1s
• The MenuItem we were called from
• CallerSource information

When users start customizing forms, it is often a problem that their manipulations are not performance-effective. Isolating these cases is very difficult, mostly because you need the cooperation of the users, which have to understand what's happening to a certain extent. Having this telemetry, an administrator could continously monitor the system for bad customizations.

Right now, the Browser Session Id is not available on X++, at least not consistently, or it isn't documented adequately how to get this information. When trying to track processes, especially for telemetry purposes, this information would be helpful, as it connects various individual Server-side activites (each with their own ActivityId) to a consistent whole. Also, LCS provides this information for the same purpose.

The standard telemetry should add this browser session ID consistently to all entries, so that one can analyse the telemetry of a given session more effectively.

In either case, make this value available for consumption in custom modules as well, please do not hide it in internal code. This would allow advanced monitoring in special cases by custom code.