It is June 2018. I have been tasked with architecting a solution to integrate data from SAGE 50 into a web application. The specific task is to pull account credit position data from Sage into the web app so that users of the latter can appreciate the exposure for each client before processing new orders.
The scope says that we should avoid installing any solution-specific code on the on-premise Sage installation, or do anything to limit the potential for the customer to have Sage updated.
The stack on the web-app side is all MS, so SQL Server + C#, etc. The Sage installation is on-premise.
In practical terms I have two options:
Use some kind of standards-based gateway or interface layer that we can talk through to get data Sage DB. This would insulate us from needing to make any low-level changes to the Sage installation. Using this option we would query the credit position data as needed.
Have some scheduled job on the Sage box post out the credit data periodically, either to a middle file store, or directly into the web app. This option obviously has a data latency problem.
Sage hides its SDK information inside a developers program that has a yearly price tag of £1500. Before I commit I would like to confirm that there is a solution waiting there.
Some of my research to date:
SO question about using ODBC from 2009
SO question about generic integration from 2009
Sage has changed its product line since 2009, at least in marketing terms, since then.
I realise that this is a broad and imprecise question, but my research so far leads me to no clear conclusion. Sage has many millions of customers so if I can beg your indulgence in not tagging this as off-topic then I think this question could help many people in the future.