Table of Contents
About Burti REST 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, for example provides REST APIs for {this solution, this and this … ????}
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
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 and an enabler key file. These are files that you will need to place on your server. You likely do not need to read ahead, since typically we will do these steps for you. In this case skip ahead to the next section.
Contents of the package:
...
Burti Enabler - Enables Burti package functionality
...
hobcust/EN.hob
...
Support file. You must amend your halcust/datadef.hal file to include the line
| Code Block |
|---|
Exec_file("halcust/datadefEN.hal"); |
...
Burti API package
...
Support file. You must amend your halcust/datadef.hal file to include the line
| Code Block |
|---|
Exec_file("halcust/datadefJSON.hal"); |
...
halcust/serverJSON/custom-interfaces/...
halcust/serverJSON/generated-interfaces/...
...
Enabler key file
...
Setting up
Burti API package and product enabler key
When
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.
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.
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.
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.
Interface generation
Read API
Write 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, for example provides REST APIs for {this solution, this and this … ????}
Advantages of using 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.
...
...
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.
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 |
|---|
| 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 |
|---|
|
| 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.
| Section |
|---|
| Column |
|---|
| 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 |
|---|
|  Image Added
|
|
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 |
|---|
| 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 |
|---|
|  Image Added
|
|
Custom security via HAL
| 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. 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. |
| Column |
|---|
|  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. |
| Column |
|---|
|  Image Added
 Image Added
|
|
| 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. | 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. |
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 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. |
| 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 |
|---|
| 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 |
|---|
|  Image Added
|
|
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. | 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 |
|---|
|
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.
| Info |
|---|
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
| Section |
|---|
| Column |
|---|
| 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. | 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. | Note |
|---|
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. |
|
|
| Column |
|---|
| 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
Entry point
All Write API is accessed via the following single entry-point URL:
| Code Block |
|---|
|
https://your.server.address/Web_JSON_UpdatingComposer.hal |
Writing records
API Expects a POST request with JSON formatted post data, all of the neccessary data should be inserted into the body instead
| Info |
|---|
| Column |
|---|
| Request: | Code Block |
|---|
| language | bash |
|---|
| title | Simple record list retrieval using curl, also demonstrating the use of multiple requests in unsafe-one call |
|---|
| linenumbers | true |
|---|
| curl "https://your.server.address/Web_JSON_UpdatingComposer.hal \
?token=security_token" |
|
| Column |
|---|
| POST Body data: | Code Block |
|---|
| language | bash |
|---|
| title | Simple record list retrieval using curl, also demonstrating the use of multiple requests in unsafe-one call |
|---|
| linenumbers | true |
|---|
| {
"0": {
"name": "WEB_JSON_ORVc_Save.hal",
"company": 1,
"data": {
"action": "insert",
"CustCode": "10101",
"OrdDate": "2024-04-15",
"matrix": [
{
"ArtCode": "16X20DAL",
"Quant": 1,
"Price": 26300.00
},
{
"ArtCode": "ABUS12829.L",
"Quant": 1,
"Price": 565.00,
"returnfull": "adsf"
}
]
}
},
"1": {
"name": "WEB_JSON_ORVc_Save.hal",
"company": 1,
"data": {
"action": "insert",
"CustCode": "10101",
"matrix": [
{
"ArtCode": "16X20DAL",
"Quant": 1,
"Price": 26300.00
},
{
"ArtCode": "ABUS12829.L",
"Quant": 1,
"Price": 565.00
}
]
}
}
} |
|
| Column |
|---|
| Successfull Response | Code Block |
|---|
| language | bash |
|---|
| title | Simple record list retrieval using curl, also demonstrating the use of multiple requests in unsafe-one call |
|---|
| linenumbers | true |
|---|
| {
"0": {
"sernr": 3900005,
"errors": [],
"warnings": []
},
"1": {
"sernr": 3900006,
"errors": [],
"warnings": []
}
} |
|
|
File Upload API - pending polishing
Entry point
All Write API is accessed via the following single entry-point URL:
| Code Block |
|---|
|
https://your.server.address/Web_JSON_UploadingComposer.hal |
Advanced Use
HAL hook functions
This section requires advanced knowledge of HAL/SERP programming.
| Section |
|---|
| Column |
|---|
| Read APIFunctions 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 |
|---|
| Write APIFunctions 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 |
|
|
Advanced Index Use - coming soon
