getContentStream filename versus getProperties filename (cmis name)

Hello,

We have encountered an issue where the filename returned by the getContentStream() operation comes back as "data" instead of the actual filename. The correct file name does get returned when using the getProperties() operation for the same cmis:objectId. It appears as though this filename issue is specifically around documents that are manually added to Content Server; documents added through CMIS integration do not have this issue.

Any reason why these filenames are not consistent?

Thank you,

Faraz

Find more posts tagged with

Comments

eLink User

Hi Faraz,

this can be explained by the way how Enterprise Library, Archive Server, Content Server and Content Archiving are integrated and the differences how Content Server and CMIS report filenames in download responses.

Does this behavior cause a problem in your project? Which behavior would you expect?

Best regards,

Andreas

From: eLink Entry: ELS General Forum [mailto:el_general_forum2@elinkkc.opentext.com]
Sent: Mittwoch, 18. April 2012 05:53
To: eLink Recipient
Subject: getContentStream filename versus getProperties filename (cmis name)

getContentStream filename versus getProperties filename (cmis name)

Posted byfaraz.i.abbasi@accenture.com (Abbasi, Faraz) On 04-17-2012 23:52

Hello,

Any reason why these filenames are not consistent?

Thank you,

Faraz

[To post a comment, use the normal reply function]
Forum:	ELS General Forum
Content Server:	Knowledge Center

Faraz_Abbasi

Hello, thanks for the quick response.

Yes, this behavior is causing an issue. We have a couple of processes which retrieve content from Content Server using the getContentStream() operation, one of which is a user process (downloading the document) and another which is a back-end process (downloading the document to send it to a printer).

When the user downloads it, these documents come back as "data", so the user doesn't know what filetype it is, so can't open the file. Similarly, the printer process sends it to the default application handler to print the file (e.g. a .doc file will print using MS Word, a .pdf file will print using Adobe Reader, etc..) but since it's just called "data", it doesn't work.

We also will be migrating a number of documents using OTIC, and I'm wondering whether we'll experience a similar issue there.

Thanks,

Faraz

Faraz_Abbasi

Just to add ... if necessary, we can change our process to get the filename using getProperties, and the actual data using getContentStream, but this will double the amount of web service calls we have in these processes, which would have an impact on performance.

eLink User

CMIS differentiates betweencmis:name (aka display name) andcmis:contentStreamFileName (aka filename).

When archiving through CMIS, thecmis:contentStreamFileName, which is given by the client application, is retained as filename inside Archive Server.

It can differ from thecmis:name, which is also given by the client.

Like in the following screenshot.

When archiving through Content Server, the filename is not retained inside Archive Server – as you’ve observed already.

When downloading the document via Content Server, however, the original filename is not used, but a new one generated based on the display name and mimetype, as you can see in the following screenshot.

Subject to further investigations, it might be possible to fix thedata issue when archiving via Content Server. Via CMIS it would then always use the original filename forcmis:contentStreamFileName (Winter.jpg in this case).

Please note, it could still happen, that this original filename differs from the current displayname (cmis:name) of the document (like above).

Please contact Customer Support to have this issue further addressed.

Andreas

From: eLink Entry: ELS General Forum [mailto:el_general_forum2@elinkkc.opentext.com]
Sent: Donnerstag, 19. April 2012 04:31
To: eLink Recipient
Subject: RE getContentStream filename versus getProperties filename (cmis name)

RE getContentStream filename versus getProperties filename (cmis name)

Posted byfaraz.i.abbasi@accenture.com (Abbasi, Faraz) On 04-18-2012 22:30

Hello, thanks for the quick response.

We also will be migrating a number of documents using OTIC, and I'm wondering whether we'll experience a similar issue there.

Thanks,

Faraz

Faraz_Abbasi

Thanks Andreas. We have a ticket open already on the issue. I have also confirmed that documents migrated via OTIC also come back as "data", which will be a problem for us as well.