Traces

For every transfer TRADElube records which record was touched through which channel by which task, when that happened, what came of it, and which content went over the wire. These entries are the traces. They arise automatically on every execution, without you having to switch anything on or write anything down.

At an interface at least three systems meet, and when a value does not look the way it was expected to, the actual work is not the correction but the narrowing down: was the value delivered that way, processed that way, or handed over that way? That is exactly the question the traces answer, per record and per field.

This page explains the model behind it. The route through the interface with practical cases is shown in Traces (guides), the columns, filters and buttons are listed in traces (reference).

The transfer as a unit

A transfer in the sense of the traces is one record, one channel and one task, not a whole execution. Three entries make it up:

The channel mapping says which record in which channel this is about, that is, this one product in this one shop.
The task says which operation touched it. Products and stock levels run through two different tasks, so the same product in the same shop has two transfers side by side, and each has a history of its own.
The point in time says when that last happened.

Traces filtered to a single product: six transfers of the same article across five tasks, one of them failed

For every such pair of channel mapping and task there is exactly one entry, and it is carried forward instead of multiplied. A product that has been running into the shop hourly for two years therefore leaves one line behind, with its current state and its history, not seventeen thousand log lines.

That is why the traces are still usable after years of operation: they grow with the number of records, not with the number of executions. A log that gets longer with every execution is bearable only with a search function after half a year, and no longer answers the question "what last happened to this product" at all.

The state hangs on the record, not on the execution

Every transfer carries a state, and it applies to this one record in this one task:

State	What it says
Neutral	There was nothing to do. The record was checked and was the same on both sides.
Created	The counterpart was newly created.
Modified	The counterpart was updated.
Removed	The record was taken out of the channel.
Failed	The transfer did not get through for exactly this record.

On a failure the list shows the error message itself in place of the state, so that you do not have to open the entry to see what went wrong.

An addition can follow the state, and it answers the question why nothing happened. Skipped means TRADElube deliberately left the record out, for instance because a condition in the task's Selection section did not apply, or because the counterpart was not found in the target system. Disabled means an entry in the target system was not deleted but switched off.

One state explains the design of the whole thing, and it is Failed. It names a single record while the task as a whole may well have succeeded, and it stays until that record is through. An execution in TRADElube is not all or nothing, it carries the state forward per record. The next execution picks an open record up again, a manually started one in every case.

TRADElube staggers its attempts while doing so: a fresh error is retried on every execution, and once it is more than a day old, still about every two hours. The reason is the case that would otherwise arise: a record that fails for a permanent reason, because a mandatory field is missing in the target system for instance, would produce the same error on every execution and eat the time the remaining records are entitled to.

What follows from this is the real value of that split: a fault does not produce a silent deviation. Whatever did not get through stands as a named error on a named record and stays due, instead of being forgotten next time. Otherwise it would only come to light when a customer fails to find something in the shop.

Four places, the same data

The same transfers can be seen in four places, each cut differently:

The navigation entry Traces shows everything, chronologically, the newest at the top. That is the way in when you do not yet know where the problem sits.
The channel holds the transfers of that channel. Useful when one connected system stands out.
The task holds the transfers of that task. Useful when one particular operation stands out, the stock reconciliation for instance.
The record, in its Channels section, holds the transfers of that one record, one tab per task. Useful when the question hangs on one product.

These are four views of the same data, not four logs. So it does not matter which side you come from: what you see on the product appears in the overall overview just the same, and the button Goto leads from there back into the record concerned.

Executed At versus Changes At

Two points in time stand side by side for every transfer, and they answer different questions. Executed At is when an execution last touched this record. Changes At is when something last actually changed in doing so.

Most of the time the two sit apart, and that is the normal case, not the suspicious one: TRADElube only transfers what has changed, and the vast majority of executions establish exactly that and are done. A change timestamp weeks in the past is therefore not a standstill but the statement that nothing has changed since. Why it is built that way is under synchronization basics.

For fault finding this is the most reliable piece of information in the whole view. It separates two cases that look identical from the outside: "the record is not being touched at all any more" and "the record is being checked, but there is nothing to do". In the first, something is wrong with the task or the selection. In the second, the cause lies in the source data.

What is kept

Every transfer carries its content along, as the other system delivered it or took it in, usually as XML or JSON. On a failed transfer the error message comes with it. The format is technical, XML or JSON, and still readable enough for the question at hand.

Trace detail dialog with the diff switched on, the changed product number highlighted in red and green

Not only the latest state is kept, but up to five. Older ones drop out. Two states can be shown as a comparison, deletions in red and additions in green, so that the change itself catches the eye instead of having to be hunted for.

Five is tighter than it sounds. A new state only arises when the content has changed, not on every execution. Five states are therefore five changes: on a product that changes twice a year the history reaches back years, on a record where something happens daily it covers barely a week. The limit exists because every kept state costs space and the traces run alongside the entire data stock.

From version 1.3.0 this history exists. Before that only the latest state of a transfer was available, so a cause further back could no longer be evidenced. See release notes 1.3.0.1.

A price that is wrong

What all this is good for shows in the case the view was built for. A customer calls: the shop says 19.99, your price list says 24.99. Three systems are involved, the supplier file, TRADElube and the shop, and the question is not how to correct the price but where it arose. The route runs through the product, Channels section:

Select the shop channel's row, Show Traces, tab of the Products Upload task. There you find the content that last went out. If it says 19.99, the shop got exactly what TRADElube sent. That takes the shop out of it.
Back to the Channels section, this time the supplier channel's row, tab of the Products Import task. This is the content the file delivered. If it says 19.99 as well, your supplier delivers that price, and sorting it out belongs with them.
If it says 24.99, the cause lies in between: the upload's transfer plan reaches for a different price group than you expect, or a script converts it.
Changes At says how long it has been that way, and the comparison of two states shows the transfer in which the price changed.

Four looks, and not one of them assumes you can read XML. Finding the number is enough. What counts is not the convenience but how the next conversation starts: you do not call your supplier with a suspicion but with the content their file delivered that day. And where the finding goes against TRADElube, it is just as unambiguous.

In everyday operation, by contrast, you never have to open this view. It keeps recording by itself and waits until a question comes.

How it fits together

The traces are the result of the other terms, not an area of their own next to them:

The channel mapping carries them. Without the link of a record to its counterpart there would be nothing for an entry to hang on, and both disappear along with the channel.
The task produces them. Every execution carries the entries of its records forward, and it also decides which records are due in the first place.
The transfer plan explains the content. The traces show which value was transferred, the transfer plan says why it was that one. Only both together give a conclusive picture.