我很快将实现一个类似的系统，该系统与进行RFC调用的第三方系统打交道-但我的数量将大大减少。 这是一些要点...

• 所有RFC都是自定义的。
• 具有一个自定义类以处理进入日志表的条目（管理键，时间戳，用户ID，RFC来源等）
• 每个RFC函数调用一次该类（或多次，具体取决于参数的数量）
• 对于表和结构，我将结构名称记录在一个字段中，然后将结构中的全部内容记录在一个数据字段中
• 一些关键的RFC也可以通过导出参数来记录日志-带有导出参数
• 我有一个表来控制整个组织单位（基于每个工厂或仓库）的默认日志记录级别 ）-调试，成功，警告或仅错误。 对于开发和质量检查系统，我的默认值为D；对于生产环境，我的默认值为E。 （与RFC相比，我记录的日志要多得多，这使D变得非常有用。
• 有一个参数ID（PID），可让我在每个用户临时的基础上将日志记录切换到不同的级别
>
• 我编写了一个自定义的前端，该前端可以逐个字段地解析结构
• 前端负责在每天第一次使用日志表时清除日志表。 避免执行后台作业-但是随着您的数量的增加，您可能希望该作业运行。

如果您有任何特定问题，请放心，我会尽力为您提供更多信息。/p>

你好詹姆斯，

对于您的问题，我没有答案，但以为您可以帮我一下。 我有一种类似的要求，即从一年中的某个外部应用程序到中间件（TIBCO），在一天的24小时内，一天24小时内一天可能会调用RFC两次。

您是否已采取任何特殊措施来实现这一目标？ 还是可以说这是一个可持续的解决方案？ 我有点担心，如果每天有那么多呼叫发生，系统可能会崩溃。 目前，该服务每天被调用约2000-5000次。

此致

Suman Biswas

ST01可以跟踪RFC调用。 有帮助吗？ 如果呼叫太多-也许每天将其提取到数据仓库中？

嗨苏曼，

我希望你一切都好。

在我的问题中，我所指的特定服务每天在我们的系统中（星期一-星期五）被调用约400万次，而没有影响。

这与您描述的设置类似； 通过中间件组件的外部消费者。 中间件基本上是RFC转换的其余部分。

基本上，您需要与基础团队讨论高峰时间的使用情况。 您需要确保有足够的连接可用于RFC和用户/批处理/更新过程。 如果我们自己的使用量增加，我们正在考虑为该服务添加专用的应用服务器，并使用登录组来确保只有该服务才能访问这些服务器。

我希望对您有帮助吗？

詹姆斯

我对这个问题有点困惑。 首先，它说"所有这些RFC都按预期执行"，但是如果一切正常，为什么还要进行任何日志记录呢？ 并且在注释中，通过添加一些" Correlation ID"来使图变厚。 您可能希望分享整个故事以获得更好的答复。

如果您确实需要这种日志记录，那么恐怕除了透明表之外，您别无选择。 "文件系统"将带来其他所有问题，并且使用起来不会更快或更简单。

另一个问题-您将如何分析1.68亿。 记录以及您是否真正需要日志（甚至14天）。 也许相反，您可以像ST01/05那样需要打开和关闭，并且只为特定的高峰时段创建详细的日志？ 如果存储有问题，请每天转储/删除数据。 但是再次，我不太确定日志的确切用途以及您期望找到的内容。

作为一个附带说明，大容量接口确实需要一些认真的人员从 设计阶段可避免此类情况。

是的，它是透明表。 在大多数情况下，您正在写而不是从该表中读取记录。 因此，您不应看到性能下降。 考虑一下您的BSEG和MSEG表，它们是系统的两个主干。 他们可以轻松地拥有数以千万计的记录，而在编写时几乎没有性能损失。

如果您想考虑进行更积极的清除，我确实有一个主意。 由于大多数情况下您确实会更快地收到问题报告（此处为假设），并且希望使用14天的时间，因此您将有几天的时间来研究该问题-您可以在第二张表中使用"提取器" "程序，将经过一段时间筛选出来的筛选数据移出进行手动研究。 可以按时间范围/RFC功能模块/RFC调用的源IP/您可能拥有的应用程序代码等提取内容。显而易见，您的密钥设计在这里至关重要。