Introduction/Overview
What is TRADElube
TRADElube builds your product range from the data your suppliers and systems deliver, and operates the connections through which it flows into ERP system, online shop and marketplace. What comes out of that is a sellable range nobody had to type in. Technically it is the merger of a PIM system (product information system) holding data of its own with a multichannel platform. We, FFE-Tech GmbH, operate TRADElube as a service at app.tradelube.com. As a customer you get your personal client and with it your own database, several of them if needed.
The word you will meet everywhere along the way is the channel: the connection to another system, such as an ERP system, an online shop like Shopware, WooCommerce or Shopify, or a marketplace like Shöpping. Your suppliers' files come in through a channel as well, the custom, file-based one: it reads them and is thereby the foundation of the product range import.
Two starting points are the normal case. Either your ERP system holds the product range: TRADElube then creates it in the remaining channels, keeps it up to date and fetches the orders back. Or the range still has to be built, from your suppliers' price lists and catalogues, just as they arrive: your files are not adapted to TRADElube, the configuration is adapted to your files. TRADElube turns them into the structure a shop needs: parent products and variants, properties, prices, images. The effort depends on the number of your suppliers, not on the number of articles. Whether 500 articles run through a format once set up, or 50,000, is your decision and not your work. And where there is no ERP system, or certain details cannot be maintained there, you manage the range directly in TRADElube, entirely or as a supplement.
The video gives a first impression of the system:
What makes TRADElube different from a conventional connection
A conventional connection or connector plugin transfers directly between exactly two predetermined systems, as shown in the illustration below: the product range into the online shop, the orders back into the ERP system. The data is translated straight from one system into the other.
That is exactly where the weakness lies. Replace one of the two systems and the pieces no longer fit together, and you will most likely be looking for new interface software.
TRADElube is built differently. As a PIM system it holds data of its own, and every channel is connected directly to TRADElube. The channels are thereby also connected to each other, indirectly and at the same time.
- The channels are interchangeable, and with them the online shop
- Channels of the same type can be connected several times, for example several online shop instances
- A newly developed channel can immediately be combined with all channels TRADElube already supports
- The channels evolve largely independently of each other
- And still, all channels benefit from new features
Say you are the vendor or a user of an ERP system for a niche market, and certain interfaces are still missing. Or you have no spare resources to permanently take care of this aspect of online trading as well. Developing a matching channel for TRADElube gives you the connection to all previously supported channels at the same time. Win-win cooperations of this kind are expressly welcome.
Connected through the vendors' official interfaces
TRADElube has its own user interface and is not a plugin installed inside the shop. It talks to the connected systems exclusively through the interfaces their vendors offer for exactly this purpose, such as the ones from Shopware, from WordPress and WooCommerce, or TriCon for TriData. That contributes to stability. The reason: such an interface (API in technical parlance) is created by the vendor for connecting from outside, and its compatibility is usually guarded strictly, which is not always the case with a plugin inside the shop. A shop upgrade therefore has comparatively little effect on the operation of the connection.
Because TRADElube runs in our data center, there is also what you do not have to operate yourself: failover safety through every part of the application running several times over on several servers, with a failed one replaced immediately, automatic upgrades, larger ones by arrangement, and continuous system monitoring through which we resolve many problems without you having to become active.
What TRADElube is built for
What sets TRADElube apart comes down to five things, and four of them go back to a single design decision: the state of a transfer belongs to the individual record, not to the execution of the task that started it. Every product, every category, every order carries its own note per channel, holding what was last transferred, the result, and what is still open. An execution is therefore not all-or-nothing, it advances the data record by record. The development effort of such a design is considerably higher than simply processing everything every time. Why we spend it anyway is what the following sections show.
Your individual way of working
What you keep, what you distinguish and how you name things is what TRADElube models, instead of forcing you into a scheme. The chain for it is continuous. Properties add what does not exist as a field, in seven types and on all six main objects, so on orders, customers and media too. The transfer plan defines line by line where a value comes from and where it goes in the connected system. Scripts compute the value that exists nowhere ready-made. Selection and filters decide which records go along at all. And the custom channel reads files and feeds whose layout only you know.
A bundled import tool demands that the file fit its schema. With TRADElube it is the other way round: the file stays as it is, the configuration adapts to its layout, and that adapting is our job, not yours.
This is what the lines of a transfer plan look like, here from a supplier import, with one field assignment and several scripts:
That freedom costs configuration effort. Once, but real. That is why TRADElube comes with a service, and it is included: we take over the configuration of the channels and tasks. The common case for most users is created by TRADElube by itself anyway. Tell us what you would like implemented and how, and we set it up. So you do not have to deal with transfer plans yourself, unless you want to. It stays looked after beyond that: what a supplier changes about their file in day-to-day business, we adjust, without you initiating anything. If they restructure it fundamentally, or a new supplier joins, that is not maintenance but a new setup. And where no suitable configuration can be found for a requirement, we are open to further development.
The concepts Properties and Transfer plan explain the chain in detail.
Only what changed is transferred
For every record TRADElube keeps a fingerprint of the data last transferred. The next time the task runs, TRADElube compares, and what stayed the same is skipped before it is even loaded. The effort therefore follows what changed, not the size of your range. A range of 50,000 articles is no different a case from one of 500. A price change reaches the shop without tens of thousands of unchanged articles being processed first.
Three limits belong to this. The first time, the task transfers everything, because nothing has been transferred yet. A change to the transfer plan resets the comparison, because the rule changed, not the data. And individualization has its pace: every script is computing work per record, and a very individual plan runs slower than a lean one. That trade-off is yours to make, not ours.
How often tasks run is described in the Tasks concept.
You can see for yourself where it went wrong
With a discrepancy, the real work is rarely the fixing, it is narrowing down the cause: was the value delivered like that, processed like that, or handed over like that? An interface connects several systems, and without evidence this is where the search for the responsible party begins. TRADElube therefore records per record and field what was actually transferred. And you can look it up yourself, in the traces as an overall view or directly on the affected product.
The classic is a stock level that does not seem to match the ERP system in the shop. The product's traces show which stock was handed to the shop:
If the expected value stands there, the cause lies in the shop. If the wrong one already stands there, the import's traces show whether it was delivered that way. Narrowing down takes minutes instead of days, and the conversation with the shop agency or the ERP vendor starts with a finding instead of a guess. This is about the cause, not about blame.
This too has its price: tracing runs across the entire data set and costs space. A limited number of states is therefore kept per record, older ones are dropped.
How you narrow down a real discrepancy with it is walked through in the traces guide. The states and filters are explained by the concept of the same name.
Errors are reported, not swallowed
What does not go through creates a named error on a named record. The status sits on the link between record and channel: a task can succeed as a whole and still leave three failed products behind, which stay visible until they are through. A visible error is cheap. An invisible one comes back through your customers, weeks later and without a trace of where it arose.
In the traces it looks like this, with the Failed filter and a message naming cause and remedy:
The error texts themselves are not programmed in. Between the technical exception and what you read sits a centrally maintained mapping that turns it into an understandable message with a suggested course of action. A newly appearing problem thereby gets a usable message without you having to wait for a new version.
This stance means TRADElube sometimes stops where another design would carry on. If a connected system suddenly delivers considerably fewer records, synchronization of that area stands still until a human has decided whether the drop was intended. Better to ask once too often than to silently halve a product range.
What a message means in detail, and what to do then, is covered under Understanding error messages.
A disruption leaves no silent deviation
A transfer that did not go through stays open and is picked up again until it is through. If a task breaks off, nothing is lost. It only means those records have not been advanced yet. After an error TRADElube waits with growing intervals, instead of hammering a foreign system by the minute. A manual start always picks up everything that failed. And the renewal time realigns a target system after a while even if somebody changed something there by hand.
A short network outage, a restart, maintenance in the shop therefore create no silent deviation. Exactly these deviations are the most expensive ones, because they only surface when a customer cannot find a product, and by then nobody remembers which task broke off three weeks ago.
Why shop data sometimes still looks different than expected, and what to do then, is covered in Synchronization basics.
Where to read on
This documentation is built along four axes, and each answers a different question:
- Getting started: account, a tour of the interface, the first channel, the first transfer. Worked through once, you know the system.
- Concepts: why TRADElube does something the way it does. Channels, tasks, transfer plan, mappings, traces.
- Guides: step by step towards a goal, from connecting a shop to analyzing a problem.
- Reference: every area, every field, every button, plus a page per connected system with its tasks and limits.
For looking things up there are the Glossary and the FAQ.
Get started now
Feel free to contact us at any time, without obligation, at info@ffe-tech.com, and we will discuss your project in detail. If you wish, we present the system to you live in an online meeting, right along your requirements. TRADElube is a pure B2B platform: as a business you register an account at app.tradelube.com. After we have agreed on the details we create your personal client, set up the initial configuration with you, and you can start right away.