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.

In this documentation topics and API elements and functions that either require or can be altered by HAL programming will be marked with a lightbulb symbol.

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
`hobcust/EN.hob`	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 `halcust/datadef.hal` file to include the line 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 `halcust/datadef.hal` file to include the line 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.
`halcust/serverJSON/custom-interfaces/...` `halcust/serverJSON/generated-interfaces/...`	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. Ask 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

Retrieving the database structure of a register

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

In this example we show how to retrieve the database structure of the Orders register to use for creating its' API end-point.

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

Step 3: Reopen to the Report Specification window using the cogwheel menu available in the upper-left hand corner of the window.

Step 4: Enter the register code (ORVc in this example) in the field labeled "Vc (View Code)", set Media to File and press Run to save the definition in a file.

Importing the register's database structure as an API Register Definition record

To start configuring the end-point, you need to create an API Register Definition record for it in the Burti - JSON API module. For this you can use a database structure definition file.

In Burti - JSON API module open Imports and select "Export/Import Format file" and pick the file.

In prior versions of the Burti API it was necessary to edit files exported in this manner to remove blocks that follow M4PackedMatrix fields up to and including double <CR> lines, but this is now automatically detected and ignored upon import.

Example

In the example we'll use the file created in the previous section to generate an API Register Definition record for the Orders register.

Navigate to Burti - JSON API module Imports, select "Export/Import Format file", pick your file and run the Import.

If all goes well, a new record should now be created in the API Register Definitions register for Orders (register code ORVc).

Congrats, you are now ready to start configuring!

API Register Definition - configuring your end-point

Records in this register are the facility for configuring the capabilities of your API end-points. You set what fields are accessible, how the records can be filtered, sorted, manipulated.

The lightbulb icon denotes parts of the Burti API that require or are related to HAL programming in some form.

Field	Explanation
Vc code	This is the register code, this specifies which data the end-point is serving and updating.
ImportTag	This currently has no effect on anything
MainKey	This is the name of the main key (primary key) for this register. You will need to know this, to configure the end-point properly. Most of the time you can guess this name by the "main" field in the register. For registers with numbered records this will typically be "SerNr", for records with a Code field it's typically "Code", but can sometimes also be called "MainKey" or something else. To be safe, you will need to consult with a HAL programmer, if you are not one yourself.
Import date and time	These are informative fields and show when the definition was imported.
Support variable fields	These are used in more advanced use cases of the API. These support variables ar maintained throughout the lifecycle of each API request and are available in all HAL hook functions. You can store temporary data (e.g. implementing a cache of some data you do not wish to be re-read from the database for each record in a record set). You can specify multiple variables or even arrays or vectors of a variable type, depending on your need.
Block	Checked when the end-point is made for a block not register.
Export Attachments	When checked, information about attached files will be included in the JSON data for records accessed via this end-point.
View Attachments	When checked, an additional interface will be generated for attachment retrieval.
Add Attachments	When checked, an additional interface will be generated for adding attachments to records accessed via this end-point.
Delete Attachments	When checked, an additional interface will be generated for deleting attachments to records accessed via this end-point.
Do not use SequenceNumbers	No longer necessary, used in older versions of the API - the usage of SequenceNumbers for registers is detected automatically.
Field configuration
Column	Explanation
Name, Type, Length, Location	These describe the field's parameters in the database structure.
In list	This determines whether the field is included when requesting the short/list version of the data. Typically used for retrieving record list with general data of the record (for displaying in record lists or other similar data overviews).
In full	This determines whether the field is included in the full set of record's data.
Filter by	Whether to enable filtering by this field when making API requests.
Index names (3 columns)	These all serve the same purpose - for listing comma-separated index names in which the field is included. This then enables proper sorting by these indexes. You do not need to list all indexes a field is used in, just the ones you actually wish to use. You also do not need to list an index on all of the index's fields, just the ones you actually wish to set your sort on or lookup records by. Same limitations apply as with using indexes in HAL - you can't omit a key field from the middle of an index.

Generating API end-points

To generate the API end-point from your API Register Definition record, select the option(-s) you need under the cogwheel menu in the record.

To enable the Read API, select "Generate JSON read API"

To enable the Write API, select "Generate JSON write API"

After running these functions, you will receive a message box about generated HAL files for your end-point interfaces.

The structure and role of these files are as follows:

File	Role
`halcust/serverJSON/generated-interfaces/JSON_InterfaceCallers.hal`	This is is the main entry point for all API calls. Think of it as a router. Everything will go through this file and get re-routed to the appropriate API sub-routines. You won't need to ever make changes to this file. This file will always be re-generated when changing the API configuration.
The register code for Orders - `ORVc` - is used, but this part of the filename will change according to whatever register you are setting up the API for.
`halcust/serverJSON/generated-interfaces/JSON_ORVc.hal`	This is the main Read API functionality. It contains code for all the indexing, filtering and include/exclude options you selected. You won't need to ever make changes to this file. This file will always be re-generated when changing the API configuration.
`halcust/serverJSON/generated-interfaces/JSON_ORVc_Tools.hal`	This file is where the Read API customisation happens. This contains all the available HAL hooks that you can take advantage of to either include additional data or add custom filtering or other behavior to the API. The various possibilities are documented towards the end of the documentation.
`halcust/serverJSON/generated-interfaces/JSON_Save_ORVc.hal`	This is the main Write API functionality. It's responsible for populating the record with the field values that you pass via the API. You won't need to ever make changes to this file. This file will always be re-generated when changing the API configuration.
`halcust/serverJSON/generated-interfaces/JSON_Save_ORVc_Tools.hal`	This file is where the Write API customisation happens. This contains all the available HAL hooks that you can take advantage of to either include record validations, additional calculations, changes to other linked records etc. The various possibilities are documented towards the end of the documentation.

Read API

Entry point

All Read API is accessed via the following single entry-point URL:

 https://your.server.address/Web_JSON_Composer.hal

Batch requests

The API allows for multiple requests to be made simultaneously in one call. Depending on the application this can have advantages, mostly performance related. This is done by prefixing all API call parameters with a request number, starting with zero.

This means that parameter1 and parameter2 become 0_parameter1 and 0_parameter2 and if you do chain multiple requests together, then all subsequent request parameters are prefixed by an incremented number.

Look for examples below the parameter descriptions on how to piece this together.

Parameters

Documentation

Parameter	Usage
token without request number prefix	Must be included, if you've set up a security token in your API Settings.
`query`	This routes the API to the specific register's end-point. This is supplied in the following format: Web_JSON_<register-code>_List.hal So for example for the Orders register with code `ORVc` the end-point becomes `Web_JSON_ORVc_List.hal`
`company`	The company number from which you wish to the data to be retrieved.
`full` (optional)	Set this to `true` to retrieve the full data set (as defined using the "In full" column in the API Register Definition record as described earlier). Defaults to `false`
`count` (optional)	The number of records to return. Defaults to `50`
`offset` (optional)	Used together with the `count` paramete to skip the first set of records when employing a paginated record retrieval approach (i.e. offset of 50 with count of 50 would mimic requesting a second page of 50 records).
`since_seq` (optional)	All data sets for registers that support sequencing/sequence numbers are returned along with the current database sequence number - a counter that is increased when a change is made in the respective register. If you record this number and then use it as the `since_seq` parameter in subsequent calls, you can retrieve only the records that have changed since the previous data request.
`index` (optional)	Select the index you wish your data to be sorted by or looked up by. Must be defined in the API Register Definition. Defaults to the main key specified on the API Register Definition.
`sort_only` (optional)	If you do not wish to lookup data by specific values of the fields in the specified `index`, you can set this to `true` to only apply a sort by this index. Defaults to `false`
`sort_order` (optional)	Set to `back` to apply a descending sort order. Defaults to `forward`
`fieldcnt` (optional)	When looking up data by specific `index` field values, you must specify the index segment/field count to use. Defaults to `none`
`fieldlist` (optional)	When looking up data by specific `index` field values, you must specify the field names by which to perform the lookup. This is then accompanied with additional dynamic fieldname-named parameters. Example: `index=CustCode&fieldcnt=1&fieldlist=CustCode&CustCode=05131` This is a pseudo-example, as you always have to prepend the parameter names with the request's index. In single-request calls use `0` (`0_index` and so on). When using indexes with date fields for lookups you can either lookup by a single specific date or use a date range. To use a lookup by range, add another parameter along with the date field, with the string "-until" appended. Example: When using field `OrderDate` you can use either just the `OrderDate=2020-01-01` for a single date or both `OrderDate=2020-01-01` and `OrderDate-until=2020-01-31` for a full month. You do not need to list the `-until` parameter in `fieldlist` Date format is `YYYY-MM-DD` everywhere on the API.
`new` (optional)	This parameter will return a blank record to be used as a template for populating a new record.
`debug` (optional)	Set this to `on` to enable debug logging in `hansa.log` for each API call. This will give performance statistics of the call. Default value is `off`
`paramlist` (optional)	Use this to list parameter names that you wish to see the values of dumped to the debug information log.
`any fieldname` (optional)	You can pass any field name with a value to use as a filter. For example, you could use the Order field `InvFlag` value set to 0, to only filter Orders that need to be invoiced. You need to explicitly configure the fields you wish to filter by in this manner by setting the matrix column Filter by to "Include" in the API definition record.

Examples

Simple record list retrieval using curl

curl "https://your.server.address/Web_JSON_Composer.hal \
  ?token=security_token
  &0_query=Web_JSON_ORVc_List.hal
  &0_company=1
  &0_count=5"

Result

{
  "0": {
    "addinfo": {},
    "db-seq-nr": 1082107131,
    "records": [
      {
        "SerNr": 200000,
        "OrdDate": "2019-12-04",
        "CustCode": "02306",
        "Addr0": "Smith and Sons"
      },
.. 5 records in total ..
    ]
  }
}

You will notice that the result is also returned in numbered blocks to match your query request index(-es).

-

Simple record list retrieval using curl, also demonstrating the use of multiple requests in one call

curl "https://your.server.address/Web_JSON_Composer.hal \
  ?token=security_token
  &0_query=Web_JSON_ORVc_List.hal
  &0_company=1
  &0_index=SerNr
  &0_fieldlist=SerNr
  &0_fieldcnt=1
  &0_SerNr=200000
  &1_query=Web_JSON_ORVc_List.hal
  &1_company=1
  &1_index=SerNr
  &1_fieldlist=SerNr
  &1_fieldcnt=1
  &1_SerNr=200001"

Result

{
  "0": {
    "addinfo": {},
    "db-seq-nr": 1082107131,
    "records": [
      {
        "SerNr": 200000,
        "OrdDate": "2019-12-04",
        "CustCode": "02306",
        "Addr0": "Smith and Sons"
      }
    ]
  },
  "1": {
    "addinfo": {},
    "db-seq-nr": 1082107131,
    "records": [
      {
        "SerNr": 200001,
        "OrdDate": "2019-12-04",
        "CustCode": "02921",
        "Addr0": "Only Smith's Sons"
      }
    ]
  }

}

-

Retrieving a full record

curl "https://your.server.address/Web_JSON_Composer.hal \
  ?token=security_token
  &0_query=Web_JSON_ORVc_List.hal
  &0_company=1
  &0_full=true
  &0_index=SerNr
  &0_fieldlist=SerNr
  &0_fieldcnt=1
  &0_SerNr=200000"

Result

{
  "0": {
    "addinfo": {},
    "db-seq-nr": 1082107131,
    "records": [
      {
        "SerNr": 200000,
        "OrdDate": "2019-12-04",
        "CustCode": "02306",
        "Addr0": "Smith and Sons",
        "Addr1": "13 Grange Road",
        "Addr2": "",
        "Addr3": "Bermondsey",
        "OurContact": "",
        "CustContact": "Miss Yolanda Sweet",
        "ExportFlag": 0,
        "InvFlag": 2,
        "ShipFlag": 1,
        "Prntdf": 1,
        "PayDeal": "30",
        "CustCat": "VIP",
        "InvMark": true,
        "ShipMark": true,
        "Objects": ["Z413", "D02306", "VIP"],
        "ShipMode": "",
        "OrderStatus": 0,
        "SalesMan": ["SJ"],
        "Sign": "",
        "ShipDeal": "",
        "ShipAddr0": "",
        "ShipAddr1": "",
        "ShipAddr2": "",
        "ShipAddr3": "",
        "CurncyCode": "GBP",
.. other defined fields ..
        "$matrix": [
          {
            "stp": 1,
            "ArtCode": "ITEM1",
            "Quant": 1,
            "Price": 19,
            "Sum": 19,
            "vRebate": 0,
            "SalesAcc": "4010",
            "Shipd1": 1,
            "Shipd2": 1,
            "Invd": 1,
            "Objects": ["SGR", "TPB", "ORI"],
            "BasePrice": 16.13,
            "rowGP": 2.87,
            "Spec": "Main Item With Interesting Example Name",
            "VATCode": "0",
.. other row fields ..
          },
          {
            "stp": 1,
            "ArtCode": "ITEM1",
            "Quant": 1,
            "Price": 19,
            "Sum": 19,
            "vRebate": 0,
            "SalesAcc": "4010",
            "Shipd1": 1,
            "Shipd2": 1,
            "Invd": 1,
            "Objects": ["SGR", "TPB", "ORI"],
            "BasePrice": 16.13,
            "rowGP": 2.87,
            "Spec": "Main Item With Interesting Example Name",
            "VATCode": "0",
.. other row fields ..
          },
          {
            "stp": 1,
            "ArtCode": "ITEM1",
            "Quant": 1,
            "Price": 19,
            "Sum": 19,
            "vRebate": 0,
            "SalesAcc": "4010",
            "Shipd1": 1,
            "Shipd2": 1,
            "Invd": 1,
            "Objects": ["SGR", "TPB", "ORI"],
            "BasePrice": 16.13,
            "rowGP": 2.87,
            "Spec": "Main Item With Interesting Example Name",
            "VATCode": "0",
.. other row fields ..
          }
        ]
      }
    ]
  }
}

Write API - pending polishing

Advanced Use

HAL hook functions

This section requires advanced knowledge of HAL/SERP programming.

Read API

Functions are available in the register's Read interface's Tools file as previously mentioned.

Function	Usage
`AddInfoGeneral`	Allows to add any additional information in the response JSON. This will appear as the contents of the response block's `addinfo` JSON property
`Options`	Allows to set specific options for this request block (e.g. things like JSON formatting options)
`AddInfoRec`	Allows to add any additional information in the response JSON of specific records. This will appear as sibling data to the record's fields. If you wish to separate, you need to explicitly make a wrapping property.
`AddInfoRow`	Allows to add any additional information in the response JSON of specific records rows. This will appear as sibling data to the row's fields. If you wish to separate, you need to explicitly make a wrapping property.
`LoopTest`	Allows to add additional test conditions for record loops, that are more complex that checking agains a single value of a field
`LoginTest`	Allows to add authentication logic that's specific to a register's API
`NewExtra`	Allows to add extra information when retrieving a blank record template with the `new` parameter.

Write API

Functions are available in the register's Write interface's Tools file as previously mentioned.

Function	Usage
`SaveCheck`	Allows to add RecordCheck-like validations or even a full RecordCheck call
`DeleteCheck`	Allows to add custom logic for validation record deletion
`SaveWarnings`	Add custom warnings that do not fail the storing of record, but simply provide some warning-level feedback
`SaveExtra`	Allows to perform additional actions when storing records
`DownloadFileTest`	Allows to implement custom logic when determining whether attachment download is allowed for a record
`UploadFileTest`	Allows to implement custom logic when determining whether attachment upload is allowed for a record
`RemoveFileTest`	Allows to implement custom logic when determining whether attachment removal is allowed for a record
`PasteValue`	Can add actions that should be run after setting a value for each or separate fields. This is similar to AfterEditField Window Actions

Table of Contents

About Burti API

What is a REST API?

Advantages of using a REST API?

Flexibility

Suited for Web

Prerequisites to using Burti API

Hansa Application Language license

Hansa Application Language knowledge optional

Burti API license and package

Burti Enabler - Enables Burti package functionality

Burti API package

Enabler key file

Configuring Burti API

Security

HTTPS (HTTP over SSL or HTTP Secure)

Firewall white-listing

Authorisation token

Custom security via HAL

Interface generation

Retrieving the database structure of a register

Example

Importing the register's database structure as an API Register Definition record

Example

API Register Definition - configuring your end-point

Generating API end-points

Read API

Entry point

Batch requests

Parameters

Documentation

Examples

Write API - pending polishing

Advanced Use

HAL hook functions

Read API

Write API

Advanced Index Use - coming soon

Burti Rest API

About Burti API

What is a REST API?

Advantages of using a REST API?

Flexibility

Suited for Web

Prerequisites to using Burti API

Hansa Application Language license

Hansa Application Language knowledge optional

Burti API license and package

Burti Enabler - Enables Burti package functionality

Burti API package

Enabler key file

Configuring Burti API

Security

HTTPS (HTTP over SSL or HTTP Secure)

Firewall white-listing

Authorisation token

Custom security via HAL

Interface generation

Retrieving the database structure of a register

Example

Importing the register's database structure as an API Register Definition record

Example

API Register Definition - configuring your end-point

Generating API end-points

Read API

Entry point

Batch requests

Parameters

Documentation

Examples

Write API - pending polishing

Advanced Use

HAL hook functions

Read API

Write API

Advanced Index Use - coming soon