TxDownloaderPro ← Salesforce — Infor Visual 9: no default templates, and the community set the catalogue carries

TxDownloaderPro ← Salesforce — Infor Visual 9: no default templates, and the community set the catalogue carries

Keep this skill current. dlake ships updates often and this text is embedded in the CLI you have installed. Before relying on it, compare dlake --version with npm view @commercient/dlake version; if they differ, run npm install -g @commercient/dlake@latest and then dlake skills install, which overwrites the installed skill files with the current text.

dlake-txdownloaderpro is the parent skill and the authority for everything general: what the writeback objects are and how they are exposed to the Data API (§1–§7), how a key is scoped to them, the TxDownloaderPro configuration table and the TxDownloaderProTrans transaction table and their columns (§9, §10), the SFUpdated state machine (§10), the field-mapping columns ProcessStructure, ResultStructure, XMLResult, ERPResponse, JsonRequest and JsonResponse and the {{Object.Field}} template paths that read them (§11), the filter-operator vocabulary (§12), and the txdownloaderpro_* tools that are the preferred way to configure any of it (§14). Read it first; this page does not repeat it. dlake-txdownloaderpro-salesforce is the Salesforce page and carries the destination-side detail: it is the skill this page is a child of, and the authority for the conventions that hold across every ERP, so read it before this page. This page is dlake-txdownloaderpro-salesforce/erps/infor-visual-9.md, and that skill’s ERP table is what points at it.

The catalogue ships no default template for this pair: there is no default query, no default mapping document and no default result structure to describe. What it does carry for the pair is a set of community templates, written on a tenant rather than shipped, and this page states how many there are, which objects they start from, what they are called where the name is a product artefact name, and which field-process versions they belong to. No template text is reproduced.

1. Community templates

The catalogue carries community templates for this pair and no default template: templates written on a tenant rather than shipped. Their content is not read and not described here — no query, no mapping document, no field. What this section states is how many there are, which objects they start from, what they are called where the name is a product artefact name, and which field-process versions they belong to.

• How many: 3 community templates, across 3 field-process versions.
• Operations: 3 carry IsInsert, 0 carry IsUpdate, 0 carry IsDelete. A flag decides which operation the template is allowed to perform, as it does for a default template.

Source → destination	Templates
CONTACT → —	1
Customer_Order → —	1
Customer → —	1

None of these rows carries a destination object name in the catalogue, so the destination side of every shape above is empty.

• Template names the catalogue carries: Create New Contact (1), Create New Customer (1), Create New Sales Orders (1).
• Field-process versions they belong to: TxDownloaderPro_38_2, TxDownloaderPro_38_1, TxDownloaderPro_38_3.

Importing one of these writes the same TxDownloaderPro row that importing a default template writes (parent §9); what differs is where the template came from, not how it is stored. What any one of them contains is read from the imported row itself, with the tools below.

2. Verifying

Read the imported row before a run, not after. The parent’s §14 is the authority on these tools and §10 on the state they report.

# the processes this tenant has, with their unresolved-error counts
dlake admin txdownloaderpro_list_processes

# one process in its edit shape, including the query and both mapping documents
dlake admin txdownloaderpro_get_process --processId <id>

# run the SAVED query against the live CRM and render one record as the engine’s XML
dlake admin txdownloaderpro_preview_xml --processId <id>

# the state breakdown the parent §10 reads
dlake txdownloaderpro transactions <processId> --status <state>

There is no default query or mapping document for this pair to compare an imported row against: what a given process runs is whatever the template it came from carries, and it is read from the imported row itself through the tools above.

3. Where this sits

• dlake-txdownloaderpro — the parent: exposure, key scoping, the two tables, SFUpdated, the mapping columns, the filter vocabulary, the txdownloaderpro_* tools. Read it first.
• dlake-txdownloaderpro-salesforce — the Salesforce destination page, which this page is a child of: the query shape, marker conventions and mapping conventions this destination uses across every ERP, and the ERP table that lists this page and its siblings.
• dlake-integration-setup — registration, CRM choice and the ERP connector, of which writeback is one step.
• dlake-crmpro and dlake-normalsync — the inbound leg, going the other way.
• dlake — general tenant operation.

This page describes what the catalogue carries for this pair, which is a community set and no default set. It grows as that changes.