Blog

My Import for a UID! No, for ‘twas not so simple.  To understand this story we must begin a few versions ago when a tool now known as WebCenter Sites Developer Tools (WSDT) was introduced to finally allow I.T. teams to manage their WebCenter Sites Artifacts within a source code repository such as GIT, BitBucket or SVN.  These artifacts were not just code related, but also content related.  

In addition to enabling the creation of local environments for Developers to truly allow them to encapsulate their work, this tool also opened new avenues for content migration and allowed I.T. teams to deploy WebCenter Sites (WCS) projects using a structured build process independent of WCS team members.

As awesome as WSDT is, with any tool eventually you will run into a bump in the road.  I ran into such a bump that generated the following error in my sites.log upon importing assets:

java.lang.RuntimeException: com.fatwire.cs.core.realtime.DataException: IDMap did not contain uid for remote id Article:1235516892424. Incoming data appears corrupted

                at com.fatwire.realtime.idmapping.IdMapKeeper.getLocalIdFor(IdMapKeeper.java:165)

                at com.fatwire.rest.util.AssetHandler.getId(AssetHandler.java:1235)

                at com.fatwire.rest.util.AssetHandler._getData(AssetHandler.java:1076)

                at com.fatwire.rest.util.AssetHandler._setAttributeData(AssetHandler.java:935)

                at com.fatwire.rest.util.AssetHandler.getAssetData(AssetHandler.java:779)

                at com.fatwire.rest.util.AssetHandler.getAssetData(AssetHandler.java:671)

                at com.fatwire.rest.util.AssetJAXBDeserializer.getResourceData(AssetJAXBDeserializer.java:93)

                ... 97 more

Caused by: com.fatwire.cs.core.realtime.DataException: IDMap did not contain uid for remote id Article:1235516892424. Incoming data appears corrupted

                at com.fatwire.realtime.idmapping.IdMappingFacilitator.getLocalIdForRemoteId(IdMappingFacilitator.java:623)

                at com.fatwire.realtime.idmapping.IdMappingFacilitator.getLocalIdForRemoteId(IdMappingFacilitator.java:611)

                at com.fatwire.realtime.idmapping.IdMapKeeper.getLocalIdFor(IdMapKeeper.java:155)

                ... 103 more

The error indicated that I needed to check for a missing uid.  For those that may not know as of version 7.6 WebCenter Sites’ (formerly FatWire) assets have not one but two metadata Id fields to uniquely identify assets.  The original one is the id that represents the asset id and is used as the primary key for the asset table; the introduced Id is the fw_uid, which is used to uniquely identify an asset within a WSDT workspace.  When exporting and importing assets within two WebCenter Sites systems using WSDT the asset id may change, but the fw_uid will be maintained.  

Looking at the exported XML file for the asset in question I found that both the assetid and fw_uid were present in the file and also validated that the fw_uid was also unique for that asset.  However it should be noted that it is quite possible that this asset is being referenced by another asset and the import of that asset is the cause of the problem and not the asset that is displayed in the error.

When looking at the output generated by WSDT there are many entries for indicating an import is occurring, as WSDT will attempt to import dependencies of each asset while importing an asset.  Should the import of dependency fail, so would the import of the asset itself.  The statement “Importing DSKEY” indicates which asset (non dependency) is being imported.  Using this I found the last Importing DSKEY statement prior to the error to find which asset import was generating the error.

When reviewing the export file for the above-mentioned asset I found that the dependent asset was declared in one part of the XML file but missing in another part.  So when looking at a WSDT asset artifact file, there are two areas where asset dependencies are declared the first within the main asset bean definition (within the <assetbean> tag) and the other within the <dependencies> tag in the Metadata section (the giant comment) of the file. 

Within the main assetbean definition the dependencies are in separated by what mechanism was used to generate the dependency i.e. generated by an Attribute (of type asset), an Association, a Parent or a Dimension.  So the XML fragment generated will differ for each of the above for example for Attribute the fragment will look like:

<attribute>

        <name>FSIIImage</name>

        <data>

            <stringValue>Media_C:1114083738327</stringValue>

        </data>

    </attribute>

For a flex parent the fragment would be as follows:

<parent>

        <parentDefName>FSIIManufacturer</parentDefName>

        <asset>Product_P:1114083739026</asset>

    </parent>

However in the Metadata section all the dependency entries look the same and are in the form:

<dependency>

      <depType>E</depType>

      <resType>Product_P</resType>

      <resId>1114083739026</resId>

      <uid>37f550b1-66f1-4578-9a73-0bf81e2385f5</uid>

  </dependency>

In my case the XML file was missing the entry for the dependency in the Metadata section, this was the result of data corruption during WSDT export.  When dependent assets are declared in the Metadata section they are referenced by the uid of the resource.  WSDT uses the uid to find resources in the workspace, as the uid is unique.

To mitigate data corruption issues occurring when using WSDT to export and import your assets, I would suggest the following:

1. Check that all assets being exported have an fw_uid assigned.
2. Ensure that mandatory attributes are populated for assets being exported.
3. Validate that any asset type metadata such as categories and subtypes exist in the destination system.
4. If using dimensions ensure needed locales have been created on the target system. 

WSDT, like any great tool, is only as good as the data ts is given to work with.  Ensuring the sanctity of the data will result in a successful migration.