深入介绍 CRM 附件存储的底层实现机制

内容管理 (Content Management，简称 CM)模块在基础版本 6.10 中引入并在 CRM 3.0 中实施。

在使用CM之前，CRM应用程序使用业务文档服务（BDS）或通用对象服务（GOS）来实现文档管理需求。BDS 用于大多数应用程序，例如业务合作伙伴、产品、产品目录、解决方案数据库、活动。 GOS 仅用于活动和机会等单序对象。所有 BDS 应用程序在 3.0 中都更改为 CM，仅在 3.1 中更改为 One Order 对象。

CM 中的文档由多个对象组成。 最重要的两个是所谓的“逻辑信息对象”（LOIO）和“物理信息对象”（PHIO）。 LOIO 作为将 PHIO 组合在一起的逻辑概念上的容器，而 PHIO 表示文档特定版本的内容。

我们可以通过现实世界中的 Word 文档编辑为例来理解 LOIO 和 PHIO 的概念区别和联系。

如果一个人处理 Word 文档并随着时间的推移更改该文档，则每个保存的版本都将由 PHIO 表示。而 LOIO 将是 Word 文档本身。

这很像在 ABAP 中查看 SE38：程序名称是 LOIO，每个传输的代码版本是 PHIO。

让我们看一个例子。 我有一个 CRM 附件产品 ZCM_DEMO，guid 0090FA0D8DC21ED395FD7C687F99BFF7，BOR 类型 = BUS1178。

我为其创建一个附件：

然后我们去查询数据库表 SKWG_BREL，输入产品 guid 0090FA0D8DC21ED395FD7C687F99BFF7，我们看到属于该产品的两个条目。 第一个条目指示一个文件夹实例，它实际上是一个逻辑容器，用于保存给定产品的所有附件。

上图INSTID_B 列的内容的命名约定为 <类型：F（旧）或 L（逻辑对象）><逻辑对象类型名称><guid>。

第一行中的 guid 可以在表 CRM_FOLDER 中找到：

第二行中的 guid 0090FA0D8DC21ED395FD830F8DD9DFFF 可以在表 BDSLOIO22 中找到，以及附件名称。

有朋友觉得好奇，我是如何知道表 BDSLOIO22 的名称？

其实如果一个应用程序想要使用CM来存储文档，那么它应该有其专用的物理对象和逻辑对象类，或者使用默认的CRM_L_DOC。 应用程序与其类之间的关系在 tcode DMWB 中维护：

在表BDSPHIO22中，通过指定逻辑信息对象ID，我们可以获得所有物理对象列表。

一旦获得物理对象 ID 0090FA0D8DC21ED395FD830F8DD9FFFF，我们就可以在表 BDSCONT22 中找到相应的条目。

附件的真实内容以集群方式存储，因此在SE16中无法看到其详细信息。