你有没有想过RNIF的两个动作请求-响应之间的关联是如何发生的？

我发现关于这个特定主题的社区信息不多。

RNIF是什么？

它是为半导体特定用例设计的消息协议。与EDIFACT或ANSI一样，消息格式等已经在DTD格式中定义，可以由PI/PO使用。就像在AS2上一样，这些消息是通过HTTP协议发送的。

这里可以访问更多关于RNIF标准的文档。

两个动作

我们将只关注两个动作消息。如果您的伙伴是发起方，它首先向您发送请求消息。您需要为RNIF发送方通道配置两个操作请求。

在技术级别，它向发送方发送一个确认（有点类似于AS2的MDN）。

在过去的XI 3.0，PI 7.0中，SAP为RNIF提供了一个标准内容，其中有一个买家ccBPM，负责处理相关性。BPM在接收到来自合作伙伴的消息后，用于将其发送到ECC，并等待响应消息（异步Idoc）。当从具有匹配相关性的ECC接收到Idoc时，它将响应消息触发回接收机RNIF信道，该接收机RNIF信道被配置为处理双动作响应消息。不需要在此接收器频道中提供合作伙伴的URL。响应消息被发送给合作伙伴，并接收到所发送消息的技术确认。流程就是这样完成的。所有跨系统的通信都是异步的。

对我们来说，有一件事仍然是个谜，那就是RNIF层如何识别给定的响应属于请求，换句话说，RNIF如何在适配器级别进行关联。

我们发现，当消息到达RNIF层时，检查相关表XI\u AF\u ISP\u CORREL中是否已存在消息的消息id。如果找不到条目，则消息id和相关id将保存在表中，并将其视为发起消息。请注意，返利平台有哪些，此关联id是由已将此消息触发到您的采购订单系统的合作伙伴设置的。一旦您的合作伙伴收到具有相同关联id的响应消息，整个周期将完成。

以上是Ispeak适配器级别的检查器跟踪。请注意，当传入请求消息的消息id在表中找不到条目时，会将其添加到此表中。

此关联id不应与XI消息头的关联id混淆。这是两个不同的实体。

之后，消息被发送到BPM和ECC，开源建站系统，云品，我们从ECC和BPM得到一个响应消息，现在RNIF准备处理响应消息。此时，将检查传入消息的消息id，更重要的是，消息引用id，以便在表XI\U AF\U ISP\U CORREL中找到条目。

响应消息的消息id将是唯一的，显然，它永远不会匹配。当响应消息还具有引用id时，设置为原始请求消息的消息id，然后我们会有一个匹配，适配器服务会将其识别为响应消息，并准备带有响应详细信息的RNIF服务头，并触发消息以与正确的相关id合作。

请注意，上面有两个消息id，一个是响应消息的消息id（005056a3-67af-1ed7-a2a1-87806fd620ee）和参考同一消息的消息ID（317bdfd7-890c-11e7-b835-000000cdafaa）。

进一步跟踪，可以看到

请注意，RNIF消息是通过内容类型为multipart/related的HTTP POST方法发送的。有些消息头不是由PI的消息映射直接控制的，而是由Ispeak服务自动生成的。

如果响应消息中没有引用id，适配器服务将永远无法识别相关性，它将假定这是一条发起消息，建站系统哪个比较好，并且将生成一条带有请求服务头的消息使用新的相关id和响应负载触发！这将导致PI或合作伙伴端的失败。

ccBPM的作用

我们发现，当ccBPM触发异步响应消息返回PI以最终将其传递给合作伙伴时，它会将消息引用id分配给该响应消息。这正是SAP为这两个异步RNIF场景提供ccBPM的原因。

当您在NW BPM中复制同一场景时，零售大数据解决方案，发现NW BPM没有用原始请求消息Id填充引用Id。在向SAP提出此问题时，我们被告知NW-BPM不支持此功能。

计划将此类ccBPM场景迁移到NW-BPM的人应谨慎并评估其他替代方案。