RNIF Message Processing

The RosettaNet organization defines message exchange in the RosettaNet Implementation Framework (RNIF) specifications. RNIF defines how integration systems will transport messages. BTARN fully implements the RNIF specifications, adding that functionality to what Microsoft BizTalk Accelerator for RosettaNet (BTARN) natively provides out-of-the-box.

RNIF communications are complex. The public processes that perform RNIF processing include a variety of validation checks and complex workflow logic. BTARN provides this functionality natively. This lets you use a RosettaNet-compliant system without developing or maintaining RNIF logic from scratch.

BTARN Support for RNIF

BTARN supports both versions of RNIF: RNIF 1.1 and RNIF 2.0 (V02.00.01). RNIF 2.0 added significant functionality beyond that supported by RNIF 1.1, including encryption, attachments, and synchronous transactions. RNIF 2.0 is not backward compatible with RNIF 1.1.

Note

BTARN is RosettaNet Ready RNIF 2.0 compliant.

The two versions define the RosettaNet message differently. For more information about the different message containers, see RNIF Standard.

Integration systems perform RNIF transfer over HTTP/HTTPS and SMTP; however, BTARN implements only HTTP/HTTPS. BTARN does not support attachments and synchronous transactions in RNIF 1.1.

Non-Repudiation

The RNIF standard includes a requirement for non-repudiation. This involves storing the wire format of any message received or sent by BTARN in a non-repudiation database, so that you can prove legally that you have received or sent it. For this purpose, BTARN uses the MessageStorageIn table in the BTARNArchive database for incoming messages and the MessageStorageOut table in the same database for outgoing messages.

You set non-repudiation requirements for service content and for acknowledgements separately in the process configuration profile. If you set one or both of the Non-Repudiation of Origin and Content and Non-Repudiation Required options to True, then BTARN will store the following data:

Data Contents
RecordID Proprietary unique ID of the stored message
MessageCategory Request (0), Response (1), or Signal (2)
DestinationParty Name of the destination party
SourceParty Name of the source party
PIPCode For example, PIP3A4
PIPVersion For example, V02.00
MessageContent Message in binary format
MessageTrackingID Message tracking ID of the message
PIPInstanceID PIP instance ID of the process

See Also

What BizTalk Accelerator for RosettaNet Adds to BizTalk Server
PIP Implementation