This post was updated to reflect current trends and information.

 

This article is dedicated to B2B EDI Integration using RosettaNet standard. It describes the RosettaNet business-to-business (B2B) standard, RosettaNet terminology such us PIPs (Partner Interface Processes), RNIF (RosettaNet Implementation Framework), Action Message, Signal Message, and other key RosettaNet features. The information in this topic will be helpful to understand RosettaNet standards and concept before its implementation.

Overview of RosettaNet

RosettaNet is a group of Technology corporations that have created and implemented B2B protocol standards. These standards define the exchange of electronic business documents. RosettaNet is one of B2B protocol standard which allows different businesses to communicate electronically over a network.

The RosettaNet description from Wikipedia is: “RosettaNet is a consortium of major Computer and Consumer Electronics, Electronic Components, Semiconductor Manufacturing, Telecommunications and Logistics companies working to create and implement industry-wide, open e-business process standards. These standards form a common e-business language, aligning processes between supply chain partners on a global basis.”

What Is RosettaNet Standards?

RosettaNet it is one of the EDI (Electronic Data Interchange) standards for exchanging business messages using HTTP(S) with MIME headers. As Identifiers RosettaNet uses DUNS numbers. RosettaNet messages contain a Preamble, Delivery Header, Service Header, and Service Content. RosettaNet Standards are free and open to the public as well as private organizations and individuals. You can have access to standards on RosettaNet website.

RosettaNet is used in the IT Supply Chain by (3) main industries:

• Electronic Components
• Semiconductor Manufacturing
• Information Technology

RosettaNet Implementation Framework (RNIF)

The RosettaNet Implementation Framework (RNIF) is an open, common networked-application framework generated to allow trading partners to exchange RosettaNet PIPs.

The RNIF regulate implementation guidelines for developing software applications components that simplify the RosettaNet PIP messages fulfillment between business partners. Recommendations are provided for packaging, security, transport, routing, signals, trading partner agreements.

In simple words, RNIF defines how to build, parse, secure, and send RosettaNet messages.

 RNIF Version 1.1 and RNIF version 2.0 key features comparison

There are two versions of RNIF:

• RosettaNet Implementation Framework v1.1 (RNIF 1.1)
• RosettaNet Implementation Framework v2.0 (RNIF 2.0)

The table below describes some RNIF version 1.1 and version 2.0 implementation guidelines.

Guideline	RNIF Version 1.1	RNIF Version 2.0
Transport	Supports the secure HTTP transport   protocol for exchanging messages   between trading partners	Supports multiple transport   protocols  (such as secure HTTP and   SMTP)
Packaging	Supports the format (RNO)   RosettaNet Object.	Supports the Internet standard that   extends the format of email   Multipurpose Internet Mail   Extensions (MIME) format
Authorization	Guarantee that the sender of the message is allowed to send a message to the   receiving partner.
Encryption	Not provides	Guarantees that transmitted messages   can be seen only by the expected   recipient, who is able to decrypt and   extract the information.
Authentication	It is required a digital signature from the message sender
Nonrepudiation	Provides total proof that a certain action has occurred. The following       nonrepudiation  types are available: •  The digital signature of the message. This prevents the sender from   attempting to reject the sending of the message. The recipient of the message   must keep the message for an agreed period of time (usually three to seven   years). •  Send back a signed acknowledgment. The message recipient has to store   both the receipt and the original message for an agreed-on period of time.

RNIF may be used different protocols such as HTTP, HTTPS, Simple Mail Transfer Protocol (SMTP)

What Is RosettaNet Partner Interface Process (PIPs)?

In RosettaNet, a Partner Interface Process (PIP) defines a fulfillment of a business transaction between trading partners. The principal objective of PIPs, is the exchange of business data between trading partners. PIPs determine the messages structure, steps order, role (buyer and seller) activities, values, for each message transmitted between trading partners. Compliance with these specifications allows the trading partners to achieve business goals.

PIPs require the following:

• A specific business result (for example, the receipt of a purchase order from a trading partner)
• A role to fulfill at least one action (for example, a buyer role requests a Purchase Order from a seller role and a seller role submits a Purchase Order Acknowledgment to the buyer role).

Each partner has to fulfill his specific requirements of the PIP. If one trading partner does not satisfy his requirements, then the business transaction is voided for all participating PIP trading partners.

What does a PIP document look like?

A PIP in its entirety consists of:

• Preamble
• Delivery Header (if using RNIF 2.0)
• Service Header
• Service Content (the actual data – the Purchase Order, Advance Ship Notice, etc.) 

 PIP Classifications

RosettaNet PIPs are classified into seven clusters. Each cluster is broken down into segments, within each segment, individual PIPs contain one or more activities, which specify actions to be performed.

Here is a list of the PIP clusters:

Cluster 0: RosettaNet Support. Delivers administrative functionality.

• Segment 0A: Administrative.
• Segment 0C: Testing.

 Cluster 1: Partner Product and Service Review. Collect information of trading partner and product-information subscriptions.

• Segment 1A: Partner Review
• Segment 1B: Product and Service Review

 Cluster 2: Product Information. Distribution and periodic update of product notices and product technical specifications.

• Segment 2A: Preparation for Distribution
• Segment 2B: Product Change Notification
• Segment 2C: Product Design Information

 Cluster 3: Order Management. Supports full order management business area.

• Segment 3A: Quote and Order Entry
• Segment 3B: Transportation and Distribution
• Segment 3C: Returns and Finance

 Cluster 4: Inventory Management. Inventory management, including reporting and allocation of constrained product.

• Segment 4A: Collaborative Forecasting
• Segment 4B: Inventory Allocation
• Segment 4C: Inventory Reporting
• Segment 4D: Inventory Replenishment
• Segment 4E: Sales Reporting

Cluster 5: Marketing Information Management. Communication of marketing information.

• Segment 5C: Design Win Management (EC)
• Segment 5D: Ship from Stock and Debit (EC)

Cluster 6: Service and Support. Post-sales technical support.

• Segment 6A: Provide and Administer Warranties, Service Packages, and Contract Services.
• Segment 6C: Technical Support and Service Management

Cluster 7: Manufacturing. Exchange of design, configuration, process, quality and other manufacturing floor information.

• Segment 7B: Manage Manufacturing WO & WIP.
• Segment 7C: Distributed Manufacturing Information.

Type of RosettaNet Messages

Messages related to PIP business document exchange can be divided into two categories: Business Action messages and Business Signal messages. The Business Action message is the basic business message such as a Purchase Order or Request for Quote, that is exchanged within a RosettaNet trading process. The Business Signal message is a positive or negative Acknowledgment message sent in response to a business Action Message. RosettaNet has five types of business Signal Messages:

Receipt Acknowledgment

A Receipt Acknowledgment is a positive signal acknowledging receipt of a Business Action message. It is sent when structurally and syntactically valid RosettaNet action.

Receipt Acknowledgment Exception (supported only in the RNIF 1.1.)

A Receipt Acknowledgment Exception is a negative signal indicating a problem (structurally or syntactically invalid RosettaNet action).

Acceptance Acknowledgment (supported only in the RNIF 1.1.)

An Acceptance Acknowledgement is a positive signal acknowledging. This message sent when a partner receiving accepts the RosettaNet Action Message for processing. The signal does not indicate a success or failure of message processing.

Acceptance Acknowledgment Exception (supported only in the RNIF 1.1.)

An Acceptance Acknowledgement Exception is a signal indicated a negative acknowledgment of acceptance A message is sent when the partner receiving the RosettaNet action message cannot accept the message for processing in the backend system.

General Exception

A General Exception is a negative signal. It’s signified that actions performed by processes outside of RosettaNet caused an error.

Note: Business Action messages are acknowledged. Business Signal messages are never acknowledged. The following figure shows a message flow: 

 Structure of a RosettaNet Business Messages

A business message exchanged between trading partners via RosettaNet 1.1 protocol is called RosettaNet Object (RNO).

The business message exchanged via the RosettaNet 2.0 protocol, is called RosettaNet Business Message (RBM).

RNIF 1.1 and RNIF 2.0. have different basic message structure.

RosettaNet Object (RNO) for RNIF 1.1

The RNIF 1.1 message has the following structure:

• Version – Specifies the RNIF version (1.1), in binary format.

• Content Length – Length of the multi-part MIME message, in binary format.

• Headers – Comprises the next headers:

• Preamble Header
• Service Header

• Content (Payload) – Contains the following components:

• Service Content—contains either an action or a signal message.
• Attachments—Optional. Can contain zero or more attachments, which comprise of XML and non-XML (binary) data. It can be attachments such as PDF files, Word documents, GIF images, and other. The information for each attachment is included in the Service Header of the message.

• Digital Signature (Optional)

• Length of the signature in binary format.
• Signature (PKCS7) in binary format.

RosettaNet Business Message (RBM) for RNIF 2.0

The RosettaNet Implementation Framework 2.0 presented the notable differences in the components of a RosettaNet Business Message (RBM):

• In the version RNIF 2.0 the Delivery Header was added.

• In RNIF 2.0 the Service Header and Content can be encrypted.

The figure below shows the components and structure of an RBM: 

• Headers. Includes the following headers:

• Preamble Header
• Delivery Header
• Service Header

All headers are essential and there is only one header of each type, per message. The general purpose of these headers is that the recipient can:

• Recognize the message as a RosettaNet Business Message
• Identify the context of the message
• Identify the sender for authentication and authorization.

• Payload. Includes the following components:

• Service Content—Contains either an action or a signal message.
• Attachments—Optional. Can contain zero or more attachments, which comprise of XML and non-XML (binary) data. It can be attachments such as PDF files, Word documents, GIF images, and other. The information for each attachment is included in the Service Header of the message.

EDI ANSI X12 and RosettaNet PIPs Cross reference

In the process of computer-to-computer exchange of business documents, such as purchase orders, invoices etc. with a Trading partner, exchanging documents occurs in a standard electronic format. It can be standards such as ANSI X12, EDIFACT, or RosettaNet in the high-tech industry. In each standard, there are different requirements for electronic documents and they can be called differently. On the example below, you can see the comparison of two standards ANSI X12 and RosettaNet.

• ANSI X12 EDI 810 Invoice – RosettaNet PIP 3C3 Notify of Invoice
• ANSI X12 EDI 846 Inventory Inquiry/Advice – RosettaNet PIP 4C1 Distribute Inventory Report
• ANSI X12 EDI 850 Purchase Order message – RosettaNet PIP 3A4 Request Purchase Order
• ANSI X12 EDI 855 Purchase Order Acknowledgment – RosettaNet PIP 3A20 Notify of Purchase Order Confirmation
• ANSI X12 EDI 856 ASN (Advance Ship Notice) – RosettaNet PIP 3B2 Notify of Advance Shipment
• ANSI X12 EDI 860 Buyer triggered P/O change – RosettaNet PIP3A8 Request Purchase Order Change

Trading Partner Integration

Our company focuses on the integration of Trading partners, which is also known as business-to-business integration (or B2B Integration). For more than 18 years we have been automating business processes and helping our clients, manage business relationships with their trading partners. We are EDI Integration experts and we have a strong expertise around RosettaNet. So, if you need help with RosettaNet or any EDI Integration contact us today.