In this article I want to consider Sage CRM's Architecture, its development options and the importance that this places on the use of Web Services especially REST and SData for integration.

We need to consider what is available to use now and look and what has been publicised and documented. We also need to start to think about where the product is going.

First of all let's look at where the product is in terms of technology.

If your company is a member of the Sage CRM developer program then you have probably seen the diagram below on one of the online training courses. It is also used within some of the technical videos available for partners that you can find on the eLearning platform.

This diagram represents the Extensibility Architecture for Sage CRM

Anyone used to customizing Sage CRM knows that they have a very wide choice of APIs and the luxury of being able to directly interact with the database and any other databases that they can see within their network.

The Hints, Tips and Tricks blog is full of articles that describe exactly how to use these different development choices whether this is by using RunBlock, or classic ASP pages or the .NET interfaces. There is a very rich API that allows both server side and client side coding. You can add extensions to the product that execute on the server or you can create remote applications that interact with the Sage CRM system over HTTP through web service. And these web service interfaces are either SOAP or REST based.

The reality for administrators and developers working with an implementation is that a project places restrictions in what API choices are made. These restrictions are primarily to ensure that systems are secure, safe, stable, maintainable and can be easily upgraded. The emphasis should always be on code reduction and where possible elimination of script in the customization of Sage CRM.

The need to connect to other systems remains of critical importance.

Sage CRM exists in an ecosystem of different systems. From an integrator's point of view the very fact that Sage CRM has so many API choices can be a problem. What do you use? Classic ASP, .NET or web services? And within Sage CRM we support both a SOAP web service and a RESTful interface.

Across Sage the problem of having many APIs and SDKs has been magnified and to counteract that Sage has developed SData as a communication protocol. It is based on REST, HTTP, ATOM and JSON. The intention was that it should improve interoperability between Sage products and access to Sage data and business logic by third party developers.

It is used as the basis for many of the integrations between Sage CRM and the different Sage accounting systems. And SData enables communication between desktop and server and between systems running in the cloud.

SData is a form of web service based on RESTful principles (Representational state transfer). Although I will be explaining more about the concept of REST in a later article in this series the article "A round up of articles to help you use the SDATA Provider" provides a spring board to learn more about the interface within Sage CRM.

In addition to SData Sage CRM can use the SOAP Web Services. These are the classic interfaces that adhere to the SOAP protocol specification.

If you are interested in reading more about the SOAP web services then this is a good place to start: "A round up of articles about using SOAP Web Services."

But the point of this series is to look at the RESTful SData interface, at what it is and how it is changing.

It is REST and SData that will provide the capabilities for the management of data insert, update and delete.

And SData is used now today as the basis of the communication between different Sage products.

The original version of REST that was implemented within Sage CRM adhered to the SData 1.1 standard. SData as you might imagine has developed over the years as a communication protocol.

Although the Sage SData 1.1 standard does cover CRUD in Sage CRM this was only implemented as ReadOnly. So although data could be extracted from Sage CRM via SData it could not be updated or inserted. Those data base actions were done in another way. Until Sage CRM implemented SData 2.0 for some of its internal interactions it was not possible to use REST and SData to carry out Create, Read Update and Delete (CRUD) tasks. Only SOAP had been available as a data manipulation option.

In the next article I will start to develop the story until you can see how Sage CRM provides us with editing capabilities on entities.

The articles in the series are:

1. Sage CRM's RESTful API, An Introduction
2. Architecture and Web Services
3. Working with an instance of Sage CRM
4. Extending query access to custom entities and views in SData
5. Thinking about security
6. SOAP CRUD vs REST CRUD
7. Limitations of SData 1.1
8. Compatibility as a priority
9. What is JSON?
10. SData 2.0 CRUD