Menu

Looking for the latest industry news and events?  Want to learn more about Microsoft Dynamics?  You've come to the right place!

How to integrate Microsoft Dynamics AX with Azure Logic and Other Apps

This post originally appeared on the AX Developer Connection Blog 

Microsoft Dynamics AX is an ERP platform designed for integration. The ease at which you can fire up a web service and call it from external clients makes this a premium ERP system to be sought after. I strongly suspect this will become even better in future versions of the AX product.

While the AIF and custom WCF services have been out for some time, and even others have shown how to mask these endpoints with a RESTful wrapper – today I’d like to demonstrate how you can turn your services in to plug n’ play components for Azure Logic and other apps.

To start, we first need a service in AX to work with. Let’s create a new Inbound Port and call it CustomerService:

Creating CustomerService Port

Next, let’s add some service operations for customers, such as the following and then we’ll activate the port:

Adding service operations

Now we should have a WSDL that we can work with locally.  Let’s create a new API App by opening Visual Studio 2013 and browsing to a new ASP .NET Web Application:

Creating a new API

If you don’t have the latest Azure SDK, you can download it from Visual Studio by going to File->New Project->Visual C#->Cloud->Download SDK:

Installing Azure SDK

I’ll call the new solution RestfulCustomer and then select Azure API App (Preview):

Selecting Azure API App

The key difference between a WebAPI and Azure API App is that the authentication is disabled. This is because you’ll use auth options from Azure such as Azure Active Directory, or another Identity Provider such as Google, Facebook, or a good ol’ Microsoft Live account.

Now let’s add our WSDL as a Service Reference:

Adding Service Reference

Add service reference

Let’s call the reference AXCustomerService and finish with the dialog.

Now, let’s create our Customer Model by right-clicking and adding a New Class to the Models folder in our project. I’ll call my model Customer.cs and it is defined as follows:

Custoner cs
Customer cs2

You’ll need to update this with the appropriate credentials you wish to connect to AX, as well as the legal entity in the CallContext.  Of course, if you wish to use Claims Users, you can pass along an email address from your calling application as long as that user exists in AX.  See Joris’ blog entry regarding Trusted Intermediaries.

Next, let’s right-click our Controllers folder and select Add New Controller.  Select WebAPI 2 with read/write actions

Azure integration 8

I’ll call mine CustomerController.cs and it is defined as follows:

Customer Controller

Naturally, you’ll want to populate the other service operations in the controller if you wish to edit, create, or delete new customers via this restful API.  For now, we should have enough to hit F5 and debug our new API.

Azure integration 9

What did we do wrong?  Well, nothing actually.  The API Apps template does not provide a welcome or help page.  Instead, let’s add /swagger/ to the URI and we should be greated with the Swashbuckle implementation of our API’s metadata:

Swagger

Let’s drill down in to the Customer API and open up the Get /api/Customer operation:

Azure integration 11

This is the metadata behind the operation.  Swagger allows Azure Apps platform to understand the inputs of the API, and what it returns.  Let’s switch the response content to “application/xml” and run it to see the output:

Azure integration 12

Which matches AX:

AX API

This is great.  Now, let’s setup our Azure API App in https://portal.azure.com/ .  Click on New->Web & Mobile->API App.  I’ll call mine AzureRestCustomer:

Azure API App

Be sure to select the Standard pricing tier, as this will be important later.

As that is being deployed, let’s setup an Azure Virtual Network for our AOS host. To do this, follow the tutorials here. After that is completed and successfully connected to the VNET, or if you already have a VNET, note down the IP assigned to your AOS via ipconfig:

Command Prompt

Now, back in the Azure Portal let’s select our App Service Plan from the Browse All blade:

Azure Portal

From there scroll down til you see the Network option and select your new Virtual Network created earlier.

Selecting the Virtual Network

This connects your APIs back to your on-premises network so that they can communicate with internal resources.

Back in Visual Studio, it’s time to publish our application. You’ll want to either have configured your web.config file appropriate for Debug vs Release, or as I have lazily done just modified the web.config to point from my AOS local DNS name to its Azure VNET IP of 10.0.0.4.

Then, select the project in your solution and right-click and choose Publish:

Publish in Azure

Select the API App (Preview) option and then choose your API App from the list.  Mine was called AzureRestCustomer. Keep all of the defaults and then publish your API to the cloud.

Publishing API to the cloud

Again, we run in to a lack of an index.html:

Lack of index error

As before, add the /swagger/ to your URI and you should still be able to retrieve your customers from on-premises a-la-cloud over HTTPS:

Retrieving customers from the cloud

Next post, we’ll make better use of this API in some of the other fun features available in the Azure App Services suite!


Lane SwenkaWritten by Lane Swenka
Dynamics AX Technical Engineer, mcaConnect