During our Dynamics 365 code upgrade the display methods on forms were raising an error. The new rule is that FormDataSource display methods must be static calls. Here is the relevant section from the Docs site:
Our change to display an Employee’s custom Job title looked like this after the upgrade:
[ExtensionOf(formDataSourceStr(HcmWorker, JJEAdditionalEmplTable))]
public final class HCMWorker_DS_JJEAdditionalEmplTable_JADOperation_Extension
{
static display Description jobTitleDescription(JJEAdditionalEmplTable _additionalEmplTable)
{
Description ret = '';
if (_additionalEmplTable)
{
ret = JJEJobTitles::find(_additionalEmplTable.JobTitle).Description;
}
return ret;
}
}
In the form designer now you need to refer this display method as a static call as per below in your extension:
In the new Microsoft Dynamics 365 Finance and Operations release a lot of things have changed in terms of reflection. One of them that we have used frequently for security access validation is gone, DictSecurityKey is deprecated.
You can find a list of still available classes which are mostly used against AOT objects here:
Sometimes we have noticed that our SQL health report has shown an out of control TempDB growth. It has happened for example when we have triggered bulk invoiced sales order cleanup, or some other larger processes. You can find out more about monitoring TempDB growth for version store in these articles:
Running the following statement can tell you the currently occupied space overall, and per file in your TempDB. Our normal usage is around 2 GB, so having a 67GB space used looked very suspicious.
SELECT SUM(CAST(FILEPROPERTY(name, 'SpaceUsed')/128.0 AS DECIMAL(10,2))) AS [Space Used in MB]
FROM sysfiles
SELECT RTRIM(name) AS [Segment Name], groupid AS [Group Id], filename AS [File Name],
CAST(size/128.0 AS DECIMAL(10,2)) AS [Allocated Size in MB],
CAST(FILEPROPERTY(name, 'SpaceUsed')/128.0 AS DECIMAL(10,2)) AS [Space Used in MB],
CAST([maxsize]/128.0 AS DECIMAL(10,2)) AS [Max in MB],
CAST([maxsize]/128.0-(FILEPROPERTY(name, 'SpaceUsed')/128.0) AS DECIMAL(10,2)) AS [Available Space in MB]
FROM sysfiles
ORDER BY groupid DESC
This query shows the composition of data within the TempDB files. It was immediately apparent that it is not the user/system data that is taking up the space, but the so called version store. Normally that should be regularly cleaned up by an internal process, unless there is a dead thread/blocking/something broken within SQL:
SELECT
--SUM(allocated_extent_page_count) AS [allocated extent pages used],
--(SUM(allocated_extent_page_count)*1.0/128) AS [allocated extent space in MB],
SUM(version_store_reserved_page_count) AS [version store pages used],
(SUM(version_store_reserved_page_count)*1.0/128) AS [version store space in MB],
SUM(user_object_reserved_page_count) AS [user object pages used],
(SUM(user_object_reserved_page_count)*1.0/128) AS [user object space in MB],
SUM(internal_object_reserved_page_count) AS [internal object pages used],
(SUM(internal_object_reserved_page_count)*1.0/128) AS [internal object space in MB],
SUM(mixed_extent_page_count) AS [mixed object pages used],
(SUM(mixed_extent_page_count)*1.0/128) AS [mixed object space in MB]
FROM sys.dm_db_file_space_usage;
The following query has shown that session 224 was active for several days, with a sleeping state, thus preventing this TempDB cleanup on the version store to run.
DECLARE @runtime datetime
SET @runtime = GETDATE()
PRINT '-- sys.dm_db_file_space_used'
select CONVERT (varchar(30), @runtime, 121) AS runtime, SUM (user_object_reserved_page_count)*8 as usr_obj_kb,
SUM (internal_object_reserved_page_count)*8 as internal_obj_kb,
SUM (version_store_reserved_page_count)*8 as version_store_kb,
SUM (unallocated_extent_page_count)*8 as freespace_kb,
SUM (mixed_extent_page_count)*8 as mixedextent_kb
FROM sys.dm_db_file_space_usage
PRINT ' -- Output of active transactions which are using version store'
select CONVERT (varchar(30), @runtime, 121) AS runtime,a.*,b.kpid,b.blocked,b.lastwaittype,b.waitresource,b.dbid,b.cpu,b.physical_io,b.memusage,b.login_time,b.last_batch,b.open_tran,b.status,b.hostname,b.program_name,b.cmd,b.loginame,request_id
from sys.dm_tran_active_snapshot_database_transactions a
inner join sys.sysprocesses b
on a.session_id = b.spid
PRINT ' -- Input buffer of SPIDs identified above Output of active transactions which are using version store'
select CONVERT (varchar(30), @runtime, 121) AS runtime,b.spid,c.*
from sys.dm_tran_active_snapshot_database_transactions a
inner join sys.sysprocesses b
on a.session_id = b.spid
cross apply sys.dm_exec_sql_text(sql_handle) c
PRINT ' -- Open cursors'
select * from sys.dm_exec_cursors(0) a
cross apply sys.dm_exec_sql_text(sql_handle)
WHERE DATEDIFF(hh, a.creation_time, GETDATE()) > 1;
The above Session 224 was running on one of our AX integration AOS instances. As a quick fix, restarting the AX AOS service has released the API sessions.
The root cause analysis has revealed that if we refer tables, which have their configuration keys turned off, it can generate TempDB entries. In our case the sales order deletion batch job was running SalesLineType::delete. It has a LedgerCov::deleteTransact call, which is a delete_from ledgerCov in a transaction block. We have introduced a configuration key check for the table, and that has eliminated the out of control TempDB growth issue.
We highly recommend to have a close look at your TempDB usage, and try to identify which tables with a disabled configuration key can have a big performance impact on your environment by running code unnecessarily.
The Microsoft Dynamics Application Checker is an excellent tool, which utilizes the BaseX XML-parsing software. Since all our objects and source code for Microsoft Dynamics 365 are represented as XML files, this presents an excellent opportunity to do XPath parsing. As a prerequisite for the software first, before you could include it in your build routine. We have seen an App Checker BaseX error like this:
Error: Could not create the Java Virtual Machine. Error: A fatal exception has occurred. Program will exit. Invalid maximum heap size: -Xmx15000m The specified size exceeds the maximum representable size.
When you deploy BaseX, it is recommended to increase the usable memory size in order to fit the entire Dynamics repository. Increasing the memory usage can result in the above error message. The solution is to deploy the 64-bit Java Runtime Environment, which makes the App Checker BaseX error disapper.
During our upgrade journey from AX 2012 to Microsoft Dynamics 365 Finance and Operations we have noticed some problems. The automated code upgrade tool available on LifeCycle Services for your modelstore did an incorrect auto upgrade on custom methods.
When we did the first builds, the following error message was showing up for various code pieces:
Compile Fatal Error: Table dynamics://Table/CCMTmpQuestions: [(39,5),(39,6)]: Unexpected token '/' specified outside the scope of any class or model element.
After checking the source code we have identified that somehow it has inserted extra lines at the end of some table methods, with a single / sign in them:
The quickest way to locate all those methods are to use our favorite file manager and search tool, Total Commander.
You can press <ALT>+<F7> and do a file search for *.xml in your \AOSService\PackagesLocalDirectory\[YourPackageName] folder for the following Regular expression value. You must tick the RegEx checkbox:
(^ \/)$
This has revealed all incorrect files, which we could fix in bulk. You can use similar approach as above to quickly find anything in the file-based Dynamics 365 Finance and Operations code repository.
Once you quick-replace these characters with a blank line, you are done fixing the incorrect auto upgrade on custom methods.
