花了一些时间，但我终于解决了这个问题。

首先，不，TREX是不是必需的。 这与问题无关，也与解决方案无关。 我已经更新了该线程的标题，以使其对于最终的结果更有意义。 同样，也不需要实现任何自定义BAdI。

最重要的是，应用程序（或者后端调用的OData服务）对表HRPY_RGDIR（工资结果目录）进行了调用。 不使用主键。 它通过类CL_HR_PAY_ACCESS，方法GET_PARTICIPATING_PERNRS来完成此操作。 具体的ABAP语句为：

 *从透明的工资单群集目录中读取
   SELECT DISTINCT pernr
     来自hrpy_rgdir" #EC CI_NOFIRST
     INTO wa_py_rgdir
     其中persdata = period-perdata
     AND人=期间人
     AND seqnr =周期-seqnr。
     将wa_py_rgdir附加到pernr_tab。
   ENDSELECT。

这将导致以下SQL代码（至少在SQL Server 2012上会这样）：

从HRPY_RGDIR中选择不同的PERNR，其中MANDT = @ P1和PERSDATA = @  P2和PERSON = @ P3和SEQNR = @ P4 

除HRPY_RGDIR上的唯一索引是主键外，其他所有都很好，它由MANDT，PERNR和SEQNR组成。 如所写，此选择必须扫描整个表以找到PERSDATA和PERSON的条件。

实际上，DBACOCKPIT内的分析揭示了使用大量数据库时间（大约占我沙箱中总时间的9％）的特定搜索。 系统），并且数据库引擎返回二级索引建议，表明可以获得高达99.96％的改进。 建议是：

• 相等谓词中的列= MANDT，SEQNR，PERSON，PERSDATA
• 包含的列= PERNR

只有一个复杂之处：SE11不直接支持创建索引 与"包含"列。 如何解决此问题？

注意事项 1775008 （索引的定义包括MSSQL Server的列），它实际上旨在在SQL Server上运行BW系统，但在这里仍然适用于我们。 详细信息：

1. 首先，在SE11中创建一个扩展索引（称为" Z01"），它是唯一的并且特定于数据库MSS。 在索引中按此顺序包括字段MANDT，SEQNR，PERSON和PERSDATA。 保存并激活。 在我的系统中，激活大约需要一分钟。
2. 然后从SA38运行RSMSS_ANALYZER。 选择索引处理标签。 选择表，刷新，然后选择新创建的索引，然后再次刷新。 在表格字段的右侧列中，选择PERNR，然后将其移到包含字段的左侧列中。 将其保留为非集群，选择在线创建，然后计划创建作业以在后台立即执行。 同样，在我的系统中，该工作需要75秒钟才能运行。

以这种方式创建此索引的结果是，现在我可以在不多的时间里拉近近15年的月薪 超过五秒钟，而之前大约一分钟会超时。 那是很大的不同！ 大概有99.96％的差异。

我感谢安迪·戈里斯（Andy Goris）的不懈努力来帮助解决问题 这个问题，以及SAP支持部门的开发人员，他们在经过长时间的等待之后，很快就指出创建二级索引是可能的解决方案（尽管他们由我自己来决定索引的字段） ；幸运的是，系统本身非常擅长于此。）

很高兴您发现了问题，并且很好地总结了该问题，如果其他人也有同样的看法 问题。

我将查看失败的 HCMFAB_MYPAYSTUBS_SRV/$ batch请求的详细信息。

您可以查看完成哪个实体集或调用的详细信息，并且可以在后端（如果到达那里）对其进行调试。 您还可以在后端和前端系统中检查错误日志。

糟糕，由于通知在这里工作的方式很奇怪，所以终于看到了。

无论如何，我们在EhP8上。

我确实在两种方法中都在BAdI中设置了一个调试断点，并且我确定只调用了PROVIDE_FILTERED_RGDIR。 尽管处于活动状态，但从未调用PROVIDE_FILTER_LIST。

但是，这不是问题。 如果调用此方法，将是 nice ，因为它是一些看起来不错的附加功能，但性能问题已通过二级索引解决。 我将在有问题的其他人的新答案中写下详细信息。

再次感谢您为解决此问题提供的所有帮助！

抱歉，回复延迟，安迪。 我没有从您的评论中收到通知（因为这是对您自己的答案的评论，但是无法对评论发表评论，因此我认为唯一的解决方案是在您的回复中"标记"我）， 所以我只是现在才看到它。

我不知道在URL中添加＆sap-ui-debug = true 的功能，所以谢谢。 我刚试过 它肯定会减慢速度，加载资源和组件的所有" dbg"版本！

因此，现在在F12工具的 Network 标签中，我看到404错误 对于 core-ext-light-dbg-dbg.js ，它发生得很早，很早就出现了超时消息，然后 $ batch？sap-client = 001 错误500 em>，即出现错误的时间（需要1.1分钟才能使该组件返回错误）。

在 Console 选项卡上的上方，我看不到有什么不同 从前，除了所有页面组件加载的更多细节之外。 与网络跟踪中的404匹配的第一个错误是针对 GET https：//<前端服务器>/sap/bc/ui5_ui5/ui2/ushell/resource/〜20190314161900〜/sap/fiori/core-ext -light-dbg-dbg.js net :: ERR_ABORTED 404（未找到）。

第二个错误是 POST https：//<前端服务器>/sap/opu/odata/sap/HCMFAB_MYPAYSTUBS_SRV/$ batch？sap-client = 001 500（内部服务器错误）。 然后，它后面是进一步的错误（与以前相同）：

无法解析服务器返回的错误消息
发生了以下问题：HTTP请求失败500，内部服务器错误，500连接 超时
$ count请求失败：HTTP请求失败
错误：无效的XML：500连接超时
呈现弹出内容：serviceErrorMessageBox

然后的顺序是 重复，但是基本上就是这样。 我认为在URL中打开调试功能后，会在 $ count请求失败中添加额外的"警告"行。 我不记得以前见过。

所以，我一直想知道的是， sap-client = 001 参数附加在< em> $ batch 命令失败。 客户端001确实是我们的前端系统上的客户端，但是后端系统的工作客户端是300。系统别名已适当设置为在后端调用客户端300，并且绝对有效。 其他应用程序没有任何问题。 甚至我的个人资料都能够提取薪资数据以查看薪酬概览，但是我的工资单失败。 应用程序是否以某种方式试图覆盖系统别名并连接到其他后端客户端？ 肯定会导致它出现问题。

干杯，
Matt

超时是在添加调试参数之前发生的。 我的看法是，加载javascript组件的调试版本时，一切都会变慢，这只是一个观察，与故障排除并没有真正的关系。 无论是否打开调试，F12中记录的错误都是相同的。

因此，我实际上并不认为这是导致超时的根本原因。 我认为更多是"内部服务器错误"引起的，并且超时是一种症状。

但是，感谢您对客户机参数的设置放心。

我有一个与此事件有关的事件已提交给SAP支持，因为这对我来说似乎是一个程序错误，但是鉴于我们目前仅在Sandbox中，所以这是一张低优先级的票，到目前为止，没有得到任何关注。

我想我终于知道发生了什么事。 根本没有"错误"。 这真的是一个超时。 该应用程序开箱即用，可为员工提取整个薪酬历史记录，并在显示任何内容之前加载每个月的薪酬数据（以及相关的工资单）。 当我使用只有四，五年历史的测试员工时，加载需要一段时间，但最终确实可以加载，并且数据是正确的，并且工资单本身可以快速而精美地显示。 只是初始负载需要一段时间。 它也不缓存；

当我使用历史悠久的人时（例如我本人在公司工作了19年），它就会超时，最终 永远不会加载任何薪水数据。

这似乎效率很低，并且对于默认配置来说是一个糟糕的选择。 不过，我假设它是可配置的，可能在与此应用程序的OData服务相关的后端BAdI中。 接下来，我将探索该途径。