Freaky Tech Friday - It came from another Platform

With it being October, one of my favorite times of the year, I thought it would be nice to have a fun, but informative series of post title: Freaky Tech Friday. This series of post, will be about Microsoft Dynamics AX 2012, and how other technologies, from other platforms, other planets, and other dimensions can be used. Maybe not so much other planets or dimensions, but you get the idea.

With that, lets start this creepy stroll down the dark alley of interopability that exists with AX 2012. The once scary path, that was filled with gotcha gremlins, and barrier trolls, now has become not such a scray place. What I'm talking about here, is not the net.tcp consumption of Services hosted within the AOS itself, but extending this, so that other platforms can consume these services through hosting end points through IIS.



From the above system architecture we would be focusing our efforts on the hosted WCF services within IIS. These services are really pointers, to the same X++ based artifacts that live within an instance of AX. This is how advanced end points can be enabled, that, say would allow Java based software, python, Objective-C, and other possible technologies that come from other platforms could consume directly these services, or at least be enabled to do so.

To help us getting started down this dark path, of creating a solution-stien architecture, we need our first lesson to be focused on how to enable the hosting of Services within IIS for AX 2012. To start, we need to read and understand the following.: Install web services on IIS [AX 2012]

"Web services on IIS is an optional component. The Application Object Server (AOS) is the Windows Communication Foundation (WCF) service host for Microsoft Dynamics AX services. The AOS-hosted services are available to users and applications across the Intranet. To consume services over the Internet, you must host services on Internet Information Services (IIS). Skip this procedure if you do not need to expose the Microsoft Dynamics AX services over the Internet."

Now I want to be clear, that for non-Microsoft platform technologies, even within the intranet, consumption of the WCF services will need to most likely take place via hosting the services on IIS. This is related to the use of AOS hosted services being offered up via net.tcp bindings. Understanding this fact, will help you in enabling this other worldy technologies from another platform, communicate and work with AX 2012 services.

Following the above referenced TechNet article through, we can see how to setup our services, so they can be consumed by internet external consumers, as well as other technologies that need more enhanced integration port bindings.

Well I think thats enough to scare almost anyone, on this Freaky Tech Friday post. Tune in next week ghosts and ghouls, as we take this further, and go past the point of no return, into the abyss of integration! Scare you then!

"Visit the Dynamics AX Community Page today!"

Dynamics AX and WCF Service - Part II

Ok, so recently I wrote the following blog entry.: Dynamics AX 2009 - Service Reference to Custom WCF Service

In that post, I showed a custom Foo WCF Service, some ServiceContracts, OperationContracts and DataContracts. I also talked about how to reference this in Dynamics AX, make use of the objects, including how to make use of .Net List.

Now if we look at the Xpp Code, that I took a screen shot of, we can start our next post.:


So if you took exactly what I did and tried to implement it, you would get an error message inside Dynamics AX. A ClrError, stating the ClrObject could not be created.

The reason why is that the above screen shot, the code is executed where ran, which is typically the client.

Any Service Reference Xpp code, that calls a service reference at all, must be done at the Server Tier. This is actually well covered in a lot of different blog post, and something that most anyone that has done this kind of integration has ran into.

So this actually starts us into the next real section that I wanted to cover when working with WCF Services that one might create and want to work with from within a Dynamics AX implementation.

There are actually several different gotchas and points of interest someone would want to look for. So the following is an attempt to list those, and try to help out anyone going this route.

So one thing to note, is during the development of your custom WCF service or services, you will most likely be changing that code a good bit. It's always a good thing to create a console or windows form test project to make sure what your sending into the WCF is working and that the WCF code you wrote is working as expected.

The wonderful thing about such an approach you can catch unhandled exceptions during debug mode, where in Xpp this is not possible. You get a general message about the ExeceptionDetails is not serializable.

Now moving forward another note on developing WCF Services. Let say you have a good start, you make your reference in Dynamics AX, and start coding Xpp code. Then you realize another WCF OperationContract would be great. Go ahead and add that WCF OperationContract and make sure the Interface the Service makes use of, is updated correctly.

Then Go to the Service refernec in AX, right click, select regenerate, get the error messages, close the client, restart the AOS, and then restart the client. The new method should show up.

Only during this process, with the regenerate and restart of the AOS, does your WCF service change reflect in Dynamcis AX for use.

I will leave you here. There is actually some more points in this area. Also keep in mind with all these little gotchas, the flexbility offered with WCF Services is well worth the effort.

I plan on moving forward with more things to watch out for, and also why choose WCF Services over standard Web Services.

Thanks for reading, and 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!"

Microsoft Dynamics AX - Application integration, BizTalk Adapter install possible error

Had this one come up lately, and thought it would be nice to post about, seeing as how this is not really been addressed and has actually been asked a few times on the web.

When you are trying to install the Microsoft Dynamics AX BizTalk Adapter, and you get the following error:

"Microsoft Dynamics AX Setup
---------------------------
Setup detected that you are installing Application integration - BizTalk adapter, but BizTalk 3.5 is not installed on this computer. You must install BizTalk before installing Application integration - BizTalk adapter."

This can be confusing. This "BizTalk 3.5" reference is actually, technically correct in that is it referencing the build of BizTalk that should be installed on the same box that you are trying to install the Adapter on, which happens to be BizTalk 2006.

Now granted, you would think this should state: BizTalk 2006 (Build 3.5.xxx) which would make more sense to everyone, but that's a matter for Microsoft to handle. :-)

What I hope is that someone will find this, that runs into that same issue, and will see that the solution is this: You must have BizTalk 2006 installed on the box you want the adapter installed on, first.

Well good luck and check back soon!

Update: If you happen to install BizTalk 2006 R2, it's build is 3.6.xxxx. Just a little bit more information on this topic.



"Visit the Dynamics AX Community Page today!"