Integrating Third party VCS with Dynamics AX 2009

Just over a month ago, Microsoft released a new white paper which talks you through how they integrated Team Foundation Server, TFS, into Dynamics AX.

That white paper can be found here.:
Microsoft Dynamics AX 2009 White Paper: Integrating a Third Party Version Control System into Microsoft Dynamics AX 2009

"The MorphX Integrated Development Environment (IDE) can integrate various Version Control Systems (VCS). Team Foundation Server (TFS) is a newly integrated VCS with the MorphX IDE in Microsoft Dynamics AX 2009. This document provides detailed step-by-step instructions to integrate a VCS with the MorphX IDE, by using how TFS was included in Microsoft Dynamics AX 2009 as an example.

The Version Control Extensibility Framework was refactored in Microsoft Dynamics AX 2009, which is now used by the integration with TFS."



In looking at this I started looking around for cloud based VCS software, that was similar to Visual SourceSafe, and already integrated to work with Visual Studio. I came across the following.: www.DynmaSoft.com The product they have can be hosted in the cloud, on-premise, and has a published COM based SDK.

It already integrates with Visual Studio, and that was key for this, because in most Dynamics AX solutions, with 2009 and beyond, Visual Studio solutions and projects are very much a part of the Source Code that make up a given AX implementation.

So with this in mind, I started to dig a little deeper in what would it take to integrate this DynamSoft product into Dynamics AX.

After looking into this, I found of course you will need to sign up for at least a free account. Next you will need to download the following two items.:

• SourceAnywhere Hosted Server Manager - To remotely manage the users, groups, access rights and other configurations of the hosted server.


• SourceAnywhere Hosted COM SDK

After getting these two, of course make yourself familiar with the COM SDK, and then go through the steps listed in the Microsoft Whitepaper for enabling DynamSoft cloud based VCS with your given Dynamics AX instance.:

• 1. Add a new class that represents the VCS and implements the sysVersionControlFilebasedBackEnd interface.


• 2. Add a new base enumeration value to the SysVersionControlControlType base enumeration type. For TFS, the SysVersionControlTfs base enumeration value was added.


• 3. Add new class construction logic to the newType method of the SysVersionControlSystem class.


• 4. Implement the VCS setup methods. These methods are the bootstrap methods that are responsible for initializing the backend instance. Therefore, they must be implemented for each VCS.


• 5. Implement the basic VCS operation methods in the new class such as the fileGetVersion, fileSetCheckIn, fileCheckout, fileAddToVersionControl, and fileDelete methods.


• 6. Use the advanced VCS methods to implement additional VCS features. The framework also defines a list of runtime surrogate methods to let the VCS notify the framework whether these features are supported by the VCS. These features are optional.


• 7. Implement the plumbing methods that are required by the framework.

I have plans to now take the above information, a free account and actually develop this and place in an XPO project for sharing. I wanted to get this out here though, making this a part 1 in this series, to help bring into focus Change Management possibilities that exists with Dynamics AX, specifically related to VCS options.

With what Microsoft has given us here, we now have the ability to really integrate Dynamics AX 2009, with near any VCS solution we desire. Be that Cloud based, on-premise, Custom, Open Source, or purchased.

I think this shows the flexibility of Dynamics AX, and also gives customers choices in their VCS options.

There is something technical you need to keep in mind, in regards to VCS solutions with Dynamics AX. This is designed so each developer has their own AOS installed on their developer workstation.

With what we have in this white paper, however, we have the ability to create a server side integration into a VCS that will work, with having a single AOS and 1 to 1,000+ developers! I will save that for a later post on this subject.

Hopefully this post has you thinking, and hopefully you have plans or already have in place change management policies, that include management of code.

That's all for now, but check back soon as more to come!




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