As mentioned in my previous post, I promised to demonstrate the power of Visual Studio integration with AX. There are times where it doesn’t make sense to do everything in X++, and native Azure integration is one of those scenarios.
The first thing you’ll want to do is grab NuGet. If you’re using VS2013 ( read the latest on AX 2012 R3 CU8 if you don’t know already! ) then you already have NuGet Package Manager available. If you’re using a previous version of AX 2012, you can install NuGet manually via the Extensions Manager.
In Visual Studio, click Tools and then Extension Manager. Navigating to Online, find the NuGet Package Manager extension and click Download.
After you have the extension installed successfully, let’s create a new Visual Studio C# project:
You can name it anything you wish, however I did rename my Class1.cs file to Proxy.
Right-clicking on your project, you now have an option to view the NuGet Package Manager, from which you can search online for the Azure Service Bus:
After this is installed, you will see a few new references to your VS Project, and can add their namespaces to your Proxy class. Also be sure to make your class public!
Now, let’s fill the class out a bit with a constructor, an initializer method for the QueueClient, and a method to populate the queue:
Now that we have something workable, let’s add the project to the AOT so that we can really have some fun:
From here, I add the AxCustInvoiceTable AXBC class to the project. This is an AIF-wrapper class that I’m using purely as an example, you could use any Table, Class, or other AOT object to populate the data that you wish.
What’s amazing, is that we can pass this exact class back to X++ execution, for native processing within the ERP system.
I’ve added a couple of extra methods to facilitate determining the size of the queue, and then processing them in to instances of the AxCustInvoiceTable class:
Now, unfortunately with the VS2010 integration ( and perhaps the VS2013, we shall see ), we have an issue where 3rd party DLL references in the project are not saved in to the AOT. To resolve this, we need to open our project file in Notepad:
Adding the VSProjectOutputFiles node will ensure that these referenced DLLs are copied to the target directory when deployed by AX. That would be the AppData VSAssemblies folder for client-side execution (jobs, GUI), or the Server\Bin\VSAssemblies folder for batch job or other server side processing.
Be sure to mark the project as Deploy to Client and then right-click the solution to Deploy:
Now, let’s move over to our AX client and open up a quick job.
The above job initializes the Proxy class by constructing a connection string. It then initializes the QueueClient, loads the queue with a dynamic number of messages.
It then retrieves those messages one by one, and populates a single method on our example invoice class.
You can see from this example here, there is a lot of potential with using Azure Service Bus Queues, and even Topics ( another post for another day! ). Surely this gives AX an advantage that it can be offline and the queue can still be populated by other applications. Our next and final post in this series will show how we can use the SysOperation framework for batch processing on the server. A multi-threaded approach for high throughput scenarios.