RNIF Two Action Request Response – Correlation

Have you ever wondered how does the correlation in RNIF’s Two Action Request Response happen?

I found that there is not much information available on community on this particular topic.

What is RNIF?

It is a message protocol designed for Semiconductor specific use cases. Just like EDIFACT or ANSI, message formats etc are already defined in DTD format which can be used by PI/PO. Just like on AS2, these messages are sent on HTTP protocol.

More documentation on RNIF standard can be accessed here.

Two Action

We will only focus on Two Action message. If your partner is Initiator, it first sends you a Request Message. You need to configure RNIF Sender channel with Two Action Request.

At the technical level, it sends out an Acknowledgement back to the Sender (somewhat similar to MDN for AS2).

In the olden days, of XI 3.0, PI 7.0, SAP provided a standard content for RNIF, which had a Buyer ccBPM, responsible to take care of correlation. BPM after receiving the message from your partner, used to send it to ECC, and waits for Response message (async Idoc). Upon receiving the Idoc from ECC with matching correlation, it triggers the Response message back to the Receiver RNIF Channel which is configured to process a Two Action Response message. It is not required to provide partner’s URL in this receiver channel. The Response message is sent to the partner and it receives a Technical Ack back for the message sent. And this is how the flow is completed. All communications across the systems is asynchronous.

One thing that was still a mystery for us, was how does the RNIF layer recognizes that a given Response belong to a Request, in other words, how does RNIF does the correlation at the adapter level.

What we found was that when a message hits the RNIF layer, it is checked if the message id of the message already exists in the correlation table XI_AF_ISP_CORREL. If no entry is found, then the message id and the correlation id is saved in the table and it is considered as an initiating message. Note that this correlation id is set by the partner which has triggered this message to your PO system. The complete cycle will be completed once your partner receives the response message with the same correlation id.

Above is Inspector Trace at Ispeak adapter level. Note that when no entry was found in the table for the message id of incoming Request message, it gets added in this table.

This correlation id should not be confused with the correlation id of XI message header. These are 2 different entities.

After this, the message is sent to BPM and ECC and we get a response message from ECC and BPM and now RNIF is ready to process the Response message. At this point, the message id and, more importantly, message Reference Id of the incoming message is checked for an entry in table XI_AF_ISP_CORREL.

Message id of the Response message would be unique and it will never match, obviously. When the response message also has Reference id, set as the message id of the original Request message, then we will have a match and adapter service would recognize this as a response message and prepare RNIF Service Header with Response Details and trigger the message to partner with the correct correlation id.

Note that above there are 2 messages ids, one which is the message id of Response message (005056a3-67af-1ed7-a2a1-87806fd620ee) and RefToMessageId (317bdfd7-890c-11e7-b835-000000cdafaa) of the same message.

Some further down the traces, this can be seen

Note that RNIF message is sent via a HTTP POST method with content type multipart/related. There are some message headers which are not directly controlled by PI’s message mapping and auto-generated by Ispeak service.

If there is no Reference id in the Response message, adapter service will never be able to identify the correlation and it will assume this to be an initiating message and a message with Request Service Headers will be triggered with a new correlation id and with a Response payload! This will lead to failure either in PI or at the Partner side.

Role of ccBPM

We found that when ccBPM triggers async response message back to PI to finally deliver it to the partner, it assigns Message Reference id to that Response message. This is precisely why there was ccBPM provided by SAP for these Two Action Asynchronous RNIF scenarios.

When you replicate the same scenario in NW BPM, it was found that NW BPM does not populate Reference Id with original Request message Id. Upon raising this with SAP, we were informed that NW BPM does not support this feature.

Those who are planning to migrate such ccBPM scenarios to NW BPM should be cautious and evaluate other alternatives.