FormDataSource display methods must be static

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:

FormDataSource display methods must be static

This should eliminate the error messages for your custom display methods.

Force executing batch jobs

There is an old, but good article posted by Tariq Bell about the inner workings of the AX Batch framework. When you are working with Dev and Test instances and enable/disable the Batch flag in Server configuration, it might take a while before your tasks are starting to run. There is a simple trick to force executing batch jobs.

As explained in the reference article, each batch task and the framework itself triggers this call, when they are ready to finish execution and a new task needs to be picked up. You could just write a simple job and trigger it with a Menu Item on Server side to kick off a batch job earlier.

static void Job1(Args _args)

Providing the correct instance number and the server name is required in order to force executing batch jobs.

We have used this method in part to change the batch framework itself, and allow execution of jobs faster than the typical 1 minute schedule. I wanted to post about those findings, but unfortunately that code is not compatible with more recent versions of AX 2012 R3 CU10+, due to Microsoft introducing the new SP_GETAPPLOCK calls in the framework.

By |2022-03-31T13:16:31+02:00March 31st, 2022|Categories: AX 2012, Microsoft Dynamics AX|Tags: , , , |0 Comments

Incorrect auto upgrade on custom methods

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:

incorrect auto upgrade on custom methods

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.

How to force running jobs server-side

We frequently write quick-fix jobs, or even some quite heavy ones which are bound to execute client-side by default. The workaround is to create an Action MenuItem pointing at the job, and setting RunOn to be Server. Then next time we need to use the code we forget about that, and it takes awfully lot to complete execution. We need to force running jobs server-side in X++ somehow, for which I do have a neat solution.

We could check if the job is running on a client or on the AOS. Then we can call the menu function to force open it server-side from code.

    // Place validation at the beginning of a job that is supposed to be server-bound
    if (!isRunningOnServer())
        new MenuFunction(menuitemActionStr(YourJobActionMenuItem), MenuItemType::Action).run();

Here is a quick example showing it in action:

Running Jobs server-side

This will guarantee faster execution times for database calls and resource-intensive processes, granting permissions required to be server-bound, or code that relies on reflection such as traversing AOT. We do not need to worry about remembering whether it should run on the client or not, or do not have to find the correct menu item manually. It just works!

By |2020-03-23T13:24:54+01:00September 12th, 2018|Categories: AX 2012|Tags: , , , |2 Comments
Go to Top