Map supplier data into Ergonode. No code.
Ergonode is GraphQL only, and every attribute kind has its own typed mutation. SDM Portal knows which one to use, writes your variants in the order Ergonode requires, and replays the same rules on every file that supplier sends.
Connection
- ProtocolGraphQL only, /api/graphql/
- AuthAPI key in an X-API-KEY header
- StructureTemplate
- WritesAliased GraphQL mutations, 25 operations per request
- VariantsSimple products first, then the variable product with bindings
- Delta syncHash per write operation
Where an Ergonode supplier feed actually gets stuck
Supplier files are built for humans. Ergonode is built for a schema. Most of the work is the distance between the two, and it comes back with every new file.
Every kind has its own mutation
Text, numeric, select, multi select, unit, price and relation each need a different typed mutation. Send a value through the wrong one and Ergonode answers with an unknown error and no detail.
Variants need an order
Children have to exist before the variable product can bind them. Get the order wrong and the bindings fail.
Status is a graph, not a field
Ergonode validates workflow transitions server-side, so you cannot simply set the status you want from wherever the product is now.
How SDM Portal writes into Ergonode
You draw the mapping on a canvas. Tricky rules are described in plain language and compiled once into a fixed rule, so runs stay reproducible. Below is what the Ergonode side of that actually does.
Template-scoped mapping
Pick the template and the attribute rail scopes to its attributes. Templates carry no display name in the API, so the picker shows the template code. The built-in SKU is not part of the attribute stream, so a field named esa_sku is injected and you map SKU like any other column.
Typed writes, resolved live
Text, textarea and date go out as a string, numeric, price and unit as a float, select as an option code, multi select as a list of option codes and a relation as a list of SKUs. The kind comes from your live catalog, not from the shape of the value, so an article number that looks numeric still lands as text.
Values per locale
Locale is a property of the connection you draw. Three description columns feed one attribute in three languages, and the run language decides the default.
Variants with axes and bindings
Mark a parent key, one or more variant axes and the variant SKU on source columns. Simple products are created first, then the variable product with its bindings, which is the order Ergonode requires. Axis values that pass through a ValueMap still resolve to binding codes.
Workflow status by shortest path
Because Ergonode enforces the transition graph, the shortest path from the product's current status to the one you mapped is computed and walked step by step instead of set in one jump.
Categories from several taxonomies
A flow can hold more than one taxonomy node. Each maps a source value to a category, and a product gets the deduped union of everything that resolved, in one category call.
Options, created and enriched
Missing options are created with a short suggested code, lowercased, that you can edit per value. Option custom fields of type text, textarea and rich text can be filled from other columns in the same row, so the long care text lands in a custom field while the option keeps a readable name. Option names cap at 255 characters.
New attributes from the editor
Create text, textarea, numeric, date, select, multi select, unit, price and relation attributes from the canvas. Ergonode has no API to add an attribute to a template, so a created attribute is instance-wide and you add it to the template in Ergonode itself. The editor tells you this at the moment you create one.
Batches that survive a bad cell
Writes go out as aliased GraphQL mutations, 25 operations per request, paced. One rejected value can fail a whole batched document, so a batch in which every operation failed with the same error is retried one operation at a time. Only the real offender fails, and Ergonode's own validation detail is shown on the row.
Soft failures stay soft
A value like nvt on a numeric attribute is skipped with a warning naming the SKU. A duplicate value on a unique attribute, such as a shared customs code, is recorded as a skip rather than failing the product. A relation to a SKU that does not exist yet is dropped from that write and named in the warning, so the rest of the relation still lands.
What we can write into Ergonode
Select and multi select map to option codes, and missing options can be created and enriched. A price attribute is a single float whose currency is configured on the attribute inside Ergonode, and a unit attribute reads its symbol from the attribute.
What the Ergonode connector does not do yet
We would rather you read this before you sign up than find it in week two. Every item below is a real boundary of the Ergonode connector today.
Images, galleries, files
Media attributes are visible in the rail but not written. Option custom fields of type image are filtered out for the same reason.
Prices
An Ergonode price attribute holds one float and its currency is configured on the attribute inside Ergonode. Per-edge currency, where several columns merge into one collection, is an Akeneo feature.
Grouping products
Simple and variable products only. Grouping products are not created.
Adding an attribute to a template
Ergonode has no API for it. An attribute created from the editor exists instance-wide, and you add it to the template in Ergonode before it appears in the scoped rail.
Option names over 255 characters
Ergonode refuses longer option names with an opaque error, so names are truncated at 255. Put the full text in an option custom field.
Template names
The Ergonode API returns no display name for a template, so pickers and warnings show the template code.
Questions about Ergonode and SDM Portal
How does SDM Portal connect to Ergonode?
Ergonode exposes GraphQL only, at /api/graphql/. You add the instance URL and an API key, which is sent as an X-API-KEY header, and the connection is verified with a live handshake. The key is stored encrypted and is never part of an exported mapping.
Does SDM Portal handle Ergonode variants?
Yes. You mark the parent key, the variant axes and the variant SKU on source columns. Simple products are created first and then the variable product with its bindings, which is the order Ergonode requires. Axis values that run through a ValueMap still resolve to binding codes.
Can it set the Ergonode workflow status?
Yes. Ergonode validates status transitions server-side, so SDM Portal computes the shortest path from the product's current status to the one you mapped and walks it step by step.
How does one bad cell not fail a whole batch?
Writes are batched as aliased GraphQL mutations, 25 operations per request. A single rejected value can fail the whole batched document, so a batch in which every operation failed with the same error is retried one operation at a time. Only the real offender fails, and the reason Ergonode returned is shown on the row.
Will a second run push everything again?
No. Every write is hashed per operation, so a re-run of an unchanged file reports the products as unchanged and writes nothing. A force full resync is there for the times you do want everything pushed again.
Running a different PIM?
The editor, the transforms and the workflow are shared. Only the write path differs per PIM, so each connector has its own page.
Map Ergonode once. It runs itself.
Start a workspace, connect your Ergonode instance and map your first supplier file. Fourteen days free, no card charged during the trial.