You are here:
Recovery and Rollback in B2C Commerce
Detect problems and recover from errors during import and export processes. This topic applies to B2C Commerce.
Detecting Job Problems
Use Business Manager to configure a job to send an email to the administrator if it runs for more than a specified period.
Sometimes, jobs experience problems and write log entries, but the problems don't stop the import. If these errors are significant, add processing to your import pipelines to detect and stop the import. It's generally a good practice to check import logs regularly to identify any problems.
Recovering from Job Problems
Release the job lock before running the job again. To release the lock, you stop and restart the instance. For more information, see the Control Center documentation.
Recovering from Network Issues
If a job dies because the instance went down, import the feed again. Because the standard import feature commits object by object, you never have a corrupted database.
If a job dies part way through an import, the database contains whatever data was successfully imported and any old data that wasn’t changed or removed. An incomplete catalog import causes the search indexes to be out of sync with the catalog, so the search feature doesn't work as expected.
Recovering from Data Errors
If there appears to be something wrong with the feed data use one of the following methods:
| Recovery Method | Description |
|---|---|
| Replicate data from another instance | This method is most useful if there’s a problem with importing onto production and staging has correct data, you can roll back to. |
| Import a new feed produced by the backend system. | This method is the most common method for recovery. Usually, fix the data in the backend system and generate a new feed. |
| Use data from import feed archives | This method is most useful if there’s a problem with backend system producing the feed. For this data to be available, set up a system for archiving feeds and cleaning up old archived feeds. |
| Use data from regular exports | This method is most useful for data determined on the production system, such as availability or data that you import directly onto production, such as price books. For this data to be available, create a job that exports the required data. It's also useful for data that only exists in the Business Manager, not the backend system, such as web-specific attributes or URL attributes. |
Customizing Production Instance Feed Rollback
On a production instance, data replication transfers most data to the instance from staging. However, data that you import frequently, such as inventory data or price data, is sometimes imported directly into production. As with staging, if a job is interrupted for any reason, you can have an incomplete import data and previously existing data in the catalog. For example, an incomplete inventory import can let items be sold that are no longer available.
To make sure you import a full feed or nothing, create a custom pipeline. This pipeline encapsulates the objects for import in a single transaction and commits them at once. However, this approach isn't needed or recommended, as it can be difficult to code and debug correctly.
The size constraints for the commit limit any custom pipeline you create. You can't commit more than 1,000 objects at once. A transaction in B2C Commerce can't modify more than 1,000 objects at once. Also, if you’re modifying all of these objects and someone modifies one of them manually, the commit can fail. If you have more objects in a single commit, the commit is more likely to fail.
