Stephen Smith's Blog

Musings on Machine Learning…

A Roadmap for SData Integration to Sage Products

with 4 comments


I’ve blogged a few times about using SData to feed data into Sage products and about the general ideas behind SData. In this blog posting I want to look at some benefits to integrating into Sage products using SData and the general reasons behind doing so. A lot of this article is forward looking and so each Sage product is somewhere along this journey and no product has reached the end yet.

Imagine that you are an Independent Software Vendor (ISV) and that you have a great product that satisfies a useful specialized business need for many customers. However it requires some data that is typically stored in an ERP system and generates some financial results that need to be entered into this ERP. Say you need to read all the Orders from the system and then you produce a number of G/L entries that need to be imported. Wouldn’t it be great if you could automate this process by being notified automatically whenever an Order is entered and being able to write the G/L entries directly into the ERP? However, you find that your customers are running all sorts of different ERP systems. As you look into doing these integrations you find that you need to join an SDK program for each ERP and have someone learn and program in all these different ERP’s SDKs and program you integration in all sorts of strange languages from VB to C# to JavaScript to FoxPro. Then you have to maintain all these integrations from version to version as your product progresses and all these ERPs evolve. This is a lot of work. There must be an easier way.

You could take the attitude that you will provide an API and SDK for your product and then, since your product is so wonderful, that all the ERP vendors will write an integration to your product using your SDK. After a few years of waiting for this to happen, you’ll probably give up on this.

Sage has many ERP systems and combined has a very large market share. However all these ERPs have their own heritage and their own SDK. How can Sage make it so this ISV can create their integration easily to a large set of Sage products using their own development tools and programming knowledge?

This is where SData comes in. SData is a REST based Web Service interface. SData is based on internet standards and easy to call from any programming system that supports Web Service calls. SData is a standard being implemented in all Sage Business Solutions. So how will this work in the scenario above?

Method One – Poll for Orders

In this case the ISV application will periodically poll for new Orders on the Orders SData feed, process them and then write any G/L entries to the G/L SData feed.

This method isn’t that different than using the ERP’s built in API in whatever technology that is implemented, perhaps COM, .Net or Java. So at least now for the various ERPs we are using only one API technology to access several ERPs.

Standard Contracts

Generally each ERP has its own heritage and hence its own database schema. Most Sage ERP’s will expose their built in native schema as their native SData schema. So although you can use SData to access a range of different ERPs, you still need to handle multiple schemas to set and return in the XML payloads associated with the calls.

The solution for this is standard contracts. These are specifications for standard SData calls that define a common schema. It is then the job of each Sage ERP to transform their native schema into the schema of the standard contract as part of their job of offering standard contract feeds.

With standard contracts implemented the ISV can then access multiple Sage ERP’s using the same API technology, namely SData, and using the same payload schemas, essentially making the integrations the same.

Method Two – Connected Services

Connected services refer to integrating products whether from Sage or an ISV being located in the cloud and then integrated to an on-premise installed ERP.

Currently there is a concern that on-premise customers don’t want to expose their ERP system to the Internet, meaning they don’t want to manage a firewall and worry about the security concerns associated with an Internet facing web server. This means they do not want to expose their ERP’s SData feeds to the Internet at large. So how does the ISV integrate if they can’t call the ERP’s SData feeds?

Although the cloud application can’t call the on-premise application, the on-premise application has no problem calling the cloud application. This means it’s up to the on-premise application to push all necessary data to the cloud application. Generally this is handled by a synchronization engine that synchronizes some ERP data up to the cloud. The SData specification contains a data synchronization specification for this purpose. The synchronization algorithm is very robust and will catch up if the Internet is down, or the cloud service is unavailable.

We could also provide notifications when things happen, but this is less robust, since what happens when the Internet is down or the other application is unavailable (perhaps offline for maintenance).

Notification Configuration

The above method for connected services assumes that SData synchronization will need to be configured. The core ERP will need to configure a list of SData services to synchronize with (hopefully down the road there will be many), then the ERP will need to ask the service which feeds it wants to synchronize.

Initially this configuration will probably be done by configuration screens in the ERP. However over time it will be nice to move this all to dynamic discovery type services. This will reduce error in setup and allow connected services to evolve without requiring setup changes in all their integrated ERP systems each time something new is added.

If the ERP and ISV solution are both installed together (either on-premise or in the cloud), then it would be nice to configure some direct notifications, basically call-outs from the application when various important things need to be done. This might be for things like requiring a calculation be performed or to notify that an order’s status has changed. These sorts of things will only work when both applications are live and connected, but there are many useful scenarios for this.


Initial SData implementations are either shipping or forthcoming across all the main Sage business products. We are starting to see integrations of the method one type emerging. We are actively developing connected services using the SData synchronization mechanisms. Then as we continue to roll out SData technology you should see any missing pieces start to fill in and greater uniformity emerge on how you integrate with all Sage products.

As Sage studies the market and determines useful profitable connected services, Sage can publish an SData contract that all our ERP systems will support. Then the chosen ISV can provide this service for all Sage products by supporting this SData contract. Often for connected services we need different providers in different parts of the world, and again it’s easy for Sage since for this one contract perhaps we have one provider for North America, another for Africa, another for Asia and another for Australia.

Written by smist08

February 25, 2012 at 4:04 pm

4 Responses

Subscribe to comments with RSS.

  1. Great blog stephen. Thanks for the same.

    Sundaresan Ramanathan

    February 26, 2012 at 3:11 am

  2. Great write up Steven – thanks for putting this out there!

    Peter Wolf

    February 27, 2012 at 4:12 pm

  3. Can’t SData notification messages be made more reliable..?

    ‘SData syncing in one direction, the on-premise application has no problem calling the cloud application, the “vector clock” algorithm doesn’t get caught in galloping bi-directional sync issues.’

    Continuing on of reliable messaging, even when on-premise applications are live but somehow not connected to the cloud, can’t notification messages exhibit eventual consistency like across distributed SQL/ NoSQL databases or use pub/sub messaging…

    Where I’m musing over is building an asynchronous planning visualization board in the cloud, synching up many Sage systems, but I need so without complexity.


    March 4, 2012 at 11:31 am

  4. […] 6, More on SData and Sage ERP Accpac 6, Stateful SData, On the Sage GCRM Contract, Fun with SData, A Roadmap for SData Integration to Sage Products or Defining SData Feeds for Sage 300 ERP. Jarett Smith has also started a blog on SData which is […]

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

This site uses Akismet to reduce spam. Learn how your comment data is processed.

%d bloggers like this: