Virtual Happy Hour this month, Jun 28, we'll be getting a sneak preview at our soon to launch SaaS CMS!

Try our conversational search powered by Generative AI!

Importing catalog next to existing one - using ServiceAPI vs importing via Catalog Management UI


There is already one catalog and I need to import a new one. Different names but some of the catalog nodes in the new one have the same names as in the existing one. Both imporing methods pass. 

Importing with file using the Service API returns GUID. Part of catalog structure is there but none of the products or variants get proper relations. This results in empty catalog nodes but some of the products end up in the existing catalog.

Same file imported using Catalog Management UI results in Import completed message but the structure, products and variants are there.

Between every import trial I deleted newly imported catalog. Both full version and malformed version.

What is so different in handling the relations information in the catalog.xml between those two methods if there is one?

Nov 17, 2017 13:05

By "same names", I suppose you meant "same codes". As the catalog entities (nodes/entries) are identified by codes, so the code must be unique across catalogs. If you have a node with code "Hello" in catalog A, but you are importing catalog B, and there is a node with code also "Hello", then the new node will override the old one, and that would mess up with the relations. 

Nov 17, 2017 13:44

How come Catalog Management UI doesn't mess up the existing nodes?

Nov 17, 2017 13:46

Can you confirm it's same codes as I supposed? They both use the same APIs internally, so it should be the same. However ServiceAPI support upload chunks and that can cause some different.

If possible can you post screenshots of how do you catalog structure look like, in (supposedly) working and faulty case?

Nov 17, 2017 13:50

Yes, I was thinking about the codes. Tax-free is the existing one and Netthandel is the new one.

Here is the Catalog Management UI result on dropbox.

Here is the Postman Service API result on the same node, but if I navigate to parent node of the new one I get this result. You can see that all the products and nodes are just pilled up without the structure.

Nov 17, 2017 14:26

That's strange. ServiceAPI will always overwrite duplicates, while you might not select "overwrite" in Commerce Manager. So I think the results must be the way around ...

That means I have no good explanation for the issue - you should contact the developer support service. 

Nov 17, 2017 14:30

You, are correct. In Catalog Manager I did not select to overwrite nodes. Postman version just pile up products and variants.. Thanks. I will contact them.

Nov 17, 2017 14:33

I talked a bit with my colleague Steve (I assume you have been in contact with him) - and it does make senses now. In Commerce 11, we introduced the concept of IsPrimary concept, so you can specify the "primary" node for an entry. 

  • When you upgrade to Commerce 11+, the "current" parent will be selected primary.
  • When you import via ServiceAPI, because the default option is to overwrite, and because you didn't specify the primary node in your catalog import file, it will clear out current primary nodes. Entries without primary nodes will end up in catalog.
  • When you import via Commerce Manager, because you didn't select overwrite, the existing nodes are left untouched, and therefore all the node-entry relations remain. 

The fix in this case is to update your import file (inRiver?) to add IsPrimary = true to the NodeEntryRelation. 

EDIT: this is an example of why you should include the version in the question. The behaviors might change over versions, and having a version number will remain us on those changes, and you'll get faster, more accurate answers.

Edited, Nov 21, 2017 15:42

Okay.. I see that there should exist IsPrimary set to true in the NodeEntryRelation.

Scenario is like this: For every product there is exactly one variation below it. Relations are defined as follows:


This sets both product and its variation so they belong to Champagne node. 

Next piece of code:


defines that variation is bound to that product. 

Where exactly should IsPrimary be set to true? In the first NodeEntryRelation element? The one that defines actual product entry?

Nov 21, 2017 23:32

In this case both NodeEntryRelation can be IsPrimary (and actually, they should, you want the product and the variant to be in same category, don't you). IsPrimary is unique per entry, not per node. 

Edited, Nov 21, 2017 23:44

Just to verify some things:

When using service API you are using the import/catalog endpoint? No CRUD operations involved?

Did you try to do the same import in the UI with overwrite enabled? What result did you get then?

Nov 22, 2017 11:26

Yes, I was using that endpoint without any CRUD involved. I can't give you the answer right now regarding the 'overwrite' option because there were some breaking changes in our model. I will get back soon.

Nov 22, 2017 12:36


the original idea was to have a new catalog imported from inRiver next to the old one. Having the same products so that editor could manualy move newly added products to the existing product. New decision is to have it overwritten during the import in case there is any change in PIM,

I have added IsPrimary to all the <NodeEntryRelation> tags and it still behaves funky on first import - when there is no catalog imported at all. Using the Postman and Service API I get mangled up catalog and using the Catalog Manager UI catalog imports nice. I did contact develop support and provided them with They are working on it.

Nov 27, 2017 12:17

I would suggest you to contact our developer support service and file a support case. If we can have a direct look at the catalog import file and your database, it should be much quicker to identify (and even fix) the problem. 

Nov 28, 2017 9:42
* You are NOT allowed to include any hyperlinks in the post because your account hasn't associated to your company. User profile should be updated.