...

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.

...

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

Section

Column

width	30%

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.

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

Column

width	70%

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

Code Block
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

Code Block
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)

Section

Column

width	30%

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

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

Column

width	70%

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

Section

Column

width	30%

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.

Note
Tokens sent over a HTTP connection can easily be intercepted and stolen (as well as all other data sent along with it).

Column

width	70%

Custom security via HAL

Section

Column

width	30%

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.

Column

width	70%

Interface generation

Section

Column

width	30%

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.

Column

width	70%

Section

Column

width	30%

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.

Info
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!

Column

width	70%

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.

...

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

Section

Column

width	30%

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"

Column

width	70%

...

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.

Info
You won't need to ever make changes to this file.

Note
This file will always be re-generated when changing the API configuration.

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

Info
You won't need to ever make changes to this file.

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

Info
You won't need to ever make changes to this file.

Note
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:

Code Block

language	text

 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.

...

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

Parameters

Section

Column

width	60%

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:

Code Block
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

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

Info

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.

Column

width	40%

Examples

Code Block

language	bash
title	Simple record list retrieval using curl
linenumbers	true

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"

Code Block

language	js
title	Result
linenumbers	true
collapse	true

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

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

-

Code Block

language	bash
title	Simple record list retrieval using curl, also demonstrating the use of multiple requests in one call
linenumbers	true

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"

Code Block

language	js
title	Result
linenumbers	true
collapse	true

{
  "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"
      }
    ]
  }

}

-

Code Block

language	bash
title	Retrieving a full record
linenumbers	true

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"

Code Block

language	js
title	Result
linenumbers	true
collapse	true

{
  "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

Section

Column

width	30%

Column

width	70%

Advanced Use

HAL hook functions

This section requires advanced knowledge of HAL/SERP programming.

Section

Column

width	50%

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.

Column

width	50%

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

Page Comparison

Versions Compared

Old Version 55

New Version 56

Key

<span class="diff-html-changed" data-a11y-before="Start of changed content" data-a11y-after="End of changed content" id="changed-diff-0">[data-colorid=</span>

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