RNIF metadata elements

The following are the available RNIF metadata elements. These elements can be used as message attributes for delivery exchanges, in inline processes or in MMDs. For MMDs, however, there are some usage exceptions (see MMD elements).

These elements are listed in the correct format. When using metadata elements, make sure to use the proper case.

Description of elements

The following are the metadata elements. In the case of MMDs, some exceptions apply. See MMD elements.

  • BusinessActivityIdentifier – RosettaNet activity identifier of the message as defined in the PIP specification. Required.
  • BusinessProtocolVersion – The version of the RNIF messages to be traded, either 1.1 or 2.0. Required.
  • CidxPackaging – For use with Chemical Industry Data Exchange (CIDX) messages only with RNIF 1.1.
  • FromGlobalPartnerClassificationCode – The role specified in the PIP. This value is from the service header.
  • FromGlobalSupplyChainCode – A value from the service content.
  • FromLocationId – The sender partner identification location ID in the delivery header. Optional.
  • FromRole – The role the trading partner sending the message plays in this PIP. Optional. Overrides GlobalPartnerRoleClassificationCode in the service content in this hierarchy:
  • fromRole

     

    GlobalPartnerRoleClassificationCode

  • FromService – The service from which the message is being sent, as defined in the PIP specification. Required.
  • GlobalBusinessActionCode – The action code corresponding to the action to which the message is in reply, as defined in the PIP specification. Required.
  • GlobalBusinessSignalCode – The signal code, if the message is a signal. This is parsed from inbound signal messages. It is not specified in an MMD.
  • GlobalDocumentFunctionCode – Required for RNIF 1.1 action messages.
  • GlobalUsageCode – Determines whether the message is to be used in Test mode or in Production mode. Required.
  • InitiatingLocationId – The initiating location identification in the service header.
  • InitiatingRoutingId – Specifies the initiating routing ID.
  • InitiatingRoutingIdKnown – Specifies whether the initiating partner is known.
  • InReplyToActionCode – This code is parsed from a signal message. The code is specified in the PIP specification.
  • InReplyToTrackingId – Helps to identify the message to which this message is in reply.
  • PipCode – RosettaNet PIP Code of the message. Set by the initiating partner. Defines what PIP code is being traded. Required.
  • PipInstanceId – The ID of this PIP instance. This must be unique within the context of the initiating partner. Optional.
  • PipVersion – RosettaNet PIP Version of the message. Set by the initiator of this transaction. Required.
  • MessageTrackingId – Uniquely identifies the message for tracking purposes. Must be unique within the context of the message sender. This value is parsed from the delivery header.
  • OriginalMessageDigest – The MIC value of the original message (in the signal).
  • ProprietaryReferenceIdentifier – The partner defined PIP payload binding ID proprietary reference identifier in the service header.
  • ReceiverRoutingId – The ID of the receiving partner. This must be a DUNS number. Optional. If not specified, the value comes from the GlobalBusinessIdentifer in the service content in this hierarchy:
  • DTD
  • toRole

     

    PartnerRoleDescription

     

     

    PartnerDescription

     

     

     

    BusinessDescription

     

     

     

     

    GlobalBusinessIdentifier

  • Schema
  • sshd:DocumentHeader

     

    sshd:Receiver

     

     

    upi:PartnerIdentification

     

     

     

    udt:*[1]

  • SenderRoutingId – The ID of the sending partner. This must be a DUNS number. Optional. If not specified, the value comes from the GlobalBusinessIdentifer in the service content in this hierarchy:
  • DTD
  • fromRole

     

    PartnerRoleDescription

     

     

    PartnerDescription

     

     

     

    BusinessDescription

     

     

     

     

    GlobalBusinessIdentifier

  • Schema
  • sshd:DocumentHeader

     

    sshd:Sender

     

     

    upi:PartnerIdentification

     

     

     

    udt:*[1]

  • service-content – The mandatory payload ID of the service content in an MMD.
  • ServiceContentDocType – The document type extracted from the service content.
  • ServiceContentMessageStandard – The document standard. The value is set on or extracted from the service header.
  • ServiceContentStandardVersion – The document standard version. The value is set on or extracted from the service header.
  • SignalDigestAlg – Defines the algorithm to use for signing a signal (the same as the one used for the original message).
  • SignalEncryptionAlg – Defines the algorithm to use for encrypting a signal (the same as the one used for the original message).
  • SignalEncryptionStrength – Defines the algorithm strength to use for encrypting a signal (the same as the one used for the original message).
  • ToGlobalPartnerClassificationCode – The role specified in the PIP. This value is from the service header.
  • ToGlobalSupplyChainCode – A value from the service content.
  • ToLocationId – The receiver partner identification location ID in the delivery header. Optional.
  • ToRole – The role the trading partner receiving the message plays in this PIP. Optional. Overrides GlobalPartnerRoleClassificationCode in the service content in this hierarchy:

toRole

 

GlobalPartnerRoleClassificationCode

  • ToService – The service to which the message is being sent, as defined in the PIP specification. Required.
  • TransactionIdentity – For RNIF 1.1 only, a unique identifier for a specific transaction (action - signal pair) within a specific instance of the process. A single-action PIP has one transaction with a unique TransactionIdentity. A dual-action PIP has two distinct transactions, each with a unique TransactionIdentity. This value is from the service header.

MMD elements

The following elements are applicable only to MMDs.

For MMDs, some names of metadata elements are slightly different than those listed in Description of elements, but the usage is the same. The following lists these discrepancies.

  • RemovePayloadAfterProcessing – Indicates ( true or false) whether Activator deletes the payload from the file system after processing the message. (MMDs always are deleted after processing.) Use of this element is optional. If not used, the payload is not deleted, which is the same behavior as using the element with a value of false. If RemovePayloadAfterProcessing is true, payloads are deleted after being picked up. This also works for the resubmit case in which payloads are retrieved from the backup directory.
  • ToRoutingId – Same as ReceiverRoutingId, earlier in this section.
  • FromRoutingId – Same as SenderRoutingID, earlier in this section.
  • ToClassificationCode – Same as ToGlobalPartnerClassificationCode, earlier in this section.
  • FromClassificationCode – Same as FromGlobalPartnerClassificationCode, earlier in this section.
  • KnownInitiatingRoutingId – Same as InitiatingRoutingIdKnown, earlier in this section.

Related topics

Related Links