AX RTW My ODATA and JSON journey – Part III

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:

  1. Visual Studio 2015
  2. Administrator access to Azure AD
  3. 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

 

 

New Dynamics AX and the Excel Add-on

When using the «Open in Excel»( Dynamics Office Add-in) feature in the New Dynamics AX RTW, you may have some trouble opening it in Excel.

Especially if you have a corporate login, like me. It then seams that the login failed.

 

Microsoft have upgraded the Dynamics Office Add-in, but on existing demo data (Contoso) may also need to be changed.

Then the connector seams to be working (At least for me)

Also take a look at https://ax.help.dynamics.com/en/wiki/office-integration-troubleshooting/

Happy DAX’ing

New Dynamics AX On premise = Azure Stack

As we know, deploying the new Dynamics AX will basically come in 3 different flavors. I wanted to explain a bit what this means and what I have found. The information here should be double checked together with your partners, and also with Microsoft. Also remember that it all is very fresh technology, and that things may change quickly as must is in early releases and preview.

 

  1. AX Public cloud – Black-box, maintained by Microsoft in Azure and it just works.
    The public cloud “edition” was the first platform that the new Dynamics AX was released on. In the public cloud it is Microsoft personnel that is deploying and monitoring the instances. Customers and partners should have no technical access to the production environments. Data and code (like customizations) are created as packages and uploaded into LCS, where according to maintenance windows, and Microsoft will deploy them to the production environment. Customers pays a monthly fee per user, that includes licenses a production environment with high availability, disaster recovery and some sand-box environments (for testing and dev). The customer doesn’t have consider how to scale or what kind of virtual machines is needed. This is taken care of by Microsoft. Customers must expect to pay at least 110.000 USD per year in costs for this. It is my consideration that this offer actually is a very good offer, because it includes many of the services and licenses that we don’t normally consider when evaluating costs for operating a ERP system. I think than smaller customers (50-250 users) would benefit from this scenario.
  2. AX Private cloud – Maintained and deployed by customer/partner, but still on Azure.
    Private cloud is 100% running in Azure. Private just means that Microsoft is not deploying and monitoring the instances. In this scenario you will purchase AX licenses, and you will purchase Azure services and deployments. Basically 2-3 invoices J. You scale up the VM’s according to you needs, and it is your own responsibility. It is typical a partner that can help out, and you probably will have to purchase service agreements to monitor and maintain your Azure deployed instances. Will this be cheaper than the “public cloud” offer? If you compare apples with apples I don’t think so. There are many hidden costs, and if you sum up the costs, at least my internal calculations show that this offer quickly can be 20% more expensive than the Public Cloud offer. But the private cloud offers flexibility, but will demand a very knowledgeable technical department/partner. You can decide more by yourself within the boundaries of the Azure. I expect that larger customers (250+ users) would like to go for this scenario.
  3. AX On-Premise and Azure Stack – For those that have a datacenter to spare

    Azure Stack is the new hybrid cloud platform product that enables organization to deliver Azure services from their own datacenters. You get cloud services, yet maintain control. You decide where to keep your data and applications—in your own datacenter or on others/azure. You will still pay for the AX licenses, but the you will also have to pay for your own hardware. There is one problem. It is not released yet. We are waiting for Windows Server 2016 with Azure Stack, and SQL Server 2016. These are still in technical preview. But for those (like me) that like to try out, you can actually download it from https://azure.microsoft.com/en-us/overview/azure-stack/ . If you wonder what kind of machinery is needed, take a look her. (Basically 16 Cores , >128 Gb RAM and a few TB of disk). It will be a bit difficult to run the Azure Stack on my portable PC J. Also remember that there will still be lots of services that still have to be on the cloud. I assume that this option will be selected for large enterprises (1000+ users) and for hosting providers/ASP.

And remember that what I write here is not facts, but just my interpretation of how it can be.

Happy DAX’ing J

Mobile Access for Visual Studio

In the new AX the tool we use for work, development, test and build is Visual Studio Online(VSO). Now a mobile access to VSO is available in the Visual Studio Markedplace. It enables you to browse, monitor and engage in projects via your phone, It’s still in preview, but it looks very interesting.

Take a look at it here; https://marketplace.visualstudio.com/items?itemName=sprints-for-vsts.sprints-for-visualstudio

AX RTW Hack to enable unsupported countries

We have learned that today the RTW is officially released, but this is mainly for the “tier-1” countries. I’m a bit jealous on Denmark and Iceland that are in the first support release wave, and that Norway have to wait until H2 2016 to get country specific support. But when I dig into the AX RTW I will find much of the country specific elements already in place. They have been included in the transfer from AX 2012.

Only one small Issue. Microsoft have hardcoded that the unsupported features cannot be used. I guess (and hope) that it is for a reason. If you try to create an unsupported company for Finland, you get;

Many of the localized fields needed to run Finland is then hidden or disabled.

But there is a way to “Hack” this. Comment out your country from SysCountryRegionCode.onCountryRegionSupportedCheck():

Then compile and deploy. Then the fields related to Finland etc will open up.

I know I’m are moving into uncharted terrain, and this is disabled for a reason. But we start already now to promote and sell AX 7, and then we expect Microsoft to stick to the release schedule, and make the Dynamics AX ready for all countries as planned. We also have several customers that don’t need the localized company specific functionality, and they don’t want to be constantly reminded J.

Disclaimer; If you do this for a production environment you are on your own!

Hacking Dax’ing

AX RTW – My ODATA and JSON journey – Part I

Learn the word; ODATA. We will hear a lot of ODATA in the future, because it will change the way we integrate and how we exchange information between AX and other systems. A good starting point is the AX help wiki, that Kuntal Mehta created. I have decided to explore what the ODATA can do, and wanted to write a bit about my journey. Instead of trying to explain all technical details of data entities and how the architecture is, then let us rather just test something J

What you need to test what I’m doing is

  1. An AX RTW environment deployed from LCS
  2. Internet explorer
  3. Good old notepad

Step1: What services is available?

To get all entities available to you use your Site address, and add “/data” at the end.

Then save the file you receive, and open it in notepad. (I have associated *.json with notepad). The file you get looks like this:

Each line here represents a data entity service we can use. The format of this is the JSON format, but that is not important now.

Step2: Show me the customers

In the file you may find that there is an entity/schema named “Customers“. I can therefore just add the “/data/Customers” to my URL

And then I get a JSON file of all the customers;

But this is a bit “cloudy” and I can further filer down what I want. Let’s say I just want to see all customer names. I can then add “/data/Customers/?$select=Name” to my URL

Now it returns a JSON file with only the Name.

If I wanted to add one more column, like the Payment terms, the syntax would look like “/data/Customers/?$select=Name,PaymentTerms“, but this would not work because the comma cannot be used on a URL. I therefore need to replace the comma with %2C, that is the URL representation of comma. For multiple columns I therefore add “/data/Customers/?$select=Name%2CPaymentTerms

You see some strange “@data.etag”, and here is an explanation. It is for caching.

Step3: Can I read this in Excel?

Yes. Excel can import OData, and format it like we would.

Then fill in the /data URL, select schema, and then select fields.

And then you may read directly into Excel all entities made available in AX RTW, even without the AX connector.

Step5: Show me all !

Sure. Try to add the “/data/$metadata“, and AX return All schemas, fields and relations. It take a long time, but nice to explore.

Step6: Can we use DIXF to import directly from OData feeds ?

This is what I would love to see. But I have not found it yet.

Happy DAX’ing😉