edi b2b integration

This post was updated to reflect current trends and information.

In my previous article Seamless EDI implementation through Web Services, I covered various types of web services. Perhaps, if you’re still worried about choosing between SOAP or REST for your EDI implementation, this brief comparative review should help you make a choice. But in any case, you should remember that the focus of your decision must concentrate on which web service best responds to your needs.

First, look at the difference between the SOAP and REST request and response packets.

Here is a SOAP request and response packets:

Here is a REST request and response:

What is difference between SOAP and REST Web services?

1. SOAP actively uses XML to encode requests and responses, as well as strong data typing, ensuring the integrity of the information is intact, during transmission between the client and the server. On the other hand, requests and responses in REST can be transmitted in ASCII, XML, JSON or any other formats that can be recognized by both the client and the server. In addition, there are no built-in data type requirements in the REST model. As a result, the request and response packets in REST are much smaller than their corresponding SOAP packets.

2. In the SOAP model, the HTTP data transfer layer is a “passive observer,” and its role is limited to sending SOAP requests from a client to the server using the POST method. Service request details, such as the remote procedure name and input arguments, are encoded in the request body. Opposite of SOAP the REST architecture, considers the HTTP data transfer layer as an active participant in an interaction using existing HTTP methods, such as GET, POST, PUT, and DELETE, to indicate the type of service requested. Therefore, from a developer’s perspective, REST requests are generally simpler to be formulated and understood since they use existing and well-understood HTTP interfaces.

3. The SOAP model allows service developers to describe its APIs in a Web Service Description Language (WSDL) file format. Creating these files is quite difficult, but it’s well worth the effort since SOAP clients can automatically retrieve detailed information from these files. For example, about the names and method signatures, input and output types and return values. On the other hand, the REST model avoids the complexity of WSDL in favor of a more intuitive interface based on the standard HTTP methods described above.

4. At the “heart” of REST is the concept of resources, while SOAP uses interfaces based on objects and methods. The SOAP interface can contain an almost unlimited number of methods; the REST interface, in contrast, is limited to four possible operations, corresponding to the four HTTP methods.

Useful link: Download EDI Web Service overview.

This EDI Web Service overview covers the following topics:

What is EDI2XML Web Services?
Advantages of using EDI2XML HTTP service
Who is EDI Web Service for?

The best Web Service for EDI

EDI2XML Web Service, is for developers, systems integrators and businesses, interested in building their own EDI (Electronic Data Interchange) integration flows and programs. Normally, these individuals, are capable of interacting with external API and Web Services to translate EDI to XML and XML to EDI, and have the resources and expertise to work with Web Services and HTTP requests in order to achieve their goals. EDI2XML web service, is the premier choice for IT people as a reliable service to accomplish such Integration projects.

The best way to discover how REST works for EDI is to try our free 15- days trial version of EDI2XML Web Service.

Click here to request the price list in order to access EDI2XML Web Service

Continue Reading About Web Service:

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.

Tag Archive for: edi b2b integration

SOAP or REST Web Services: what you should use for EDI implementation?