This is the second article in the a new series of articles which aims to explain the architecture of the Sage CRM Connector for Sage 200.

As part of this article I want to consider the different ways in which the connector can be set up.

There is a slightly different install procedure if you are installing the connector in an environment where Sage CRM and Sage 200 are both installed on the same server.

The loosely coupled architecture allows split server deployment. This is where Sage CRM and Sage 200 are not installed on the same server.

Let’s get into more detail. This diagram provides an overview of the architecture of the Sage CRM Connector for Sage 200.

You can see that the Connector utilises a Gateway that interacts with a set of Sage 200 proxy objects via .NET. These proxy objects expose the core Sage 200 API objects which in turn provide the interface with the Sage 200 database tables.

The use of the Sage 200 proxies allows full data manipulation and the Gateway can call and carry out any query, insert, update or delete tasks that the underlying Sage 200 API objects allow.

The Gateway interacts with Sage CRM differently. Instead of using .NET it interacts with a broker using a mix of XML and ADO. This broker then interacts with the Sage CRM database via ADO.

The Sage 200 proxy layer will have exposed data structures and data type. Part of the interaction with Sage CRM is to transform and model those Sage 200 data structures within the metadata of Sage CRM. Sage CRM uses its metadata to know how to draw screens and manipulate data.

The other role of the broker is to allow user actions within the Sage CRM to drive real-time interaction with the Sage 200 database.

Let’s drill down a little further into each of the different parts.

The Proxy Objects provide a set of methods to create, modify or delete a Sage 200 object record with certain conditions. They can interact with Sales Orders, Customers and Quotes

The internal Sage 200 objects provide the logical connection to the underlying database tables. It is the objects that can contain the business rules to ensure integrity within the Business Management Solution system when data manipulation is carried out.

We’ve looked at how Sage 200 has its data exposed via its proxy objects. The Gateway needs to be able to exchange data with Sage CRM. Because the Sage 200 server and the Sage CRM server may be split on different servers the internal communication within the Gateway and Connector uses XML.

The Connector must then take the XML, process it and transform this so that it can then be handled by Sage CRM.

The image above is of the definition screens in Sage CRM that show that the connections to the Sage 200 objects have defined.

The information is passed to a set of libraries and functions run within the Sage CRM server via ADO XML. The purpose is to process the data so that is recognisable to Sage CRM as a record object.

Once the data is defined as a record object then Sage CRM can then treat the data from Sage 200 is the same way as data within its own database.