Tips for Creating Services in Microsoft Dynamics AX 2009 - White Paper

While staying on the topic of integrations for Dynamics AX 2009, I wanted to give a link to a great resource that was first released in June of this year.

That is the Tips for Creating Services in Microsoft Dynamics AX 2009 - White Paper

The previous post, of consuming services inside Dynamics AX 2009 was taking and bring in data or working with serviecs from the point of Dynamics AX 2009 to the outside world.

This white paper goes into great details, helps, do's and dont's for creating Services that expose Dynamics AX 2009 to the outside world.

These services can then be consumed by the outside world for working with process, data, and business logic inside Dynamics AX.

Before this white paper came out, there was good help on the web with great blog entries, etc. However this white paper is recommended for anyone that is working with AIF, or will be working with AIF to expose Dynamics AX to the outside world.

From the white paper.:
"Microsoft Dynamics AX services are designed and implemented in the Application Object Tree (AOT) using X++. A service is defined once, but can be exposed via different transport protocols, such as a Web Service, an MSMQ adapter, a BizTalk adapter, or a file system adapter. Microsoft Dynamics AX tools and wizards are available to expose and deploy services to these different environments, leaving the application developer to focus on the service definition and implementation.

The application developer uses tools and wizards to generate and deploy the X++ service as a Windows Communication Foundation (WCF) service hosted in Internet Information Services (IIS). After a service has been implemented, any requests made to that service are forwarded from IIS and run on the Application Object Server (AOS). These generation tools create the service definition in the form of XML Schema Definitions (XSDs) and managed assemblies. From a high level, service requests are made to the managed assemblies that delegate them to the X++ service implementation using .NET Business Connector. The incoming message is not deserialized inside the managed assembly to increase performance."

AIF, in Dynamics AX 2009, comes as part of the base package and should be used for exposing business logic, data and processes to the outside world.

That's all for now, check back soon!




"Visit the Dynamics AX Community Page today!"

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!"

Integrating Dynamics AX 2009 with the outside world

One topic I wanted to start really spending some time on, in the next few months is Integration options for Dynamics AX 2009.

There are several ways for doing this, and what I want to take and look at each. Go over some pro's and con's, and when should the different approaches be used.

So the following is a list of ways you can integrate Dynamics AX 2009 with the rest of the world.:

Outbound Integration

• Calling a COM Object - Server and Client Context


• Calling a .Net Assembly - Server and Client Context


• Calling a Web Service through a .Net Wrapper


• Calling a Web Service or WCF Service through Service Reference in AOT


• Out of the Box AIF Outbound End Points


• Custom AIF End Points - (MSMQ, File Transfer, Web Service, FTP)


• AIF End Points for BizTalk - BizTalk then offers a wide range of options once inside it's scope


• Your own custom or Third party developed framework that lives inside Dynamics AX 2009

So the above list can be sliced upon into sections of itself. Like Server or Client context, AIF, Web Services, etc.

The approach I want to take is now take the above list, on my next post, and talk about the pro's and con's of each type. After that, take the same list, and talk about when each of the types would be used, and what would be driven factors to use those.

Hopefully by the time we cover these options a solid understanding of what all exist for integration Dynamics AX 2009 out to the rest of the Microsoft stack, and world can be understood and we can move forward with inbound integrations.

I also plan on giving examples of some of these. Like the Reporting Options in Dynamics AX 2009, the integration options are many. And there is specific factors that drive you to choose different paths.

That's all for now, check back as more to come. August is Lean month, so another post tomorrow on the LCE, and interviews are coming up. See you then!




"Visit the Dynamics AX Community Page today!"