pickTable method being painfully slow in AX 2012?

The call to pickTable in a user session can be extremely slow. I have measured times of up to 20 (!) minutes on an otherwise well functioning system.

A trace shows very clearly that the method is very chatty, so wrap the call into a server bound method. And ta-da, what took minutes now takes a second or two.

Explore the different form arrangements in AX 7

There is a tutorial form in AX 7 that shows you the different types of form arrangements.

The link to the form is: https://(your AX instance).cloudax.dynamics.com/?f=tutorial_Form_Arrange&cmp=DAT

Show the table browser in AX7

I just wanted to share this tip I have picked up from Marc Hugelshofer in a forum.

In your browser you can open the table browser by entering an URL that looks something like this:

https://(the url of your ax instance)/Default.htm?mi=SysTableBrowser&prt=initial&cmp=USMF&tablename=CustGroup&limitednav=true

Creating code for a dll that might or might not be on the system

We are working on a vertical solution where parts of it requires integration with an external .net dll. Not all customers are interested in using the part that requires the external dll, and thus they are not interested in installing the dll.

So how can we write our code so it will compile and run regardless of this dll being there or not.

Well, one way is to create a proxy class in AX to wrap all operations for the external dll. The proxy class need to call the dll through CLRObjects which makes it possible to compile the code even if the dll is not present. Secondly the proxy class needs to runtime deal with the fact that the dll is not there.

The following job shows how the proxy class could be constructed. The example works with a random standard dll I choose.

static void TestCLR(Args _args)
{
    CLRObject /*Microsoft.Dynamics.AX.Framework.Tools.DMF.CrossInstanceProxy.InstanceProxy*/ dllObject;

    str     nameOK     = 'Microsoft.Dynamics.AX.Framework.Tools.DMF.CrossInstanceProxy.InstanceProxy';
    str     nameNotOK  = 'xMicrosoft.Dynamics.AX.Framework.Tools.DMF.CrossInstanceProxy.InstanceProxy';

    str proxyStr = nameNotOk; // Switch name here to test with the dll being alright and the opposite

    try
    {
        dllObject = new CLRObject(proxyStr);
    }

    catch (Exception::Internal)
    {
        // Clear the info log of CLR errors
        infolog.clear(infologLine() - 2);
       
        // Register that the dll couldn't be instantiated
        print "Could not make an instance of the dll";
    }

    if (dllObject)
    {
        print "Got the object";
    }
    else
    {
        print "No instance";
    }
    pause;
}

It is a pest working against just the CLRObject and not with the direct access you could get if you could be sure that the dll would be there. That's a another reason for wrapping all your calls to the dll into an X++ proxy class.