Next, let’s add some service operations for customers, such as the following and then we’ll activate the port:
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:
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:
I’ll call the new solution RestfulCustomer and then select Azure API App (Preview):
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:
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:
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
I’ll call mine CustomerController.cs and it is defined as follows:
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.
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:
Let’s drill down in to the Customer API and open up the Get /api/Customer operation:
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:
Which matches AX:
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:
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:
Now, back in the Azure Portal let’s select our App Service Plan from the Browse All blade:
From there scroll down til you see the Network option and select your new Virtual Network created earlier.
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:
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.
Again, we run in to a lack of an index.html:
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:
Next post, we’ll make better use of this API in some of the other fun features available in the Azure App Services suite!
Written by Lane Swenka
Dynamics AX Technical Engineer, mcaConnect