2020-09-08 11:08发布
点击此处---> 群内免费提供SAP练习系统（在群公告中）加入QQ群：457200227（SAP S4 HANA技术交流） 群内免费提供SAP练习系统（在群公告中）我们正在设置新的Fiori前端服... 显示全部
加入QQ群：457200227（SAP S4 HANA技术交流） 群内免费提供SAP练习系统（在群公告中）
我们正在设置新的Fiori前端服务器，而我只是想首先使一两个应用程序能够向管理人员演示UI。 到目前为止，我的我的收件箱正常工作，但是当我尝试使我的Paystubs 正常工作时，我只是一次又一次地出错。 当然，我是新手，但是我正在浏览/IWFND/ERROR_LOG和F12浏览器开发人员工具，运行RFC和授权跟踪，尽管我开始明白了，但我无法确定原因 一些怀疑。
单击磁贴时的主要症状是，在加载应用程序后，它会挂载一分钟，就像正在加载数据一样，然后出现 500连接超时错误。 关闭错误对话框后，它会显示消息当前没有可用的工资单。
顺便说一句，我知道这是不正确的，因为工资单肯定可以通过我们门户网站中的传统ESS获得。
在F12开发人员工具中，我可以看到更多的http错误代码，而主要的错误代码似乎是 403 Forbidden 。 通常，我会将其与SICF中未激活的服务相关联，但是我无法精确确定哪个服务是此错误的根源。
在网关错误日志中，我确实收到一堆"未找到服务"消息，但是这些消息大多数是属于HCM捆绑包中的其他应用程序的，我知道我尚未对其进行配置，因此我希望这些消息 当我访问启动板时。
但是，其中之一用于ESH_SEARCH_SRV。 我的Paystubs应用中有一个 Search Paystubs 小部件。 因此，我开始怀疑是否缺少配置ESH_SEARCH_SRV会阻止我使应用程序的其余部分正常工作。 当然，应用程序实现文档中没有任何东西提到此前提条件，但是再一次，这就是SAP文档：可以安全地假设没有提到很多需要了解的内容，或者假定它们是倾斜引用的，并且仅在某些情况下可用 other 文档，该文档只能在由三头攻击犬保护的活板门下方的带锁盒子中找到。 为什么不能只有一个文档依次说先执行此操作，然后先执行此操作，然后再执行，而又不要求您先弹出其他文档，然后又弹出其他文档， 会为您提供实施该应用程序的从头到尾的说明...我不知道。
因此，ESH_SEARCH_SRV当然是企业搜索。 感觉就像是在坐公交车过马路，但是我开始怀疑也许我的Paystubs （也许还有HCM捆绑包的其余部分）毕竟需要这个，但是哦，是的 ，您必须在一些晦涩的注解中找到它，因为它没有被引用，也没有被适当地关键字化，以便知道这个小事实。 而且，如果像我们一样，您不在HANA上，则企业搜索需要TREX。 而且TREX还需要另一台服务器。
我开始认为这完全是一种阴谋，目的是说服像我们这样的内部部署客户，毕竟我们真的应该付出巨大的代价才能迁移到云中。 我的意思是，感觉有意很复杂，没有明确的理由。
所以，这是我的问题。 我是否需要配置TREX服务器才能克服此讨厌的 403 Forbidden 错误？
有需要的人：这是 My Paystubs v3 ，又名HCMFAB_MYPAYSTUBS_SRV，是 Fiori for SAP HCM 2.0 （sps 05）的一部分，位于 Fiori Front- 最终服务器5.0 （sps 01），本身位于AS ABAP 7.52（sps 03）上。 它作为HUB部署安装，因此后端ERP系统是独立的。 该系统在SAP ERP 6.0的EHP8（sps 10）和NetWeaver 7.5（sps 11）的基础上，具有针对SAP ERP HCM 1.0的 Fiori（sps 12）。 因为Fiori for ERP HCM 1.0后端是一个棘手的恶魔，所以我将进一步提及其组件是GBX01HR 600 sp12和GBX01HR5 605 sp9。 SAP_HR和EA-HR 608组件是sp59。
我的浏览器是Chrome，但我也在IE11中尝试过，结果相同。
希望获得一些令人惊奇的见解，并真的希望其中之一不是"您需要安装TREX。"
干杯，马特
花了一些时间，但我终于解决了这个问题。
首先，不，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％的改进。 建议是：
只有一个复杂之处：SE11不直接支持创建索引 与"包含"列。 如何解决此问题？
注意事项 1775008 （索引的定义包括MSSQL Server的列），它实际上旨在在SQL Server上运行BW系统，但在这里仍然适用于我们。 详细信息：
以这种方式创建此索引的结果是，现在我可以在不多的时间里拉近近15年的月薪 超过五秒钟，而之前大约一分钟会超时。 那是很大的不同！ 大概有99.96％的差异。
我感谢安迪·戈里斯（Andy Goris）的不懈努力来帮助解决问题 这个问题，以及SAP支持部门的开发人员，他们在经过长时间的等待之后，很快就指出创建二级索引是可能的解决方案（尽管他们由我自己来决定索引的字段） ；幸运的是，系统本身非常擅长于此。）
最多设置5个标签!
{var%20f='http://v.t.sina.com.cn/share/share.php?appkey=1515056452',u=z||d.location,p=['&url=',e(u),'&title=',e(t||d.title),'&source=',e(r),'&sourceUrl=',e(l),'&content=',c||'gb2312','&pic=',e(p||'')].join('');function%20a(){if(!window.open([f,p].join(''),'mb',['toolbar=0,status=0,resizable=1,width=440,height=430,left=',(s.width-440)/2,',top=',(s.height-430)/2].join('')))u.href=[f,p].join('');};if(/Firefox/.test(navigator.userAgent))setTimeout(a,0);else%20a();})(screen,document,encodeURIComponent,'','','http://www.easysap.com/data/attach/logo/logo.png', '推荐 d56caomao 的问题《Fiori My Paystubs v3：HRPY_RGDIR的性能问题》','https://www.easysap.com/answer/64483/180472.html','页面编码gb2312|utf-8默认gb2312'));){kind=link}
花了一些时间，但我终于解决了这个问题。
首先，不，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上的唯一索引是主键外，其他所有都很好，它由MANDT，PERNR和SEQNR组成。 如所写，此选择必须扫描整个表以找到PERSDATA和PERSON的条件。
实际上，DBACOCKPIT内的分析揭示了使用大量数据库时间（大约占我沙箱中总时间的9％）的特定搜索。 系统），并且数据库引擎返回二级索引建议，表明可以获得高达99.96％的改进。 建议是：
只有一个复杂之处：SE11不直接支持创建索引 与"包含"列。 如何解决此问题？
注意事项 1775008 （索引的定义包括MSSQL Server的列），它实际上旨在在SQL Server上运行BW系统，但在这里仍然适用于我们。 详细信息：
以这种方式创建此索引的结果是，现在我可以在不多的时间里拉近近15年的月薪 超过五秒钟，而之前大约一分钟会超时。 那是很大的不同！ 大概有99.96％的差异。
我感谢安迪·戈里斯（Andy Goris）的不懈努力来帮助解决问题 这个问题，以及SAP支持部门的开发人员，他们在经过长时间的等待之后，很快就指出创建二级索引是可能的解决方案（尽管他们由我自己来决定索引的字段） ；幸运的是，系统本身非常擅长于此。）
一周热门 更多>