CODEWITHSUNDEEP
.netdocumentum
pchel
pchel

Reputation: 31

.NET and Documentum 5.3 Integration

I need to implement integration of a custom .NET application with Documentum 5.3. .NET application should provide functionality of managing folders, documents, metadata and search in configured Documentum 5.3.

I've found the following integration options are available in Documentum 5.3:

I guess for .NET application preferable variant is DFC PIA. But here - http://forums.contology.com/index.php?showtopic=23639 - guys are discussing that DFC PIA is deprecated and will not be supported soon (I understand that it is sufficient for 5.3 - but I guess it'll require to overwrite the integration part if customer upgrades its Documentum).

As for ADO.NET Services and "Web Services Framework for accessing Business Objects" - could you please provide more information to me - will I be able to perform tasks above (manage folders, documents, metadata, search) using these options? Could I access document content using ADO.NET Services or only document metadata?

The final question is are there any other options I missed? And do you think the best option here is writing custom web service in java using DFC and then integrate .NET application with this web service? (approach similar to "Web Services Framework for accessing Business Objects" - but I'm not sure if this framework could provide all the abilities I need)

Upvotes: 1

Views: 2061

Answers (2)

Brendan Hannemann
Brendan Hannemann

Reputation: 2154

It doesn't sound like you have a requirement for web services specifically. I've read the same stuff that you have about DFC getting deprecated "eventually" but it is still alive and kicking.

Documentum Foundation Services (DFS) is the "new" public web services API that everyone is supposed to use, starting with 6.5 (6.0 really, but they made a LOT of changes). It is SOAP-based with some of the functionality also available via REST.

Basically, DFS is a layer on top of DFC, so really it is DFC running anyway. The advantages of DFS are that you are not forced to use Java or .Net, session management is simplified, and that there are some operations that are simpler to perform, but if you are stuck with 5.3 then I see no reason not to use DFC.

You can still use DFC against a 6.5 or 6.6 repository. Who knows what EMC will say when 7.0, 8.0, 9.0 come out, but my guess is it will be difficult for them to completely get rid of the DFC. Even if they do, the upgrade challenges your client will face if they wait until that happens to move from 5.3 will be bigger than just worrying about moving to DFS.

Just FYI, I converted a 5.3 DFC application to DFS two years ago, and have been happily using DFS ever since. The conversion was only painful because I did not know anything about the application or DFS itself at the time, but honestly it was more tedious than difficult.

Upvotes: 1

Martin Snyder
Martin Snyder

Reputation: 528

The company Wingspan (http://wingspan) has an integration server for Documentum that supports 5.3 (and everything else going all the way back to 4.2.x). It's called the DocWay Server and it has a Web Service API and separate Content Transfer facility. It's similar in some ways to DFS, but predates it by many years and has been shipping since 2002.

I work there, and I'm sure pitching products is frowned upon on stack overflow, so I'll just leave it there. PM me or contact Wingspan directly if you want more information.

Absent that, I would do just what you suggested and "[write a] custom web service in java using DFC and then integrate .NET application with this web service"

If you need to expose a lot of the DFC though, that's a tough hill to climb. Do you have access to 5.3 SP6 of Content Server? I believe that includes DFS which is more accessible from .NET.

Upvotes: 0

Related Questions