Exception handling in Rosettanet

While processing an inbound RosettaNet message, there are chances of the message being erronous due to vaious reasons.

The likely cause could be in
1.Rosettanet Exchange specific values mismatch in either service header or delivery header
2.Error Document validation

In this case, B2B will send an exception message back to the trading partner. This is an automatic process of creating the exception message and sending back to trading partner and this does not need any additional configuration.

It is different from PIP 0A1 processing. In the case of PIP 0A1, an Exception message is trigger by B2B Engine for any error/exception, where as NOF has to be sent by the Back end application.

Time to perform /Time to Acknowledge

Time to perform : Time to perform is an important concept in Rosettanet implemented by Oracle B2B to define the timeout of a collaboration . It can be defined in the transaction level or collaboration level. It is defined as the time in minutes to perform or complete the transaction. If there is a failure to complete the collaboration with in the specified time, then b2b errors out the collaboration. This configuration can be seen as part of defining Transaction or collaboration.

This value can be overridden specific to Trading Partner.

Time to Acknowledgement : This defines the time with in which the Acknowledgment message must be received. If an Acknowledgment message is not received then B2B retries based on the retry count and failure in getting the Acknowledgment results in error.

Rosettanet Exception handling in B2B

Exception/Error handling in Rosettanet

RosettaNet is an e-business standard based on XML which is predominently used in the High Tech Industries for the supply chain management needs. This standard talk about rapid, reliable process interaction between different trading Partner, and also about transport and packaging requirement.

Partner Interface Process (PIP) defines the sequence of steps required to execute a business process between two trading partners. PIPs are specialized, XML-based dialogs that define the structure, sequence of steps, role activities, data elements, values, and value types for each business document message exchanged between trading partners.

The RosettaNet Implementation Framework (RNIF) is a collection of specifications used to implement message exchange between trading partners over the Internet. It covers Transport,Packaging,Authorization,Authentication,Encryption and
Nonrepudiation.

Rosettanet Specification refers to two types of errors, in-band and out-of-band.

1. in-band error : This occurs during collaboration such as General exception and Receipt Acnowledge exception.

2. out- of -band error : This ocurs outside collaboration resulting in generation of 0A1. For e.g failure related to
time to perform, retry count etc. Currently B2B is not supporting this.

Exception scenarios

1. Outbound PO Processing : Back end application send the message to B2B, for any exception B2B sends the B2B Exception to Back end application.

2. Inbound PO Processing : For any message which failed during inbound PO processing, B2B sends RNIF exception to trading partner, Trading partner in turn has to consume the RNIF exception and generate a B2B exception corresponds to it.

3. Outbound POA Processing :For any message which failed during outbound POA processing, B2B sends RNIF exception to trading partner and B2B Exception to Back end application. Trading partner consumes the RNIF exception and sends B2B Exception to Back end application.

4. Inbound POA Processing :For any message which failed during inbound POA processing,B2B sends B2B Exception to Back end application.

How to handle Host/Trading partner with Multiple Idenfier

Lets consider an organization which has multiple business units with different Trading Partner Identification of same Type.

e.g Host has multiple DUNS number as identification with value 111111111 and 222222222.


This feature provides a capability to handle Multiple DUNS eventhough it is not part of the agreement, but still present as part of the Trading partner Idenfitification.

Outbound:
For outbound messages, instead of setting the AQ header 'From' as Name Identification set it as DUNS:value

e.g DUNS:111111111 and the same is applicable to 'To' attribute in the AQ header.

In this case, B2B will use the identification type and value
for Agreement Identification and also for populating the exchange headers.

Inbound:

As part of the Trading partner Identification B2B compares the Exchange identifier with various Identification value of the same exchange Identifier type.

For e.g For an incoming document with Trading partner DUNS: 333333333, it compares with all the DUNS number of the Trading Partner. If any one of the DUNS number matches it identifies the appropriate Trading partner. The identified trading partner name is used for Agreement identification.

Added a new Exchange Parameter for EBMS Exchange:SendPartyTypeAndValue and the value for this parameter could be true/false. Default value is false. If the value is true, b2b will enqueue partyid:value to FROM/TO Trading partner.

For specifying a different seperator than : , set the following property.

oracle.tip.adapter.b2b.partyTypeAndValueSeparator=;

B2BSP - B2B service Provider

B2B Commerce Sdn Bhd is a B2B service provider which we help our customer in daily document exchange process. Our customer can be SME or MNC which have different needs.

What we do daily is receive document from sender via either our client software or standard protocol like AS2 or RNIF and perform data translation or transformation, such as data mapping and transform csv file into EDI file using our in-house product, after all these translation and transformation. Then only send the document to receiver.

What is our value, we help SME to send document to their customer or receive document from their customer. Usually SMEs are not able to do it themselves, due to several problems like budget problem, expertise problem.

We are not only helping SME but also MNC, where they have to exchange document in different format and different protocol such as A want send to B via AS2 but B only receive via RNIF. We help MNC to reach to their level 2 or level 3 suppliers, which usually is not AS2 or RNIF enabled.

Here is a scenario of MNC-A send ORDERS to 1 of its SME supplier, MNC-A send us ORDERS via AS2 in EDI format, we received and transform the document from EDI into XML, then SME supplier logon to e-Supplier to view/print/acknowledge the ORDERS.

Another scenario of A send ORDERS to B send us ORDERS via our client software or AS2 in fixed-length format, we received and transform the document from fixed-length to EDI, then send to B via AS2, so B can import the ORDERS into their backend server, like Oracle EBS or SAP.

There are cases that A will upload the document via our web form and we will perform all the required steps before we send to another party.

Attachment feature in RosettaNet using Oracle AS B2B 10g

These steps help in sending Text as an attachment in RosettaNet.

1. Create an xml file, which follows the following dtd.

<!ENTITY % common-attributes "id CDATA #IMPLIED" >
<!ELEMENT B2BAttachment (Attachment*)>
<!ELEMENT Attachment (#PCDATA) >
<!ATTLIST Attachment Type CDATA #REQUIRED
ID CDATA #REQUIRED
Encoding CDATA #REQUIRED
Description CDATA #IMPLIED
FileName CDATA #IMPLIED>



2. Save the xml in UNIX FILE FORMAT. Here is the sample xml, which contains 2 attachments


<?xml version="1.0" encoding="UTF-8"?>
<!--Sample XML file generated by XMLSpy v2005 sp1 U (http://www.xmlspy.com)-->
<B2BAttachment>
<Attachment ID="213123" Type="text/plain" Encoding="none" Description="Description">Sample Text message
</Attachment>

<Attachment ID="215123" Type="text/plain" Encoding="none" Description="Description">Sample Text message another
</Attachment>
<Attachment ID="215123" Type="application/pdf" Encoding="base64" Description="Description" FileName="Form.pdf">file:///C:/Form.pdf
</Attachment>
</B2BAttachment>


3. Edit the enq_3a4_req.properties to provide the file name for the "attachment" attribute

4. Provide directory name in tip.properties for the key "oracle.tip.adapter.b2b.AttachmentInboundDirectory" where the file will be stored in the inbound scenario.
5. Restart the server and enqueue the Message.
6. By Default oracle.tip.adapter.b2b.MimeType accepts only below types,

@ application/xml
@ application/octet-stream
@ application/EDIFACT
@ application/EDI-X12
@ application/jpg
@ image/jpeg
@ application/gzip
@ application/x-gzip
@ application/pkcs7-signature

If you want more options, Then you must modify tip.properties in
$ORACLE_HOME/ip/config directory to include your MimeTypes also, For example,
You want to include pdf attachments, Then your tip.properties would look like,

oracle.tip.adapter.b2b.MimeType=application/xml : application/octet-stream :
application/EDIFACT : application/EDI-X12 : application/jpg : image/jpeg :
application/gzip : application/x-gzip : application/pkcs7-signature :
application/pdf

Add a new content type such as application/pdf restart opmn and re-try testcase.

Rosettanet Automated Enablement - RAE

Rosettanet Automated Enablement

As all of us are aware that the Rosetteanet standard is adapted heavily in the High Tech industry for addressing various business challenges. RAE is aimed at small to medium sized customer who has challenges in terms of lack of expertise in implementing RN stack, lack of complex infrastructure, complexity in nature, cost involved in it and the time to market. These challenges will make the mid-small customer not complying to RN standard thereby failing to do business with High tech Biggies even being compitative in the product line. RAE has great backing from Industry biggeies such as Cisco, Hewlett Packard, Motorola, Nokia etc. enabling the mid-small supplier to reap the benifit of Rosettanet

It involves,

1. Trip - PIP : through which it is possible to use XML tools availble in the market to define PIPs. Through this
it is possible to define multiple scenario.
2. Trip - PF : Presentation format for TIP-PIP , and is decided to be in PDF.
3. Trading partner will develop the TRIP - PIP and Implementors provide TRIP - PF
4 The Registry specification defines the requirements for posting and retrieving TPIR-PIPs and TPIR-PFs.

what RAE for a Supplier

Fill out various business related details using a PDF file and send it to RAE Implementors. PDF files has place holders for collecting various details which adheres to Trip- PIP schema. RAE Implementors inturn transform the PDF file content to PIP Schema and send it to the Trading partner having RN solution. In the reverse direction, when RAE implementor gets the PIP data , it transform it into Human readable PDF files and send it to the end supplier.