Skip to content

Limitations

What XmlExtractor doesn't do, so you can plan around it. Most of these are by design: the macro is a small, predictable step in a Rules Engine flow, not a transformation engine.

Matching

  • The first match wins. When a node repeats, for example one per order line, a path returns the first occurrence in document order whose value isn't empty and under which the rest of the path resolves. There is no way to pick the second line, and no way to extract from every line. A path such as lineItems>nodes>sku is always the first line's SKU.
  • One value per path. Each path writes one value. To capture several fields, list several paths; each becomes its own property or note.
  • Leaf nodes only. Pointing a path at a node that has children returns the text of its first child with the child's label in front, not a useful value. Point paths at the node that holds the text.
  • Up to 8 levels. A deeper path is skipped. The first level is searched across the whole document, so you rarely need to start from the root.
  • A short path can hit a nested copy first. id or name returns the first node with that label anywhere in the document, which on some channels is not the order's own. Add parent labels, or start the path with >> to prefer the shallowest match. See Shadowed nodes.
  • Prefix lookups stand alone. WooMeta., Metafield., NoteAttribute., and VariationSelectedOption. must be the whole path. Only the text between the first and second dot is the key, and when the same key appears more than once, the first pair is used.

Data

  • Only what the channel sent. The macro reads the channel XML that Linnworks stored for the order. A field the channel didn't include, or that Linnworks' integration doesn't request, isn't there to extract. Orders created manually, or by channels that supply no XML, can't be processed.
  • No computation. Values are copied as text. Format can wrap a value in other text, but the macro doesn't calculate, convert, trim, or combine values. Use a Rules Engine action or a template expression for that.
  • Some characters change on the way through. A value the channel sent already encoded, such as Tom &amp; Jerry, is written out encoded, and a <br/> inside a value drops out. See Characters that change.

Writing

  • Two destinations. Values go to order extended properties or to order notes, in the five variants listed under Targets. The macro doesn't write to other order fields, items, or customers.
  • Property names are the path. An extended property is named after the path exactly as you typed it, so Order>ShippingAddress>Phone is the property's name. Renaming a path renames the property.
  • Notes aren't updated. A property with the same name is overwritten with the latest value; a note with the same text is left alone, and a note with different text is added, never replaced.

Running

  • Rules Engine only. The macro runs when a rule's action triggers it, usually as a new order downloads. It doesn't run on a schedule, and it doesn't go back over orders that were already in Linnworks unless something triggers the rule for them.
  • Linnworks' API limit applies. Each order costs two or three API calls. A rule that fires on a large batch can exceed your account's per-minute quota; the orders that hit the limit are skipped and can be re-run.
  • No visibility of the log from your account. The macro's run log is in the Linnworks developer portal, which RFP IT Solutions reads. See Troubleshooting for how to find node names and what to send us.