Showing posts with label AX 2012. Show all posts
Showing posts with label AX 2012. Show all posts

Thursday, 29 January 2015

How the Connector for Dynamics consumes AX AIF Document Services

I've been working lately on integration with AX using the Application Integration Framework (AIF) and thought some might find this little code sample useful.

This example demonstrates conceptually how the Connector for Dynamics makes service calls AX to get data (without change tracking enabled). 

At a high level, the Connector for Dynamics integrates with AX by:
  1. Calling the findKeys service operation to get a collection of entity keys
  2. Iterating over the collection of keys and calling the read service operation providing each key. This ensures only one record per document is returned, for example one customer
Here is the sample code:

[TestClass]
public class AxCustomerToCrmAccountTests
{
    private readonly CallContext _callContext = new CallContext
    {
        Company = "company",
        Language = "en-US"
    };

    [TestMethod]
    public void TestShowingHowTheConnectorCallsAx()
    {

        // setup the client
        // Use the following to specify credentials otherwise:
        //      ConnCustomerOrgServiceClient client = new ConnCustomerOrgServiceClient() 
        // will do.
        ConnCustomerOrgServiceClient client = new ConnCustomerOrgServiceClient(new NetTcpBinding(),
                new EndpointAddress(new Uri("net.tcp://host:integrationport/DynamicsAx/Services/DynamicsConnectorDefaultServices")));

        string userName = @"domain\username";
        string password = "password";
        if (client.ClientCredentials != null)
        {
            client.ClientCredentials.Windows.ClientCredential = new NetworkCredential(userName, password);
        }

        using (client)
        {
            // construct the query criteria
            // Base on AxdConnCustomerOrg
            // Gets data based on modified date time of the parent datasource in the document service query
            QueryCriteria queryCriteria = new QueryCriteria
            {
                CriteriaElement = new[]
                {
                    new CriteriaElement
                    {
                        DataSourceName = "CustTable",
                        FieldName = "modifiedDateTime",
                        Operator = Operator.GreaterOrEqual,
                        Value1 = new DateTime(2015, 1, 25, 1, 0, 0).ToString("s") 
                    }
                }
            };

            // find the keys based on the query criteria
            EntityKey[] keys = client.findKeys(_callContext, queryCriteria);

            // iterate over the keys to read each document
            if (keys != null)
            {
                foreach (var entityKey in keys)
                {
                    // Get the specific message for the selected customer
                    AxdConnCustomerOrg axCustomer = client.read(_callContext, new[]
                    {
                        entityKey
                    });

                    AxdEntity_CustTable custTable = axCustomer.CustTable.First();

                    // Not a real unit test, just output some data to verify it works
                    Console.WriteLine("{0}|{1}", custTable.AccountNum, custTable.RecId);
                }
            }
        }
    }
}



Friday, 13 December 2013

Quick Tip #1: Debug with reduced permissions

I discovered this neat trick when troubleshooting Security issues in AX 2012.

I’m not sure about you, but finding issues related to restricted security for a user is sometimes like looking for a needle in a haystack. Suffice to say that this often leads to users having more permissions than they should.

It would be nice if security related failures were at least logged somewhere, but currently they can present themselves in many different forms, often disguising the real issue.

Debugging code can be one way to troubleshoot security related issues, and is often a last resort. However if you remove yourself (or the user you are testing) from the System Administrator group, you cannot debug. And even if you didn't need to debug, it is inefficient to say the least. So here's how you can have your cake and eat it too.

How to steps

  1. Start AX and modify the security for the user you are logged in as. This user must be a member of the system administrator role.
  2. Open a developer workspace (Ctrl + Shift + W)
  3. Ensure you set breakpoints in the code that you wish to debug.
  4. Create a job and run the following code:
    SecurityUtil::sysAdminMode(false);
    
  5. Open an application workspace from the development workspace (Ctrl + W)
  6. Perform the task you are troubleshooting and the debugger will start when it encounters a breakpoint.
To revert to system administrator privileges, close out of AX and then launch the application how you normally would. Or alternatively, Change the code in your job to:

SecurityUtil::sysAdminMode(true);

and run. This will put the session back in admin mode. Just open an application workspace from the development workspace and you once again have full admin privileges. 

More information about this can be found in the Microsoft Dynamics AX 2012 White Paper: Role-based Security Use Patterns for Developers.