您好Bartosz，

它设置为"立即发送"而不是批处理作业。

由于该消息是在上周处理的，因此我们现在在SMQ1或SM58中找不到任何内容。

我们可以检查ECC中某处的日志以说明其向PI发送特定IDoc的时间吗？

我们应该要求Basis检查与任何相关处理有关的内容吗？

谢谢

Ramu。

嗨， Ramu G ，
我将从 检查：
-IDoc的处理方法（设置为"立即发送"还是通过批处理作业执行）。
-如果消息未在SM58中被阻止，则
-如果消息未在SMQ1中被阻止，则
Bartosz

嗨Ramu，

据我了解，消息不会在队列中被阻塞，也没有RFC问题。

据我所知，所有同步/异步消息都将有一定的处理时间，如果 时间超过消息/IDOC的时间将被自动取消。 因此，如果消息在队列中被阻塞，则出现延迟的唯一机会。

您是否在触发IDOC之后立即在ECC中检查了这些队列？ 因为我们有一些SAP标准作业，可以安排它们检查队列并清除卡住的消息。 检查此功能是否到位，如果是，则检查作业的频率。

另一个原因可能是时间设置差异。

您是否检查了ECC和SAP PO系统时区/设置是相同还是不同？

我建议您在质量检查环境中测试界面。 要求ECC小组触发Idoc并检查您是否立即收到它？ 如果IDOC立即收到，请检查ECC和PO系统中的时间戳。

您可以从控制记录的技术信息选项卡中获取IDOC时间戳。

注意事项

< p> Bhargava Krishna

嗨Ramu，

1. 您是否使用Java Only PI（AEX）/PO？
2. 我没有 认为您应该使用有限的信息/已经从日志中推出的有限信息来分析问题，这是明智的选择。
3. 考虑为iFlow/ICO更改登台（运行时配置）（假设您不这样做） t有一个经典场景）以"存储" BI步骤。 即使未找到接收器或类似信息，这也会导致将iDoc存储在PI上
4. 这是EO还是EOIO方案？ 换句话说，序列化/阻止/保留在这里会成为问题吗？
5. 您能重现该问题吗？ 如果是这样，请检查" PI上的日志"或设置XPI Inspector跟踪并进行重现，以期获得更多见解