Integrating with Ax 3.0

Pre-Post:
I wanted to address with this post, my lack of ability to post new items for the past month. I have been swamped doing work, and admit have not had much time to post. I do however plan to get back on a twice a week schedule, hopefully within the next two weeks.

Integrating with Ax 3.0

Recently I have been doing a lot of work, taking 3.0 instances and integrating them with .Net applications, and EDI / EAI with BizTalk. This are seems to be one that does not have a lot puhlished on the net, so I thought it would be nice to have a nice post that talks about the different ways to achieve two-way integration with a Ax 3.0 instance.

The obvious is using the Business Connector (COM+) object. The business connector is a COM / COM+ object that is installed on a given box, that gives outside applications an interface into calling Ax code, and preforming Ax logic without having to be logged into an Ax Client Session.
My work with the Business Connector has mostly been with .Net / C#. Basically you register the Business Connector on a given AOS, etc. and then you can reference the AxaptaCOMConnector Object from within a given langauge. You can then create a Connector object, and create instances of object from within Ax that are used to preform logic, just as if you where in Ax.

With that said, there are some things to keep in mind about the Business Connector. For instance it's a COM / COM+ registered object, that come become unstable if not maintained correctly. Basically what I mean by that is if you are connecting and dropping the connection over and over, the over head generated from such transactions can become an issue, and I have noticed the COM connector becomes unstable or 'flaky'. The best way to manage such a thing that I have found is create a web service that wraps the objects you need or want access to, and only open the connection on the first time the Web Service is called. Then store the object in memory (cache) and use the open connection throughout all of the rest of the calls. You still have to handle the proper closing of the object, that's why you only close it when the web serivce or App is truly shuting down, and unloading from memmory.

For me, using web services as a messaging layer has been very successful. The next are to talk about inegrating with Ax is through making COM calls from within Ax itself. To give an example, so you had a custom end point in BizTalk that you wanted to interact with. How would you do it in Ax 3.0? Will the end point would be exposed as a web service, so for that matter how would you interact with Any web service from within Ax 3.0. Simple!

You create a C#.Net class that is a wrapper for the Web service that is then registered as a COM componet on the given machine. Then you can use the COM Wizard form with Ax 3.0 to create a wrapper class to call the COM object which, can in turn be used to interact with said web service. This approach can get tricky too, with say having multiple AOS(es). Basically though you just make sure the correct version of the object is registered on every AOS, and that's pretty much it for the trickiness.

That's all I have time for now on this subject, which can get really deep. For our forseen future that use of COM is going out the window which I believe is the right move. In 4.0 the Business Connector is native .Net, and calls can be made to .Net assembly in the GAC from DAX 4.0... so more stability and flexible is there for us in 4.0.

Check back soon for the next peice on this subject related to 4.0 integration!

Find a job at: www.DynamicsAXJobs.com