【问题标题】:FileNet Content Engine - Database Table for Physical pathFileNet 内容引擎 - 物理路径的数据库表
【发布时间】:2015-08-10 15:30:31
【问题描述】:

我意识到这可以通过 FileNET P8 API 实现,但是我正在寻找一种方法来查找数据库中的物理文档路径。具体来说,FileStore 中有两个级别的子文件夹,例如 FN01\FN13\DocumentID,但我在任何地方都找不到对 FN01 或 FN13 的引用。

【问题讨论】:

    标签: filenet-p8 filenet-content-engine


    【解决方案1】:

    您不会在 FN 数据库中的任何位置找到文件夹的名称。文件夹结构由散列函数确定。以下是文件存储上this 页面的摘录:

    文档存储在叶级别的目录中,使用哈希算法在这些叶目录之间均匀分布文件。

    【讨论】:

    • 文件的物理名称确实包含数据库中文档的 ID。所以如果你真的想要这个,你必须手动“索引”你的文件存储。我必须这样做一次,我使用了一个创建目录结构的 xml 打印输出的程序。然后,我构建了一个处理文件的应用程序,并构建了一个包含文件 ID 和名称/位置的数据库。我知道这既麻烦又麻烦,但如果你真的需要这个,这是一种方法。
    • @RobertvdS 你知道吗,Filenet 如何“计算”特定文档 ID 存储在哪个文件夹中?
    • 我不知道 ce 是如何计算这个的,我创建了一个程序,它通过文件存储的实际文件进行爬网并将完整路径和 doc id 写入 db 表。
    【解决方案2】:

    仅从预期功能的技术角度来看,IBM 的答案是正确的。

    如果您确实需要查找文档文件名和文件夹位置,请通过使文件存储文件夹对 Content Engine 不可用来禁用您的实际文件存储。我通过简单地将根 FN# 更改为 FN#a 来为每个文件存储做到这一点。例如,FN3 变成了 FN3a。完成后,我将顶部树文件夹改回来。我使用了该方法,因此日志文件不会超过该工具的最大输出。任何使存储位置(例如:驱动器、共享等)可访问和可搜索但使单个文件不可用的方法都应该导致相同的结果。

    然后,运行内容引擎一致性检查器。它将为您提供所有文件、ID 和位置的完整列表。

    之后,您可以将条目与数据库表中的 OBJECT_ID 字段进行匹配。在非 MSSQL 数据库中,UUID 的前几个八位字节的字节顺序是相反的。您需要考虑这一点并修复字节顺序以匹配 CCC 输出。

    ...需要进行字节反转,以便可以在 Oracle 中查询。 查询 GUID 时,GUID 以字节反转形式存储在 Oracle 和 DB2(不是 MS SQL),其中前三个部分是成对的 颠倒了,最后两个就不管了。

    因此,反过来也是如此。为了使用 Content Consistency Checker 的输出将输出与数据库匹配,必须经过相同的字节顺序反转。

    有关详细信息,请参阅此 IBM 技术文档和下面链接的答案:

    有关存储机制的更多详细信息位于此处:

    我不建议将它用于任何灾难性需求,例如重建和重写整个文件存储,当您的前任破坏 NTFS 时(或一些类似的令人讨厌的情况),该文件存储被您的前任严重破坏。

    这是一种绕过 FileNet 散列的解决方法,该散列用于混淆查看文件系统的人的内容信息。

    【讨论】:

      猜你喜欢
      • 1970-01-01
      • 1970-01-01
      • 1970-01-01
      • 2013-06-03
      • 2022-01-10
      • 1970-01-01
      • 1970-01-01
      • 1970-01-01
      • 1970-01-01
      相关资源
      最近更新 更多