Wednesday January 31, 2007 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. Most of the delays in traditional process used to happen due to delay in human intervention.
Came ”Electronic Data Interchange” (EDI) for rescue. The main purpose of EDI was to avoid and prevent additional human intervention in reading/processing information between trading partners by establishing a standard data transmission protocol. EDI was developed in the 1970’s. It is/was generally used by organizations to manage their supplier-receiver relationships. These business relationships are portrayed as messages. The communication here is not open to all corners and happens between companies with pre-established relationships.
There exist three players in an EDI message exchange:
1) Message sender.
2) Message receiver.
3) EDI Value Added Network (VAN)
EDI VAN is responsible for delivering/receiving the message. Its role is not just of sending/receiving packets. It is a "store and forward" network that can accept and queue messages for deferred delivery. It can also be assigned role of a watchdog to corroborate in order to resolve disputes between senders and receivers.
The lessons learned during EDI development and the advance of technology has given birth to new approaches to solve the problems posed by B2B integration. One such successor to EDI is RosettaNet
RosettaNet is a business protocol based on XML. It enables enterprises to overcome the barriers to conduct business over the Internet. 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 that allows the different trading partners involved in a business to automate and communicate over the Internet. In the days of EDI, trading partners in the business process have to design, implement, and test a custom business process for each trading partner they interact with. RosettaNet on other hand has been designed to facilitate on-demand integration.
RNIF – RosettaNet Implementation Framework
RNIF is an implementation of RosettaNet standards and was designed to facilitate communication among trading partners through PIP’s.
RosettaNet PIP’s define the processes in which trading partners participate while performing e-business transactions. Trading partners participating in PIP’s need to implement the process specified in the PIP.
PIP’s essentially define set of sequential steps needed to execute a business process between supply-chain partners (e.g., Purchase Order Management). PIP specification also includes structure and content format (XML schema) of business formats being exchanged along with security, authentication and performance constraints. PIP also contains detailed validation rules for messages being exchanged. These validation rules are expressed in XML schema documents (XSD), which are included with the PIP templates.
RNIF as of today is available in two flavors -
RNIF 1.1 and RNIF 2.0
Some of the key differences between 2.0 & 1.1 are -
> 2.0 is more well-defined, robust, and interoperable as compared to 1.1.
> 2.0 supports SMTP in contrast to 1.1, which supports HTTP/HTTPS only. 2.0 also introduces protocol independent message format.
> 2.0 defines a mechanism to utilize transfer 'protocol level debug headers'. These headers carry info along with message being transferred. This enables return of meaningful errors to sender even if receiver fails to process message.
> 2.0 introduced option to encrypt Service Header which also carries sensitive info along with Payload.
RNIF in JavaCAPS
Support for RNIF business protocol will be available in coming versions of B2B Suite (eXchange 5.1).
Will be posting details on how RNIF Protocol works shortly.
-Update-
Sun's B2B Suite (eXchange 5.1) will be released on March 6, 2007. the Rosettanet Delivery Protocol will be available for B2B Champion Customers late March and should be GA by May, 2007. please note that this is the RNIF protocol and NOT the PIPS documents. The PIPS documents can be supported through the OTD wizard.