When designing an integration to Sage 300, it usually boils down to two basic decisions when it comes to writing data: Direct database access or API? As with any approach, there are advantages and disadvantages but from my perspective, there is one concept that holds the highest priority: data integrity. Without data integrity, your Sage 300 system is open to corruption and may display inconsistent or incorrect results. Upgrades to future releases may not be possible. There may also be performance issues related to data that the system does not expect. The cost of correcting such issues as well as the cost of the misleading data in your system can be high. So how can we protect against such issues? When writing to Sage 300 always use the Sage 300 API.

So what is the Sage 300 API? Let’s start by defining what API stands for: Application Programming Interface. In layman’s terms, it’s a way to “talk” to the Sage 300 system using sets of commands and data that is specific to Sage 300. It provides consistency not only in the way you communicate with Sage 300, but consistency in the way data is validated and saved. The Sage 300 API is a layer that is exposed to any outside system. This layer communicates with the business logic layer of Sage 300 and communicates with the database layer as well. This means that when you use the API, you don’t necessarily need to know the specifics of the rules or how to write to the database. As long as you use the API, all the “heavy lifting” is done for you. The API allows you to extend the functionality of the Sage 300 system. For example, if you need to add an extra set of validations or go to another system for information before you allow an operation to happen, you can use the API to do so. The API also preserves the security around the information that a particular user has access to. For example, let’s say you have built a custom screen and each user will log into Sage 300 using their own login. That user will not have the ability to write or see data from modules that they were not given access to. This eliminates the need to write your own security around your application (as it pertains to Sage 300) as everything is centralized in Sage 300.

When writing data to Sage 300, you must always use the API. Data integrity is important to any system and in an ERP, it is critical. If you use direct database access to write data (i.e. writing directly to the tables), then you are risking compromising the system in various ways. Take this example: you create a program to import OE Orders into Sage 300. This program will write to the various tables that would create the sales order. Not only do you have to make sure the internal IDs are unique (and incremented), you have to be aware of all the business rules around creating an order. For example, did the customer already reach its credit limit? Does the system allow for out of stock items to be ordered? Do the items even exist in Sage 300? There is a tremendous amount of overhead to include in a custom program that does not use the API. In addition to the business logic overhead, there is overhead associated with the security aspect. You would need to store database credentials in a file or somewhere else where your program can read from. These credentials may or may not be kept in a secure place or may not be stored using best practices. For example, the user name and password could be stored in clear text which could easily be read by someone. These database credentials can also supersede the security within Sage 300 that was placed by the Sage 300 administrator. So if your program is writing to the PO tables and the user who is running the program is set up to just have access to AR, then the program is breaking the integrity of Sage 300’s security.

Using the API can also allow you to automate certain processes within Sage 300. You can run the Inventory Control day end processing using the API. You can also post batches. Automation, preservation of the business rules & security, and most importantly, data integrity are the reasons you should always use the Sage 300 API when writing data. Yes, there is a performance hit when you use the API (due to the various rules and layers involved), but isn’t your data worth it?

Net at Work has been writing custom integrations to Sage 300 for many years. We also provide training and mentoring for customers that want to write integrations on their own. Have an integration need? Our staff is ready to support you in any capacity that is needed from designing, building and implementing a solution.