Channels and tasks

The Channels area holds your client's connections to the connected systems, one row per connection. The Tasks area holds the transfers scheduled through those channels, one row per task. You reach both through the navigation entries of the same name.

What is described here is what is the same on every channel type. Which fields, sections and tasks your system brings along is on its own page, linked in the table below. What a channel is and which two kinds exist is described under channels.

Which system transfers what

The table answers the question that comes before the connection: can this system do what you have in mind at all? Import means data comes from there into TRADElube, export that TRADElube writes there.

System	Objects	Direction
Custom	Products, categories, manufacturers, stock, orders	Products and orders both ways, everything else import only
Shopware	Products, categories, manufacturers, media, properties, stock, customers, orders, order status	Products, categories, manufacturers and media both ways; properties, stock, customers and order status export only; orders import only
WooCommerce	Products, categories, media, properties, stock, customers, orders, order status	Products both ways; categories, media, properties, stock, customers and order status export only; orders import only
Shopify	Products, collections, media, stock, orders	Everything export, orders import. Products come twice, in full and as a short version
eBay	Products, categories, orders	Products export, categories and orders import
Shöpping	Orders, order status	Orders import, order status export. No products
TriData	Products, properties, stock, orders, order status	Orders export, everything else import
CAO-Faktura	Products, categories, manufacturers, media, customers, orders	Both ways. A connector, so without tasks: the connected program fetches and writes by itself

The table names objects, not tasks. There is one task per object and direction, which is how a Shopware channel reaches thirteen. What they are called in detail and where their limits are is on the system's page.

What a system transfers is decided by its channel type, not by the configuration. The channel type selection does show more entries than this table has rows: whatever is under trial there or merely planned carries an addition after its name and has no page here yet. What those additions mean is described under channels.

The list of channels

The list shows a single column, Name, and sorting is fixed to it, ascending. A click on the column header changes nothing about that, as everywhere in TRADElube.

Unlike the data areas it has neither the Filter field nor the Filter By button nor a pager below it. It always shows every channel of the client, and with a handful of connections you miss none of that.

Three buttons sit above the list. Edit opens the selected channel in the detail view and requires a selected row.

You see New and Delete as well, but for you they do not lead to creating or deleting: we create channels, and we remove them too. Delete therefore answers with a message pointing you to us, and New leads to the channel type selection and from there to a page with the contact details instead of a creation dialog. You set up everything beyond that yourself: login details, configuration, mappings and transfer plan.

The channel types are grouped there by the kind of system. How things continue from here to the first transfer is described under connecting your first channel.

A single channel

The detail view shows a single channel. At the very top sits the save bar with Save and Discard, below it the collapsible sections. At the very bottom sits the record's identifier, which you only need when writing to us about exactly this channel. It is explained under the user interface.

Every channel has Common and Traces, most also have Login Details and Mappings. These four are described here because they are built the same way everywhere. What fills them is decided by the connected system and is on that system's page. A channel that reads its data from files signs in nowhere and has no values to map: on that one both sections are absent.

Common

The section holds exactly one field. Everything else about the channel sits in one of the sections below.

Field	Meaning	Note
Name	The channel's designation	Mandatory, and unique per channel type. Two Shopware shops therefore have to differ, while a Shopware shop and a supplier file may share a name

You see this name everywhere afterwards: on the task, in the traces and on the individual record in its Channels section. A telling name pays off quickly.

Login details

The section holds what TRADElube signs in to the connected system with. Which fields it contains is on the system's page. The buttons above them, by contrast, are the same everywhere.

Up to four buttons sit above the fields, and which of them appear depends on how the system can be signed in to:

• Connect checks the sign-in immediately, without a transfer having to run, and answers with Connection successful or Connection failed plus the text the system returned.
• Request Consent takes you to the connected system's sign-in page, where you grant TRADElube access. This applies to systems that do not hand out their credentials as a key pair.
• Reset Consent withdraws that permission, so it has to be granted again.
• Renew is present where TRADElube issues the login details itself instead of receiving them. The fields are read-only in that case, and the button replaces them with a new pair. The previous one stops working, so the connected program has to be updated.

Mappings

A mapping pairs a value of the connected system with the matching value in TRADElube. This is how the shop's order status meets the matching order status in TRADElube, a customer's salutation the matching salutation, and the shop's language the matching localization.

The section carries one tab per list, and which lists exist is on the system's page. Every tab shows the same table with the two columns External and Internal: on the left the value as the connected system delivers it, on the right the value in TRADElube.

Up to seven buttons sit above the table. The first four work on the selected row:

• New appends an empty row in which you pick both sides yourself.
• Delete removes the selected row after a confirmation.
• Move Up and Move Down shift it. The order matters, because TRADElube takes the first matching entry from top to bottom.

The other three work on the whole list. Where a system does not hand out its values or does not accept any, the button is absent altogether instead of sitting there disabled:

• Reload fetches the values of the External column from the connected system again and creates a row for each. It replaces unused rows in doing so. Whatever you have mapped stays. If the system delivers more than 250 values, TRADElube says so and creates no rows, because a list that long comes out shorter when you build it by hand than when it builds itself.
• Import creates the matching entry in TRADElube for the external values not mapped yet.
• Export does the reverse and creates the missing values in the connected system.

Rows the channel type brings along cannot be deleted. They are shaded gray and cover the cases the connected system always knows, its own order statuses for instance. You may change the right-hand side, the row itself stays: Delete remains disabled even while such a row is selected.

Traces

The section shows this channel's transfers, newest first. It is the same view as under the Traces navigation entry, only restricted to this one channel: the same toolbar, the same Filter field, the same state filters and the same columns. They are described under traces and not repeated here.

It opens with the Failed state filter set, so it shows only the failed transfers at first. On a channel running without trouble it is therefore empty, and that is the answer rather than a fault. You see the remaining states as soon as you tick the other boxes.

One further button sits below the list: List Delete removes the entries shown from the traces. That does not undo the transfers themselves, only their record disappears.

The list of tasks

The list shows seven columns and sorting is fixed to channel and action. As with the channels there is no Filter field, no Filter By button and no pager: the list always shows every task of the client.

Four buttons sit above the list. Edit opens the selected task in the detail view, Execute starts it straight away, regardless of its cadence. Both require a selected row.

New and Delete behave as they do on the channels: we create tasks too, and we remove them, together with the channel they belong to. Both answer with a message pointing you to us. You set the cadence, the renewal time, the configuration and the transfer plan yourself.

Column	Meaning	Note
Channel	The channel the task transfers through	A task carries no name of its own. Channel and action together are its name
Action	What is transferred, and in which direction	Fixed once the task exists
Performance	The cadence the task runs at by itself	Manually means: only on demand. A fixed interval appears as a number with a unit, 10 Minutes for instance
Started At	Start of the last execution	Empty as long as the task has never run
Stopped At	End of the last execution	If this is empty while Started At is filled, the task is running right now
State	The result of the last execution	Successful, otherwise the short message of the failure. A dash means: no result yet
State Since	Since when that result has applied	Stays put as long as the result does not change

The list is wider than the content area and can be scrolled sideways inside its box. You only see the last two columns there.

What an execution shows

An execution started with Execute reports back with a short toast at the end, Execution finished or the failure message. If it changed anything, the Traces dialog opens as well, holding exactly the records of that run, one row per record with state and object info. Show Details opens the individual entry in full. If it changed nothing, the toast says No changes done. and nothing opens.

Some actions ask for a file at the start or hand one back. An import from an uploaded file shows an upload field before the execution and only starts on the Execute inside it. An export into a file shows the download afterwards. Both apply only to tasks whose data source is set to the route through the browser. The others fetch and drop their files themselves. How a data source is set up is described under data sources.

A single task

The detail view shows a single task. At the very top sits the save bar with Save and Discard, below it the collapsible sections. At the very bottom sits the record's identifier, which you only need when writing to us about exactly this task. It is explained under the user interface.

Which sections a task has is decided by its action. Every task has Common, Configuration and Traces. Transfer Plan is only present where the mapping of the fields can be changed at all.

Common

The section holds what is transferred and how often.

Field	Meaning	Note
Target	The channel the transfer runs through	Read-only in an existing task. A different channel is a new task
Action	The one transfer this task carries out	Read-only as well. Which actions exist comes with the channel type, see the table above
Performance	The cadence the task runs at by itself	The choices are Manually, 30 Seconds, 5 Minutes, 10 Minutes, 1 Hour and Nightly. The preset is Manually
Renewal Time	After how long a record is transferred again even without a change	Never through Monthly, plus Nightly. What this is for is described under tasks

Some actions bring a second renewal time, for instance Media Renewal Time, because images need renewing less often than prices. Which fields a task shows depends on its action.

Configuration

This holds the settings only this one action knows. There is no field every task would have here, and on most actions the section stays empty. That is the normal case and not a display fault: this action simply has nothing to set.

Two patterns recur. Actions that fetch orders or report their status back carry a field for the age of the orders still taken into account, so that a transfer does not walk the entire order history on every pass. File-based actions carry the list of their endpoints, meaning where the file comes from or where it is written, with the columns Name, Data Source and Data Format and the buttons Add and Delete above them. Below them sit the two checkboxes Disable Unused Items and Delete Unused Items (only by manually execution!): they decide what happens to records that no longer appear in the file just read. The addition in the caption is meant seriously, and what is at stake is described under custom.

Which fields the action of your system brings along is on that system's page.

Transfer plan

The transfer plan determines which value is written where. It hangs off the task and not off the channel, which is why two tasks of the same channel can map things completely differently. What it does and how an assignment is built is described under transfer plan.

The section only exists where the mapping can be changed at all. On an action with a fixed mapping it is absent, and that is not a permission problem.

It carries two rows of tabs above each other. The upper one picks the plan, because an action can have several, Product and Product Variant for instance. The lower one picks the section within that plan, from Selection through Common to Categories. Which sections exist is on the system's page. Below them Add creates a further assignment, and then one row per assignment follows.

On a connector the transfer plan sits in the channel instead of on the task, because there are no tasks there for it to hang off. It is built the same way.

Traces

The section shows this task's transfers, newest first. It is the same view as under the Traces navigation entry, only restricted to this one task, and it is described there in detail: traces. As on the channel, the section opens with the Failed state filter set, so it shows only what failed at first.

A second row of five buttons sits below the list here, and it exists only on the task. They act on the whole list instead of on a single row and are described in detail under traces. The point that matters here: Restart All resets every transfer of this task, so the next execution processes every record again. That is the route to "all of it once more", which a manual start with Execute does not take, because that one only picks up what changed and what failed last time.

Further reading

• Channels (concepts): what a channel is and which two kinds exist
• Tasks (concepts): how the cadence works and what the renewal time means
• Transfer plan (concepts): how an assignment is built
• Channel mappings (concepts): what the individual record remembers about its counterpart
• Setting up a channel: the path through login details, configuration and mappings
• Planning and starting tasks: setting a cadence, starting manually, checking the result
• Traces (reference): what a transfer records