Search our Wiki
REST API Transfers
A Transfer is a specification of how data should be transferred from a specific source table to a specific destination table. Read more about Transfers
NOTE: The JSONAPI format is currently not supported.
|
Field |
Type |
Notes |
|
id |
string |
unique id for the record |
|
type |
string |
always "transfers" (only used with JSONAPI) |
|
flatten |
boolean |
Determines if the result is returned in a flat format (all transfers), |
|
Attributes |
|
|
|
code |
string |
mandatory - please set a unique code |
|
description |
string |
mandatory - please provide a useful description |
|
status |
string |
"Implementing" (default), "Testing", "Ready", "Live", "Archived" |
|
group |
string |
|
|
source |
string |
|
|
source_layout |
string |
|
|
destination |
string |
|
|
destination_layout |
string |
|
|
source_table |
string |
|
|
destination_table |
string |
|
|
link_storage |
string |
|
|
enabled |
boolean |
|
|
update |
boolean |
|
|
add |
boolean |
|
|
delete |
boolean |
|
|
actions |
boolean |
|
|
move |
boolean |
|
|
delete_all |
boolean |
|
|
autogenerate_key |
boolean |
|
|
disable_dest_lookup |
boolean |
|
|
all_fields |
boolean |
|
|
continue_on_error |
boolean |
|
|
type |
Integer |
0 (Transfer), 1 (Sub-transfer), 2 (Scatter-transfer), 3 (Gather-transfer) |
|
Related objects |
Notes |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Query Parameter |
Notes |
Examples |
|
id |
Unique identifier of the transfer |
id=100 |
|
flatten |
Determines if the result is returned in a flat format (all transfers one by one), or returned as a collection (Main transfers contain their sub-transfers/scatters/gathers) |
flatten=true |
|
search |
Finds transfers where searchable fields contain the provided value. |
search="transfer_01" |
Difference between normal and flattened outputs:
The "flatten" parameter exists to make it easier to export a list of transfers.
The normal output has sub-transfers, scatter and gather transfers contained within their parent transfers, which can be difficult to export as they can also be parents to other transfers, which makes it extremely difficult to store in a normal data table.
Normal output:
[
{
"id": 1,
"code": "A0_TEST_BUILDFIELD",
"scatters": [{
"id": 2,
"Code": "A0_SCATTER1",
}]
}
]
The flattened output, however, treats all these transfers, irrespective of type, as "parent" transfers, and lists them out in the data table.
This means there are only 3 possible levels of data. The first one being the list of transfers, and the second one being the tables inside each transfer (list of comments, list of triggers, etc.) with comments on the other tables representing the last level.
Whereas the normal output would have an indeterminate number of levels in the data (A transfer containing it"s tables as well as a list of it"s subtransfer, which themselves could contain subtransfers or scatters, which themselves could also contain their own sub-elements" )
Given the flattened output removes the association of a transfer and it's nested sub-transfers/scatters/gathers, we've added two extra fields that allow the user to conserve this information:
| Field | Type | Note |
| transfer_type | String | 'Transfer', 'Sub-transfer', 'Scatter-transfer', 'Gather-transfer'' |
| maintransfercode | String | The code of the main transfer this transfer belongs to, this field does not exist for main transfers themselves. |
Flattened output example:
[
{
"id":1,
"code":"A0_TEST_BUILDFIELD",
"transfer_type": "Transfer"
},
{
"id": 2,
"Code": "A0_SCATTER1",
"maintransfercode": "A0_TEST_BUILDFIELD",
"transfer_type": "Scatter-transfer"
},
]
