Catalog Import and Export: Concepts

What Can Be Imported or Exported?

The following entities can be imported or exported:

Static Content

Static content includes, but is not restricted to, product images, data sheets, and user manuals. These files can be referenced, for example, when defining images or attachments for a product. It is possible to create a directory structure to store and manage uploaded content. Note that the content of zip files is automatically extracted and stored in the designated directory.
Product Data

Product data can be imported into the master or the channel repositories. The data is imported in ASCII format (csv files using the semicolon as separator) or XML format. Product data can be exported in XML format.
Catalog Categories

Catalog categories can be imported for master and channel catalogs. Catalogs are imported using data sources in ASCII format (csv files using the semicolon as separator) or XML files. To import a category structure, you must first create a root category as target for imported catalog categories. Categories are exported into XML files.
Classification Categories

Classification categories can be imported from and exported to XML files.
BMEcat Data

Product and category data in BMEcat format can be imported from and exported to XML files.
Variation Types

Data defining variation types can be imported from CSV and XML files and can be exported into XML files.

Standard Import Modes

The standard import modes listed below apply to all import processes in Intershop Commerce Management. That is, they are valid for catalog and product data, promotion data, content assets, etc., if not specified otherwise.

Table 1. Standard Import Modes
Mode	Description
OMIT	Import is simulated, changes are not written to the database. Can be used for testing purposes.
IGNORE	Ignores all objects that already exist in the database, creates records only for new objects and adds them to the database. For example, if a product is specified in the import source and the product is found in the database by the import/export service, it is not modified.
UPDATE	Updates existing objects and creates records for new objects. Attributes and objects that do not exist in the import file are kept untouched.
REPLACE	Replaces existing objects (UUID is kept) and creates records for new objects. Objects that do not exist in the import file are kept untouched. Missing attributes of existing objects (in the import file) will be removed.
DELETE	Deletes all import file records that exist in the database.
INITIAL	Does not perform a database query to find existing objects. This allows for a quick import but causes an error whenever an object is imported that already exists. This mode is generally used during the DBInit process.

Object Locking

Concurrent mass data operations and individually triggered "single-object" operations may produce inconsistent data. Intershop Commerce Management features a specific object-locking mechanism to prevent concurrent modifications of the same data. In case a user intends to edit an object that is already locked by another process, Intershop Commerce Management shows a warning and, depending on the operation, provides options to either:

Unlock it, which gives priority to the "calling" process and allows it to be executed,
Wait a specified time and then fail, where the "calling" process waits the defined time for the previous lock to be released in order to run afterwards, or fails if the timeout is reached.
Fail, where the "calling" process is terminated immediately.

Product Identifiers

For successful import of product, catalog and other data, certain elements must be defined in the data source while others can be optional. When preparing the import data, always check the Intershop XSD schema files for optional and required elements. If necessary, contact your system administrator to obtain these files.

For product import, note that Intershop Commerce Management uses an extended product identifier system (PIDs), in addition to standard product SKUs. Intershop Commerce Management supports the following product identifier types:

Manufacturer ID

This product identifier is defined and maintained by the original manufacturer of a product. Since manufacturers are not hosted by Intershop Commerce Management, they do not manage these IDs within the Intershop Commerce Management database themselves. However, these identifiers are important whenever hosted suppliers or sellers need to interact with their manufacturers, for example to fulfill orders.
Supplier ID

This product identifier is defined and maintained by the supplier of a product. Suppliers usually aggregate products from different manufacturers and therefore need their own numbering schema to uniquely identify products from different manufacturers.
Seller ID

This product identifier is defined and maintained by the actual seller of a product. Seller IDs are defined relative to a product identifier scope. This makes it possible to assign multiple seller IDs in case the seller offers the product in multiple repositories.
Buyer ID

This product identifier is defined and maintained by a buying organization.

PIDs are defined as custom attributes. Each PID definition comprises two parts: one part to define the owner of the PID (buyer, seller, supplier, or manufacturer), the other part to define the actual value. A sample definition of a Supplier ID is shown below:


<custom-attribute dt:dt="string" name="PID_OWNER_SupplierID@global">IQ</
custom-attribute>
<custom-attribute dt:dt="string" name="PID_VALUE_SupplierID@global">D598
9C</custom-attribute>

In many cases, PID definitions are more complex. Consider the sample below. The sample defines three different PIDs (SellerID, SupplierID, ManufacturerID). Note that the Seller ID has a well-defined scope (the domain "inSPIRED-MasterRepository") to identify the repository relative to which the Seller ID has been defined.

<custom-attribute dt:dt="string" name="PID_OWNER_SellerID
                @inSPIRED-MasterRepository">inSPIRED</custom-attribute>
<custom-attribute dt:dt="string" name="PID_VALUE_SellerID
                @inSPIRED-MasterRepository">D5989C</custom-attribute>
<custom-attribute dt:dt="string" name="PID_OWNER_SupplierID@global">IQ</
custom-attribute>
<custom-attribute dt:dt="string" name="PID_VALUE_SupplierID@global">D598
9C</custom-attribute>
<custom-attribute dt:dt="string" name="PID_OWNER_ManufacturerID@global">
IQ</custom-attribute>
<custom-attribute dt:dt="string" name="PID_VALUE_ManufacturerID@global">
D5989C</custom-attribute>

When preparing products for import, take care of the following issues:

A product to be imported by a supplier must have at least a PID of type SupplierID.
A product to be imported by a selling or buying organization must have at least a PID of type SellerID or SupplierID. When defining a SellerID, a scope must be provided which references the domain behind the repository to which the SellerID belongs. Contact your system administrator to obtain the domain names to use.
Make sure the structure of the PID is correct. PIDs with incorrect structure are ignored during import. Moreover, the system ignores a PID definition with value "null" or no value at all.

Note: PIDs are validated automatically before import.

General Import/Export Workflow

The general approach for importing data into Intershop Commerce Management is as follows:

Upload the import data stored in a file from your local machine to the server.
Import the data from the file.

The export works the other way around:

Export the data to a file stored in Intershop Commerce Management.
Download the file to your local machine.

Tip: This procedure is identical for all data import/export processes, incl. catalog and product data, promotion data, content assets, etc., if not specified otherwise.