Building Your Own Export Framework with Dynamics AX (part 1)


Error message

Deprecated function: implode(): Passing glue string after array is deprecated. Swap the parameters in drupal_get_feeds() (line 394 of D:\home\site\wwwroot\webapp\includes\

It’s a fresh year, and I’m really excited about the new tutorials I have to share with you. Today, I’ll start with a brief overview of the next batch of blog posts centered around data export.

ERP systems contain a massive wealth of information.  In many cases, this data can be accessed on demand from outside applications via the AIF.  However, there come situations where it is best to export that data to an external database.  Common scenarios include data warehousing, reporting, and integrations that require 100% uptime, even while AX may be offline for a modelstore update or upgrade.

When it comes to data export, there are several options available.  If you don’t mind the normalization inherent of AX, you can use SQL database replication to copy to an external source.  Or, you can create ODBC connections on your AOS hosts and draft custom X++ to write data directly to another database.  You even could look at the new Data Import / Export Framework that ships with AX 2012 R3, if you don’t mind the fact the only option for export is a flat file…

I’d like to make the case for another option: build your own framework.  It isn’t all that involved, and can give you a lot more options. 

Over the next three posts I’ll demonstrate how to:

**Use an ASP.NET Web API combined with Entity Framework to handle the exported data

**Create a Visual Studio project within the AOT to use .NET Dynamic objects that match the strongly typed objects from the Web API

**Add a mapping function in AX to relate entities in the ERP with entities from the API.  Also, I’ll discuss how to make adjustments after you get things going.

Let’s get started!

First, open Visual Studio 2013 and create a new Web Application:

Next, let’s select WebAPI.  Of course, you can host this on your (Free!) Azure account via your MSDN Subscription but for the purpose of simplicity let’s just host it locally to start.

Now the fun part, let’s create some classes in the Model folder that will represent our exported business objects.  For example, I’ll start with Customer:

Note the additional using statement there for the data annotations.  This allows us to set explicitly our primary key.

After your class is created, go ahead and Build the solution.  If you have no errors at this point, let’s add a new Controller to the Controllers folder for our class.  Be sure to use the option with Entity Framework!

I named my objects as such, feel free to use whatever naming convention you prefer:

We now have a workable API for customer data.

Let’s make a quick enhancement to the simple GET command ( /api/Customer/5 ) and make sure that for customer 0 which will never exist, we get ourselves an empty data contract.  This will help us in the next phase when AX needs to synchronize with the contracts from the API.

From here, you can hit F5 if you wish, and check out the API home page.  If you’re feeling even more daring, you can check out the api/Customer/0 to validate you get a new customer contract!

A quick check of the localDB that Visual Studio uses by default will show you the matching database has been created, along with our Customer table schema:

In our next post, we’ll show how to create a C# Project in the AOT that will consume this API and create .NET Dynamic Objects that match the data contract we have setup for the Customer.