Cloud First, Mobile First Series: New Dynamics AX


Hi all! It’s been a bit of a break from the blog and twitter-sphere the past couple of months.  As many of you are aware, AX7 ( now, simply called Dynamics AX ) has been made publically available for testing and the release is coming soon!  As it is now public, the strict Non-Disclosure Agreements surrounding the product have been lifted and we are able to spread the good news.

To start off 2016, I’m running a series on how the Microsoft Cloud First, Mobile First mission is satisfied in the new Dynamics AX.

In November, I had the pleasure of passing the Architecting Microsoft Azure Solutions exam and I highly recommend this for any old or new AX developer.  It forced me to learn the inner workings of the Azure cloud offerings, how they are priced, and when to pick certain solutions over other similar options based on requirements. 

With Dynamics AX, you now get Azure features by default as the new ERP system is entirely cloud based.  The ease at which Blob Storage, APIs, Logic Apps, Machine Learning, Hadoop / Data Lakes, Queues, Load Balancing, and more can be woven in to the product is beyond anything we have ever seen before.

To bring the focus in for this post, I’d like to highlight the excellent work done by the Data Management and Integration portion of the Dynamics AX Product Team.  In AX 2012, we had separate and diverging concepts for integration: Application Integration Framework (AIF) with Document Services, and we had Data Import/Export Framework (DIXF).  While both served their own purpose, it was confusing when to use what.

In the new version of AX, the Product Team has consolidated this in to a single Data Management Framework (DMF).  This introduces Data Entities, which are the foundation and replacement of both AIF and DIXF:

We can see that the Data Entity can be exposed as either a synchronous service call, or via asynchronous or recurring integrations with the DMF platform. 

The authentication for both are a bit more complex than in AX 2012, as the new ERP system is backed by the Azure Active Directory identity provider.  AAD is not necessarily based on Windows credentials, although it is commonly synchronized with an on-prem Active Directory database.  AAD allows companies to build new native Windows or Web-based applications that integrate with AX, and requires that these applications be catalogued in AAD on Azure. 

When you add a new application to your AAD tenant, it receives a client GUID and a secret key.  This is used to authenticate the application and permit actions against AX.  The client GUID and key can be used against a REST API to obtain your authorization header in which your applications must pass on each call to AX OData services or async APIs.

While the integration options in the new AX are outstanding, there are still questions that technical architects must face in terms of balancing load on high-traffic integrations, and also the possibility for failover or outages on both sides of any integration. 

Introducing the Azure answer to this dilemma – Service Bus Queues & Topics!

Often times external systems such as warehouse / supply chain, manufacturing, or online storefronts are integrating data back and forth with AX.  During periods of high volume, this could overload the AX service and cause performance problems or outages.  To account for this, we can make use of a Service Bus Queue between our integrating apps and AX.

This provides a form of load balancing, as we can drop messages on to a queue at a variable and rapid pace, and then process those messages one at a time in AX.  It also allows for maintenance windows on the AX end of things, without disrupting integrations.

If we find AX falling behind and the queue size is growing, we can add additional AX instances to add performance.  This is commonly referred to as the Competing Consumers Pattern:

 

Using the new Extension Model of software development, I’ve created a simple AXDC Integrations model which extends the Application Platform, Foundation, and Suite models provided by Microsoft:

If you aren’t aware of what an Extension is, in simple terms it means we can add to existing objects provided by Microsoft, without overlayering them.  This means we are not customizing the base application, but simply adding new fields to tables, new controls to forms, extension methods to classes, and so forth.  In all actuality, these are DLLs referencing Microsoft DLLs. In most scenarios, we don’t want to change the software provided by Microsoft and instead just wish to extend it for our needs.  That is what we have done here.

Using extensions, we have added a new datasource to an existing form and placed a few new controls on the form to match.  In the UI, the extension is seamless:

You can see here, the authentication mechanism for Service Bus Queues is also much simpler than OAuth and AAD tokens.  We simply need to provide a key and that key contains permissions on whether we can send messages in to a queue, retrieve messages out of a queue, or manage the queue (create, update, delete).

From here, we can create new queues right from inside of AX:

We can see the queue is created in AX and in Azure:

In AX, we have options for making the queue inbound or outbound. This is how I’ve built this example extension to handle bidirectional integration.  Using Service Bus, you can specify a ReplyTo metadata property on a message so that we know after we are done processing a message we can put it in a ReplyTo queue outbound.  This is similar to Text Messages when you see your text was “Delivered” to the desired party.

Using the JSON capabilities built in to the new Dynamics AX, we can serialize a data entity to JSON and pass that as a message outbound to the queue for other applications.  Likewise we can receive a JSON message and map those properties to fields on AX Data Entity:

So there you have it!  A simple queue can solve a lot of problems in the cloud integration world, and the new Dynamics AX is primed for using these kinds of Azure solutions with ease.  Using the Extensions capabilities, we can seamlessly add functionality to the ERP without customizing the base software which is really important for ease of upgrades in the future, and heavily regulated industries.

Note, this example extension will be posted to GitHub on February 1, 2016.