Hello Team,
Could you please help me with the following questions?
1) Is it possible to integrate data from Sage 100 via web API?
2) Does Sage 100 have a cloud version? or it is just an On-Premise version?
Hello Team,
Could you please help me with the following questions?
1) Is it possible to integrate data from Sage 100 via web API?
2) Does Sage 100 have a cloud version? or it is just an On-Premise version?
There are a few options that you have with the first question you have. Most are not a true API but ways that you can get and write data to Sage 100 from other sources.
Kevin is right on. If you only need to read data, ODBC is the way to go. BOI requires a lot of work and understanding of the system to read through a table and deal with the business classes. Security…
If all you want to do is read data (not write anything back into Sage 100), use ODBC. BOI has a high learning curve, but ODBC queries are pretty standard (as long as you know where the data lives).
1. Yes, but not without additional (usually 3rd party) software. There are options (which have been explained in many Sage City threads answering this exact question), but it really depends on budget / functionality required / how much customization is required.
2. On-Premise. The word "Cloud" in the branding is not representative of the systems architecture... it's just what Sage used to call their subscription license (which I believe has been rebranded recently to remove that word).
The new "Sage Partner Cloud" product is just the On-Premise software running on a secure Azure server. (Ironically it offers less potential for web interface, since you can't have a static IP / DNS address for external connections... but of course, that gives you the peace of mind that the SPC server is not exposed to random web based attacks).
That sounds similar to what InSynch and WebSitePipeline do (although I have no idea what platform they use for their cloud connectors). I believe each of those work by installing software on the Sage server so it's an outgoing connection (instead of an open port).
(There are other options too... I just know about these two options because we've worked with them both before).
There are a few options that you have with the first question you have. Most are not a true API but ways that you can get and write data to Sage 100 from other sources.
For your second question, Sage 100 can be hosted in the cloud but it is not a cloud based solution.
Hey T-Man, thanks for such an extensive description!
I am looking for ways to integrate our application with Sage100 cloud and it looks like the BOI approach might be useful.
We want to read clients' Account Receivable data, and they won't be paying for any licenses, and any 3rd party clients are also not an option. Would you agree that it might suit better for such a purpose?
I'd appreciate if you could point me to the reference materials you mention.
Cheers
You handle all that yourself. If you set up a SQL environment with linked server (using ODBC) to Sage data, that should work as a bridge... then you set up secure access to SQL (which should be well documented elsewhere).
I'm sure there are other methods but this is what comes to mind as a potential approach.
ScriptBasic's approach to securing connection info is use the ODBC Connect() function with a name as its argument. The associated connection info is stored in the ScriptBasic configuration file which is compiled to binary format.
Kevin is right on. If you only need to read data, ODBC is the way to go. BOI requires a lot of work and understanding of the system to read through a table and deal with the business classes. Security in Sage 100 handles security for ODBC, if is turned on. Kevin is referring to a method that uses ODBC to create a linked table in SQL, of the data in Sage. This makes it so that SQL is your interface to the data. This can be very handy, depending on your queries, as the ProvideX ODBC driver doesn't handle some types of joins like right outer joins and such. It can also speed the query when joining complex joins. He is suggesting this as a way to deal with security and managing the queries through SQL and depending on your use, it may be the better way to go.
If you are doing a true integration where you are both reading from and writing back, this will not be what you will use as ODBC is READ ONLY. If the customer is on Premium, they are already on SQL so the read will already be there and you can, but wouldn't suggest it, write back to the SQL tables. The reason I would not suggest it is you are bypassing the business logic. That is what the business class is doing and when you bypass it you can cause a world of hurt if you are not careful with what you are doing. It is better to use the BOI and it would make it more consistent if they change from Standard, Advanced or Premium versions.
If you don't want 3rd party and you feel BOI may be too complicated then the power apps would be an option if you are connected through Microsoft. it has more limitations and not much for help/documentation about it. But it is evolving.
It really depends on what you are integrating and how you expect it to flow but 3rd party might speed up the ability to integrate and strengthen the integration as the 3rd party can handle issues with Sage and you get get or put data where you want it.
*Community Hub is the new name for Sage City