1. Contents
  2. Guides
  3. Channels and tasks
  4. Restricting the transfer scope

Restricting the transfer scope

Not every record belongs in every channel: only the active products should go into the shop, only one brand to the marketplace, only the rows of one type out of the supplier file. This guide shows the two places where you determine that, and what happens to the records that are not let through. Which place is responsible is decided by the direction: when writing into a target system it is the Selection section, when reading a file the Filter on the record set.

Prerequisites

Step by step

  1. When writing into a target system: set the condition. The Selection section sits at the start of the plan and decides per record whether it is transferred. Tick the Condition row and choose what it listens to: the source Mapping Exists only lets records through that already have a counterpart in this channel, and a script decides by your own rules, by a property or the manufacturer for instance. If the condition says no, the record is skipped.

  2. Mind the neighbouring rows, because they belong to the scope. Up to three further rows sit in the same section. Existing Item says how the counterpart in the target system is recognized. New Item says whether a record without a counterpart is created. With the row set to Insert the channel grows with your data. With it deselected, the stock in the target system stays frozen and only what exists is updated. Removed Item says what happens to the counterpart when the record drops out of the channel: Delete or, where the system offers it, Disable.

  3. When reading a file: the filter on the record set. In the Layout section every record set carries the Filter assignment, and it takes a script. It is evaluated per row. What it does not let through is not even read. That is how one plan imports only the rows with IsVariant == 1 while the other plan of the same task takes the rest, out of a single file.

Checking the result

The difference between the two places shows in the traces, and that is exactly how you check them:

  • A record left out by the condition appears there marked Skipped. So you can see it was deliberately not transferred.
  • A row left out by the filter does not appear at all: it was never read, and without a record no transfer is created.

Check the numbers after the first execution: the number of transfers has to match the expected subset, not the whole file or the whole stock.

Frequent pitfalls

  • A filter does not clean up. Narrowing the scope from step 1 afterwards removes nothing from the target system: what is already transferred stays there. Whether what drops out gets deleted or disabled is governed solely by the Removed Item row.
  • The condition sits on the plan, not on the task. If a task has several plans, each checks its own Selection from step 1. A plan without a condition keeps transferring everything that reaches it.
  • Field conditions and row conditions are two levels. If not the whole record but a single field is to be written conditionally, that is not a case for this page but for the second record set with its own selection, see adjusting the transfer plan.
  • A missing product may simply be filtered out. If you look for a product in the shop and cannot find it, check the condition from step 1 and the filter from step 3 alongside errors. The checklist for that is under product does not appear in the shop.

Further reading