生成意外查询的业务对象答案

【问题标题】：Business Objects Generating Unexpected Query生成意外查询的业务对象
【发布时间】：2014-07-10 08:27:43
【问题描述】：

我对 BusinessObject Universum 及其生成查询并因此产生结果的方式有疑问。这是背景：正在运行的机制已经实施。我试图复制 SAME 机制只是为了提供不同的字段。这是数据模型：http://tinypic.com/r/ng524g/8 起作用的机构用蓝色标记。我尝试实现但不起作用的机制用红色标记。

在业务层上，我定义了一个具有聚合感知功能的维度。此函数获取第一个 VWF_Party_Collection_A.Collectionstatus_CD 列（在更高级别）。如果用户从合同级别选择属性，则函数采用 VWF_Contract_Collection_A.Collectionstatus_CD 列。

问题是当我从 VWD_Kunde_A 表中获取所有属性并使用提到的聚合感知函数（即 Collectionstatus_CD）添加维度时，从 BO 端构造的查询没有任何意义。这里是：

SELECT
D_ATA_MV_FinanceTreasury.VWF_Party_Collection_A.Collectionstatus_CD,
D_ATA_MV_FinanceTreasury.VWD_Kunde_A.Namespace_TXT,
D_ATA_MV_FinanceTreasury.VWD_Kunde_A.Party_KEY,
D_ATA_MV_FinanceTreasury.VWD_Kunde_A.Legacy_ID
FROM
D_ATA_MV_FinanceTreasury.VWD_Party_A 
  LEFT JOIN D_ATA_MV_FinanceTreasury.VWF_Party_Collection_A
ON D_ATA_MV_FinanceTreasury.VWD_Party_A.Party_KEY=D_ATA_MV_FinanceTreasury.VWF_Party_Collection_A.Party_KEY,
D_ATA_MV_FinanceTreasury.VWD_Kunde_A
WHERE
  (
D_ATA_MV_FinanceTreasury.VWD_Party_A.Party_KEY=D_ATA_MV_FinanceTreasury.VWD_Kunde_A.Party_KEY  )
AND  
D_ATA_MV_FinanceTreasury.VWD_Kunde_A.Legacy_ID  =  102241978

请注意“FROM”部分的奇怪结构（已添加逗号）。 'WHERE' 部分是另一个奇怪且出乎意料的结构：

  ( D_ATA_MV_FinanceTreasury.VWD_Party_A.Party_KEY=D_ATA_MV_FinanceTreasury.VWD_Kunde_A.Party_KEY  )

正在运行的机制是将 VWD_Kunde_A 与 VWF_Contract_Collection_A 表连接起来并产生正确的结果。

现在，我尝试定义一个没有提到的仅包含 VWF_Contract_Collection_A.Collectionstatus_CD 属性的聚合感知函数的维度。当我运行相同的查询时，BO 会产生正确的结果并生成正确的（预期的）查询。

这是我期待的查询：

SELECT
D_ATA_MV_FinanceTreasury.VWF_Contract_Collection_A.Collectionstatus_CD,
D_ATA_MV_FinanceTreasury.VWD_Kunde_A.Namespace_TXT,
D_ATA_MV_FinanceTreasury.VWD_Kunde_A.Party_KEY,
D_ATA_MV_FinanceTreasury.VWD_Kunde_A.Legacy_ID
FROM
D_ATA_MV_FinanceTreasury.VWD_Kunde_A LEFT JOIN D_ATA_MV_FinanceTreasury.VWF_Contract_Collection_A ON D_ATA_MV_FinanceTreasury.VWD_Kunde_A.Namespace_TXT = D_ATA_MV_FinanceTreasury.VWF_Contract_Collection_A.Namespace_TXT  AND  D_ATA_MV_FinanceTreasury.VWD_Kunde_A.Party_KEY = D_ATA_MV_FinanceTreasury.VWF_Contract_Collection_A.Party_KEY  AND  D_ATA_MV_FinanceTreasury.VWD_Kunde_A.Legacy_ID = D_ATA_MV_FinanceTreasury.VWF_Contract_Collection_A.Legacy_ID
WHERE
  D_ATA_MV_FinanceTreasury.VWD_Kunde_A.Legacy_ID  =  102241978

此外，我怀疑它可能与上下文有关。但是，我没有找到任何已经运行并且我试图复制的机制的上下文。因此，我没有为我要实现的机制实现任何上下文。

此时我一无所知，因为我尝试了我所知道的一切。我将不胜感激。

谢谢！ A.

更新：似乎聚合感知功能不起作用......这是它的定义方式：

@Aggregate_Aware(D_ATA_MV_FinanceTreasury.VWF_Party_Collection_A.Collectionstatus_CD,D_ATA_MV_FinanceTreasury.VWF_Contract_Collection_A.Collectionstatus_CD)

（我刚刚从 Kreditklasse 复制代码并对其进行了修改...这让我更加困惑...）

UPDATE_2：在我的情况下，似乎聚合感知不起作用，因为我从 contract_context 中选择了所有属性，它仍然跳转到派对上下文。非常困惑，因为当我选择 Kreditklasse 时，相同的机制按预期运行......

【问题讨论】：

聚合感知需要上下文。仔细检查已经存在的内容。您可能还需要配置聚合导航。
我想到了那个乔。整个故事中令人困惑的是，一切都在 Kreditklasse 中正常运行。另外，我确实检查了上下文 - 对于 Kreditklasse 没有定义上下文。我还检查了“聚合导航” - 没有为 Kreditklasse 定义任何内容......我一遍又一遍地查看它，但找不到任何合理的解释。你还有什么想法吗？
我还必须补充一点，从我的角度来看，“VWF_Contract_Kreditklasse_A”和“VWF_Contract_Collection_A”表看起来不像真正的 FACT 表，因为您可以看到它们都从“VWD_Kunde_A”表，只需分别添加 Kreditklasse_CD 和 Collectionstatus_CD 属性。这就是为什么我不确定是否必须定义任何上下文（毕竟，Kreditklasse_CD 的一切都按预期工作......）
实际上，聚合感知不需要上下文（尽管它们经常一起使用）。但是，它确实需要聚合导航。

标签： business-objects

【解决方案1】：

检查聚合导航。

设置聚合感知需要两个步骤（当然，除了正确定义表之间的连接）：

使用 Aggregate_Aware 函数定义对象
通过操作设置表对象不兼容性 > 设置聚合导航。

听起来第二部分没有正确配置：确保需要第二个表的任何对象都标记为与第一个不兼容。

【讨论】：