The classic SOAP web services provide us with an existing set of abilities to create, read, update and delete data. In this article I want to examine those web services in order to explain some of the limitations of the interface and why we can instead expect enhancement of the SData based RESTful API to include full CRUD and more.

I want to start by reminding ourselves about the technology used by Sage CRM.

Here you can see that I have logged on to my instance of Sage CRM.

It is the the URL I wish to discuss.

http://localhost/crm/eware.dll/Do?SID=19423767845089 &ErgTheme=0 &Act=184 &Mode=1 &CLk=T &Key0=4 &Key4=12 &T=User &ErgTheme=0

Specifically I want to draw your attention to the eWare.dll and consider the architecture of Sage CRM. You may want watch the video below that explains the System Architecture of Sage CRM.

(Please visit the site to view this video)

The video explains that the eWare.dll is the key element for the classic SOAP Web Services.

We see this very clearly within the end point that produces the WSDL.

http://[servername]/[instancename]/eware.dll/webservices/webservice.wsdl

So although we can use .NET languages like C# and tools like Visual Studio to write sophisticated extensions to Sage CRM these are all ultimately tied back to the 32 bit eware.dll that was written in Delphi.

In addition the SOAP web services are 'stateful'. The SOAP web service requests to Sage CRM depend on the results of the first request. They depend on a session be opened and maintained on the server. This makes the web services more difficult to manage because a single action may involve more than one request.

The SData RESTful API is however based on the Java technology. This also includes the Ajax features of the Client Side API as this uses SData behind the scenes.

In the purely stateless environment of SData you don't need the session id. No session is maintained within the CRM server as each request contains all the information the server needs to process.

The SOAP WSDL is strongly typed with only limited schema discover ability and present challenges around exposing meta data and other services. The SOAP interface is also very peculiar to Sage CRM. Although SOAP may be a standard the objects and methods described within in it are unlike the way in which other Sage accounting products or 3rd party systems may describe their objects.

SData on the other hand provides a common way across Sage of describing new objects and discovering them. And we will see over the remaining articles that SData 2.0 provides a very flexible way of handling all sorts of data.

The developments in SData allow for not just data to be managed but services too.

The next article will look at the limitations of the current implementation of SData and how the RESTful API is changing.