Now the fun begins, and let’s develop! The following post is only meant for hardcore Dynamics AX technical consultants J
In previous posts I wrote about how to access Dynamics AX data and metadata through ODATA and only using an internet Explorer. In these scenario’s we where only fetching data from Dynamics AX. This time, we will use Visual Studio to publish data into Dynamics AX, by accessing the ODATA services. I must let you know, that I consider myself as a newbie to creating C# code, and the following post is only for giving you a directional guide for you to start exploring for yourself.
What you need to make this happen is:
- Visual Studio 2015
- Administrator access to Azure AD
- A deployed New AX on Azure
What I wanted to achieve here, is to be able to add vendors from a C# program. A None-Dynamics AX developer may have no idea of the inner structure of AX, but they can be given access to the metadata. Based on this metadata it should be possible to create CRUD integrations. One issue with Visual Studio is that it is not possible to consume ODATA services directly. So we need to generate a proxy library. The MSDN OData v4 Client Code Generator is the best way of doing this, because it will generate wrapper classes for the data entities. To speed up a bit I found the AX-LAB12, where Microsoft is showing how to import a BOM, here I found the framework that we can use. This AX-LAB12 contains a word document that is good to understanding how to set this up. I’m “stealing” the following 4 first classes from the.
The AuthenticationUtility is the class that makes sure we are authenticated with Azure AD, and that we are logged in with the right user. In this class you can hardcode the user/password and the Tendant and the ActiveDirectoryClientAppId
The next step is to generate the ODataProxy. This is done in the Microsoft.Dynamics.DataEntities project. This basically means creating a bunch of classes that reflects all the metadata. It will give us a class, so that we can assign values to Odata fields and execute methods etc. But first we must specify where all the metadata can be downloaded from. In the picture below, you see that this is just a hardcoded string in the OdataProxyGenerator.tt file.
Then right-click as shown under, and select the “Run Custom Tool”.
This will then download all the metadata from the published data entities in Dynamics AX, and create one class per data entity. It takes a few minutes, and it creates thousands of classes.
Since we want to create vendors, it is interesting to see how the Vendor data entity looks in AX, and how the generated C# proxy class looks like:
As you see, we are consuming the ODATA Data entities into visual studio, that let’s to access fields and methods as we are used to in X++. And this by only generating proxy classes from the Odata metadata.
Then I may start developing against the ODATA proxy classes, and now I see that fields and method lookup, that we are used to in X++ is working. As seen in the following picture, I’m declaring the vendVendorEntity of the type Vendor, that have the same structure as defined in the Data Entity.
My complete code for creating a vendor using ODATA is therefore :
I build and run:
I then check AX to see if the vendor is created:
It works J
Let’s try to see if I change the code, and are selecting a vendor group that does not exists :
It correctly don’t let me create the vendor J
The conclusion:
The ability to create CRUD operations using ODATA, changes the game. External none-Dynamics developers can create apps and integrations through the Odata services, and it regulated through security and validation. They don’t need to know the internal structure of Dynamics, because this is exposed through the metadata service. Dynamics AX is truly a game changer.
Happy DAX’ing J
