One downside of linking is you're using ADO. This can get resource intensive if you have large tables.

so to get more Accounts Receivable data than just Customer and Sales orders available with e-Business Web Services, it looks like I should use ODBC. could you point me to how it should be installed on client’s side and what does client should do for it? should the client open access to their DB? how is the 3rd party app is then interfaced? 

Perhaps the least complicated strategy to explain is set up MS SQL Server on the Sage server with a Linked Server to the each Sage company code you need to query.  (There are a few posts here on Sage City about how to set up a Linked Server).

When done, SQL queries work for Sage data, directly from MS SQL Server.  I'd create a database with SQL Views pointed at Sage data to make it easier to manage, but that is just a personal preference.

How to access and secure queries to SQL Server should be well documented elsewhere.

thanks again!
question on the performace if you will: we are planning to work with great volume of data, are there any recommendations how to avoid any issues with performance, maybe using filtering of queries etc?

If you have a large amount of data, stay away from anything using ADO. 

Deal with that as it comes up, table by table and query by query.  At it's worst, I've used SQL Merge statements to maintain mirror tables in SQL, and if you use SQL Views to start with, making that kind of change later would be be like a black-box change.

If Sage comes through with a SQL Standard edition, I hope the focus will be moving some the business logic to the SQL server as functions and views.

I know you mentioned already that SData's development is discontinued, but I also saw people saying it is pretty easy for reading from Sage. would Accounts Receivable data be available with its integration?

I wonder about the API alternatives, like the ones here, but for 100cloud nothing is available there yet.

I worked with SData on one project and it was a hassle getting things configure.  On top of the overhead to get it configured, the version Sage implemented at the time was SData 1.0 or something which is an older spec and can't filter on date fields.  As far as I know Sage never implemented the later versions of SData so if you search the web, you might find documentation on newer versions but and new implementations in the later versions likely won't work. 

In all honesty, if you have access to the server where Sage 100 is installed and you only need read only access, as others have said, ODBC is the easiest way to go.

If you need to write back and you have access to the server where Sage 100 is installed, then you could use the BOI.

If you need remote access like a true web API, then you are probably better off going with an existing solution, such as one that T-Man included in his post.

thanks, David. 

so the true web API method would be the 3rd party solutions then?

I'm checking the OData method as well: is it possible to read data from Sage100 through PowerApps (thus requiring Azure license) connection only or it would require to build own connector otherwise for such purposes?