您好Sayak

通过NAM，您的意思是"小说访问管理器"。 如果是，那么它是第三方SSO应用程序，需要为此进行探索，为什么它不从后端系统获取大量订单。

在NAM（配置了反向代理）上，您可以尝试增加超时参数。

在Novel Access Manager中，默认数据读出时间为120秒（2分钟）。

请查看以下网址：

https://www.netiq.com /documentation/netiqaccessmanager4/accessgatewayhelp/data/b3q98a7.html

注意：假设您提到的NAM是：Novel Access Manager

致谢

Hello Basu，

在NAM中，反向代理的超时时间增加了。 sap webdispatchers中的超时参数也增加了。
现在两个地方的超时参数都设置为最大可能值。
这无疑已解决了其中一个巨大订单的问题。
< br>但是我们还有另一个订单，在订单项，交货和发票方面，订单的大小是上述订单的两倍。
对于此订单，屏幕将继续处理数据约6分钟，然后显示空白屏幕 留下任何结果，也没有任何错误消息。

嗨，Sayak

您是否在ECC系统的ICM上设置了处理超时？ 有点像SAPGui用户的标准对话框超时，这些用户在对话框中运行进程的时间超过默认的10分钟。

希望有帮助

马克·哈雷特

嗨，马克，

感谢您的快速回复。
我已经与基础人员核对，该人员通知我ICM处理超时在 ECC系统设置为3600秒，两个sap Web调度程序设置为3600秒。

不过，我想在这里添加一点。 处理大约128秒后，该会话失败。

您能建议现在如何继续吗？

我只能建议您让Basis团队暂时增加流中每个系统的跟踪级别，然后监视跟踪以确定消息在哪个系统上出现故障。 大消息导致此事实的事实将导致我调查流中每个系统的超时。

希望有帮助

Mark Hallett

Hey Mark，
自您上次发表评论以来，我一直在与Basis团队和NAM团队进行测试。 这次测试提出了一些更奇怪的东西。

我们已删除了NAM（打破了代理映射），并尝试直接到达门户以获取相同的订单详细信息。 令人惊讶的是，订单详细信息已成功获取。

然后我们再次尝试使用NAM（打开SSO），再次出现了与我的帖子中所述相同的错误。

通过上述测试，我可以 假设问题可能在NAM级别上。 在这种情况下，增加代理或反向代理级别的超时时间会有所帮助吗？

能否请您对此发表宝贵的评论？

谢谢马克。

希望我的假设是正确的，并且可以解决Sayak的担忧