Preparing to move our products to CRM 2011 was a significant undertaking and was not done without a great deal of planning and forethought. The time and monetary commitment was significant and we wanted to take what we’d learned in the past into account when designing the new architecture which could have ultimately led to a ground up rebuild of the entire code base. Fortunately, help was on the way in the form of the Adapter.
The general concept illustrated below is a single point of integration between all of the platform independent integration points and the Cobalt business logic and presentation layer. The lessons we learned from previous upgrades from CRM 3 to CRM 4 formed the basis of the next step in Cobalt’s architecture, and ultimately, platform independence. The abstraction layers we’d created in the CRM client layer on CRM 3 led to the idea of a platform adapter that could sit between CRM and our product code to provide a single point of integration between the platform and product. The idea was simple though the implementation was still a mystery. If all of the CRM specific code lived in an assembly that was specified in the application settings then we could continue to do development as we had been in our product and not be subject to the ever changing platform integration points. This layer of Cobalt’s code became known as the adapter or more specifically the Platform Adapter.
An important part of the idea behind the adapter was that we should be striving not only to detach our products from any specific version of CRM but treat our product development as platform agnostic. In the end our products would be limited by what the adapter interface would allow us to do. Even though that sounds restrictive and could lead us to not being able to take advantage of new functionality and features of CRM it’s important to keep in mind that we control the adapter’s interface and if a decision is made by the architecture team at Cobalt that the adapter must adapt then it is within our power to do so. The upside is this adds to the rigidity of our programming methods and gives us the ability to maintain consistency across our products and implementations.
With platform independence in mind we began fleshing out the components of the new adapter architecture. What those discussions led to was the development of unified messaging model for handling events, through proxies, from the platform, as well as the introduction of specific interfaces for interacting with data and metadata. As a result it was left up to us to determine the structure of the code that handled the messages from the platform. This code ultimately resembled much of what had already been written for our products beginning in CRM 3 with the callout model. In fact Cobalt continues to write plugins that look more like the original callouts than the plugin code you’ll see in most CRM implementations. The new plugin code lives in the adapter layer and passes messages to configurable Event Dispatchers who in turn call the Listeners as necessary.