Large EDI File Processing

This challenge is addressed by writing the payload to a input directory. The corresponding translated payload will also be written to an output directory.

p.s As a pre-requisite always apply the latest patch and set the appropriate heap size as per the performance best practice post.

1. Set the heap size as discussed in the peformance post.
2. Apply the latest patch.
3. You will need to set following two properties in tip.properties

1) oracle.tip.adapter.b2b.edi.incoming.wiremessage.size
.
Specify the size of incoming EDI message that must be treated as large enough
to be kept in file system instead of memory, during message processing. The size
specified is in bytes.

Default is 300 MB (300000000)

2) oracle.tip.adapter.b2b.edi.incoming.wiremessage.directory
Specify directory where large incoming message must be saved.
Example:
oracle.tip.adapter.b2b.edi.incoming.wiremessage.directory=/scratch/mdsharma/edi_files_dir/globalchips

4. For outbound consider File batching as well as Disk caching.

These are the parameters needed to set for this in tip.properties file -

# entries to support large file outbound processing
oracle.tip.adapter.b2b.edi.fileBased=true
oracle.tip.adapter.b2b.edi.outputDirectory=E:\\oracle\\product\\DVAPPSRV01\\ip\\log\\edioutput
#outputSize is expressed in bytes
oracle.tip.adapter.b2b.edi.outputSize=102400

#entries to support no-lock processing of batched outbound messages
oracle.tip.adapter.b2b.sqltablelock=false

#entries to support splitting large batched outbound into smaller batches
#value determines size of smaller batches split off from the large batch
#if this property exists and is set to a value, then #oracle.tip.adapter.b2b.edi.outputDirectory
#and oracle.tip.adapter.b2b.edi.outputSize must be specified.
#if this property exists and is set to a value, oracle.tip.adapter.b2b.edi.fileBased #can be either true or false. true is preferred.
oracle.tip.adapter.b2b.edi.mergeMsgSize=500
oracle.tip.adapter.b2b.qMsgRatio=20

#Entry for file-based processing across multiple B2B instances.
oracle.tip.adapter.b2b.edi.fileBased.directory=E:\\Oracle\\Product\\DVAPPSRV01\\ip\\log\\filebased.

Variable Retry Interval for HTTP Transport

Use case : There is a notion of Retry Count and Time to Acknowledgement in Oracle B2B for HTTP Transport where by B2B Engine retries for a Retry Count number of times with an interval of Time to Acknowedgement between every retries. Consider a practical case where in Partner server is down and it takes few hours to bring it up, hence it may not be practical to retry it immediately.

Details :

Using the Variable Retry Interval it is possible to schedule the retry activity during appropriate time. This will make the retry feature more effective.

To enable this feature set

oracle.tip.transport.HttpSender.TimeToAck = 1,20,120

where it will retry after 1 minute, 20 minute and 2 hour after previous retries.

Stacking Feature in B2B to handle the scheduled outage of Trading Partner

Use case

1. Should be able to configure the scheduled outage of a TP on the host.
2. During the outage, B2B should be able to store the messages without any processing and not error them out.
3. At the end of outage should be able to send the messages to TP in a controlled manner i.e batch mode. The batches can be defined either using message id or time range or it can be partner-wise

This Use case is handled by Quesing all the appropriate Agreement related to the Trading partner during the begging of the down time and is done by using public API.

java oracle.tip.configuration.ConfigurationManager -quiesce

and to reactivate the configuration at the end of Scheduled down time.

java oracle.tip.configuration.ConfigurationManager -reactivate

Resubmit :

InstanceMessageUtil is enhanced to get the instance messages based on Start time, End time , Agreement Name and status.

getInstanceMessages(String startDateStr,String endDateStr,
String agrmtName,String status)

This will provide all the messageID and the resubmission utility can be used in manual mode to resubmit all the messages.

Please note In case of a planned outage of the trading Partner, you can use the Stacking feature mentioned above, in which case B2B will not post the message to the Trading partner end point. If it is not a planned outage, it errors out in the transport layer


and you can use B2B in Auto/Manual mode to resubmit. HTH. Let us know.

Resubmission Feature

Resubmission feature which is part of the latest patch.

Introduction

Oracle AS B2B is a B2B Product with very rich protocol stack and is based on Standard based Scalable Architecture managed through Oracle Application server. This product has a rich Exception handling framework to capture the error/Exception at various stages in the Engine, and send the exception message to IP_IN_QUEUE with B2BERRORUSER. With the increased customer base over the recent past, resubmission of error/Exception message in B2B is the key feature identified to be supported. There have been many best practices used by several of our customer to get the Exception message and to resubmit the business message using the Workflow driven BPEL Process. This is just an initial pilot project undertaken to provide the Resubmission feature out of the box. It is expected to go for multiple enhancements depending on the customer drive and the acceptance.

Use Case Addressed

1. Basic Resubmission feature with Retry count and Interval for both inbound and outbound.
2. Notification to B2B Administrator.
3. Resubmission based on message ID, Agreement and Status.
4. Payload based resubmission. This is ideally for error/Exception based on payload.
5. Outbound resubmission using IP_OUT_QUEUE and inbound Resubmission through Event queue. This will get the inbound message goes through all the layer of B2B as if it has come from Trading Partner.
6. Deletion of duplication message and correlation of business message with appropriate Acknowledgement.
7. Support Stacking feature to handle the B2B Downtime and Resubmission after the same.
8. Variable Resubmission interval.

Outbound Scenario
B2Bresubmit Utility runs in two modes.

Auto Mode:
B2Bresubmit Utility runs in infinite listening mode to IP_IN_QUEUE with B2BERRORUSER. For every exception message, it gets the messageID and uses InstanceMessageUtil to obtain the From Party, To Party, DocType , Revision and the payload . It uses the above information to enque the message to IP_OUT_QUEUE to be picked up by B2B.

Depending on the configured Retry Count and Interval it resubmit the message and send a notification to the configured email ID once after exhausting all the attempt to resubmit the message. Email subject contain the messageID and the body contain Error Description.


Variable Resubmission Interval

Be default the Retry Interval is constant for all the retry effort during resubmission. However there is an option to define variable resubmission Interval for every resubmission. This will enable the B2BAdministrator enough time to debug and bring up the partner server in case of any issues.

If the value for ResubmitWithInterval is set to true, the utility will resubmit every message with interval mentioned for the property

oracle.tip.adapter.b2b.data.ReSubmit.ResubmitIntervals.


In this example,

First resubmission will happen after 1 minutes of first failure
Second resubmission will happen after 1 minutes of first resubmission

Also ensure that the value for oracle.tip.adapter.b2b.data.ReSubmit.ReSubmitCount is same as number of intervals mentioned.
Manual Mode
B2Bresubmit utility resubmits messages based on
1. Message ID,
2. Agreement ID and Status.

MessageId based
Once after B2BAdministrator gets the notification for a failed resubmission, he will extract the messageID from the email, Identify the root cause of the problem by referring b2b.log/Report, fix the problem and use Resubmission utility in manual mode to resubmit the message based on messageID.
Agreement name and message status

Ideally this feature is used in Bulk Resubmission after the Trading partner Downtime and is based on Agreement name, Status, Start time and End time.

The typical way to execute is as below.

Example:

java oracle.tip.adapter.b2b.data.ReSubmit "2008/01/28 16:00" "2008/01/28 16:15" Agreement Error

The time format is: yyyy/MM/dd HH24:MI

Inbound Scenario

Inbound Resubmission is pretty much the same as Outbound with both Auto and Manual mode, however the resubmission is based on the event queue, which will enable the resubmission messages to go through the respective exchange layer as if it has come from Trading Partner.

Resubmission Configuration

Complete List of configurations used for this utility

Turn off TPA Validation for Delivery channel Information

This feature is used for re-submission. Assuming the inbound essage has come through AS2/EBMS exchange plugin, which needs to be re-submitted through a File Delivery channel which is encapsulated using a Dummy Agreement. This may not be feasible as B2B performs TPA validation for delivery channel (checking if the delivery channel info on which message arrived is same as the delivery channel
info present in matching trading partner agreement).

In order to turn off this validation, there a tip.property
oracle.tip.adapter.b2b.tpa.validateTPA

If the value of this property is set to false in tip.properties, B2B will not
perform TPA validation

Identification of Document - Custom Over EBMS

Identification of Document - Custom Over EBMS

Inbound : Ideally Custom Document Plugin identify the document based on Xpath Expression and value. In the EBXML world the identification is based on action name of the incoming document. To provide this flexibility oracle B2B tries to Identify the document, based on the Xpath expression if present, else identify based on the incoming action name.

Outbound : Along with the typical Identification of Agreement based on From, To , DocType and Revision, it can also be Identified based on From,To and Action_Name where the Action_Name has to be mapped against the business Action Name.

actionName=ACTION:

By setting the above AQ (ACTION_NAME for jms) property, TPA identification can be done using business action instead of document type and revision. This is typical use case in ebms

Example :
from = Acme
to = GlobalChips
payload = Acme_850.xml
actionName=ACTION:Process_850

Correllation of Business Message in EBMS Exchange

Correllation of Business Message in EBMS Exchange is done using

a. RefToMessageId
b. ConversationId

It is possible to correllate a business message such as ORDER with its response message such as ORDRSP and it is also allowed to correllate as many number of related messages as long as they carry appropriate RefToMessageID and ConversationID.

Back end application such as BPEL can make use of the AQ/JMS header replyToMsgID for setting the correllation information. Format of the replyToMsgID is as follows.

replyToMsgID : RefToMessageId : ConversationId


Example to correllate ORDER and ORDRSP

Let us consider two EBMS setup one for ACME and another for GlobalChips. Following are the sequence of activities which is of interest.

1. Enque an order message to ACME with the value of replyToMsgID as

replyToMsgID = : 999999999

B2B in the Acme side generates its own message id and use 999999999 as Conversation ID.

EBMS header of the business message sent to GlobalChips

a. Do not have RefToMessageID as this is the 1st message
b. MessageID contain the messageID (e.g Acme@222222222) of the ORDER message
c. ConversationID contain 999999999

2. GlobalChips gets the ORDER message (msgid= 444444444) and sends an Acknowledgement with the EBMS header as follows.

a. MsgID of the ACK message
b. RefToMessageID as copied from ORDER message from ACME i.e Acme@222222222
c. ConversationID contain 99999999

3. GlobalChips Enque an ORDRSP message with the value of

replyToMsgID = 444444444 : 999999999

where 444444444 is the messageID of the ORDER message. EBMS header of the ORDRSP

a. MsgID of the ORDRSP message
b. RefToMessageID as copied from ORDER message from ACME i.e Acme@222222222
c. ConversationID contain 99999999


4. Acme to send the Acknowledgement.

As a prerequisite it is required to set the following tip.properties to avail the correllation feature in EBMS Exchange.

oracle.tip.adapter.b2b.ebms.deliverConvId = true
oracle.tip.adapter.b2b.ebms.TreatMsgWithReplyToMsgIDAsReq = true

Please send a mail to ramesh.anantharamaiah@oracle.com for sending the export of the configuration.

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=;

Resubmission Feature in B2B - Error Exception Handling

Resubmission Feature in B2B


There are various Best practices suggested to re-submit the failed messages in B2B. Following is one approach.

1. Outbound Flow

The exception handling and resubmission mechanism can be split it into three different activities.

I. Get the Exception Message details: Query IP_IN_QUEUE using consumer name as B2BERRORUSER.
II. Get the Business message details: Query the b2b_instancemessage view for a specific b2bmessageID for which exception occurred.
III. Resubmit the Business message to IP_OUT_QUEUE with appropriate AQ header information such as From, To, Doc Type, Revision etc.

For any Error/Exception during outbound message processing, B2B sends an exception message whose Document type is “Exception” to the IP_IN_QUQUE with error user as B2BERRORUSER. The exception message enqueued will be based on the ipException.xsd available in the $midtier/ip/lib.

To accomplish the 1st step BPEL Process can be created with an inbound AQ Adapter to listen on to the IP_IN_QUEUE with Consumer Name as B2BERRORUSER to dequeue the exception message sent by B2B Exception handling Mechanism. Exception message contains the message details such as b2bmessageID, Error Text, Error code etc. The status of the business message and wire message is updated with Error.

As part of 2nd step, using the B2BmessageID available in the exception message, it is required to query b2b_InstanceMessage view in the b2b schema to get the following information.

a. Payload (PAYLOAD)
b. From Party (SENDERNAME)
c. To Party (RECEIVERNAME)
d. Document Type (DOCUMENTTYPE)
e. Document Revision (DOCUMENTPROTOCOL)
f. Business Action (BUSINESSACTION)

Ideally, the above database call to the b2b schema is accomplished by configuring the DBAdapter in the same BPEL Process.

As part of the 3rd and final step enqueue the payload obtained in second step to IP_OUT_QUEUE by setting appropriate AQ headers such as From Party, To Party, Doc Type and Revision. This is done by, outbound AQ adapter configured in the Enqueue mode.
Note: In this approach, IP_IN_QUEUE, IP_OUT_QUEUE and b2b_instancemessage view are in b2b schema.

Retry Count: As a best Practice it is advised to introduce a concept called Submission Retry count based on one of the column in the tip_businessmessage_rt table such as NOTM. For every re-submission, increment the Retry count for a specific b2bMessageID for a pre-configured Retry count. An email notification can be sent to the B2B Administrator once the maximum Retry count is reached.

2. Inbound Flow

The above Exception handling mechanism applies to inbound as well. Instead of resubmitting the message through IP_OUT_QUEUE, it is required to configure a listening inbound File end point and drop the file, with appropriate naming convention. B2B picks it up and process in the inbound direction as if it has come from the Trading partner.

Note: As this approach uses file protocol for inbound processing, the exchange specific features may not be available.

Reference: http://www.oracle.com/technology/products/integration/b2b/pdf/B2B_TN_007_Exception_Handling.pdf

Why big corporate using B2B service instead of doing themselves?

It is crucial for a company that able to trade with all its trading partners electronically.

Despites this, many businesses still receive business-critical information from their SME trading partners through fax, email or phone even though all these manual processes are slow, inefficient and error-prone.

I think these maybe some of the reasons why they not going to connect all their trading partner themselves.

• Cost – software ownership cost, cost for software customization, software support/maintenance cost, infrastructure setup cost, technical staffing cost.
• Speed – total time and effort spent to connect to all trading partners is slow.
• Skillset and resource – require extra resource to track different project for various trading partner and also to support the trading partner.
• Different protocol and data format – different data format and protocol used when connecting to various trading partners, eg: EDI, XML, RNIF AS2, HL7
  

Benefits of using B2B service:

• Speed – speed up the implementation of a new trading relationship, as B2B service provider will help to build the electronic trading communities.
• Cost savings – avoid costly software and customization, infrastructure and technical staff.
• Control over a single source – document can be track and monitor over a single source and single data format and also single protocol.
• Efficiency – free up the in-house resources to devote more time and effort to core business activities.

1 Sync (UCCNET) offering in Oracle AS B2B

1 Sync is a means of Data synchronization i.e product and company data between Trading Partners. This is predominently used in retail Industry and there is an adaption from retail giants such as Walmart, Home Depot etc.

Synchronization involves electronic transfer of product and location information with the continuous synchronization of that data over time. 1Sync is a subsidiary of GS-1 (Formally the Uniform Code Council) Was formed by through the combination
of Transora and UCCnet and is a Global Data Synchronization Network (GDSN) certified data pool.


Benifits of 1 Sync

# A single point of truth.
# The data is represented with the same semantics
# It Enables Item Management, Price & Promotion Management, Item Introduction, Retail customization
# Provides internet based Suppliy chain management data registry service.


How does it work

Load Data : The Seller registers product and company information in its data pool

Register Data : A subset of the Seller’s information is sent to the GS1 Global RegistryTM

Subscription Request : The Buyer via its data pool subscribes to a product category and/or manufacturer to receive the information.The GS1 Global RegistryTM locates the data pool that contains the information.

Publish Data : The Seller’s data pool publishes the complete item and party to the Buyer’s data pool

Recipient Confirmation
The Buyer sends a confirmation to the Seller from the buyer’s data pool to the Seller’s data pool

Oracle AS B2B Support



Oracle AS B2B supports 1 - sync through its Custom Document protocol offering and is typically used with AS2 Exchange.

Correlation in HL7 Document Plugin

Correlation in HL7 Document Plugin
Control Number is used to correlate between Busingess message and its Acknowledgement. Control Number can be either generated by B2B or by Back End application such as BPEL. You can delegate the Control Number generation to B2B byusing the macro #ControlNumber# for e.g

<MSH.10>#ControlNumber#</MSH.10>

How Correlation works
MSH.10 of any business message contains a unique value (i.e. Control Number) that identifies a message. The receiving system sends this unique ID back to the sending system in the MSA.02 segment of ACK message. The sending application reads MSA.02 and correlates with business message.

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.

How to Suppress Error In XEngine

It is possible to suppress any specific Error in XEngine by modifying the ErrorSeverityConfig.xml

E.g To supress the 5034 error add

<ApplyTo>
<Criteria Name="ErrorID" Value="50340000"/>
<SetSeverity SeverityID="0"/>
</ApplyTo>

to $ORACLE_HOME/ip/oem/edifecs/XEngine/config/ErrorSeverityConfig.xml

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.

Oracle AS B2B Sizing Guidelines

Please find the B2B sizing questionaire in the following URL.

http://www.oracle.com/technology/products/integration/b2b/pdf/B2B_TN_014_Questionaire_Sizing.pdf

Please leave your sizing requirement in the Post comment section for us to suggest you appropriate sizing.

Trading Partner Identification in HL7 Domain

Trading Partner Identification in HL7 Domain

Trading Partners are identified by default based on the Exchange. For MLLP based Exchange it is MLLP ID which is used for Trading partner Identification and is possible to use IP Address (prefereble) or Host Name for the Idenfication.
For HL7 MLLP business Protocol, there is a Need to create MLLP ID as the Identification Type and use it as part of Agreement.

It is also possible to Identify the TP based on the payload attributes such as

a. Sending App MSH:3
b. Sending Facility MSH:4
c. Receiving App MSH:5
d. Receiving Facility MSH:6

Set the following property in tip.property

oracle.tip.adapter.b2b.hl7.identifyFromTP = SendingApp | SendingFacility | ReceivingApp | ReceivingFacility

Make sure to create the appropriate Trading partner identification such as Sending App ID, Receiving App ID , Sending Facility , Receiving Facility with values. However there is no mandate to use these Identifier as part of the Agreement like in case of Exchange Identifiers.

When B2B receives the incoming message it compares the value of SendingApp with the configured value of Sending App ID in the TP identification process for identifying the remote Trading partner.

It is also possible to use a combination of these identifiers and can be specified in the tip.properties with comma seperated values.

e.g oracle.tip.adapter.b2b.hl7.identifyFromTP= SendingAPP,SendingFacility,ReceivingApp

Trading Partner Identification in HL7 Domain

Trading Partner Identification in HL7 Domain

Trading Partners are identified by default based on the Exchange. For MLLP based Exchange it is MLLP ID which is used for Trading partner Identification. It is possible to use IP Address (prefereble) or Host Name for the Idenfication.
Need to create MLLP ID as the Identification Type and use it as part of Agreement.

It is also possible to Identify the TP based on the payload attributes such as

a. Sending App MSH:3
b. Sending Facility MSH:4
c. Receiving App MSH:5
d. Receiving Facility MSH:6

Set the following property in tip.property

oracle.tip.adapter.b2b.hl7.identifyFromTP = SendingApp | SendingFacility | ReceivingApp | ReceivingFacility

Make sure to create the appropriate Trading partner identification such as Sending App ID, Receiving App ID , Sending Facility , Receiving Facility with values. However there is no mandate to use these Identifier as part of the Agreement like in case of Exchange Identifiers. When B2B receives the incoming message it compares the value of SendingApp with the configured value of Sending App ID in the TP identification for identifying the remote Trading partner.

It is also possible to use a combination of these identifiers and can be specified in the tip.properties with comma seperated values.

e.g oracle.tip.adapter.b2b.hl7.identifyFromTP= SendingAPP,SendingFacility,ReceivingApp

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.

Comments/Feedback/ Request for New Post

Please feel free to Leave your comments, feedback or request for any Features in B2B which needs to be Explained. Please click on post comment section for the same.

I am officially part of blogs.oracle.com

I am excited to be part of blogs.oracle.com, where lot of people with various interest share their knowledge regarding Oracle products, implementations, customization, best Practice etc.

blogs.oracle.com/nittur

AS2 File name Preserve Feature

In order to preserve the filename Between different Enterprise corresponding to Trading Partner Oracle AS B2B offers a filename Preserve feature as part of the AS2 Exchange Plugin offering. Please follow the below steps.

1.Apply the latest B2B patch.
2.Import the tutorial X12_seller_export.xml in the location $ORACLE_HOME\ip\tutorial\X12\config for Acme
3.Import the tutorial X12_buyer_export.xml in the location $ORACLE_HOME\ip\tutorial\X12\config for GlobalChips.
4.Edit the enq_850.properties in the location $ORACLE_HOME\ip\tutorial\X12\runtime and add/edit the property name “actionName=”.
Eg. actionName=contentType:application/octet-stream;filename:abc.xml
7.Start the b2b server
8.enq_850.bat or sh enq_850.sh (if OS is linux).
9.B2B will set the filename in the MIME body part i.e Content-Disposition (filename) as part of the AS2 Call..

Sending Application in the Host side should enque the filename (in the actionname AQ header ) as part of the Enque process to IP_OUT_QUEUE which is the default outbound queue provided by Oracle AS B2B. B2B engine will send the filename in MIME body part as part of the AS2 call. The receiving application should have the capability to intercept the MIME body part and obtain the filename.

If the receiving application is Oracle AS B2B it receives the message, extract the filename from the MIME body part and set it as part of the AQ header while enqueing the message to IP_IN_QUEUE in the same way as for outbound.

Even though AS2 does not mandate this filename, Oracle B2B offeres this feature for the benifit of Customer who are relying on filename for further processing.

Processing VICS document

Oracle AS B2B offers VICS support based on X12 Document Plugin.Please follow the below steps.

1. create the document guidelines for the VICS 850 & 997 from the X12 4010 guildelines rather than the VICS guidelines

2. create a group ecs file based on the one from the Xengine directory
that has the codelist for GS08 removed

3. create a protocol for version "4010VICS" (004010VICS doesn't work). specify the new group ecs from step 2 and install the 2 documents from
step 1 into it.

Sending 997 in BISAC23020 format

997 BISAC23020 format is similar to X12 3020,except for the version in GS08 segment.Please follow these steps.

1. create the document guidelines for the 850 and 997 from the X12 3020 guildelines.

2. create a group ecs file based on the one from the Xengine directory that has the codelist for GS08 in which replace 003020 with 003020BISAC2

3. create a protocol for version "3020BISAC2". specify the new group ecs from step 2 and install the 2 documents from step 1 into it.

Oracle AS B2B EDI CookBook

EDI Cookbook

ODETTE standard Support in Oracle AS B2B

The ODETTE standard consists of over thirty messages for deployment in the automotive industry and the messages can use either EDIFACT or TRADACOMS service segments. ODETTE messages are supported as part of B2B EDIFACT Document Protocol offering.

Oracle AS B2B - Performance Best Practices

I am sharing some of the Best practices for Oracle AS B2B Performance. Please feel free to add and make it helpful for the B2B community.

1. Index TIP_WIREMESSAGE_RT table on column B2BWIREMESSAGEID

2. set oracle.tip.adapter.b2b.sleepTimeout=1 in tip.properties (default value 10)

3. use multiple worker IP listener threads in B2B and make sure to do appropriate testing as it is most suited for multiple processor. This is done by setting oracle.tip.adapter.b2b.NumOfIPListeners to appropriate values. However this is not a well tested feature.

4. Use custom queues for processing outbound messages instead of IP_OUT_QUEUE. If you have more load, create multiple queues and load balance among them. For e.g for every 2 messages/sec create an additional queue.

5. oracle.tip.adapter.b2b.defaultIdcOn=false. This turns off the message retrieval from default delivery channel, in case of custom queues as in step 4.

6. change the Log level from DEBUG to ERROR in tip.properties.

7. Batching messages for outbound . This is only for EDI messages.

8. Index B2B_CTLNUM_IN, B2B_CTLNUM_OUT for better EDI throughput.

9. Index INTERCHANGECONTROLNUMBER,GROUPCONTROLNUMBER,TXNSETCONTROLNUMBER column in TIP_BUSINESSMESSAGE_RT table.

10.Set the following variables in opmn.xml
<variable id="LDR_CNTRL" value="MAXDATA=0XB0000000@DSA" />
<variable id="LD_PRELOAD" value="/opt01/app/ESIP/oracle/esip10gR2iAS/B2B10gR2/iAS/ip/oem/edifecs/XEngine/bin/libecxenginejni.so" />

11. Set the following JVM parameters in opmn.xml
<data id="java-parameters" value="-verbose:gc -Xp20m,5m -Djava.net.preferIPv4Stack=true -Dcom.ibm.cacheLocalHost=true -Xloratio0.3 -Xms1024M -Xmx2048m -Xss6144K -Xoss6144K" />

12. Configuring the Row Fetch size
oracle.tip.repos.RowSize=100

13. Set aq_tm_process = 10 and restart Database. Please note that this value has to be arrived based on the CPU/Memory available. For small to medium infrastructure set the value of 3-5.

14. Use TPACache. http://www.b2bgurus.com/2008/08/tpa-caching.html

15. Set oracle.tip.adapter.b2b.receiveTimeout=1

16. For better performance, it is advised to deploy the agreements in one Config. Following this suggestion is discretionary.

17. Set appropriate value of polling interval for AQ/JMS based Delivery channel

NCPDP Support in Oracle AS B2B

B2B supports NCPDP/Script through "EDIFACT over Generic" business protocol because its syntax is based on EDIFACT standard.

Control Number in EDI Document Protocol

Control Numbers are included in all header and trailer segments as an additional means of tracking and confirming EDI transmissions. Control numbers issued in the header segments must match control numbers assigned in the trailer segments. An ISA control number must match the IEA control number, the GS control number must match the GE control number, and the ST control number must match the SE control number in each EDI transmission, or there could possibly be errors. Control numbers can be assigned in the following two ways.

Control Number along with the sender ID provides a unique identifier to identify incoming EDI data from a sender. Following are various control numbers,

Interchange Control Number : Originated by the sender and is typically a sequence number. This together with the sender ID uniquely identifies the Interchange.
Functional Group Control Number :This Uniquely identifies Group.
Transaction Set Control Number : This Uniqely Identifies Transaction Set.

Control Numbers are predominantly used for correlation at various stages; it may be correlation in the back end application or correlation in the B2B application.

Control Number Generated by Back end Application

This is the most likely case as back end application uses the Interchange, Group and Transaction Set Control Number for correlation at various levels and also for correlating the control/Aperack and business messages.

E.g. To correlate 850 EDI message with 997 and 855.


Control Number Generated by B2B

B2B Generates the control number only in case the Back end application send the EDI message with the Keyword #controlNumber for e.g.

#ControlNumber#

Oracle AS B2B fills in the unique number for Interchange and Transaction set Control Number and uses it for correlating the incoming Control messages.

This is not a preferred approach, as most of the correlation has to happen in the back end application.

Processing VICS document using Oracle AS B2B

Oracle AS B2B offers VICS support based on X12 Document Plugin.Please follow the below steps.

1. create the document guidelines for the VICS 850 & 997 from the X12 4010 guildelines rather than the VICS guidelines

2. create a group ecs file based on the one from the Xengine directory
that has the codelist for GS08 removed

3. create a protocol for version "4010VICS" (004010VICS doesn't work). specify the new group ecs from step 2 and install the 2 documents from
step 1 into it.