Do Not use the .Net Business Connector with AX 2012

With the release of Microsoft Dynamics AX 2012, a lot a great things have come about. One area that I have spent some time on now, is around integration. In the past, when integrating outside line of business (LOB) applications or custom software, the options for enabling this were either the use of AIF Document Services or the .Net Business Connector.

There is good reason not to use the .Net Business Connector, as I point out in the following post: Net Business Connector Not Recommend for AX 2012



A reader today, stated that they have read on the web, and with my blog post, to not use the .Net Business Connector with AX 2012 integration's, but they were not really clear why. I thought this would make for a good post, as to clear the air of sorts on this topic, and explain why.

First you see from the above AX 2012 system architecture image, that the .Net BC is actually used in a few places to enable different parts of the solution. With that said, and beyond this fact, the only reason the .Net BC exists in AX 2012, is to truly support backwards compatibility. Understand this, future versions of AX, beyond AX 2012 will not have the .Net BC as an option. This has been made very clear in the official Microsoft Documentation released on the subject.

This means, that anyone upgrading from previous versions, will still have their integration's developed using the .Net BC, will still work. However, planning should be made to make the switch to make use of services.

The desire behind this move, is to take away proprietary technology that the .Net BC represents, and the RPC protocol it implements, and use more true .Net technologies, like WCF. This move, not only takes a step towards true .Net native code execution, but also replaces the very chatty protocol of RPC, with the less chatty and more well formed protocol of WCF.

So the reasons, for not using .Net Business Connector in AX 2012 are.:

• 1. Microsoft will not support it beyond AX 2012
• 2. It using the RPC protocol for communication which is very chatty compared to WCF, and does not enable the vision of cloud computing Microsoft has for AX in version 7.0 and beyond

I started, on this list, to add more, but honestly the first reason in the list is point enough. Microsoft will not support the .Net BC after AX 2012. Since that is the case, any development done with it, or any integration that is not upgraded and changed to make use of WCF and Services in AX 2012 is a waste of time and money.

I hope that through the many efforts of those in the community, including myself, to point to the desired method of services with: Custom services and document services, that it's clear why the .Net BC should not be used. Upgrades are supported to AX 2012 that make use of this technology, however it's important to understand that such integration's have to be changed over for any version of AX beyond AX 2012.

With this, I believe we can move forward and all understand that any integration efforts between AX 2012 and the outside world, should reside around services. This is, as I've pointed out before, a true statement even within AX 2012. Services help abstract some of the complexities of AX 2012, and help empower the marketing term powerfully simple.

That's all for now, but check back soon as I continue with my dive into workflows, and many other great topics. Till next time!

Update: A fellow peer of mine pointed out that this post sounded a little harsh. That is never my intention at all, and I hope this is taking as a warning. The idea is to save you time, money and effort and help deliver a clear message that WCF and services are the way for extending and integrating with AX 2012.

"Visit the Dynamics AX Community Page today!"