Table of Contents
About Burti API
What is a REST API?
Simply put, an API is set of rules developed to expose data and functionality across the internet in a consistent format. Representation State Transfer (REST) is a term used to refer to API generally being accessed via HTTP protocol.
Resources often have one or more methods that can be performed on them over HTTP, most popular of them being, GET, POST, PUT and DELETE.
Burti REST API resources provides information or content, which can be accessed at a predefined set of URL and returns JSON-encoded responses, and uses standard HTTP response codes, authentication, and verbs.
Burti API is a simple implementation of a REST API. It is used for communication with Web stores, Logistics applications, Service applications, custom Web applications as well as Mobile apps.
Advantages of using a REST API?
Flexibility
A RESTful API breaks down a transaction to create a series of small modules. Each module addresses a particular underlying part of the transaction. This modularity provides developers with a lot of flexibility.
Suited for Web
REST technology is generally preferred to the more robust Simple Object Access Protocol (SOAP) technology because REST leverages less bandwidth, making it more suitable for internet usage.
Prerequisites to using Burti API
Hansa Application Language license
To make use of the Burti REST API a HAL license is required. The license might come included in your product's base package, depending on your country and the product you are using, but typically this will not be the case (e.g. with Standard ERP).
Hansa Application Language knowledge optional
To take advantage of the more advanced aspects of the API, you will benefit greatly from having some HAL programming knowledge or a HAL programmer's assistance. For simpler use cases this might not be necessary.
Burti API license and package
Burti API is not included in Standard ERP base package. You will need to acquire a license from us and as soon as the formalities are settled, you will be provided with the API module package (see panel to the right for explanation of the contents of the package which includes an enabler key file).
You will need to place these files on your Standard ERP server.
You likely do not need to read this section in detail, since typically we will install these files for you. If this is indeed the case, please, feel free to skip ahead to the next section.
| File | Description |
|---|---|
Burti Enabler - Enables Burti package functionality | |
| If you are already using any Burti functionality packages, you will likely already have this installed. |
halcust/datadefEN.hal | Support file. You must amend your Exec_file("halcust/datadefEN.hal");
|
halcust/enab/... files | These files need to be added to your HAL Rules setting and distributed to client computers. These will add UI elements that will allow you to renew Burti Enabler keys from your SERP client if necessary. |
Burti API package | |
hobcust/JSON.hob | |
halcust/datadefJSON.hal | Support file. You must amend your Exec_file("halcust/datadefJSON.hal");
|
halcust/json/... files | These files need to be added to your HAL Rules setting and distributed to client computers. These will add UI elements that will allow you to configure the Burti API functionality. |
| These will most likely be empty folders at first but will be populated by support files generated by the package. These will provide the main functionality of the API. |
Enabler key file | |
BurtiEnabler.bkey | This file contains the product key that enables the use of the package. This will need to be updated periodically with a new key. However, this is done automatically in most cases and you will likely not need to bother with this. The contents of this file can also be manipulated via the Burti Enabler package mentioned at the top of this table. |
Configuring Burti API
Security
There are several layers of security that can and should be implemented to protect your data and your API transactions from snooping from unwanted parties. As a minimum we recommend configuring and using HTTPS in tandem with an authorisation token. This will ensure that the data you send and receive over the API is virtually impossible to access by unauthorised third parties.
HTTPS (HTTP over SSL or HTTP Secure)
Burti API can be accessed both via HTTP and HTTPS, but it is strongly encouraged to serve your data over HTTPS only (this means disabling HTTP altogether).
This will ensure that your traffic is encrypted and safe from third party snooping.
See sample configuration to the right. The Program Mode setting is available in the Technics module (listed as a register).
Please note that this can be set up in multiple ways and very much depends on how your Standard ERP instance is run and where it is hosted. It very well may be that changes made to this setting will be overridden by command-line parameters or by settings in your hosting provider's Cloud control interface. If this is the case, contact your system administrator or hosting provider.
Firewall white-listing
Normally the parties accessing API's reside at fixed network addresses. This is not always the case, but does apply for scenarios like web stores, connections with logistics companies, reporting tools and many others. If you are providing access to software or tools that does reside at a fixed IP address or addresses, consider only allowing access to your server from these addresses in your firewall if you have one in place, or setting one up if you do not already. This way other parties will not be able to connect to the API at all, unless you explicitly allow them by whitelisting in your firewall software or hardware.
Authorisation token
Burti API can and should be configured to require a secret token for all transactions. Consider this a password. Usage of the API without a token should be limited to testing environments only.
The setting for this can be found in the "Burti - JSON API" module.
Tokens sent over a HTTP connection can easily be intercepted and stolen (as well as all other data sent along with it).
Custom security via HAL
Burti API allows you to implement additional layers and logic to control who and how can access the API as a whole or separately for its' endpoints. As us for more details on how to do it, as this is an advanced topic and will require HAL programming.
This is done using the field "Custom boolean auth.function" on each relevant interface definition record, found in the "Burti - JSON API" module.
The function can be as simple as a username/password check that is passed along additionally with the request or as complex as calculating and validating against a passed hash of the request by a pre-determined algorithm.
Interface generation
To generate the various end-points Burti API relies on the database structure that Standard ERP exposes via the Export/import Format report in its' Technics module.
When the report is run without specifying a register code, it will dump the database definitions of all the registers in the database. These are for example Invoices, Sales Orders, Deliveries and such.
You will need to look up the register(-s) that you wish to expose via the API in this report and then separately export these to a text file.
Example for retrieving the database structure of a register
In this example we show how to generate an API end-point for the Orders register.
Step 1: Enter the keyword "Orders" in the search field of the report
Step 2: Cycling through the search results pin-point the correct register and take note of its' code (ORVc).
