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 http://sdata.sage.com. 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
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