Showing results for 
Search instead for 
Do you mean 

Consuming SData Web Services - Introduction

by ‎01-29-2010 12:17 PM - edited ‎01-29-2010 01:38 PM



We introduced Sage Data (SData) to the SalesLogix Business Partner community at Insights in May 2008. At the time, SalesLogix had already started using RESTful web services internally in the SalesLogix web client. There was also an SData Working Group in place within the Sage organization, working to solidify the SData protocol specification, which would standardize the way Sage products communicate with each other, and with third-party integrations, via web services. So, here we are a year and a half later, and much work has been done to bring the SData story to life. Let's take a look at what's been happening...


What we've been doing


Since that 2008 Insights conference, a v0.9 version of the SData specification was finalized, followed by a v1.0 core specification and a corresponding SData Sync specification. You can read the details of these specifications, along with overviews and examples, at In parallel with the specification effort, another cross-product team was working on an initial set of "contracts", defining the data and service operations for certain types of product integrations. Three integration contracts have been published on the SData web site: Global CRM, HR-Payroll, and Fixed Assets.

Finally, individual product teams have been working on SData web service providers. SalesLogix 7.5.2 shipped with a dynamic SData provider that exposes application entities according to the v0.9 SData protocol. Later this year, a fully SData v1.0 compliant update will be provided, including support for service operations (business rules). Additionally, multiple teams have been working on contract-specific SData providers.

My small "platform" team has been working hard on an SData Provider Toolkit that builds on top of the SalesLogix/Gobi NHibernate-based entity model and facilitates mapping application entities to SData contract resources. Teams using the toolkit can focus on transforming data between application and contract, not learning every last detail of the SData specification or parsing SData queries. This has been an important step in making sure we follow through on the SData promise to integrate products based on a standard, and allow third parties to work with Sage data via web services.


SData from a consumer perspective


So, now you have an idea of the kind of work we've been doing here at Sage to provide an open, standardized, reliable way of accessing application data. But what about the client side? All of the SData web host providers in the world won't do any good unless people are consuming them. As much as we believe in the RESTful web service story, especially in head-to-head comparisons with RPC-style web services (usually with the SOAP protocol), I don't think we can completely ignore the WSDL factor. This metadata-generated proxy makes consuming RPC/SOAP web services pretty straight-forward for developers. That's where the SData Client API and libraries come into play…

As a side-project while working on the SData Provider Toolkit, the GCRM platform team decided to come up with a client API similar to the one provided by Google for GData. They have a Core Client API, with additional domain-specific APIs built on top of it for strongly-typed access to things like Blogger, Google Analytics, Google Calendar, and many more services. They offer libraries that implement these APIs for multiple platforms. This seems like a great idea. We're not too proud to admit that, and we've decided to offer up sincere flattery to the Google team by taking a similar approach.


The SData Core Client API and .NET library


Rather than copy Googles actual Client API implementation, which seems rather heavy for what we're trying to do, we looked around and found the open source Argotic Syndication Framework, created by Microsoft. We started with that, and built an SData-specific client API. Our first library implementation of the API is for .NET. However, we hope to have additional libraries in the future for Java, JavaScript, Objective-C and possibly other languages/environments.


Our initial "Core" Client API allows you to work with SData web services much more easily than by using the native .NET APIs and learning all of the SData specification details (although, I still encourage you to read the specification and look at the examples). We've also eliminated the need to directly manipulate the XML that the web services return. The payload is accessible through an IDictionary interface, and there's type descriptors available to facilitate binding. Phase two, coming later this year, will involve generating domain-specific libraries on top of this Core API that give you strongly-typed access to application and contract data and functionality.

The .NET library, documentation and examples will be posted for the community shortly. Over the next few weeks, I'll post a series of blog entries that dig down into some of the details of the new SData Client API. I hope you find these posts interesting. For more complete information and instruction, please browse the official SData web site, and look into the excellent SData training courses being put on by the SalesLogix training department.


Message Edited by jhershauer on 01-29-2010 12:19 PM
Message Edited by jhershauer on 01-29-2010 12:20 PM
Message Edited by jhershauer on 01-29-2010 12:43 PM
Message Edited by jhershauer on 01-29-2010 01:36 PM
Message Edited by jhershauer on 01-29-2010 01:37 PM
Message Edited by jhershauer on 01-29-2010 01:38 PM

by Gold Super Contributor
on ‎01-29-2010 12:57 PM


   Any ideas when/if the other groups (ex MAS90/200) will be publishing a set of client libs? 

on ‎01-29-2010 01:06 PM

You mean publishing web services to be consumed by the client libs? :-)


Right now, I know that Line 50 in the UK has published a contract-specific web service. Also, Sage 1000 (UK) and Logic Class (Spain) are in the process of using our framework to publish against the GCRM contract. I'll see if I can find out anything in terms of timelines for other North American teams.



by Bronze Super Contributor
on ‎01-29-2010 01:25 PM

Jeff, will the .NET client API lirbary be open sourced? That's been discussed before, is that still the plan?


Also, BTW, the  link in the second paragraph is backwards, should be (instead of

on ‎01-29-2010 01:40 PM

I don't know what you're talking about, Ryan. The link works fine. ;-)


Yes, our plan is to open source it. There are still some things to work out in terms of license text and determining where to host it. To start with, we'll send out just the DLL, and the source will follow.




by Gold Super Contributor
on ‎01-29-2010 04:06 PM
I had heard rumors that the MAS90 group was "close" to a release that supports SData
Register Read Guidelines Request Partner or Employee Access

What's New in 8.1