Channels

A channel is the connection between TRADElube and one connected system: an online shop, a marketplace, an ERP system, an accounting system, or a file provided by a supplier. The channel holds who TRADElube talks to and what it signs in with. What gets transferred, and when, lives elsewhere, depending on the kind of channel.

How many channels you run is your decision, and several of the same type are provided for. Two Shopware shops, one ERP system and three supplier files side by side is an ordinary setup, not a special case. Every channel brings its own login details, its own configuration and its own traces, and none knows about the others. That is why one of them can be switched off, swapped or rebuilt without touching the rest.

What a channel is

Every channel is an entry under the navigation item Channels. It carries a name you choose freely, and behind that everything needed to connect to exactly this system. You pick the name once and meet it everywhere afterwards: on the task, in the traces and on the individual record. A descriptive name pays off quickly, "Shopware Demo Shop" gets you further than "Shop 2".

Channel list with a selected channel and an active toolbar

A channel is bound to a channel type, meaning the system it talks to. It decides more than the name suggests: an online shop signs in differently than a file on a server, and it can transfer different things. Which ones in detail is listed for each system under Channels and tasks.

The type is fixed when the channel is created and cannot be changed afterwards. The reason lies in what hangs off it: the available actions, the mapping lists, the transfer plans, and per record the channel mapping to its counterpart in the connected system. Switching the type would invalidate all of that without the records on the other side going away. Anyone moving to a different system therefore gets a second channel, and several running side by side is provided for anyway.

Direction: import and export

A channel transfers in both directions, but never in one execution. Every transfer has exactly one direction, and it belongs to the individual action, not to the channel:

Import means data comes from the connected system into TRADElube. Typical cases are orders and customers from an online shop, or product data from a supplier file.
Export means TRADElube writes data into the connected system. Typical cases are products, categories, images, prices, stock and order status.

Which directions a channel supports is decided by the channel type, not by the configuration. An online shop such as Shopware offers both directions for products, whereas a marketplace such as Shöpping transfers only orders and order status. What the individual system can do is on its channel page.

Two kinds of channel

Not every channel is addressed from TRADElube, and that decides where schedule and transfer plan live.

The regular case is the channel TRADElube addresses of its own accord, for instance with online shops, marketplaces or the custom channel. TRADElube signs in to the connected system and reads or writes there. Every transfer is a task, and the schedule and the transfer plan hang off it.

The connectors run the other way round, at the moment for instance the CAO-Faktura and the JTL-Wawi connector: a program on the side of the connected system signs in to TRADElube and fetches what it needs. When that happens is decided by that program. There are therefore neither tasks nor a schedule, and the transfer plans sit in the channel itself, in the Transfer Plans section with one tab per action. The login details run the other way round too: TRADElube issues them, they are read-only, and the button Renew replaces them with a new pair.

For everyday use the difference is small: on a connector the scheduling falls away, because it sits on the other side. So it costs you one setting less, not one more.

The range of channel types grows with the product, and both kinds grow with it. So do not rely on the examples above but on two features that stay: a connector carries the word in the name of its channel type, and its channel cannot be picked as a target under Tasks. Which systems can be connected is listed under Channels and tasks.

An opened channel is divided into collapsible sections. Every channel has the sections Common and Traces. The rest depend on the channel type:

Section	What it is for
Common	The name of the channel
Login Details	What TRADElube signs in to the connected system with. Absent for channel types that do not sign in anywhere
Configuration	What applies to every task of this channel, as opposed to the transfer plan, which belongs to one task. Absent for channel types with nothing to set channel-wide
Mappings	Value pairings between the two sides, one tab per list with the columns External and Internal. This is how the shop's order status meets the matching status in TRADElube, and a customer's salutation the matching salutation
Traces	The transfers of this channel, newest first. The first place to look when something is missing, see Traces

A channel type can bring sections of its own and leave others out. The custom channel has neither login details nor mappings, but a Data Formats section holding the layout of the files it reads. A connector additionally has a Transfer Plans section, see above. A missing section is not a gap here: it means there is nothing to set at that point.

The login details belong to the connected system and are issued there, not in TRADElube. They are therefore the part most likely to change without you doing anything. Every task of a channel uses the same login details. Once the target system revokes access, they all fail together.

You check whether they are correct with the button Connect, without a transfer having to run: TRADElube signs in straight away and answers with the message Connection successful or Connection failed plus the text the system returned. It is the quickest way to narrow a fault down, because it separates "signing in does not work" from "the data does not fit".

Several channels of the same type

Connecting the same channel type more than once is provided for, two Shopware shops for two countries for instance, or one production shop and one test shop. The channels only have to differ in their name.

They are not copies, though: a product that goes into both shops has its own channel mapping per shop and may carry a different number in each. The scope may differ too, for instance when one shop only shows part of the range.

An ordinary setup

Suppose you sell through a Shopware shop, receive article data from two suppliers as files, and keep your accounts in CAO-Faktura. That makes four channels:

Name of the channel	Channel type	What runs over it
Main Shop	Shopware	Products, categories, images, prices and stock out; orders and customers in
Article Data North	custom	Article data from a file, inbound
Article Data South	custom	The same, from a differently built file
Accounting	CAO-Faktura connector	Orders and master data, fetched by the program on the other side

The two supplier channels are of the same channel type and are still two channels. Each reads a differently built file, and the layout sits in the channel. One channel for both would mean that every change to either file endangers the other.

The fourth is the odd one out because it is a connector: it has no tasks and no schedule, its transfer plans sit in the channel, and CAO-Faktura decides for itself when it gets in touch.

What that means when something breaks plays out on an ordinary Monday: the shop withdraws your access because somebody there regenerated the login details. The channel Main Shop then fails, and with it all of its tasks. The two supplier imports keep running, the accounting side keeps fetching, and the traces show the fault on the one channel where it occurs. You enter new login details, check them with Connect, and the records left behind are picked up the next time.

Where a new channel comes from

Creating a channel is something we take on, together with the tasks that belong to it. The reason is the damage the alternative could do: an incompletely configured transfer writes into a foreign system, and what has landed there is not undone by a correction in TRADElube.

Everything else you set yourself: the login details, the configuration and the mappings. And if you would rather hand that over, we do that too.

You get there via the button New in the channel list. It lists the channel types grouped by the kind of system, and clicking an entry does not lead to a creation dialog but to a page with the contact details.

Channel type selection with six groups, from the custom channel through to services

Entries marked yet non-existent are planned and not usable yet. alpha and beta mark channels still under trial.

How it fits together

The channel on its own transfers nothing. It is the connection, and three further things build on it:

An action is a single transfer, for example "Products Upload". Which ones exist comes with the channel type.
A transfer plan determines which field is written where. On a channel with tasks it hangs off the task, on a connector off the channel.
A channel mapping remembers, per record, which counterpart it has in the connected system, so the task finds it again next time instead of creating it a second time.

What actually ran in the end is in the traces, both on the channel and on the individual record.

If you delete a channel, its channel mappings go with it. A later transfer through a new channel will therefore create the records in the connected system again.