Table of Contents
...
| Section |
|---|
| Column |
|---|
| 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 |
|---|
|  Image Removed Image Added
|
|
Interface generation
...
| Section |
|---|
| Column |
|---|
| Retrieving the database structure of a registerTo 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. ExampleIn 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. |
|
| Section |
|---|
| Column |
|---|
| Importing the register's database structure as an API Register Definition recordTo 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. ExampleIn 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 |
|---|
|  Image Removed |  Image Added
|
|
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. |
Read API
Write API
...
