1

我需要实现自定义 .NET 应用程序与 Documentum 5.3 的集成。.NET 应用程序应提供在配置的 Documentum 5.3 中管理文件夹、文档、元数据和搜索的功能。

我发现 Documentum 5.3 中提供了以下集成选项：

  • Documentum ADO.NET 服务
  • Documentum 基础类（包括 PIA 和 Web 服务支持）
  • WDK

我猜对于 .NET 应用程序而言，更可取的变体是 DFC PIA。但在这里 - http://forums.contology.com/index.php?showtopic=23639 - 伙计们正在讨论 DFC PIA 已被弃用并且不会很快得到支持（我知道它对于 5.3 来说已经足够了 - 但我猜它'如果客户升级其 Documentum，则需要覆盖集成部分）。

至于 ADO.NET 服务和“用于访问业务对象的 Web 服务框架”——您能否向我提供更多信息——我能否使用这些选项执行上述任务（管理文件夹、文档、元数据、搜索）？我可以使用 ADO.NET 服务访问文档内容还是仅访问文档元数据？

最后一个问题是我错过了其他选择吗？您是否认为这里最好的选择是使用 DFC 在 Java 中编写自定义 Web 服务，然后将 .NET 应用程序与该 Web 服务集成？（类似于“用于访问业务对象的 Web 服务框架”的方法——但我不确定这个框架是否能提供我需要的所有能力）

4

2 回答 2

1

听起来您对 Web 服务没有特别的要求。我已经读过关于 DFC“最终”被弃用的相同内容，但它仍然存在并且在踢。

Documentum Foundation Services (DFS) 是每个人都应该使用的“新”公共 Web 服务 API，从 6.5 开始（实际上是 6.0，但他们做了很多更改）。它是基于 SOAP 的，其中一些功能也可通过 REST 获得。

基本上，DFS 是 DFC 之上的一层，所以实际上它是 DFC 无论如何都在运行。DFS 的优点是您不会被迫使用 Java 或 .Net，会话管理被简化，并且有一些操作更易于执行，但是如果您坚持使用 5.3，那么我认为没有理由不使用 DFC .

您仍然可以针对 6.5 或 6.6 存储库使用 DFC。谁知道EMC在7.0、8.0、9.0出来的时候会说什么，但我猜他们很难完全摆脱DFC。即使他们这样做了，如果他们等到碰巧从 5.3 迁移到您的客户将面临的升级挑战将比仅仅担心迁移到 DFS 更大。

仅供参考，两年前我将一个 5.3 DFC 应用程序转换为 DFS，从那时起我就一直愉快地使用 DFS。转换只是痛苦的，因为当时我对应用程序或 DFS 本​​身一无所知，但老实说，这比困难更乏味。

于 2011-06-24T13:50:12.747 回答
0

Wingspan 公司 (http://wingspan) 有一个 Documentum 集成服务器，它支持 5.3（以及其他一切都可以追溯到 4.2.x）。它被称为 DocWay 服务器，它有一个 Web 服务 API 和单独的内容传输工具。它在某些方面与 DFS 相似，但比它早了很多年，并且自 2002 年以来一直在发货。

我在那里工作，我确信在堆栈溢出时推销产品是不受欢迎的，所以我就把它留在那里。如果您想了解更多信息，请 PM 我或直接联系 Wingspan。

没有那个，我会按照你的建议去做，“使用 DFC 在 java 中编写一个自定义 Web 服务，然后将 .NET 应用程序与这个 Web 服务集成”

但是，如果您需要暴露很多 DFC，那将是一座难以攀登的山。您可以访问 Content Server 5.3 SP6 吗？我相信这包括更容易从 .NET 访问的 DFS。

于 2011-06-15T04:27:30.673 回答