BASIS团队最近提出了一个性能问题。据报道，许多DIA进程都忙于处理idoc。有趣的是，很多TRFC都是用目的地NONE创建的，这对我们来说并不明显。

合作伙伴简介指向PI系统，IDoc会立即触发，我们不确定为什么TRFC会用目的地NONE创建。

通过这个博客，当

Partner profile设置为"Transfer idoc Immediately"时，大数据云计算，我将显示为出站idoc创建的trfcPartner profile设置为"Collect idoc"

请注意，测试中的步骤将停止tRFC处理，应在沙箱系统中进行，以免影响用户。

对于功能良好的SAP ABAP系统，tRFC处理速度非常快，淘客推广，因此很难监控tRFC。因此，数据技术与大数据技术，要继续测试，我们需要在SMQ中注册目的地"NONE"，以便调度器可以像控制普通RFC目的地一样控制它。

将NONE添加到tRFC调度器并停止自动处理。

这可以通过事务SMQ和添加destination NONE来实现。

单击Registration并给出目的地‘无’

既然没有像正常目的地一样注册，我们可以取消注册，这样TRFC就不会自动处理。但是，大数据是干嘛的，它们可以从SM58手动处理。

任何推送到目的地NONE的tRFC都不会被执行并作为tRFC条目保留。这将允许我们观察tRFC。

tRFC调度程序中的Derigster PIèu目的地停止自动处理。

我们也注销了PI目的地，但概念是通用的，它将适用于IDoc端口所指的任何目的地。

NONE和PIèu目的地都已注销。

这意味着SMQ调度程序不会自动处理这些目的地的条目。您仍然可以在事务SM58中手动处理它们。

-消息的合作伙伴配置文件被立即设置为触发器。

我们使用由输出类型触发的消息进行测试：

有一个为目的地无和功能模块IDocS\u output\u TO\u R3创建的条目。

IDoc保持状态30（即使合作伙伴profile设置为trigger immediately）。

如果我们现在通过注册destination NONE来处理这个条目

处理上一个tRFC，用一个新的TID创建一个新的tRFC。

此外，IDoc被推到状态03。

为了确保它不特定于输出类型处理，我们测试了一个没有通过输出类型触发的IDoc。

就像以前的测试一样，为目标NONE创建一个tRFC条目，大数据可视化，IDoc在状态30下创建。

我们现在注册目标NONE。这将导致tRFC条目被处理，IDoc状态移到03。为PI destination创建一个新的tRFC条目。

查看调用堆栈以了解为什么会为destination NONE触发tRFC，对功能模块IDocS\u OUTPUT\u to \u R3的调用嵌入在EDI\u OUTPUT\u NEW的调用中。

这里它在后台任务中调用功能模块IDocS\u OUTPUT\u to \u R3，触发一个目标为NONE的tRFC。

伙伴配置文件设置为"Collect IDocS"的IDocS

这里没有异常。

IDoc在状态30中创建。未创建tRFC条目。

输出处理程序as RSEOUT00将处理IDoc，并将状态设置为03，并为IDoc端口的RFC目的地创建tRFC条目。

对于出站处理，当合作伙伴配置文件设置为"立即触发IDoc"时，有2个tRFC

–在中生成IDoc状态30，为目的地无生成一个tRFC条目。

–如果处理了上述TID，IDoc将处理为状态03，并为IDoc端口的目的地生成一个新的tRFC。

这对我们来说是一个学习，因为我们认为对于立即触发选项，IDoc通过tRFC创建并发送到目标目的地，但正如我们在本博客中看到的，这一步分为两步。

注意1862248提到了如何修复出站处理中的延迟，但没有明确提到两步tRFC，因此我们决定做测试来为我们澄清它。