General XMetaL Discussion
wksim September 12, 2011 at 9:27 pm
XMetaL and Documentum checkout via DFSSeptember 12, 2011 at 9:27 pmParticipants 1Replies 2Last Activity 10 years, 11 months ago
I am having a very interesting issue with the XML documents that were checked out from Documentum becoming read only in XMetaL. Here are the steps that causes the issue:
1. Check out an XML document from Webtop
2. Edit in XMetaL – all good at this point.
3. Check out another document from DFS this time (any XML documents)
4. Reopen the first document that was checked out from Webtop
5. The document is now read only. When I try to edit the document, I get a popup window saying it is read-only. But the file itself it NOT read only. I can edit the XML file from other editors such as notepad, Oxygen, etc.
Question: How does XMetaL determines it is read only? I initially thought it looks at the dctm:obj_status attribute from the root element only, but it seems it is affected by other things – would like to know what it is so that I can find a workaround at least.
XMetaL Version: v6.0.
I spent three days on this, and I think I finally conclude this is true after many many testing, and I can replicate this issue by following the steps above every time now.wksim September 12, 2011 at 10:35 pm
Reply to: XMetaL and Documentum checkout via DFSSeptember 12, 2011 at 10:35 pm
I just figured out the issue after lots of debugging.
The issue arises when the registry.mode in the UCF client config is set to the file (Documentum.ini) instead of the registry. The default value in the client.config.xml file is set to use the file instead of registry for the Documentum (e.g. Webtop, DA) version 6.7 (at least).
The issue is that when it is using the file system for file information, Webtop/DA uses documentum (that is lower case “d”) for the paths, but DFS uses Documentum (upper case “D”). For example, [documentumcommonWorkingFiles 901e2480001026f]” is stored. And the Documentum.ini gets rebuilt each time an object is downloaded, checked out, checked in and cancel checked out. So either it is D or d through out the entire file.
And it seems XMetaL is looking for the information about the documents with lower case “d” (documentum) only, so it fails to get the information about the object from the file (Documentum.ini) if an object is checked out or downloaded via DFS.
It is not an issue if the registry is used to keep track the file information as Windows API for registry is done case-insensitive way.
It seems to be a bug in Documentum, but at least they are finding the information case-insensitive way, so Webtop/DA works fine with DFS. It will be nice XMetaL can do the same.Derek Read September 13, 2011 at 12:05 am
Reply to: XMetaL and Documentum checkout via DFSSeptember 13, 2011 at 12:05 am
It was assumed that clients will configure XMetaL Author Enterprise for Documentum Webtop to use either of the two supported methods for keeping track of checked out files (registry or file system in the registry.mode setting). It is really an either or option I think (I don't believe you can actually choose both). We do not test your scenario, where both methods are somehow in play and so were not aware of the issue. I will have our development team look into it though, just in case anything might be done. Perhaps you could explain your need in more detail so we can understand why you need to do this.
DFS is not currently supported at all at the moment, our product only supports Documentum Webtop. I think the name suggests that to some extent: “XMetaL Author Enterprise for Documentum Webtop”. Perhaps given enough demand (and depending on EMC's continued support for Webtop) we may consider creating something like “XMetaL Author Enterprise for Documentum DFS” in the future.
The scenario you suggest, where a file is checked out externally to XMetaL is not one that we encourage clients to use. If you wish to edit a document in XMetaL Author Enterprise then it would generally be best to use the interface provided in the product for checking that document out from Documentum. I believe if you do that you should not run into the scenario you describe here. If you wish to use other products in your workflow then it would be best to finish authoring in those products, save the file and check it back into the CMS using their means for interacting with Documentum and then use XMetaL's UI for checking that document back out of the CMS to continue authoring there.
Please also note that you may run into various other issues if you wish to use Documentum 6.7. We have not certified on that release yet. Currently supported versions include 6.5 SP1/SP2/SP3 and 6.6.
- You must be logged in to reply to this topic.