AIF Services and the .Net BC - Where and When?

One of the sessions I attended at Convergence 2010, was the AXUG Software Architect SIG. The initial coverage post for that session, can be found at the following link.: Coverage of AXUG Software Architect SIG at Convergence 2010

In this, a good bit of topics were on the minds of the people who attended. One of them was around AIF Services and the .Net BC. What a good bit of discussion for this surrounded, was where and when to use either?

As promised in the above post, this is a start into digging deeper into the topics covered during that session. So for this When and Where should AIF Services or .Net BC be used, when connecting into a Dynamics AX instance?

This is a valid question actually, as both offer the ability to interact with Dynamics AX. Both offer different pro's and con's as well.

Lets look at the nature of these two different paths for interacting with Dynamics AX from an outside application, service or other LOB application.

First AIF Services. AIF Services are targeted specific end points for document exchange in and out of Dynamics AX, on a transactional, one off level. These services are generated from an AOT Query element, and make use of Axd* Classes, which in turn AX uses to generate the WCF Services that end up being hosted in IIS.

These are WCF services, and so when consumed by a .Net Application, BizTalk, or other LOB Application, will interact as such. These services represent Dynamics AX "Documents". Which could be reading a customer, a sales order, creating a purchase req, or any custom AIF Service you create.

From looking at past use, and desgined nature of AIF Services, these best serve the one-off, transactional calls. Meaning, if the nature of your integration is calling to create a Sales Order, or lookup a customer, then AIF Services are best suited for this type of interaction. Notice the key on "a" meaning singular interactions, with distinct returned result sets.

Moving on to the .Net BC, it offers a different type of access than the AIF Services. With the .Net BC, you get direct access to AOT objects. So you could in theory, access the Query object that a given AIF Service is created from, directly. Not sure why though, other than to look up information. :-)

With this direct access, that means you have direct access to X++ classes, tables, and business logic directly.

So the nature of the .Net BC, is meant to expose to .Net based code / assemblies, the AOT, for working with the AX AOT objects and business logic, directly from .Net.

AIF Services, there is a layer of Abstraction, and therefore a layer of possible extra validation, and context control over data, that would not actually exists through the .Net BC.

Looking at these two options for working with Dynamics AX, still we have the question of Where and when? Since we have a base understanding of the nature of these two choices, lets move forward in answering this question.

Since AIF Services are meant to act in the "a", singluar transactional nature, consuming a AIF Service is best for when you have calls in the nature and context of creating, reading, updating or deleting (CRUD) data, in the form of "Document" based information. This could include creating a sales order, a purhcase req, looking up information on a item, or a customer.

Comparing AIF Services, to the .Net BC for achieving this same need, I have seen the AIF performs better, and is best suited for this. Also using the AIF for these needs, you end up having that layer of abstraction that enables control of the how data is accessed, and the shaping possibly of that data in a uniformed control fashion.

The other benefit for using AIF Services, is was generated, enables the creation of composite applications, that include AX with an SOA type of architecture in mind.

Moving to the where and when for the .Net BC, lets say you have a need for pushing in a massive amount of data? Or you want direct access to maybe having a complex LOB application workflow, that is deeply tied to the business logic in Dynamics AX, that might actually live in X++, and want to expose and reuse that.

Then .Net BC is best suited for this type of integration, and performs better. It performs best with larger amounts of bulk data, or the need for exposing possibly complex workflows, or deep X++ business logic, or custom X++ business logic, and having that tie in with other LOB applications or Enterprise needs.

I hope the above helps answer some of this, and I welcome any comments from anyone on their own thoughts for this topic.

If we look forward with Dynamics AX, take a look at some of my past post. AX internally even will be making use of AIF Services for "document" level integration and data flow needs. Also AX moving forward is turning into a true Managed Code, at the kernel ERP package. This means tighter integration for the AOT into .Net, in a more native fashion will exists.

That's all for now, but check back soon, and again feel free to leave comments on this topic!

"Visit the Dynamics AX Community Page today!"