Scheduling¶
Importing data feeds¶
An import is made through using the standard HTTP POST protocol, with personal cluster credentials provided by Apptus.
Request example¶
A single data import request example, with fictive credentials, is demonstrated using cURL below.
curl -i -X POST -d @- \
-H "Content-Type: application/xml" \
-H "Api-Key: pkA123456789AB1BDA3E968F69A97B5508BF5B123456778912FFC99" \
"https://w1A2B3C45.api.esales.apptus.cloud/api/v1/import/lifestyle-data" < /my_data.xml
Request specification¶
| Request specification | Description |
|---|---|
Method | POST |
Header | Content-Type: application/xml |
Header | Api-Key: apiKey, the unique apiKey provided by Apptus |
body | The XML data feed. |
url | https://webApiId.api.esales.apptus.cloud/api/v1/import/lifestyle-data, with the unique webApiId provided by Apptus |
If the data feed is valid, a 204 OK response will be returned. If the data feed is invalid, an error will be returned with descriptions of the errors in the file. For more information about validation, see Validation.
Compression¶
The request body can be compressed with gzip if the header Content-Encoding have the value gzip. It is recommended that the imports are compressed.
Scheduled imports¶
When going live, products and updates to them must be scheduled to be imported on a regular basis. This is typically achieved by creating a program that queues and sends full imports and incremental imports at regular intervals.
Updating advanced custom attributes
When performing an import containing advanced attributes, each identifier must always be related to the same name for all products within the import. Relations are permitted to differ from already imported products that are not included in the current import. In this case, the latest id to name relation will be interpreted as an override, and apply for all products in the catalogue.
Full imports¶
Full imports, containing all product data is recommended to be sent on a regular basis for ensured data consistency.
For small databases (i.e. less than 10 000 products), full imports could be sent on a frequent basis, replacing the need for other types of imports. For an approach of only sending full imports, it is recommended to send the full imports once every hour.
For large databases, full imports are also recommended to be sent on a regular basis but at a less frequent interval, such as once a day or once a week. These are recommended to be complemented with more frequent smaller imports, modifying parts of the catalogue.
Incremental imports¶
There are two types of incremental imports: partial imports and attribute modifications. These types of imports should only contain the products where a change has been made since the previous import, and are therefor often significantly smaller than full imports.
Partial imports allows for structural product group changes such as adding or removing variants, products, or product groups. These must include complete product groups.
Attribute modifications allows for modification of individual attributes on variant, product, or product groups. These are typically useful for changes driven by separate systems such as price and stock_number changes from an ERP.
Queueing imports¶
Imports are processed one at a time
Incoming imports will be rejected while another import is being processed. This means that the data feed software must be set up to run imports one at a time.
Since imports are processed one at a time and for various reasons could fail, all imports should ideally be sent to a queue that aggregate imports, handles retries, and handle errors. A typical process for this is normally responsible for the following or similar tasks:
- Changes invoked by other systems are placed in a queue
- Once every e.g. 5 minutes, empty queue and if any changes, aggregate them and send as a single import
- Log and notify an appropriate person to take action upon errors
- Remove successfully imported changes from the queue
- Save unsuccessful import files for easier debugging
Error handling¶
All imports are atomic (i.e. either the entire import is processed or nothing will be imported), to make it easier to recover from errors. An error can be caused either by the content being invalid or because of other factors, such as network errors. If an error is received, the import can be safely rerun once the connection is restored or content of the data feed has been resolved.
The following types of errors can be returned:
| Code | Description |
|---|---|
| 400 | The import was deemed dangerous according to eSales. For more information, see Force imports. |
| 403 | Incorrect cluster credentials. |
| 404 | Cluster not found. |
| 409 | An import is currently in progress. |
| 4xx | The import contained errors. The response body contains more information about the error to help with corrections to the data feed generation. |
| 5xx | Server error such as cluster unavailable or busy. If 5xx errors persist, contact Apptus Support and attach any information found in the response body. |
If a retailer experiences persistent network errors they should first contact their network administrator. If the problem seems to be on Apptus end, please contact Apptus Support.
Temporary network errors
The data feed software should handle temporary network errors without manual intervention as this is usually done through retries.
Force imports¶
Protection from potentially harmful imports is built into eSales Lifestyle. If an import looks dangerous, e.g. it removes half of all products in a market it will be rejected with an appropriate error message and code 400. To override the protection and force eSales to accept such an import, a force=true argument can be added to the post request of the import.
curl -i -X POST -d @- \
-H "Content-Type: application/xml" \
-H "Api-Key: pkA123456789AB1BDA3E968F69A97B5508BF5B123456778912FFC99" \
"https://w1A2B3C45.api.esales.apptus.cloud/api/v1/import/lifestyle-data?force=true" < /my_data.xml