Related Topics: XML Magazine

XML: Article

The RosettaNet Standard

The RosettaNet Standard

This month's focus is on RosettaNet-related questions. As my company is a serious player in this market, I've received quite a few inquiries about the so-called lingua franca of supply chain software. I'd like to alert my readers, however, that many of the issues discussed stretch way beyond the smaller domain of RosettaNet and deep into the broader ocean we call the XML marketplace.

Let me begin with a quick paragraph on RosettaNet and then I'll respond to questions concerning schemas, DTDs, and all things PIP (Partner Interface Processes) related. RosettaNet is a consortium of roughly 400 large supply chain companies from three major industries (semiconductor manufacturing, electronic components, and information technology). Their goal is 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" (from the RosettaNet Web site at
rosettanet/Rooms/DisplayPages/ LayoutInitial
). In a nutshell, RosettaNet is striving to create a common set of standardized processes for the electronic sharing of information over the Internet or other electronic medium. Now, on to the questions...

Q: How do you think PIPs will evolve?
A: PIPs are where the RosettaNet standard meets the road. PIPs are the implementable building blocks of RosettaNet-based transactions. In its simplest form a PIP represents the electronic version of a traditionally paper-based transaction. For example, purchase orders have traditionally existed as paper-based documents either mailed or faxed directly from buyer to seller. PIP 3A4 is an XML-based representation of that same paper document in electronic format. PIP purchase orders can be sent electronically over HTTP, SMTP, FTP, and so on.

One thing I'm certain of is that PIPs are here to stay. Since PIPs represent the most implementable part of any RosettaNet system, replacing them entirely is out of the question. What's going to happen in the future is that the specifications used to define a PIP are going to change.

Currently, PIPs are defined using two very different documents, and in some cases multiple documents, as is the case with PIP 2A9. For this discussion, however, I'll focus only on the two documents. The first is a DTD (Document Type Definition). DTDs are older carryover documents that were prevalent in the SGML world and have been quite useful in the newer XML world. The PIP DTD defines the overall document structure of the PIP XML document as well as the cardinality, hierarchy, and mandatory/nonmandatory elements that make up the PIP. A DTD is similar to an XML-formatted document.

The second document, the Message Guideline (MGL), is an HTML file that goes one step further in defining our PIP document. The MGL defines not only structure, but also the allowable values for given elements within the PIP document. For example, in PIP 3A4 R02.00 PO Request, the DTD defines an element called "GlobalPartnerRoleClassificationCode" as being a mandatory child element of "PartnerRoleDescription". In addition to knowing that we must include that element in our PIP 3A4 document, the MGL also defines the allowable value(s) for that element. In the case of "GlobalPartnerRoleClassificationCode" for PIP 3A4, the only allowable value is "Buyer". In this way the DTD and the MGL together play an important part in the overall makeup of a PIP document.

In the future, the DTD and the MGL will be replaced by a single XML Schema (XSD) document that will offer advantages over the current DTD and MGL in several areas. A single XSD file will provide solution providers and systems integrators with a single source to define the PIP. An XSD file is machine readable, which will increase the time necessary for solution providers to support new PIP standards. Finally, the current DTD and MGL model presents some challenges when there are discrepancies between the DTD and the MGL.

Because the MGL file isn't machine readable, many vendors simply use the DTD as their authoritative source for the definition of the PIP. The drawback to that approach is that when discrepancies occur, RosetttaNet has stated that the MGL should be referenced as the authoritative document. The move to XSD will eliminate this problem.

Note: In addition to the DTD and the MGL, RosettaNet also defines several local and global dictionaries for use with PIPs. These documents are important, but a full discussion of their value and future is outside the scope of this article. Q: How hard are PIPs to work with?
A: In my experiences so far, the PIPs have been the easiest parts of an implementation. Most of the implementations we've done to date have involved the RosettaNet Basics PIPs (PIP 3A4, 3A7, 3A8, 3A9, and 3B2). In some cases - PIP 3A4, for example - multiple versions of the same PIP are available from RosettaNet. The partner companies we most often work with are connecting into an already established RosettaNet business process at their trading partner. The partner with the existing RosettaNet infrastructure usually dictates which version of the PIP they'd like to use. Once the PIP and PIP version have been identified, the real integration work begins. The PIP message itself is simply an XML-formatted document that provides placeholders for your business data.

Most business data resides in some type of relational back-end system like MS SQL or Oracle. The process of "mapping" your data from the back-end system to the PIP document is often the most time-consuming part of any integration effort. Tools and SDKs available from a multitude of vendors help to reduce this time.

Q: Is the technology behind RosettaNet solid? A: In my opinion, absolutely. When you think about the RosettaNet standard, it's best to think of it in two parts. Part 1 is the PIP. The defining specifications for PIPs are DTDs and MGLs, with XSD specifications just around the corner. XML has now been in the marketplace for four years and has gained widespread adoption. Any specifications leveraging XML as their underpinning, especially data exchange specifications, are certainly headed in the right direction. The movement from the legacy DTD format to the newer, pure XML-based XSD format is also a clear indication of RosettaNet's forward-thinking vision.

Part 2 is RNIF (RosettaNet Implementation Framework). RNIF leverages several existing standards, including HTTP, HTTPS, SMTP, MIME, XML, and SOAP (coming in RNIF 3.0). In addition, because the RosettaNet architecture is decoupled into PIP and RNIF components, the replacement of RNIF with an equivalent ebXML or other standard is relatively easy and straightforward. RNIF-level services can even be augmented by services provided by other frameworks (RNIF 3.0 will take advantage of ebXML's BPSS - Business Process Specification Schema). When you combine XML, HTTP, MIME, and SOAP with the ability to incorporate emerging standards into the existing framework, you've built one very solid foundation for the future.

Q: How hard is RosettaNet to implement? Can you give us some issues to be prepared for?
A: Conducting RosettaNet-based transactions between two or more companies used to be a very challenging endeavor. In some instances it could take up to six months for a trading partner to implement just one PIP. With the rapid adoption of RosettaNet by many large supply chain companies, and with the steady improvements of B2B software offerings, implementing RosettaNet-based transactions has become easier than ever before. Nonetheless, there are still challenges to be overcome:

  • Interoperability: Solution providers who currently provide RosettaNet functionality in their offerings have come together and begun an initiative, together with RosettaNet, to perform interoperability trials. These trials will ensure that each vendor's RosettaNet implementation can communicate with every other vendor's solution at the RNIF level. In addition, the RosettaNet compliance program is aimed at providing interoperability at the PIP level. Together, these two programs will help to ensure that the B2B software solution you choose can communicate efficiently with your trading partner's system.
  • Trading Partner Agreement: Most companies that transact business with partners have some form of TPA currently in place. Anything from a handshake to a legally binding document represents an agreement between companies as to the particulars of their business interactions. An electronic form of this TPA is required for RosettaNet-based transactions. In addition to the specific roles that companies define for their interactions (buyer, seller, shipper, etc.), other RosettaNet-specific details must be addressed in the electronic TPA.

    For example, RosettaNet transactions define default values for Time to Acknowledge and Time to Perform operations. The former represents the time period that you will allow your partner to respond to a message you've sent. The default is two hours for most PIPs, but you and your partner may decide that the pace of your business interactions is time sensitive and that you need to reduce that time so the transactions meet your business needs.

    In addition to these settings, you and your partner also need to define the communication protocol (HTTP HTTPS, SMTP) and other variables for your electronic TPA to be complete. Time spent ahead of time defining these parameters will greatly reduce your time to implement.

  • Partner's Implementation: An understanding of the RosettaNet B2B solution that your partner uses, as well as an understanding of their internal processes, is often of great value. While the interoperability trials I mentioned earlier are still going on, many solution providers are compiling their own internal DBs of known issues with certain vendors. The ability to tap into that knowledge will help to reduce integration efforts significantly. Understanding how your partner does business from a process standpoint is also important. Do invoices normally take two to three business days to process? Do they typically respond to purchase order requests the same day? Given that most companies already have an existing relationship in place, this step should be fairly easy. The more knowledge you have about how the process works today, the better off you'll be when the time comes to do your RosettaNet implementation.

More Stories By Trace Galloway

When he’s not diving for lobsters, Trace Galloway is a Sr. Sales Technologist for Infoteria Corporation (, an XML software development company based in Tokyo and Beverly, Massachusetts. He is an expert in XML and XSLT technologies and specializes in RosettaNet B2B implementations.

Comments (0)

Share your thoughts on this story.

Add your comment
You must be signed in to add a comment. Sign-in | Register

In accordance with our Comment Policy, we encourage comments that are on topic, relevant and to-the-point. We will remove comments that include profanity, personal attacks, racial slurs, threats of violence, or other inappropriate material that violates our Terms and Conditions, and will block users who make repeated violations. We ask all readers to expect diversity of opinion and to treat one another with dignity and respect.