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,
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
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.
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.
For business documents exchanged
in a PIP, RosettaNet has specified the contents of business documents,
using RosettaNet's own XML vocabulary.
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.
Because communications are
point-to-point, the gateway operating environment needs to support
7x24 availability of services.
RosettaNet requires the use of some
specific standards and infrastructure components. The effort to
implement these pre-requisites is not insignificant.
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
EAN. A GTIN
implementation guide is available on the RosettaNet web site.
RosettaNet requires implementation of
DUNS numbers for
identification of trading partners.
RosettaNet requires the use of
for product classification. Not all PIPs messages require product
classification information, so implementation of UNSPSC may not be needed for
initial RosettaNet engagements.
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.
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
Dates contained in the business content
of PIP messages must indicate Universal Time. DateStamp must be formated
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
Since trading partners may be located in
different time zones, measures like timeToAcknowledge and
timeToPerform should be based on Universal Time and Date.
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
www.rosettanet.org. Choose "Standards" then "RosettaNet
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
Standard and Version
Service Message in MIME Packaging contains
Standard and Version with which the message structure is compliant.
More info about
sender and receiver; context, date and time of creation
XML Payload as
defined by PIP. Specified in guidelines contained in the PIP
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.
If the fields in the digital certificate do not uniquely identify the user
within the Initiating Organization then trading partners must agree to use
additional mechanisms (in conjunction with use of the certificate for
authentication) to convey a unique user ID as part of user access to services.
RosettaNet does not specify the level or class of certificate to be used nor
does it specify other certificate policies. These decisions are left to the
discretion of individual organizations in conjunction with their key trading
By agreeing to a short term certificate validity period, e.g. 6 months,
trading partners can mitigate the risk of fraudulent certificate use in the
absence of a certificate list revocation infrastructure.
Trading partners should discuss possible authentication failures and how these
will be handled (e.g. RosettaNet certificate is not available, certificate not
signed by the expected Certificate Authority, certificate expired, they do not
accept the authenticated name of the other server, etc.)
Trading partners should discuss how to deal with certificate revocation
information given the lack of support for a certificate revocation list (CRL) in
browser and server software. Applications can be designed to check a CRL as part
of authorization if it is available. In all cases, the use of CRL information
should be dictated by the value of the information that is protected.
Trading partners may exchange certificates for servers (and authorized
signers) as part of the process of establishing a RosettaNet-based trading
partnership. A trading partner database might contain trading partners
certificates (including public keys) as well as mappings to trading partner IDs,
server-related information, electronic mail addresses, shipping and billing
addresses, tax status, pricing algorithms, catalog views, etc.
Other Pre-implementation Information Exchanged
Trading partners are responsible for negotiating SSL ciphers and key lengths
for RosettaNet transactions. In all cases however the selected cipher suite must
provide at least 40-bit encryption and must ensure that authentication occurs,
i.e. Diffie-Hellmann without certificates should not be used.
Trading partners must agree on a method for exchanging and maintaining valid
URL’s for each of their networked application where necessary.
Trading partners must agree to use only the DUNS number
to identify companies in a message exchange. If no agreement is reached
then all the company identification information must be provided in a
message exchange e.g. name, address, etc.