CSDT can have a tendency to be "delicate", especially the 7.6 version. At Function1 we recently completed an upgrade from Fatwire 7.6 to WebCenter Sites 11g for a client, and we used quite a lot of CSDT to get the data migrated. Below are some of the lessons we learned along the way, which we bring to you in this blog as useful CSDT tips.
Tip #1: The "toSites" Catch
Say for example that you have exported Site1's assets to a datastore "Site1" using the "fromSites" parameter and supplying "Site1" as the value. That means of course that the datastore "Site1" contains assets strictly from Site1. When using that datastore to import into a new environment, try to leave out the "toSites" parameter as much as you can. This is because during import, most of the assets will naturally get imported into their proper site (in this case Site1), without having to use "toSites". Using "toSites" excessively can cause some data to be missing during import. However some asset-types may have dependencies on it's parent site, and in those cases the "toSites" parameter must be used. Most of the time, the logs will tell you if you need to apply the "toSites" parameter. However there are certain cases where all you will see is a NullPointerException stacktrace in the logs. If you happen to come across this, apply the "toSites" parameter and retry the import.
Tip #2: Special Characters
If there are special characters in the names of any assets, CSDT import will fail for those assets. And as we know, CSDT does not gracefully resume after failing, so for each asset that fails, we need to restart the entire import. In order to avoid this painstaking process, we recommend using the following SQL query to proactively find (even before exporting!) all assets that have special characters, and then manually fixing them within ContentServer. Making sure to do this before exporting ensures that the data is legitimate and will not fail on import due to special character issues. You can of course use the Database Query Tool within Support Tools to execute the SQL:
SELECT H.id, H.name, P.name
FROM [asset-type-table] H, AssetPublication AP, Publication P
WHERE H.id = AP.assetid
AND AP.pubid = P.id
AND P.id in (1285275196694)
AND NOT REGEXP_LIKE(H.name, '^[a-zA-Z0-9#()/$,&\\_ .-]+$')
ORDER BY P.name, H.id
However if you do find yourself in the unfortunate situation of dealing with special characters during CSDT import, it is still possible to fix those assets directly within the datastore. You must extract the fw_uids of the corrupt assets from the stacktrace in the logs, and then navigate the datastore to find those assets. Once you have found them within the datastore, you can rename them by removing any special characters. Please also make sure to remove all special characters from within the asset's actual CSDT file as well.
Tip #3: AssetPublication
It is possible during CSDT export that you will come across an error where an asset is not associated with any site, or techincally speaking, it is not in the AssetPublication table. Usually this is because of some sort of dependency between assets where CSDT mandates an entry in AssetPublication. Sometimes this type of error is easy to recognize because the stacktrace will explicitly contain the word "publication". However other times it may not. Regardless, when encountered with an error during export, one of the main steps is to manually enter the asset as a row into the AssetPublication table, and then retry the export. This can be done via SQL "INSERT" using the Database Query Tool within Support Tools. You can simply assign the asset to AdminSite.
Tip #4: Asset Parents/Groups
WebCenter Sites asset model allows for a parent-child hierarchy between assets. Depending on the asset model, it may be mandatory for an asset to have a parent asset, and CSDT will detect this requirement. However there are situations in which a mandatory parent is missing. This is a form of corruption that can resutl from, for example, changing a definition so that the parent is required, when before it was optional. Regardless of how it occurred, if CSDT encounters this, it will fail during import. Rather than having to fix the original asset within the system, re-export, and then re-import, there is a shortcut that removes the parent requirement from directly within the datastore. This can be accomplished by finding the XML Definition file of the asset, and then searching for "Groups". In that "Groups" segment, there will be a "<name>required</name>" entry, and within that, a "<stringValue>true</stringValue>" entry. Simply change that "true" to "false" and you will have effectively removed all parent requirements for that particular asset Definition. Then, you can resume CSDT import.
Hope this was helpful, and please feel free to search our blogs for more CSDT related articles. Good luck!
Function1, Inc. Copyright 2024. All Rights Reserved