Integration with Sage 100

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?

  • 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).

  • FormerMember
    FormerMember in reply to Kevin M

    My approach is giving BOI and ODBC a web face and proxy the content to a cloud hosted Linux site. You can't hack what you can't see.

  • in reply to FormerMember

    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.

    • Part of Sage that is either free or an additional module
      • e-Business Web Services
        • Very limited only Sales Order, Customer and Customer contact is really open to this
        • No more development being done with this
        • You have to purchase it
        • Limited Documentation
        • Ports to the server must allow communication
      • SDATA
        • Can be customized and is more open to access additional data more than web services
        • No more development being done and was only on version 1 I believe
        • Limited Documentation and some docs not specific to 100 are on different versions of SDATA
        • Ports to the server must allow communication
      • BOI or Business Object Interface
        • Very powerful and access to just about anything you need
        • Lots of programming to get it to work. Not a simple call and get info
        • Must be local to call the pvxcom object
        • No documentation but there are some reference materials to help
      • Sage 100 Power Apps Connector
        • Need to be connected through Microsoft eco system
        • Limited function but is actively being developed
        • New and not much documentation but more is expected to come as more adopt it
    • 3rd Party applications (this isn't a complete list). These are actively being developed
      • In-SYNC
        • This really is syncing data from Sage 100 to your app on the web.
        • Used by many websites and programs to get and write back data.
        • More about it
      • CIMCloud
        • Very much like IN-SYNC but they have an API interface to them that you can use and then they sync back to Sage 100
        • Price is much higher than other options
        • Once data is synced to their platform you can have access through APIs as you would usually expect
        • More about it
      • SDE
        • Can define the resources you need
        • API that is real time using JSON or XML with GET and POST
        • Ports to the server must allow communication
        • More about it

    For your second question, Sage 100 can be hosted in the cloud but it is not a cloud based solution.

  • in reply to T-Man

    Hey , 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

  • in reply to milla k

    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).

  • in reply to Kevin M

    great, thanks !

    with this approach how is security ensured?

  • in reply to milla k

    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.

  • FormerMember
    FormerMember in reply to Kevin M

    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.

  • in reply to milla k

    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.