我最近有两个SAP HCM客户,他们都在时间管理环境中生活了相当长的一段时间,在他们的时间评估计划(RPTIME00)中彼此在几天内经历了相同的短转储。通常,每当我听到一个短时间的转储时,我首先想到的是"自定义操作或函数"。然而,在事务ST22中第一次看到这个短转储时,很明显定制操作或函数不是根本问题。这些短转储是源于完全相同的代码段的完全相同的消息,但根本问题是完全不同的。我想谈谈这个简短的转储,并分享一些我调试这个逻辑的经验。首先,我将介绍一下我的两个客户机的背景和每一个客户机的经验。
客户机1
客户机2
这里是短转储–一个内部表字段被定义得太小。
您可以看到短转储将我们指向FUCUMBT。任何在时间管理领域工作了足够长时间的人都知道,这是CUMBT函数,它是时间模式处理中每天结束时运行的最后一个函数。在进一步的调试中,我能够在短转储中找到一个人员编号,因此我将有问题的员工复制到测试环境(对于客户机1),然后运行时间评估(在过去)以确定它能够运行到哪一天,这样我就可以看到时间集群表中的数据。当我运行当前日期时,我能够在测试环境中重新创建短转储。
当在短转储开始的前一天为客户机1运行有问题的人员编号时,我在SALDO cluster表中发现以下条目
因为您可以看到时间类型0903中的数量非常大。这是非常不寻常的,特别是考虑到0903是一个标准的SAP时间类型,处理每周加班。
我马上知道,在时间模式的定制是错误的,导致这个标准时间类型有一个异常高的平衡。
最终与这个客户机,大数据技术及数据分析培训,我发现了一些自定义OT模式每天填充MB0903和复利的规则,结果MB0903从未被重置。自2005年以来,负责的模式规则一直没有更改,大数据怎么样,但最终变得足够大,导致了短转储!!为了解决这个问题,我不得不加入新的逻辑来清除时间类型,类似于标准的SAP模式规则TW34。
Client#2是一个完全不同的故事!这些人在BSI10.0升级过程中实现了支持包,所以我在测试环境中发现了这个问题,同时对每个人进行了大量的时间评估。为了查看这次发生了什么,我在调试的同一个地方开始,并像以前一样从事务ST22的短转储中找到了一个人员编号。在这一点上,我运行的人员数量在时间评估到目前的日期,甚至到了未来的年底,我没有得到一个短转储!我检查了一些主要的时间簇表(TES,ZES,SALDO,ZL),什么都没有。这对我来说非常奇怪,所以我做了另一次大规模的运行时间评估,以确保这不是一个侥幸事件,但我得到了相同的短转储,除了这次不同的人员编号。我查看了在短转储中引用的第二个员工,再次没有任何内容与他们的时间集群数据有关。经过进一步的研究,我做了一个生产和测试的比较,并看到SAP改变了一些逻辑,时间计划,在QA中,但不是在产品中,作为OSS Note 1879092的一部分,它于2013年4月10日发布,但只是与支持包一起放进了这个客户机的系统中。我指的是SAP所做的更改。
对于客户机#2,生产中的计划作业都运行良好,企业管理软件开发,而不是短暂的转储,这一事实使我相信这是SAP程序错误,是应用的支持包的一部分,而不是错误的模式逻辑。最后,我做了进一步的研究和挖掘,发现了OSS Note1942144,它描述了我看到的症状。我已经把它包括在这里了。
在这个发现之后,我在开发环境中使用事务SNOTE来实现这个注释,淘客联盟,把它放在一个transport上,然后把它移到QA。一旦我确认运输已经转移到QA,我就使用现有的生产变量通过后台作业对每个人重新运行时间评估,虽然运行时间很长,但由于QA数据只有几个月的时间,这次没有短转储!
在我的研究和搜索OSS笔记的过程中,我还想向阅读本文的任何人指出,我发现了一个类似的问题,这个问题是由相同的逻辑引起的,在某些情况下可能也会导致工资单的短暂转储。我的两个客户都没有遇到过这种情况,但对于任何有此问题的客户,请参阅SAP OSS Note 1966322–RPCALCXX:Dump:Collect\u Overflow\u Type\P,一旦应用,应该可以解决此问题。
总之,我遇到了两个不同的问题,恰好在两天之间产生了完全相同的错误消息,我只是惊讶于两个完全相同的短转储的根本原因是多么不同!这也让我意识到,在编写自定义模式规则时必须小心,并且要注意时间类型的平衡,因为这种逻辑会在10年后引起很大的头痛!
您好,
非常好的分析和有用的信息。
感谢分享您的知识。
问候,
Raja Sekhar
Imran,
这是非常好的分析,免费自助建站系统,将证明对任何可能在未来遇到此问题的人非常有用。
感谢分享!
问候,
Kory
Imran
感谢分享
John
非常有用的信息Imran,
这一定会帮助很多顾问在看到垃圾场时震惊,不知所措。