你好，SCN社区，

正如我在第一篇博客"大数据场景中的BRFplus"中提到的，我想分享一些与处理大量数据相关的其他话题。比我预期的要快，我解决了一个关于操作分析对话框的问题。这是关于我上一篇博客的主题3：

"探索性搜索技术，以确定发票中的异常-我们如何在最终用户的日常工作中支持他们？"？我们可以使用ALV网格来分析具有主-细节关系的数据模型吗？"

我们从前面讨论的商业案例开始：处理发送给法定健康保险公司的大量发票。

每次收到新发票时，都会处理一组支票。每项检查都集中在发票的一个特定方面或星座上，从而产生最终用户必须分析的澄清案例。但这些检查是由于一个特定的概念或方面而发展起来的。因此，他们的目标是这些发票中最常见的已知异常。其他以前没有考虑过的星座呢？

这个问题的一个解决方案可能是一个对话框，用户可以在其中进行某种预分析，以寻找新的模式来识别异常、错误，甚至检测这些发票中可能的欺诈案例。

这个任务听起来很简单。你拿着发票去看，然后把它们放到一个ALV网格里。因此，您可以使用ALV网格的所有过滤器和排序条件。您还可以将"查询"保存为用户特定的布局以供重用。

在这一点上，我们需要提出一些重要的方面：

在本例中，我们讨论的是一个通用的解决方案。有了这个工具，用户就可以对我们场景中的账单错误进行探索性搜索，而无需进入业务仓库。

事实上，我们无法基于HANA特定的功能，我们只能选择一个具有标准ALV网格的解决方案。我们把对话框的屏幕分成两部分。主视图有一个ALV网格用于显示发票，详细视图包含三个ALV网格，对应于三种支持文档。

如果双击发票，所有明细数据都加载到相应的ALV网格中。

我们决定不将所有发票加载到ALV网格中，以避免主视图过载。在探索性搜索过程中，您对每一张发票都不感兴趣。相反，你必须找到另一个过滤器，大数据好不好，以减少搜索结果-给你的兴趣边界。现在，人工智能的技术有哪些，我们讨论的是数据的提取（在屏幕截图中称为"Ausschnitt"）和底层表的整个数据（称为"Gesamtdaten"）。提取的大小由用户定义。根据提取的大小，用户决定需要显示多少发票，从而将其传输到前端。定义最大数据量是一个约束。为了获得这种截短，我们在ALV网格中添加了一个新按钮。

"Sätze"代表定义了一种截短的行或发票。ALV网格的给定筛选和排序标准在网格的内部数据表上运行–因此它只处理提取，云服务器报价，但运行非常快。

如果我们想有效地减少搜索结果，筛选和排序标准将在整个基础数据表上运行。因此，我们在网格中添加了一些其他功能来控制ALV过滤和排序操作。

借助这些新功能，我们能够在大量数据中搜索各种事实。如果要显示的数据量太大，由于截断，我们只能看到冰山一角。

按细节数据搜索是一个更大的问题。ALV过滤器只在它自己的数据上下文上运行。但细节数据在额外的ALV网格中分离。因此，我们构建了一个带有附加过滤条件的弹出窗口，用于处理我们必须处理的医疗文档的键。

详细过滤器的约束由主视图的管理器类处理。这种约束定义为单个选择选项。此管理器类基于这些约束构建SQL查询。我们将主-细节关系的所有组合构建为每个细节关系的EXISTS子句。我们计算了8个有效组合（猜测2^3），因此SQL查询可以在manager类中硬编码。

另一个问题是在主视图中保存ALV布局时处理细节过滤器。如果用户定义了详细信息过滤器，大数据如何分析，则必须将其与常规布局一起保存。我们通过在ALV布局的同一个键下创建一个包含细节过滤器的附加表来解决这个问题。为此，我们在ALV布局按钮的事件处理中添加了一些功能。当用户加载一个布局时，细节过滤器也被加载，因此原始的搜索结果被复制。

通过对ALV网格的这些扩展，我们实现了标准ABAP编码的主-细节关系，允许用户在整个数据卷中进行探索性搜索。

通过这个解决方案，我们没有走到最后。由于使用Select选项来定义细节过滤器，我们无法进行所有类型的过滤。我们建议跟踪除C或D之外的所有包含医疗A和B的发票。通过选择选项，我们只能选择通过或不通过和。

此外，我们希望将这样一个保存的布局（带细节过滤器）转换为客户定义的检查功能，当新发票到达时，该功能正在处理。在这种情况下，我们面临着一个重大的ABAP限制：

8硬编码存在条款不再符合新的要求。所以我们必须处理一个动态WHERE子句，它目前不支持子查询。我们遇到了死胡同。