Clickable Business Models eBusiness Education Acronyms Cross References
B2B Content Standards EC Technology Standards Glossary Implementation Guidelines
Implementation Options General Recommendations References Methodology/Legends
 Home | Copyright Notice and Legal Disclaimers | Navigation Help | Tour! | Downloads | Contact Us | Site Index | Search
Implementation Options | Technical Basics | Internet Commerce Model  | Architecture |
Implementation (Technology) Options

Implementation Option 3c (RosettaNet PTP) - What You Need for Implementation  
Special Notes:  

Application Interface Software
Internet Service Provider
Implementation Plan
RNIF Requirements
   RNIF 1.1 Service Wrappers
   RNIF 2.0 Service Wrappers
Digital Certificates and Trading Partner Agreement
Other Pre-Implementation Information Exchanged
Back to Implementation Option 3c Index

All the items listed in the Basics You Need for Implementation are required, with exceptions noted below; the links in olive green below take the reader to those lists of basics.

  1. In addition to or instead of the basic Application Interface software:
    1. Many companies use back-end interfaces that already exist - that were built for legacy EDI.  However, the back-end application may need to be modified to support internet communications or communications with a new or modified gateway.  This may be the case if a new gateway is developed to support RosettaNet communications.  For outbound files, the back-end application may need to be able to identify whether a file is to be routed to the legacy gateway (for EDI) or routed through the new, RosettaNet-enabled gateway.
  1. In addition to or instead of the basic Gateway:
    1. Few companies build their own RosettaNet gateway; most companies choose the product of a solution provider.  Some solution providers obtain a badge that indicates that RosettaNet considers their solution to be compliant with RosettaNet specifications.
    2. RosettaNet requires some specific standards and methods to be used for enveloping and transporting data.   These requirements are captured in the RosettaNet Implementation Framework (RNIF), which is available on the RosettaNet web site.  RNIF requirements are discussed further below.
    3. RosettaNet is process-based.  A Partner Interface Process (PIP™ ) specification defines the choreography of an interaction, and executable code for each PIP to be implemented needs to be installed in the RosettaNet gateway.
      1. For business documents exchanged in a PIP, RosettaNet has specified the contents of business documents, using RosettaNet's own XML vocabulary.
    4. Each RosettaNet service requires the establishment of a unique URL that can be accessed by partners' networked computers.  A service is a networked application capable of participating in a RosettaNet conversation.
    5. Because communications are point-to-point, the gateway operating environment needs to support 7x24 availability of services.
  1. An Internet Service Provider is used rather than a VAN; connections are point-to-point.
  1. In addition to or instead of the basic hardware:
    1. RosettaNet gateway server
    2. Extranet gateway server
    3. HTTPS server hosted outside the firewall
    4. Requirements for communications hardware depend on whether or not a 3rd party ISP is used.
    5. Since no third-party is archiving data, it is imperative that storage devices with sufficient capacity are on hand in order to support requirements for non-repudiation.
  1. In addition to or instead of the basic Implementation Plan:
    • RosettaNet requires the use of some specific standards and infrastructure components.  The effort to implement these pre-requisites is not insignificant.
      • Product Identification:  RosettaNet requires implementation of Global Trade Item Numbers (GTIN); the "workaround" in PIPs that allow proprietary product identifiers to be used for an interim period is still considered to be a "temporary" workaround to allow companies time to implement GTINs.  GTINs are managed jointly by UCC and EAN.  A GTIN implementation guide is available on the RosettaNet web site.
      • Partner Identification:  RosettaNet requires implementation of DUNS numbers for identification of trading partners.
      • Product Classification:  RosettaNet requires the use of UNSPSC codes for product classification.  Not all PIPs messages require product classification information, so implementation of UNSPSC may not be needed for initial RosettaNet engagements.
      • Product Descriptions:  RosettaNet has specific requirements for product and product data taxonomy.
      • Partner Interface Processes (PIPs), including RosettaNet business message specifications using vocabulary from RosettaNet's Business Dictionary.
      • Dictionaries:  The RosettaNet Business Dictionary (RNBD) needs to be implemented.  Every content standard has a dictionary that needs to be implemented, and the RNBD may already be included in a solution provider's product.  Depending on which PIPs are implemented, implementing the RosettaNet Technical Dictionary (RNTD) may be required.  At the time of this writing, there is analysis underway to determine the feasibility of merging the two dictionaries into one.
      • Universal Time and Date/Time Format - RosettaNet requires all dates and times to be expressed in Universal Time, a/k/a Greenwich Mean Time.  Not all computing systems are set up to do this, and some effort may be needed to implement use of Universal time.  For executing the PIP process, this is enables the process requirements of tracking the amount of time between events in order to determine what action to take next.  For business contents of messages, it allows all times and dates in messages to be interpreted from the same frame of reference. 
        • RNIF requires that the date/time stamp used in message enveloping be in the format CCYYMMDDThhmmss.sssZ , where "CC" represents the century, "YY" the year, "MM" the month, and "DD" the day. The letter "T" is the date/time separator and "hh", "mm", and "ss.sss" represent hour, minute, and second respectively. The "Z" at the end of the date/time element indicates Coordinated Universal Time. All elements of this format MUST be present.
        • Dates contained in the business content of PIP messages must indicate Universal Time.  DateStamp must be formated as CCYYMMDDZ, and DateTimeStamp must be formatted as mentioned above for RNIF.  Not all applications handling business content have functionality for dealing with Universal Time, and so changes must be made and/or maps must include conversion logic.
        • Since trading partners may be located in different time zones, measures like timeToAcknowledge and timeToPerform should be based on Universal Time and Date.


RNIF Requirements

The RosettaNet Implementation Framework (RNIF) contains specifications for the packaging, routing, and transferring of RosettaNet business messages (including security aspects), as well as specification of business signal messages used in the execution of RosettaNet Partner Interface Processes (PIPs).  The RosettaNet Implementation Framework specifications can be downloaded from the RosettaNet web site at   Choose "Standards" then "RosettaNet Implementation Framework".

RosettaNet payloads are placed inside XML- and MIME-based transport envelopes and are sent to trading partner URI using an agreed-upon transport: HTTP(S), SMTP, others in the future.

RNIF 1.1 Defines RosettaNet Object (RNO) and specifies how to to transport RosettaNet Objects between trading partners’ network applications..  RNIF 2.0 Defines RosettaNet Business Messages and specifies how to transport Business Messages between trading partners’ network applications.

RNIF 1.1 Defines RosettaNet Object Rqmt? Encrypt?  
1. RNIF Version ID Identifies Standard and Version Yes N  
2. Service Message in MIME Packaging contains
2.1 Preamble Header Identifies Standard and Version with which the message structure is compliant. Yes No
  2.2 Service Header More info about sender and receiver; context, date and time of creation
  • Process Controls
  • Transaction Controls
  • Action Controls
  • Signal Controls
Yes No  
2.3 RosettaNet Business Document XML Payload as defined by PIP.  Specified in guidelines contained in the PIP package. Yes Yes
3. Digital Signature Uses PKCS #7 detached No N/A  
-- Digital Certificate SSL mutual authentication required Yes N/A  
RNIF 1.1 Service Wrappers (Parts) and Messages      

Acceptance Acknowledgment



Acceptance Acknowledgment Exception

Exception (ExceptionGuideline.html  
Failure Notification 0A1FailureNotificationMessageGuideline.html +.dtd  
Preamble Header PreamblePartMessageGuideline.html  
Receipt Acknowledgment ReceiptAcknowledgementGuideline.html  
Receipt Acknowledgment Exception ReceiptAcknowledgementExceptionGuideline.html  
Service Header ServiceHeaderPartMessageGuideline.html  
RNIF 2.0 Defines RosettaNet Business Message in MIME packaging Rqmt? Encrypt?  
1. Preamble Header Identifies Standard and Version with which the message structure is compliant. Yes No  
2. Delivery Header Contains IDs of sender and receiver, and message instance info (tracking data); this is non-encrypted information that can be read by a hub/VAN. Yes No  
3. Encrypted Payload Container in S/MIME Envelope      
3.1 Service Header Identifies the PIP and PIP instance information, including more info about sender and receiver, context, date and time of creation; includes test/production flag. Yes Optional
  3.2 Service Content XML Payload as defined by PIP.  Specified in guidelines contained in the PIP package. Yes Advised  
  3.2 Attachments Any payload that can be handled by partner No Advised  
4. Digital Signature Uses PKCS, S/MIME No N/A  
-- Digital Certificate SSL mutual authentication required Yes N/A  
RNIF 2.0 Service Wrappers (Parts) and Messages      
Delivery Header DeliveryHeader_MS_V02_00.html + .dtd  
Exception Exception_MS_V02_00.html + .dtd  
Notification of Failure 0A1_MS_V02_00_FailureNotification.html + .dtd  
Preamble Header Preamble_MS_V02_00.html + dtd  
Receipt Acknowledgment AcknowledgmentOfReceipt_MS_V02_00.html +.dtd  
Service Header ServiceHeader_MS_V02_00.html + .dtd  

Receipt Acknowledgment can be sent upon completing:

1. Message Grammar Validation. Messages are validated against an alphabet, punctuation, vocabulary and set of syntax rules.
2. Message Sequence Validation. Message sequences are validated against a set of sequence rules.
3. Message Schema Validation. Messages validated against a set of structure rules that specify entity composition, cardinality and format.

In RNIF 1.1, there was a Acceptance Acknowledgment that could be sent after Message Content Validation, but no one was really using it.  Message content is validated against a set of business rules that specify necessary conditions for further business processing.

Digital Certificates and the Trading Partner Agreement

Digital Certificates are not required by RosettaNet, but are advised.  The following is a list of items that Trading Partners currently need to agree to between themselves.

Other Pre-implementation Information Exchanged


Last updated 02 March 2003