In this post, I'm going to cover some of my learnings while attempting to import content from a third-party PIM into Episerver commerce using code. There are two ways of importing content into commerce, one via an XML file and one in code. Generate an XML file, configuring it to work using commerce schema and then importing that file into commerce is a valid way to import products. In the past when I've undertaken a complete product import from a legacy PIM into commerce, this is the approach I've taken.
For this project, using the APIs and importing products in code seemed like a good approach. If you want to import products, variants, or catalogue nodes into Episerver commerce using the commerce API then one option that will be of interest to you will be the CatalogImportExport class and its Import() method. CatalogImportExport can be found within the Mediachase.Commerce assembly. A common example of when you might want to do this is when you are working with a third-party PIM product like InRiver, and you want to import content from the PIM into commerce on a regular basis.
I'm going to be honest before we get going, getting the import process fully working was a pain compared to the XML approach. Importing all the markets, the languages and mapping them correctly was fiddley and time-consuming. When the import process fails it is hard o debug things. If you're importing data and you accidentally mismap some data, you can inadvertently end up with hidden properties in your products and variants that you can't see in your code.
Getting all the data 100% working, with no import issues can be tricky. One of the big problems being the sheer amount of data you need to keep in sync. Figuring out what goes where, and where things were stored required a lot of time and patience. If you're just about to go through this process yourself, then give yourself plenty of time. Overestimate rather than underestimate 😊😊😊
How Do I Import Code?
The code above is, hopefully, fairly straightforward to understand. The code is reading in an export file that is stored on a local disc. The file gets serialized into a file stream which is then passed into the Import() method. As long as you have a valid commerce export file this should import correctly.
Import File Overview For InRiver
This section doesn't have anything to do with importing, but it might be handy for me to quickly discuss my learnings working with importing data from InRiver into commerce. After some Googling, I can't see anyone else mention these things. The inRiver connector uses a standard commerce import process. InRiver generates a folder, containing an XML file and a zip file that contains all the changes for a given PIM amend. The export folder contains a file called catalog.xml and an additional ZIP file.
The zip file contains an additional catalog.xml file that contains slightly different data. When I first saw this extra XML file within the ZIP it confused me slightly. For the record, the zip file contains additional data that will be imported, e.g. things like meta-data, drop-down entries etc...
Within InRiver, the names of the properties being imported were contained within the MetaField element in a Name property. The type can be found within the Type file. If you don't have a corresponding property defined on the commerce item that you are importing onto, when the import runs, any types defined will be imported as hidden fields. If you notice missing data within your C# code after importing, you can try the method below to double-check that the property exists. To access a 'hidden' properties can be done using this code:
As you can see, importing a file into commerce is simple. In my experience, the hard part is making sure all the data imports, as you want it to, is the hard part. If an import takes 10 minutes and you miss a property, making a code tweak, re-running the import and testing can take about 20 minutes. It is very easy to lose half a day over a few missing bits of data 😢😢
I think I'd still recommend manually writing the code to map your import file into a commerce specific form, as in the long run, it will be easier to maintain and debug. If your import does dodgy things and all the code is within internal Episerver assemblies, it's harder to figure out exactly what's going on. Happy Coding 🤘
