文件网络内容引擎 - 物理路径的数据库表

Question

我意识到使用FileNET P8 API可以做到这一点，但是我正在寻找一种方法来找到数据库中的物理文档路径。具体来说，文件存储中有两级子文件夹，如FN01\FN13\DocumentID，但我在任何地方都找不到对FN01或FN13的引用。

Answer 1

IBM的答案只有从预期功能的技术角度来看才是正确的。

如果确实需要查找文档文件名和文件夹位置，请通过使文件存储文件夹对Content Engine不可用来禁用实际的文件存储。我只需将根FN#更改为FN#a，就可以对每个文件存储执行此操作。例如，FN3变成了FN3a。完成后，我将顶部的树文件夹更改回原来的文件夹。我使用了这种方法，这样日志文件就不会超过工具的最大输出。任何使存储位置（如驱动器、共享等）可访问和可搜索，但使单个文件不可用的方法都会导致相同的结果。

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

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

…需要颠倒字节，以便在Oracle中查询。在查询GUID时，GUID在Oracle和DB2（而不是MS SQL）中以字节反转的形式存储，其中前三个部分是成对反转的，最后两个部分是单独存储的。

因此，反之亦然。为了使用内容一致性检查器的输出将输出与数据库相匹配，必须经历相同的字节顺序反转。

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

• IBM 技术说明：https://www.ibm.com/support/pages/node/469173
• 堆栈答案：https://stackoverflow.com/a/53319983/1854328

有关存储机制的更多详细信息，请参阅此处：

• IBMTechnote：“如何转换FileNet Enterprise Manager中显示的唯一标识符，使其与Oracle和DB2数据库中存储的内容相匹配”

我不建议将其用于除灾难性需求以外的任何用途，例如重建和重写整个文件存储，当您的前任销毁NTFS（或其他类似恶劣情况）时，该存储被严重损坏。

这是一种绕过FileNet散列法的解决方法，该散列法用于从查看文件系统的用户那里删除内容信息。

Answer 2

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

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