Continued talks of Integrating Dynamics AX to the outside world

Recently I posted the following blog entry.:
Integrating Dynamics AX 2009 with the outside world

This was the start of looking at all the different ways you can integrate the current version of Dynamics AX to the outside world.

As I said in that post, I wanted to move forward which each different type, talk about real world examples, and what I have seen fail and work.

A reader posted a comment on that blog entry, asking.:
"... more and more data needs to be shipped to and from Dynamics AX. What options have been more successful for you when implementing ..."
- Nathan

Nathan, you have great point there, and that is why I wanted to start talking more in depth about this topic. You see, like all things there is a lot of different ways to achieve something. The best answer, or correct answer, has a lot of inputs to reach that.

Same as the cloud conversation, common sense and functional ends should drive the means. This is true also for integration, though integration, it terms of pure integration is mostly technical.

Still the functional ends, should be the driving factor. And what do I mean by that, in this case?

Lets look at some examples. If for example, you have desperate, decoupled older systems that need to talk with Dynamics AX. And this 'conversation' or integration needs to happen in an asynchronous manor, with sometimes queue delivery of data and information. Then looking to middleware, like MSMQ might be something that is considered.

Taking the route of MSMQ, though, brings is on set of enabling functions, and limits with size, performance, and timing.

I have seen a good MSMQ integration work before, but I have seen more bad MSMQ integrations developed for integration into Dynamics AX than good actually. And maybe bad and good are wrong terms. Instead of bad, because MSMQ did what it was told to do, it's more the implemnetations driving functional ends did not really call or have to have an asynchronous integration to reach those ends. Only a part of it did, and since a part of it did, the entire thing was feed through that same channel.

That brings me to another point, a lot of the times a single channel for intergation is not always the best option. Sometimes, depedning on the functional ends or nature of a given process, it could be that a system to system intergation needs more than one channel for communication.

So for the truly needed asynchronous integration point, of queue data, MSMQ be used. But for the other integration path that can handle synchronous, event based integration points, .Net Services / Web Services would be the best approach.

Sometimes technology is the limiting factor, and when that is the case, you have to take the best route for the given limit. For example, it could be the only way to integrate with a given older system is through COM objects.

If this is the case, and you wanted to design some kind of workflow driven, 'smart' integration that could handle errors, routing, and failures. Things that come with newer technologies. Then it might make sense to wrap those given COM objects in .Net Workflow based Service. Where the .Net Service is the exposed integration to Dynamics AX, and it wraps the needed COM objects.

To wrap this conversation up, for now, and get directly to Nathan's question. 'What options have been more successful', I personally have seen many of the mentioned options both suceed with high and low degrees of sucess, and fail as well. It all goes back to the functional ends.

I guess it would be better to change the question, just a little bit, to say which one's have I seen fail the least. That, because of the nature of the integration, would be synchronous integration points. Be that Flat file, .Net Services / Web Services, direct calls to COM or .Net assemblies, etc. These are usually very event driven, easier to debug, understand, and don't usually have as many layers of abstraction.

That's also not to say that layers of abstartction are bad. In designs, if done correctly, the right amount of abstraction is a good thing. This is also not to say that asynchronous should not be used. I am not saying that at all. I am just trying to get across that what should be used, should only be used, based on the functional ends. If a functional ends, or technology limiting means extist and drives to an asyncrhonous type of intergation, where MSMQ or some other form of middleware, message delivery system is needed. Then a correct design and implementation of that, will help make that a success.

That's all for now, thanks for the question Nathan, and check back soon everyone. More great post are coming out.

See you then!




"Visit the Dynamics AX Community Page today!"