Installation of Hotfix, EBF or One-Off-EBF (=Patch) on Server

Generally this is an easy process. Please consider the following steps in order to migrate your PIM to a newer version.

• Consider pre-migration checklists

• Before applying an Hotfix or Major update, you have to update the Control Center itself. See chapter "Control Center Migration" of this Migration guide.

• Login into the Control Center

• Navigate to the installation tab

• With the upload functionality, upload all packages you want to deploy. Do not rename or extract any of the packages that are delivered.

• If you want to deploy also accelerator plugins or custom plugins, you can also upload them. Custom plugins have to be uploaded separately as jar file.

• Please note that all uploaded files will be deployed and overwrite the existing files. But all files will be backuped in a folder, so you can revert them if something went wrong.

• By clicking the upload button, the update process will start and all configured servers will be updated. All configuration files on all servers will be also replaced with the ones that are located in the Control Center.

• Execute steps in chapter "Product 360 Core Database Migration" by running setup to your existing database connection in order to update existing database.

Generally, you should run your custom JUnit tests in order to ensure that your custom functionality is still working.

Installation of Hotfix, EBF or One-Off-EBF (=Patch) on Desktop

• Before updating the Desktop you should execute the migration of the Server first.

• For Hotfix or Major updates:

  • Remove content of PIM Desktop Installation Folder and unzip the content of the new release package

  • Update the configuration files if you have any customizings here. Instead of copying the whole file, rather copy only your changes, since there might be some new settings which then will be overwritten.

• For EBF's and One-Off-EBF's (=patches):

  • Remove the existing plugins with old revision and then place the plugin with new revision which are part of the EBF resp. One-Off-EBF.

Structure Migration

First of all, please read the following knowledge base article, in order to understand the impacts of the new structure paradigm: Structure Types

The Structure Migration Tool is part of the standard Product 360 8.0 Installation, so you do not have to install anything seperately. With the Structure Migration Tool you can migrate structures to maintenance structures. Therefor this tool first of all validates the given structures in means of the new structure paradigm. The validation (and also correction of invalid items) works the same as the Structure Migration Preperation Tool (see Product 360 Server and Desktop Pre-Migration Checklist). If the structures are valid they are migrated to maintenance structures.

The following permissions are needed, when using the Structure Migration Tool:

• Interface visibility "Structure systems"

• For validation of structures:

  • Action right "Create item/variant/product assortments" (depending on which data types are used in the Product 360 system)

  • Action right "Delete item/variant/product assortments" (depending on which data types are used in the Product 360 system)

• For migration of structures:

  • Action right "Edit structure systems"

  • Action right "Close versions" (only when using versioning)

XML parsing exception while loading export templates or other data graph objects

If you experience unexpected errors during the serialization or deserialization of data graphs after an upgrade or change of your local environment, the following hints might be helpful.

In the past we had problems with the SDK deployment mechanism, specifically with the target platform refreshing. When you define the target platform in the SDK by using the update-site, eclipse is copying all bundles of the update site to an internal cache directory.

Now, when you switch to a different target platform release, eclipse is updating it's internal cache only in case the bundles have changed. The fact that a bundle has changed is determined by the bundle name and the version inkl. build identifier suffix of the version. If none of these changed, the bundle is not refreshed in the internal cache which leads to ClassNotFoundException as soon as someone wants to access a new class of that bundle.

In most of our cases there is no issue with this since nearly all bundles have a build identifier which changes with every build.

Most of them, but not all. The com.heiler.ppm.xml bundle has no build identifier. This bundle contains the XML parser implementations which must be used with Product 360 - those parsers are also used within the Java SDK since we're using the so called "endorsed-directory" mechanism. During launch (either by cmd, by service or by launch config of the SDK) we provide the full path to the com.heiler.ppm.xml/endorsed directory to java.

So, in case the directory is not there, or the path is not correct in the launch scenarios, the default XML parser will be used which does currently not work with the used XML serialization of the EMF based data graph objects.

Strange XML parsing exceptions are the symptoms of this problem.

With Product 360 version 7.0.04 we increased the version number of the com.heiler.ppm.xml bundle from 5 to 6. So you need to make sure you also update all configuration files (incl. wrapper.conf) as well as your launch configs - unless you will also experience those exceptions.

A typical stacktrace of such exception can look like this:

Entity IDs for ArticleLangType and ArticleExtensionType repository custom entities

With Product 360 7.1.04.00 a new data base column "EntityID" has been introduced for data base tables "ArticleLang" and "ArticleExtension". The content of this column has to be the same as in the corresponding repository logical key for custom entities based on "ArticleLangType" and "ArticleExtensionType" repository entity types.

The "ArticleExtensionType" based standard repository entities cannot be migrated automatically because it's not possible to determine the entity of the data base entries. Those entities got a valid Entity ID but use "0" as corresponding logical key value.

Server Jobs

With version 8.0.5 the preference for defining the number of threads for server jobs in the quartz.properties has become obsolete.

If changes have been made to this preference, the number should be set to the new default, which is 3.

org.quartz.threadPool.threadCount=3

The maximum number of running jobs can now be configured in the plugin_customization.ini with the preference:

com.heiler.ppm.job.server/maxRunningServerJobs = 40

Data Quality

Import mappings

By introducing subentity deletion on import new checks were put in place in order to ensure import results are correct and consistent.

This requires existing import mappings to be validated again manually, because the error tolerance is slimmer than before.

Migration of Subentity Deletion customizing

For customers with an existing customization for the "Subentity deletion on import" feature it is required to remove the customization from their Product 360 System and migrate the Subentity Deletion Configuration to this new standard feature, via the Import Perspective in the Product 360 Desktop Client. For more details, see subchapter "Subentity deletion on import" in the Knowledge Base chapter of the Technical Documentation.

Media Manager Integration