SData is the short form of 'Sage Data'. This is the HTTP-based communication protocol used by many Sage product APIs and integrations.

SData is used as the basis of the integration between Sage ERP 1000 (developed in the UK) and Sage Murano ERP (developed in Spain).

You can read more about the Standard at http://sdata.sage.com

The standard enables all type of Sage applications, whether they are desktop, server, or web-based systems to communicate with each other easily. The standard is usable by third-party applications and web sites so it is easy to publish and share information with any applications capable of executing a web request such as Microsoft Excel. Have a look at the article "Using SData to Extract Data into Excel" to see how that can be done.

The SData standard is built on top of leading industry standards including HTTP, XML, REST, and Atom/RSS. The full standard covers basic reading, writing, updating and deleting of data between and across products as well as more complex functions such as the synchronization of data, control of security and access, the discovery of services, and single sign-on, error handling, and data paging and batching of information for increased performance.

SData is an HTTP-based protocol and is an example of a RESTful web service as opposed to a SOAP web service. REST stands for Representational state transfer and the idea is the the HTTP verbs are used to imply the type of action that will be take in the system.

The different HTTP verbs of GET, POST, PUT & DELETE all have implicit meanings. Which can then be converted into SQL statements.

Part of the SData standard includes the ability to publish entities and views in a discoverable XSD Schema.

The exact URI for the schema will differ slightly between different applications. In the case of Sage CRM this publicly exposed schema will have a path something like

• http://[servername]/sdata/[installname]j/sagecrm/-/$schema

This schema is Read-only and will get updated or refreshed only if custom entities are added or deleted or if other changes are made to exposed entities

Note: In Sage CRM only GET is available for 3rd Party Developers, so it can only be used for ReadOnly purposes.

A request for data using the Sage CRM SData API would look like

• http://[servername]/sdata/[installname]j/sagecrm/-/person?where=lower(pers_firstname) like 'william%'

Sage SData URIs that fetch data conform to the ideal of a "Nice" URI. The URIs for SData requests are short and use nouns rather than verbs. So what we are retrieving (a person) is included in the URI.

A RESTful URI can be broken into a number of sections

When working with SData it is the 'Query' part of the URI that will chiefly change to determine the data returned.

Again using examples from Sage CRM

Pattern

• http://myserver/sdata/installnamej/sagecrm/-/entity

Examples

• http://myserver/sdata/crmj/sagecrm/-/company/$schema
• http://myserver/sdata/crmj/sagecrm/-/company('43')
• http://myserver/sdata/crmj/sagecrm/-/company?where=comp_companyid in ('43', '45')
• http://myserver/sdata/crmj/sagecrm/-/company('43')?include=person
• http://myserver/sdata/crmj/sagecrm/-/company(comp_companyid eq '962')
• http://myserver/sdata/crmj/sagecrm/-/person?where=lower(pers_firstname) like 'william%'

This is the type of URI that is utilised by the integration to query both Sage ERP systems and Sage CRM.

The GCRM Contract

But beyond the SData standard there is the further specific standard called the GCRM contract.

The purpose of the GCRM Contract is to provide a standardized interface between Sage CRM and the different ERP products in Sage. Differing ERP systems use different terminology to describe contacts, companies and product and pricing information. The GCRM contract allows a common denominator to be defined that allows very quick creation of the interfaces into Sage CRM. Sage CRM also uses the same technology in its integrations with other services such as Sage E-marketing and Microsoft Exchange.

The full GCRM Contract consists of three parts:

1. The base customer/account tables that need to be synchronized and the protocol to handle that.
2. Real time data SData feeds in a standard format to access data.
3. SData feed definitions that allow CRM to provide a basic Order Entry screen, to query pricing information from the accounting system and feed orders into the accounts package.

It maybe that in the accounting Integration that you use that only the first 2 parts are implemented within the integration. The diagram above shows that SData and GCRM contract are used by the sync engine to synchronize the core trading account information and that SData is used to fetch the accounts data in the Real Time Data Views. In the some integrations with accounts system the Order and Quote entry is handled by popping open either the accounting system's web interface or special screens so that best use can be made of the business rules within the system.