I would like to draw your attention to a bug in the FileNet connector. The URL
(Id) that is created for each document includes the document class as the
object type. This is not the correct usage of that parameter. The object type
is actually a reference to the parent class of a particular object; document,
custom object, or folder. The current method technically works for any
documents in the Document class, but any that are configured to come from
sub-classes will generate an error when trying to follow the URL to FileNet to
retrieve the document.
It is pretty easy to programmatically get the parent class of a document class.
However, the primary use of MCF is to crawl documents and only document classes
are available in the class list. Therefore, it seems to me to be just as
reasonable to hard-code "Document" into the objectType URL parameter in the
convertToURI function. If this is reasonable to you, I have included the
function below. I have just started using it and it works for me.
Additionally, I would like to point out that FileNet Workplace has been
deprecated and will soon be sunset. I think it would be nice to be able to
select a URL (Id) builder in the job configuration. This could allow users to
select whether they will be serving up documents from Workplace, WorkplaceXT
(soon to be sunset as well) or Content Navigator (IBMs newest front-end to
Content Engine).
I would be happy to write these, provide information, or help in testing.
protected static String convertToURI(String urlBase, String
documentIdentifier, int elementNumber, String documentClass) { // Will this
work for sub-types of documents too? ask - MHL return urlBase + "&id=" +
documentIdentifier +
"&element="+Integer.toString(elementNumber)+"&objectType=Document"; }
