• 1 reply
  • Latest Post - ‏2011-04-20T19:11:05Z by TigerTrix
1 Post

Pinned topic mapping problems when publishing Domino -> CM8

‏2011-03-29T16:08:18Z |
Hi all,

I am trying to publish from Quickr Domino to CM8 and get the following error

Publishing this document failed.Please contact your System Administrator.(QL069: Property sheet \'null\' is not supported by document type \'UlfEcm\'. The application submitted an undefined property sheet with label \'null\', title \'null\', and type ID \'QuickrArchiveMetadata\' for the document named \'What to do Immediately (2).docx\' with ID 1028_ v0. You cannot add property sheets to individual documents that are not defined in the document type. The list of valid property sheet types defined for document type \'UlfEcm\' include: [1] clbNonGroup: Individual Properties (UlfEcm/clbNonGroup))

This is my mapping

  • <mappingInfo docType="UlfEcm">
<mapping field="c_Title" property="Title" propertySheetType="Individual Properties" />
<mapping field="c_Author" property="Author" propertySheetType="Individual Properties" />
<mapping field="c_ZIPcode" property="ZIPcode" propertySheetType="Individual Properties" />

All fields are defined both in the Quickr form and CM itemtype!
I did first try with the Title filed not mapped but got the same error on the title field. Noticed that the error msg writes title with no starting capital. Is this significant? Looked at some sample that said "Indidvidual Properties" was the right propertySheetType to use for non grouped attributes in CM.

All help and suggestions are appreciated

Your Desperate

Updated on 2011-04-20T19:11:05Z at 2011-04-20T19:11:05Z by TigerTrix
  • TigerTrix
    18 Posts

    Re: mapping problems when publishing Domino -&gt; CM8

    First, a few side notes...

    "Individual Properties" is a display name, like a title, not a programmatic key name or ID. I am a little surprised that you would need to use "Individual Properties". I would have expected the short name such as "clbNonGroup". What I can say is to follow the actual documentation in the IBM Content Manager Services for Lotus Quickr information center which has a specific example mapping topic. The doc does say "Individual Properties". You might find that both work. It will try mapping my any possible match, and it should prefer the programmtic IDs, but will attempt to match by display name as a last resort. This particular virtual group, clbNonGroup (displays as "Individual Properties") does not have a translatable title. But actual attribute groups will have display names that the administrator controls. Also see related: Document publishing from Quickr Domino, Document type mapping Quickr to CM8, Publish mapping examples for Domino, Publish mapping examples for Portal.

    Next, regarding the actual names used, again, it will attempt a best effort to find a match for anything you enter. It prefers the non-translated key names first or IDs equally, then will rely on attempts to map by title. The ECM Serices system will check the prop sheet in the following order (but is always subject to change) -- ID, label (key name), display title. It needs only to match any one value to equate identify it. It shaves off some cpu cycles if it can use the most ideal values that are a best match for a programmatic comparison. But it really shouldn't be noticeable. Although the ECM Services might prefer ID-based & key-name based values, it still has to work with the Quickr application which will match those values up against the type definitions that identify IDs, names, and titles. You might need to enter certain values so that the application correctly matches a value as well. So this could influence why you might need to follow the example documentation using a display name.

    But the Individual Properties doesn't seem to be your problem. Your actual error indicates a problem with QuickrArchiveMetadata, which is an auto-generated property sheet by the Quickr application when it publishes (moves or copies) content from the Quickr Domino repository to CM8. The ID is "QuickrArchiveMetadata", and came in with label (key name) and title being NULL. It only needs one valid value to equate a match in the ECM Services, and the ID is "QuickrArchiveMetadata", which could be enough as long as that value is right. QuickrArchiveMetadata is a special case property sheet, unlike other property sheets, it doesn't need to exist in all document types. If not supported by a particular document type, the sheet is simply ignored instead of an error. However, it relies on very specific clues to consider ignoring the sheet when your document type doesn't have this optional extended property sheet. I believe it relies on 2 clues from the application -- (1) isExtracted=true, (2) ID QuickrArchiveMetadata. But I haven't verified the exact ID or label that it is expecting, but it sounds reasonable as is. My guess is the application is passing isExtracted=false. Only "extracted" property sheets are considered auto-generated and can be ignored if not supported by the particular document type. I suspect an application error in the Quickr application to correctly identify the property sheet as "extracted". You can verify what is sent by using a TCP/IP monitor, such as Fiddler, and looking into the XML of what is submitted from the Quickr application to IBM Content Manager Services for Lotus Quickr.

    It could be considered a bug in either the application that isn't identifying it correctly as per agreement in protocol with the ECM Services, or else the ECM Services server can look into additional considerations for the special property sheet that isn't following the previously expected protocol to add more support to detect that sheet by other means. But there could be other factors or clues involved than just this because there are differences in how Quickr for Portal and for Domino vary in this protocol and each are uniquely detected to minimize ignoring of this property sheet to only the exact single case that this is optional.

    You can probably work around the issue by using the DocumentTypeEnable tool and adding the QuickrArchiveMetadata extension group to your ECM doc type.