RESTful Web Services Coming in SalesLogix 7.5

This week I’ve been in Washington DC attending the Sage Insights Business Partner conference. It’s been great meeting up with friends in the business partner community and the guys from Sage. There’s been a lot of discussion about things coming in the next release, version 7.5 (codenamed “Sahara”) and in the release beyond that (codenamed “Tanami”). The focus for SalesLogix is definitely shifting to web, not that the windows side is being neglected, but it reflects the shift in the industry to web-based applications, which I think is awesome. Of all the new details that have been shared about the Sahara release (See my previous post on new features coming in 7.5), by far, one of the more exciting is the introduction of the RESTful web services layer.

This is just huge and introduces a whole new level of capabilities for SalesLogix. For those who might not be familiar with REST (See Wikipedia), it basically comes down to URL addressable resources and simplifies the use of these resources while taking the programmable web to the level of functionality contained within the browsable web – in a way that is far superior (IMO) to SOAP.

OK. For SalesLogix, the REST services all use an SData protocol to define the structure of the URL for accessing resources. As an aside, the great thing is that this SData protocol is meant to eventually be common accross all Sage products, providing a unified way to integrate Sage applications. Maybe that’s a pipe dream, time will tell. I’m just thrilled to have it coming in SalesLogix. These services will be able to read data, such as groups, named NHibernate HQL queries, and even perform CRUD functions (CReate, Update, Delete)! Business rules won’t be accessible via the REST layer for the initial version, but the entity level eventing will. This is where the real power comes from. You’ll have a common place to implement business rules for entity events that is made available to any/all SalesLogix applications, addons, external applications, etc. BTW, these entity level events are available in this way due to a move to the provider level. The SalesLogix OLEDB Provider will raise entity level events, executing the code you’ve defined there – so these events will basically apply throughout SalesLogix. Woot!

For data returning RESTful GET calls, the data can be returned in one of three formats:

1. XML
2. JSON
3. ATOM (current default)

So what do these URL addressable resources look like? Well, for example, let’s say you want to return all accounts, your URL would look like the following:

http://<server:port>/sdata/slx/accounts

How about a specific account:

http://<server:port>/sdata/slx/accounts(AXXXX0000001)

List all contacts for a specific account:

http://<server:port>/sdata/slx/accounts(AXXXX0000001)/Contacts

You get the idea. The SData protocol/scheme is very well thought out and I could not be more pleased with how this has been implemented. It goes much deeper than what I’ve covered here, the ability to perform HQL queries via REST is so completely powerful. The fact that we’ll be able to perform basic CRUD operations as well was a VERY welcome surprise. For sure, there will be much more to come from me on this subject in the future.