Introduction to RosettaNet

Introduction to RosettaNet

by Hussein Badakhchani

11/09/2004

Abstract

This article introduces RosettaNet and the benefits it brings to B2B supply chain trading partners to the reader. We will start by looking at the origins of RosettaNet, the business processes it deals with and how it fits in with other B2B integration initiatives. Digging deeper we will examine RosettaNet’s specification structure, usage scenarios and design patterns for implementing RosettaNet solutions.

Introduction

Lets start by briefly looking at the history of e-business. The technical goal of B2B integration is to automate business processes and as a result reduce the traditional processing delays and inefficiencies associated with manual processes. If we consider e-business as the networking of business communities and digitalisation of business information then EDI (Electronic Data Interchange) is widely viewed as the beginning of e-business. The main purpose of the EDI was to avoid and prevent additional human intervention of reading and processing information between trading partners by establishing a standard data transmission protocol. Large organisations have been investing in the development of EDI since the sixties however, it did not gain reasonable acceptance until the eighties and EDI has never reached the level of popularity of the web-based e-business for several reasons:

  1. The high cost of EDI prohibited small and medium-sized enterprises from participating in electronic commerce.
  2. Slow development of standards hindered the growth of EDI.
  3. The complexity of developing EDI applications limited its adoption to a narrow user base.
  4. EDI solutions introduced their own maintenance and administrative overheads.

The lessons learned from EDI and the advance of technology has allowed new approaches to solve the problems posed by B2B integration and in realm of supply chain management RosettaNet has risen to prevalence. Founded in the US in February 1998, RosettaNet is an independent, non-profit consortium of more than 500 organisations. These organisations include some of the world’s leading Electronic Components, Computer and Consumer Electronics, Semiconductor Manufacturing, Telecommunications and Logistics companies. In 2002, RosettaNet and the Uniform Code Council, Inc. (UCC) merged to bolster the adoption and development of open e-business process standards across the industries served by the two organisations.

What is RosettaNet?

The name RosettaNet was derived from the Rosetta Stone discovered in Egypt in 1799. The stone was found near the town of Rosetta (Rashid) and was inscribed with the same message in two different languages in three different scripts and dated back to 196 B.C. Using the Greek language, scholars were able to decipher the hieroglyphic inscriptions. Much like its namesake in the 18th century, RosettaNet is a business protocol that enables enterprises to overcome the barriers to conduct business over the Internet by establishing a global language for e-business.

In a nutshell the principle goals of RosettaNet focus on the supply chain and it’s optimisation by improving efficiency and performance through enhanced B2B integration. The RosettaNet e-business process standards aim to facilitate speed, efficiency and reliability to enable greater collaboration and communication between trading partners. RosettaNet provides a common platform of communication, or a common language, that allows the different trading partners which are involved in a business process to automate that process and to conduct it over the Internet. This common platform addresses one of the major cost overheads of EDI, the fact that the IT departments of trading partners in the business process have to design, implement and test a custom business process for each trading partner they interact with. Unlike EDI and earlier B2B integration efforts RosettaNet has been designed from the ground up to incorporate security and on demand integration, this allows the traditional batch processing of business transactions which could take days to be processed in minutes.

The chief difference between EDI and RosettaNet is that EDI exchanges documents between companies, while RosettaNet defines business processes across the network and integrates them to determine the best course of action. Numerous case studies have shown that RosettaNet offers a variety if benefits over EDI, the most commonly sited of these are:

  1. Easier and more cost efficient implementation, greater return on investment (ROI).
  2. The ability to automate a greater number of business processes.
  3. Real time transaction handling as opposed by batch processing.
  4. Greater scalability.

RosettaNet and ebXML

Let’s try and put RosettaNet in context by looking at the other XML based B2B integration initiatives, namely ebXML. ebXML is often described as a horizontal B2B standard. A horizontal e-business standard is a set of specifications that is common to all e-business; it is general and not specific to any particular sector or industry. RosettaNet on the other hand is a vertical standard; it focuses on the needs of specific industries (e.g. electronic components manufacturers) and the business area of supply chain automation and optimisation. Since the creation of both initiatives there has been some duplication and convergence of the specifications in these standards, perhaps the best way to conceptualise how these standards fit in with each other is to consider RosettaNet (vertical) plugging into to ebXML (horizontal). A good example of this is the use of the ebXML Business Process Specification Schema (BPSS) to describe RosettaNet Partner Interface Processes PIPs, as we shall see latter PIPs define business process between partners.

RosettaNet, Implementation and Web Services

To see how RosettaNet sits with Web Services lets start by defining Web Services. The term Web Services will be taken to mean using SOAP and WSDL to describe and access services over the network. Many organisations have identified the benefits of using Web Services to implement their business processes, these include the open standards on which Web Services are based, the service orientated approach, and the degree of flexibility of implementation which allows re-use of existing infrastructure and skills. All of this sounds very familiar, and at this point you may be thinking if I can implement my business processes using Web Services what’s the benefit of using RosettaNet? To answer this question we need to look at business processes in more detail and to understand the difference between public and private processes.

A business process consists of a set of steps that, when executed, accomplish a certain business goal. The RosettaNet Implementation Framework (RNIF) defines private processes as business processes that are internal to the organisation and public processes as those that involve interactions with trading partners. To start with lets consider a simple business process, requesting a quote. The customer issues a request for a quote from a supplier by sending a message which contains the specifications of the quote. The supplier checks for the availability of the items in the inventory and if they can meet the requirements of the quote they send the quote to the customer. If the supplier cannot meet the requirements of the quote they may identify another supplier for the customer, in this case a referral is sent to the customer.

In this example, checking the availability of items in the suppliers inventory or identifying alternative suppliers are internal processes, they are not visible to the customer and do not involve trading partners, such processes are therefore private. Typically organisations have their own custom implementations for private processes that adhere to their own internal standards; they could utilize Java, CORBA, Web Services or any combination of legacy technologies. In the first step of our example the customer issues a request for a quote from the supplier, this is a public process. The problem of using Web Services alone to implement this step is that without a clearly defined dialog between trading partners we soon run into one of the key problems faced by EDI, in that we would have a different implementation of this service for every trading partner we want to deal with. By ensuring our Web Service implementation of this public process adheres to RosettaNet standards we can request a quote from any number of trading partners that do the same, without having to reinvent the wheel every time. RosettaNet and Web Services are thus complimentary and Web Services lend themselves as an excellent implementation mechanism for the RNIF but it should be stressed that we are not restricted to using Web Services as an implementation for RosettaNet. Private business processes can be implemented with any suitable technology including Web Services but it makes sense to ensure the public processes adhere to RosettaNet specifications as it standardises B2B communications between trading partners. In a typical implementation model we may expect to find custom Web Services to be used to handle private business processes and RosettaNet compliant services to handle public processes.

RosettaNet standards

RosettaNet standards offer a robust non-proprietary solution for e-business standardization and are free and available to the pubic via the RosettaNet Web site. The standards are developed with the collaboration and expertise of leading high-tech companies worldwide and by adhering to these standards trading partners, solutions providers and systems integrators can leverage this expertise and experience. By adopting RosettaNet trading partners can benefit from a global framework of repeatable specifications and guidelines that enables the alignment and automation of real-time, server-to-server transactions; this means global transaction visibility and consistency across the entire supply chain. Using these standardised processes also lets trading partners reduce costs, respond to customer requests faster and promotes efficient, high-integrity data processing. The standards cover the following core areas:

  1. Partner Interface Processes.
  2. The RosettaNet Implementation Framework.
  3. RosettaNet Business and Technical Dictionaries.

Partner Interface Processes (PIPs)

Partner Interface Processes (PIPs) are the result of extensive research to identify the business processes in every level of the supply chain, they are a set of generic, standardized processes that could serve as the basis for real-world business-to-business alignment. PIPs aim to encapsulate business processes by specifying the structure and format of business documents as well as the activities, actions, and roles for each trading partner. In simple terms PIPs can be defined as the choreography and message content exchanged with trading partners. We should remember that PIPs are a specification and not an implementation this gives the trading partners that adopt RosettaNet the flexibility to implement the PIP specifications themselves or to purchase third party products that reduce the development overhead. RosettaNet divides the entire e-business supply chain domain for which PIPs are specified into seven groups of core business processes called clusters and an eighth cluster that is used for administrative purposes. The clusters are:

  1. RosettaNet support: Provides administrative functionality.
  2. Partner product and service review: Allows information collection, maintenance and distribution for the development of
    trading-partner profiles and product-information subscriptions.
  3. Product information: Enables the distribution and periodic update of product and design information, including product
    change notices and detailed technical specifications.
  4. Order management: Supports the full order-management business area, from price and delivery quoting through purchase
    order initiation, status reporting and management. Order invoicing, payment and discrepancy notification are also managed using this cluster of processes.
  5. Inventory management: Enables inventory management, including collaboration, replenishment, price protection, reporting
    and allocation of constrained products.
  6. Marketing information management: Enables communication of marketing information, including campaign plans, lead information and design registration.
  7. Service and support: Provides post sales technical support, service warranty support and asset management capabilities.
  8. Manufacturing: Enables the exchange of design, configuration, process, quality and other manufacturing floor information to
    support a “virtual manufacturing” environment.

Each cluster comprises two or more segments. Segments are groups of related functionality for example Cluster 3: Order Management, has segments to manage quote and order entry as well as transportation and distribution. Segments are further divided up into PIPs and PIPs define one or more Activities, which in turn specify Actions, before we explain the difference between Activities and Actions lets look at an example of the hierarchical structure of a cluster:

  • CLUSTER 3: Order Management
    • Segment A: Quote and Order Entry
      • PIP 3A1: Request Quote
        • Activity: Request Quote
          • Action: Quote Request Action
          • Action: Quote Confirmation
    • Segment B: Transportation and Distribution
    • Segment C: Returns and Finance
    • Segment D: Product Configuration

Figure 1 is the PIP interaction diagram that shows the business roles, messages, and their sequence of exchange in the PIP.
[singlepic id=7 w=320 h=240 float=]

Figure 1. PIP Interaction Diagram

PIPs can be described as specialized system-to-system, XML-based dialogues. Each PIP specification is composed of three major parts known as views, these are:

  1. Business Operation View (BOV) which is responsible for capturing the semantics of business entities and the
    flow of information between Roles as they engage in business activities. BOVs are typically accompanied by a flow diagram.
  2. Functional Service View (FSV). The FSV is derived from the BOV and details the interactions amongst the network components during
    the execution of the PIP. The network components are known as RosettaNet “services”. In figure 1 the “Buyer” and “Seller” are two
    RosettaNet services and map onto the roles defined in the BOV.
  3. Implementation Framework View (IFV) specifies the action message formats and communication requirements between RosettaNet services
    as per the RosettaNet Implementation Framework. The communication requirements include secure transport protocols such as SSL and
    digital signatures. For message formats, RosettaNet distributes XML DTDs and Message Guidelines for the action messages that are exchanged
    when the PIP is executed. It should be noted the RosettaNet consortium intend to use W3C XML-Schemas to define the structure of Action
    and Signal messages in the future.

Activities are exchanges of business information between trading partners or more specifically trading partner roles as defined in the BOV. For example a pair of trading partners can be viewed as a Buyer and Seller. A Buyer can request a quote from a Seller and this activity is formally named “Request Quote”. Each Action maps onto a Business Document in the BOV of the PIP model that is exchanged during the course of the Activity. Earlier versions of the PIP specification included communications requirements between peer network components as of RNIF 2.0 this is no longer the case as these aspects can be derived from the BOV and FSV parts of the PIP specification.

The RosettaNet Implementation Framework (RNIF)

The RosettaNet Implementation Framework is designed to assist e-business system implementers and solution providers who wish to create or implement interoperable software application components that cooperatively execute RosettaNet PIPs. By complying with the RNIF specifications these parties can ensure their applications integrate with trading partners that do the same. RNIF defines the packaging of PIPs as well as authentication, authorization, encryption and non-repudiation requirements. RNIF 2.0 also introduces the concept of transfer independence: this ensures RosettaNet Business Messages must be delivered to trading partners in exactly the way they where generated by the senders. Currently RosettaNet specifies transfer binding and other details for the HTTP and SMTP transfer protocols. In the future other implementations will also be supported but until then developers should be aware that use of other protocols is not considered RosettaNet-compliant. In order to ensure all trading partners can support at least one transfer protocol the HTTP transfer protocol must be available from all solutions providers. The core of the RNIF 2.0 is the RosettaNet Business Message specification. Figure 2 shows the RosettaNet networked application protocol stack used to exchange RosettaNet business messages.
[singlepic id=8 w=320 h=240 float=]

Figure 2. Network Application Model

The RosettaNet Business Message

Figure 3 depicts the constituent parts of a RosettaNet Business message. The message is the basic unit of exchange between RosettaNet end points and contains the individual documents in a PIP (i.e. action and signal messages) as well as any other related entities such as headers, attachments and digital signatures. RNIF ensures that these business messages are understood by all trading partners by detailing the rules that govern their creation and choreography.
[singlepic id=9 w=320 h=240 float=]

Figure 3. PIP RosettaNet Business Message

All RosettaNet Business messages must contain a Preamble Header, a Delivery Header, a Service Header, and Service Content document. The Service Content can define an action or signal message and if it defines an action message it may also include one or more attachments. As depicted in Figure 2 all the contents of a RosettaNet Business Message are packaged together using a MIME or S/MIME multipart construct. Lets take a closer look at some of these headers and their XML document structure.

Preamble Header Instance
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE Preamble SYSTEM "Preamble_MS_V02_00.dtd">
<Preamble>
    <standardName>
       <GlobalAdministeringAuthorityCode>RosettaNet</GlobalAdministeringAuthorityCode>
    </standardName>
    <standardVersion>
	<VersionIdentifier>V02.00</VersionIdentifier>
    </standardVersion>
</Preamble>

We can see from the example instance of the Preamble XML document that it identifies the standard (RosettaNet) and its version (02.00). The values of the elements in the Preamble are fixed by the sender of the first message in the Activity and must remain fixed in all subsequent messages. The RNIF specification states that the structure of the Preamble must follow the Preamble DTD.

Delivery Header Instance
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE DeliveryHeader SYSTEM "DeliveryHeader_MS_V02_00.dtd">
<DeliveryHeader>
    <isSecureTransportRequired>
	<AffirmationIndicator>Yes</AffirmationIndicator>
    </isSecureTransportRequired>
    <messageDateTime>
	<DateTimeStamp>20041109T145200.000Z</DateTimeStamp>
    </messageDateTime>
    <messageReceiverIdentification>
	<PartnerIdentification>
	    <domain>
		<FreeFormText>DUNS</FreeFormText>
	    </domain>
	    <GlobalBusinessIdentifier>012345678</GlobalBusinessIdentifier>
	    <locationID>
		<Value>London</Value>
	    </locationID>
	</PartnerIdentification>
    </messageReceiverIdentification>
    <messageSenderIdentification>
	<PartnerIdentification>
	    <GlobalBusinessIdentifier>880123456</GlobalBusinessIdentifier>
	    <locationID>
		<Value>Hong Kong</Value>
	    </locationID>
	</PartnerIdentification>
    </messageSenderIdentification>
    <messageTrackingID>
	<InstanceIdentifier>083084</InstanceIdentifier>
    </messageTrackingID>
</DeliveryHeader>

The Service Header provides the process context for a message. It also provides information about whether the message is a Test message or a Production message, who the PIP initiator is, whether the initiator is a known or unknown partner, and Quality of Service negotiation information (which is currently unused).

Service Header Instance
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE ServiceHeader SYSTEM "ServiceHeader_MS_V02_00.dtd"> <ServiceHeader>
   <ProcessControl>
      <ActivityControl>
	 <BusinessActivityIdentifier>Create Purchase Order</BusinessActivityIdentifier>
	 <MessageControl>
	    <fromRole>
	       <GlobalPartnerRoleClassificationCode>Buyer</GlobalPartnerRoleClassificationCode>
	    </fromRole>
	    <fromService>
	       <GlobalBusinessServiceCode>Buyer Service</GlobalBusinessServiceCode>
	    </fromService>
	    <Manifest>
	       <numberOfAttachments>
		  <CountableAmount>0</CountableAmount>
	       </numberOfAttachments>
	       <ServiceContentControl>
		  <ActionIdentity>
		     <GlobalBusinessActionCode>Purchase Order Request Action</GlobalBusinessActionCode>
		  </ActionIdentity>
	       </ServiceContentControl>
	    </Manifest>
	    <toRole>
	       <GlobalPartnerRoleClassificationCode>Seller</GlobalPartnerRoleClassificationCode>
	    </toRole>
	    <toService>
	       <GlobalBusinessServiceCode>Seller Service</GlobalBusinessServiceCode>
	    </toService>
	 </MessageControl>
      </ActivityControl>
      <GlobalUsageCode>Test</GlobalUsageCode>
      <pipCode>
	 <GlobalProcessIndicatorCode>3A4</GlobalProcessIndicatorCode>
      </pipCode>
      <pipInstanceId>
	 <InstanceIdentifier>20041109T145200.000Z</InstanceIdentifier>
      </pipInstanceId>
      <pipVersion>
	 <VersionIdentifier>1.4</VersionIdentifier>
      </pipVersion>
      <KnownInitiatingPartner>
	 <PartnerIdentification>
	    <domain>
	       <FreeFormText>DUNS</FreeFormText>
	    </domain>
	    <GlobalBusinessIdentifier>880123456</GlobalBusinessIdentifier>
	    <locationID>
	       <Value>Hong Kong</Value>
	    </locationID>
	 </PartnerIdentification>
      </KnownInitiatingPartner>
   </ProcessControl>
</ServiceHeader>

A new feature of RNIF 2.0 not found in RNIF 1.1 is the support for routing RosettaNet Business messages through hubs. The Delivery Header facilitates this routing, and contains elements for the sending and receiving of trading partner identities, the date and time stamp of the message, and a globally unique tracking ID. The initiator of the message must ensure the Delivery Header is present in a RosettaNet Business Message and must be added by the initiator. As we mentioned earlier every document in the RosettaNet Business Message is packaged as a separate MIME or S/MIME part. In RNIF 2.0, some of these parts of the RosettaNet Business Message can be encrypted, including the Service Content and Service Header parts. In order to allow third-party hubs that may not have access to the encrypted Service Header to be able to route the message, the RNIF specifies the Delivery Header should never be encrypted.

RosettaNet Dictionaries

One of the core problems faced by B2B integration efforts in the past was in dealing with the uniquely defined terminology that each company used in their procurement processes. This inevitably created a lot if confusion among the trading partners. To tackle this problem the RosettaNet consortium provide a common vocabulary for conducting e-business. The RosettaNet Business Dictionary (RNBD) designates the properties for defining business activities between trading partners. This dictionary defines the Business Properties (e.g. a business address), Business Data Entities (e.g. an ActionIdentity) and Fundamental Business Data Entities (e.g. BusinessTaxIdentifier) in PIP Message Guidelines.

The RosettaNet Technical Dictionary (RNTD) provides properties for defining products and services.The RNTD eliminates the need for trading partners to use separate dictionaries when implementing multiple PIPs, what is more it is no longer industry specific, allowing it to be used in a variety of supply chain applications. The RNTD is designed to support unambiguous and automated electronic exchange of production information. This is achieved by standardising the semantics used to describe product characteristics and information. As an example lets take a look at the definition of a photocopier:

<class id="RNIC021" propDefs="RNIS001 RNIS043 RNS-XJA001">
    <identifiers>
	<code>RNIC021</code>
	<majRev>001</majRev>
	<date.def>2000-12-05</date.def>
    </identifiers>
    <names>
	<preferred.name>COPIER</preferred.name>
    </names>
    <definition.short>A machine used to make photographic copies of pages.</definition.short>
    <app.specific name="industry.domains">IT</app.specific>
</class>
Copyright © 1997 IEC, Geneva, Switzerland.www.iec.ch.

The class element, it’s attributes, and children reference the IEC international standard IEC 61360-4, entitled “Standard data element types with association classification scheme for electronic components. The RNTD reproduces extracts of this standard as well as the ECALS dictionary in XML form.

Conclusion

In this article we have become familiar with the basic concepts that make up the RosettaNet standards and we have seen how RosettaNet is complimentary to other B2B integration efforts. RosettaNet standards have been proven to deliver on their promised benefits and as a result have gained global acceptance in a relatively short space of time. One of the key strengths of any standard is the community that supports and develops it, and it is here that RosettaNet benefits from a vibrant and dedicated community.

Additional Reading

Hussein Badakhchani is a senior developer/consultant at Orbism, the system integrators and BEA partner. He has a background in software engineering most prominantly on the J2EE platform and designed, managed and implemented e-business applications in Financial, Leisure and Telecommunications sectors.

The author thanks the International Electrotechnical Commission (IEC) for permission to reproduce information from its International Standard IEC 61360-4. All such extracts are copyright of IEC, Geneva, Switzerland. All rights reserved. Further information on the IEC is available from www.iec.ch. IEC has no responsibility for the placement and context in which the extracts and contents are reproduced BEA System, Inc; nor is IEC in any way responsible for the other content or accuracy therein.