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

首先，不，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支持部门的开发人员，他们在经过长时间的等待之后，很快就指出创建二级索引是可能的解决方案（尽管他们由我自己来决定索引的字段） ；幸运的是，系统本身非常擅长于此。）

更新：

在解决此问题的尝试中，我们使用新的后端组件进行了更新。 发布的支持包：

• SAP_GWFND 750 sp14（was sp13）
• SAP_UI 750 sp14（was sp13）
• GBX01HR 600 sp13（was sp12）
• GBX01HR5 605 sp10（以前是sp9）
• 内核753 pl400（以前是pl300）

我们还应用了后端注释2753981，及其先决条件。

在前端，我们将SAPUI5库从1.60.1更新为1.60.9，然后应用了注释2760302及其先决条件，以及一些注意事项。 附加说明以增强" ETag错误处理"并为许多HCM应用程序提供了增强功能（不幸的是，我的Paystubs 都没有）。

并清除了后端的元数据和ICM缓存，

这完全修复了我的个人资料应用程序，该应用程序也失败了（存在另一个错误），但是 My Paystubs 仍然顽固地损坏了。 但是，从我的个人资料中，我们现在可以在"薪酬"区域中查看薪资概览数据，这表明我们绝对能够从前端访问后端的薪资数据。 只是我的Paystubs 应用程序失败。

2259626-修改Fiori我的Paystubs APP

更新2中显示的工资单：

我已经确定该应用程序实际上没有什么"破损"，但是在如何从后端加载支付数据和支付桩方面效率很低。 当我切换到只有几年工作经验的测试用户时，该应用程序可以正确加载所有工资单，尽管加载初始概览屏幕仍需要花费相当长的时间。

当我使用测试时 具有近二十年历史的用户，该应用程序始终会超时，并且根本不会加载任何数据。

问题似乎是打开该应用程序后，它将加载所有paystub和相关的 数据，对于每个月的薪水，可追溯到雇员的雇用日期，而没有机会将选择范围限制在日期范围内。 虽然当然希望授予员工访问所有工资单的权限，但是大多数情况下，他们很可能只希望看到最新的工资单。

大概可以在某个地方进行配置，也许在后端BAdI中 该应用程序，而我现在正在探索该途径。 但是，与此同时，任何有关此操作的建议将不胜感激！

我不知道，这是配置它的必需步骤：

https://fioriappslibrary.hana.ondemand.com/sap/fix/externalViewer/index.html#/detail/Apps（'F1313A'）/S13OP

https://blogs.sap.com/2019/05/21/fiori-my-paystubs-v3-and-performance-in-a-non-hana-environment /

嘿。 添加参数会使所有操作变慢。 可能是造成超时。 如果odata出了点问题，那么您也应该在没有参数的情况下看到错误。 是否可以在不带参数但打开F12控制台并选择"网络"选项卡的情况下测试应用程序？ 您可以看到odata是否错误。 客户端的参数应该不是问题，通常是FES中的参数。