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.

Various Acknowledgement in EDI

I have already talked a little bit about Functional Acknowledgement. Typically it is called 997 in X12 and is defined in each and every version of X12 such as 4010,4020 etc, where as the same is called Control in EDIFACT and is of version D3.

In the EDI world, people often get confused Functional Acnowledgement with Exchange/Transport level acknowledgement and also the Application level confirmation such as Purchase order Acknowledgment such as 855.

Exchange Level Acknowledgement/Trnasport Level :

Acknowledgement such as MDN i.e Message disposition notification in AS2 or Acknowledgement in EBMS specified the aknowledgement of the business message
in the enterprise only w.r.t meeting the security aspects such as verifying the signed message and decrypting the encrypted message and uncompress it if it is a compressed message and it do nothing w.r.t the payload validity or the business level integration.

Functional Acknowledgement :

Functional Acknowledgement as a Best Practices is handled in most of
the cases using B2B Application level and it caters to validation of the business message w.r.t any defined grammer such as schema,DTD or anything specific to EDI and it also specifies the translation status etc.

It is also possible to handle this in the back end application by delegating the Functioanl Acknowledgement generation to the back end application , however the correllation happens in the B2B.

The flag isFunctionalAck required controls whether an ACK) is needed are not. The flag isFunctionalAclHandledbyB2B controls whether FA is required and it is generated in B2B or it comes from Back End application such as BPEL. This option is useful only when isFunctionalAck required is YES. The flag isFunctionalAclHandledbyB2B should be set to 'YES', unless there is special way ACK is generated outside B2B. Functional Ack is generated using the XEngine in B2B and captures all the translation and validation errors.

To enqueue a query response from BPEL to B2B, populate the replyToMsgID field of
IPMessage with the MsgID field of the incoming message.

Application Acknowledgement :

Application Acknowledgement such as Purchase order Acknowledgement is from the ERP application and caters to the process integration status.

Custom Code List - EDI

Use case : using Interchange Receiver ID qualifier or Interchange Sender ID qualifier ZZ which is not there in the standard code list as part of the Document Protocol Parameter configuration.

Follow the below steps.

1. Modify the interchange ecs file to add the "ZZ" in the standard code list_007.
2. This can be done by editing the Interchange ecs file in the spec builder and adding zz in the S003/007/Standard Code List_007
3. Use the updated ecs while configuring the EDIFACT document protocol parameter as interchange ECS.
4. re-deploy the agreement after validation.
5. Make sure your transactionset ecs do not have any envelope information.

How to test:

Exhange an EDI document whose Interchange Receiver ID as ZZ. It should work :)

Latest B2B Patch and Features Incorporated

Latest B2B Patch is Latest patch : 6673231
. Following are the list of features as part of this patch.

1. Identification of Trading partner based on Exchange/Interchange

Trading partner Identification Any (newly Added)

If property is set to ANY, B2B will first try to identify TP using Interchange. If no TP found using Interchange, B2B will next try to find TP based on Group.

2. Performance improvement in EDI Batching.

3. SFTP

4. Large EDI Message Processing. Tested more than 300 MB file.

5. Sending one Ack for all the messages in the Batch.

6. IMMEDIATE HL7 ACK AND ANONYMOUS TP

Already discussed about this in another thread.

7. Self Service API Enhancement to address the same Trading partner being intiator and responsder for a business action corresponding to same Document Type and revision.

Oracle AS B2B - Various Features in FTP Adapter (FTPS, SFTP...)

As part of the Oracle AS B2B 10.1.2.0.2 FTP adapter offering following features are supported. FTP Protocol forms part of the Generic Exchange Plugin.

1. Basic FTP

Identification of Trading Partner Criterion is slightly different for Internal and External Delivery channel, even though identification is based on the "Name" in both of this cases.

a. For External Delivery Channel.

i. Identification of Trading Partner is based on the name of the file and the name shoud follow the patterns as nameOfTP_UniqueID.

ii.Identification of Trading Partneris based on the name of the Directory. To enable this it is required to set

oracle.tip.adapter.b2b.allTPInOneDirectory= True as part of tip.properties setting.

b. For Internal Delivery Channel.

The identification of Trading partner and the Document is based on the name of the file and should follow the pattern as
TradingPartner_DocumentType_Revision_msgType_msgId_replytoMsgID_extension.xml


2. FTPS : FTP OVer SSL

Download any of the FTP server which can be configured to FTPS such as FIlezilla. Configure FTP server for FTPS as per the FTP server documentation. The SSL configuration is driven by the value of parameter "Channel mask" , please use it accordingly.


Oracle AS B2B Configurtion:

1. Depending on the mode of data transfer i.e Active/Passive , specify the data port for Active configuration and no data port for passive mode. Control port is there for both the mode and by default B2B considers this to be 21, there is a need to
mention it for any deviation.

2. Receiver Channel Mask (Host) : Depending on whether No channel encrypted, data channel to be encrypted , Control Channel to be encrypted or Both control and Data channel to be encrypted specity none, Data, Control or Both accordingly.

2. Sender Channel Mask (Trading Partner) : Depending on whether No channel encrypted, data channel to be encrypted , Control Channel to be encrypted or Both control and Data channel to be encrypted specity none, Data, Control or Both accordingly.

Refer to the user guide for FTP Transport configuration.


3. SFTP(New Feature available as part of latest B2B patch # 6353697)

P.S If SFTP protocol is not seeded , please seed it using

%ORACLE_HOME%\jdk\bin\java oracle.tip.seed.SFTPSeedDriver

SFTP implementation has been provided for Oracle B2B 10.1.2.0.2 version. This enables B2B to send and receive payload files over SFTP (SSH FTP) protocol.

SFTP protocol support added for both external trading partners and internal applications communications. The naming conventions of the payload files are in-line with File and FTP adapters.

Proxy support provided (HTTP)

Authentication Support :
Password based authentication – username/password combination authentication

Public key authentication – authenticating the identity based on the public key

create a key pair using OpenSSL keygen tool and the Public key need to be installed in the server. and the private keys fully qualified file location has to be specified in Private Key file and the passphrase has to be provide in Prive Key Pass phrase.

If the passphrase is present in the FTP configuration, B2B engine considers the password based Authentication else key based Authentication otherwise it is key based Authentication.

EDI Van Migration to AS2 Protocol considerations.

Coming Soon. Please check back often.

Creating B2B Metadata Using Self Service API

The Self-service API for Trading Partners and Agreements creation

The primary way to manage trading partners in the Oracle Integration B2B product is through the web-based GUI. This GUI allows authorized users to create, update, delete and validate trading partners and agreements, and to create and deploy configurations. However, there frequently is a need to create trading partners and agreements “on the fly” i.e. programmatically. There also exist situations where a commandline-based way to create trading partners and agreements may be appropriate, such as when needing create trading partners in “bulk”, where it can get really tedious, if not downright impossible to create huge numbers of trading partners using the GUI.

The new Trading Partner self-service API was developed due to these needs, and is driven primarily through XML-based descriptors for Trading Partners and Agreements. This document details the formats of these XML Trading Partner and Agreement descriptors, the usage of the Trading Partner Self-Service API, its capabilities and restrictions, and also includes some samples.

The Trading Partner descriptor XML

A trading partner’s characteristics and capabilities are described through an XML file, whose format is defined by the XSD referenced in the appendix. In this section, we will look at the elements and attributes that make up this XML file.

TradingPartners: The root element that contains 1 or more TradingPartner profiles.
TradingPartnerProfile: This element contains all the information needed to create a Trading Partner and hence is the "root" for a single trading partner. There can be many such elements under the "TradingPartners" element.
Attribute TPName: This specifies the "Name" of the trading partner.
Attribute Description: An optional description for the TradingPartner is specified here.

TradingPartnerID: This element is used to specify zero or more trading partner IDs.
Attribute Type: Specifies the type of the Identification.
Attribute Value: Specifies the value for this type of identification.
Attribute Description: Provides an optional description for the TP ID type.

OperationalCapability: This element contains all the information that describes the operational capability of a trading partner.

SupportedBusinessAction: Describes a SupportedBusinessAction for the trading partner.
Attribute BusinessActionName: Specifies the name of the BusinessAction supported by this trading partner.
Attribute isInitiator: Specifies if the trading partner is the initiator of the business action.
Attribute isFunctionalAckReqd: Specifies if the functional ack is required.

DocumentType: This element is used to specify any DocumentTypeParameters that need to be different from the protocol default, as well as the DocumentDefinition.
Attribute Name: Name of the DocumentType
Attribute Protocol: The name of the document protocol.
Attribute Version: the version of the document protocol.

DocumentTypeParameter: Specifies zero or more DocumentTypeParameters and their values that need to be different from the defaults.
Attribute Name: The name of the Parameter
Attribute Value: The value of the Parameter

DocumentDefinition: Contains information pertaining to the DocumentDefinition.
Attribute Name: The name of the DocumentDefinition
Attribute Description: An optional description for the DocumentDefinition.
Attribute isTranslationEnabled: Indicates if translation should be performed.
Attribute isValidationEnabled: indicates if validation should be performed.
Attribute Definition: Specifies the full path to the file containing the definition (e.g. and XSD file).


CommunicationCapability: This element contains all information pertaining to the communication capbilities of a trading partner.

DeliveryChannel: This element contains information regarding a delivery channel for a trading partner.
Attribute ReceiptNonRepudiation: indicates whether non-repudiation of receipt is required.
Attribute OriginNonRepudiation: indicates whether non-repudiation of origin is required.
Attribute EncryptionEnabled: indicates whether encryption is enabled.
Attribute CompressionEnabled: indicates if compression is enabled.
Attribute TransportSecurityEnabled: indicates whether transport security is enabled. if this is enabled, an HTTP transport would be HTTPS, for example.
Attribute RetryCount: indicates the number of retries.
Attribute TimeToAcknowledge: specified the time window before which an ack is required.
Attribute Name: Specifies the name of the delivery channel; optional. If unspecified, a delivery channel name would be synthesized.

DocumentExchange: Specifies information relating to DocumentExchange for a trading partner.
Attribute Name: Specifies the name of the DocumentExchange; optional. If not specified, and name is synthesized.

ExchangeProtocolRevision: Specifies the ExchangeProtocol.
Attribute Name: Name of the Exchange protocol.
Attribute Version: Specifies the version of the ExchangeProtocol.

ExchangeProtocolParameter: Specifies the ExchangeProtocolParameters that need to be different from the defaults.
Attribute Name: The name of the Parameter
Attribute Value: The value of the Parameter.

Encryption: Contains information relevant to encryption, such as Certificate location.
Certificate: Contains certification information.
Attribute Name: Name of the certificate.
Attribute Location: Specifies the location of the certificate.

Non-Repudiation: Contains information relevant to non-repudiation.

Transport: Specifies the transport information for this Delivery Channel.
Attribute Name: Name of the transport, and is optional. If unspecified, a name will be synthesized.
Attribute URI: The URI/endpoint used by this transport.

TransportServer: Specifies the transport information for this Delivery Channel.
Attribute Name: Name of the transport server, and is optional. If unspecified, one will be synthesized.
Attribute Description: an optional description for the transport server
Attribute HostName: This is required if TransportServer needs to be created
Attribute IPAddress: IPAddress of the host, and is optional.
Attribute UserName: This is required for a new TransportServer. Specifies the username to use (for protocol such as FTP).
Attribute Password: This is required for a new transport server. Specifies the password to use (e.g. FTP).
TransportProtocol: This element identifies the Transport protocol (HTTP etc.)
Attribute Name: The name of the transport protocol.
Attribute Version: The version of the transport protocol.

TransportProtocolParameter: Specifies transport protocol parameters.
Attribute Name: Name of the Parameter.
Attribute Value: Value of the parameter.

The Agreement XML

The Agreement XML contains the following elements:

TPAgreements: Contains descriptions of one or more agreements.

Agreement: This element contains the description for an Agreement.
Attribute Name: The name of the agreement.
Attribute ID: The ID of the agreement.
Attribute Description: description of the agreement.
Attribute EffectiveFromDate: When the agreement is effective from
Attribute EffectiveToDate: Till when the agreement is effective.
Attribute InvocationLimit: Ceiling for the number of invocations.
Attribute ConcurrentConversations: The max number of concurrent instances of this Agreement.

BusinessActionParticipant: This element describes the participants in this business action.
InitiatingTP: Describes the TP initiating the business action.
Attribute TPIDType: The type of the TP ID used in the agreement.
Attribute TPIDValue: The value of the TP ID used in the agreement.

DeliveryChannel: Describes the delivery channel used in the agreement.
Attribute Name: Name of the delivery channel.

RespondingTP: Describes the responding TP in the business action.
Attribute TPIDType: The type of the TP ID used in the agreement.
Attribute TPIDValue: The value of the TP ID used in the agreement.

InternalDeliveryChannel: Describes the Delivery Channel used in the agreement.
Attribute Name: the name of the internal delivery channel used in the agreement.

CalloutUsage: Describes the call out usage in the agreement.
Attribute Name: Name of the callout usage.

Using the SelfService API

The self-service API can be used by clients programmatically to create Trading Partners and Agreements, or can be used in the command-line mode. To use it in the command line:

· java oracle.tip.adapter.b2b.selfservice.TradingPartnerManager
creates the Trading Partner profiles from the specified XML file.
· java oracle.tip.adapter.b2b.selfservice.AgreementManager creates agreements from the specified XML file.

The following code snippet shows how to use the SelfService API programmatically:
FileInputStream fis = new FileInputStream(tpFile);
InputSource is = new InputSource(fis);
TradingPartnerManager tpMgr = TradingPartnerManager.newInstance();
tpMgr.init();
if (args.length == 2) {
tpMgr.processTPProfiles(is, true);
} else {
tpMgr.processTPProfiles(is, false);
}
tpMgr.shutdown();
FileInputStream fis = new FileInputStream(tpFile);
InputSource is = new InputSource(fis);
AgreementManager agreementMgr = AgreementManager.newInstance();
agreementMgr.init();
agreementMgr.processAgreements(is);
agreementMgr.shutdown();

References

1. TPProfile.xsd
2. Agreements.xsd
3. TPProfile samples
4. Agreements samples.

and can be furnished upon request.

Handling Positional Flat file

Apart from the capability of Handling XML file and Traditional EDI file based on various XML and EDI Standard, Oracle AS B2B also provides an option to Handle positional Flat File.

In 10.1.2.0.2 Positional EDI Document can be processed using Custom Document Plugin and following are the steps for the same.

1. Apply the latest B2B patch on 10.1.2.0.2 Installation.

2. Add the parser into registryValidator.xml

<Item
Name="SchemaFile">D:/Oracle/midtier/ip/oem/edifecs/XEngine/config/schema/IDoc_parser_40_2_char_delim.ecs</Item>

For EANCOM Based positional Flat file

There is a need to edit the registryValidator.xml to include the EANCOM parser schema. Open the eancom.ecs file that you have generated using B2B Document Editor in step 3 and Goto Tools->Generate Parser Schema. Save the parser schema for this eancom.ecs file as eancomparser.ecs . Copy this file to ORACLE_HOME/ip/oem/edifecs/XEngine/config/schema directory. Then edit $ORACLE_HOME/ip/oem/edifecs/XEngine/config/registryValidator.xml to include this eancomparser.ecs. For example,

<Item Name="SchemaFile">$ORACLE_HOME/ip/oem/edifecs/XEngine/config/schema/eancomparser.ecs</Item>

3. Design the ecs file in spec builder depending on the Positional Flat file.

4. As part of Document protocol Revision Override the Document Protocol parameter by specifying the ImplementationClass as oracle.tip.adapter.b2b.document.custom.CustomIDocumentPlugin

5. Provide the IDOC Ecs file as part of the Document definition Parameter along with start position and End position.

6. Run the End to End test.

Typical EDI Errors and Solutions

Typical EDI Errors

1. Unable to identify the Document

Make sure the document protocol parameters defined in the document definition matches the corresponding data in the inbound document.

2. Agreement Identification which involves Document Identification and TP Identification

For e.g. trading partner agreement not found for the given input values: From party [NAME-ROLE] "GlobalChips-Seller", To party [NAME-ROLE] "GlobalChips-Buyer", Collaboration name "3A4"; also verify agreement effectiveToDate

Check: Make sure to verify Trading Partner Name, Trading Partner Parameters (Optional), Document Type Name, Document Type Revision ,Trading Partner Id, Delivery Channel

3. Document Validation Error

Check: 1. Make sure Document Revision Protocol Parameters i.e Transaction Envelope has valid values.

Proper ECS file is used for Validation. Make sure you have not used xsd instead of ecs file.

4. Connection Issues
Transport error: [IPT_HttpSendConnectionRefused] HTTP connection is refused. Connection refused: connect

Check : Make sure the information about delivery channel is correct and also the end point is active. This can be done by pinging the end points.

5. Duplicate Delivery channel
Check : Make sure you have not used the host ip address for configuring the Trading partner Delivery channel.

Oracle AS B2B -EDI FAQ

1) Is it always mandatory to send the Edifecs XML to B2B for EDI processing?

It is possible to process Native EDI, Edifecs XML and any other flat file using Oracle AS B2B. Following are some of the features with native EDI/Flat File Processing.

· Translation should be switched off with optional validation.
· Oracle AS B2B would not provide features such as Batching, etc. with this configuration.
· It is required to send the complete envelope, as Oracle As B2B will not generate the envelope using Document Protocol Parameters like in case of Edifecs XML processing.


2) What if I have a native EDI file in the back end application can I process in B2B?

Refer to Q1.

3) What if I have a EDI document with multiple transactions, how do I handle in B2B?

Oracle AS B2B Processing is based on Transaction set, hence it is required to split the envelope into multiple transactions and send it to B2B. B2B translates the transaction set into native EDI and generates the envelope using the Document Protocol Parameters.

4) Can I receive EDI document with multiple transaction from a trading partner?

Yes. Oracle AS B2B provides a feature of debatching for inbound messages. Refer to section EDI Debatching for more details.

5) Can I outbound batch a native EDI documents to be sent to B2B from Back end application?
No, Refer Q1.

6) Can I identify the Trading partner using Interchange and group? How to enable this. What is the default method and most preferred method.

Default method and most preferred method is to identify the trading partner using Exchange. For identification based on Interchange/Group please add the following.




Refer to the section Trading Partner Identification for details.



7) Can I customize the group and Interchange ecs files? How?

Yes, it is possible to customize Group and Interchange ecs file using Oracle AS B2B Document editor. Refer to section User Experience while configuring EDI protocol in Oracle AS B2B for details.

8) Is there a need to redeploy the agreement in case of change in the ecs file. Does it require B2B restart?

Refer to section User Experience while configuring EDI protocol in Oracle AS B2B

9) Which database table holds the information about ecs and xsd files?

It is not advisable to access the tables directly as it is driven by the Business Logic layer of Oracle AS B2B.

select a.name from tip_parameter_t a, TIP_DOCUMENTTYPEPARAMETERVAL_T b where a.id = b.DOCUMENTTYPEPARAMETER and a.name like '%ECS%';

Need to link the following 2 tables to get to the DTD/XSD.
· tip_documentdefinition_t
· tip_nativedatatype_T

10) Can I migrate from Gentran system and what is the effort?

It is possible out of the box to migrate a Gentran map to Edifecs ecs file and back. Oracle AS B2B Document Editor provides out of the box features to do this migration. Refer to Document Editor Section for more details.

11) What is the preferred Exchange protocol for EDI?

EDI won’t mandate any Exchange protocol as such. However AS1/AS2 are the most popular exchange protocol which go well with EDI.

12) Can I disable the validation of incoming data against the document protocol parameter? Is it possible to identify the incoming document only based on ecs file?

Yes, it is possible to disable the validation of incoming document against Document protocol parameters.

Oracle.tip.adapter.b2b.edi.ignoreValidation=

Type: String
Default Value: None
Possible Values: EDI Interchange and Group envelope Parameters
Description: Users can specify a list of EDI Envelope Parameters to ignore their validation.


For e.g.: If users enters value InterchangeSenderID, InterchangeSenderQual for this property Oracle AS B2B will not validate Interchange Sender ID and Interchange Sender Qualification for the incoming message.

13) How to change the Recipient and sender Qualifier. Does it require a change in the ecs file?

This needs a change in the ecs file for any deviation from the EDI Standard .

For e.g to change the Interchange Qualifier to ‘zz’ which is not present in the list of default qualifier please do the following steps.

· Edit the Interchange ecs in the B2B Document Editor.
· Add the required qualifier i.e zz in S003-0007 and save the ecs file.
· Update the Interchange ecs file in the Document Protocol Parameter.

14) Can I implement Two-phase commit feature while batching?

Yes. By setting Oracle.tip.adapter.b2b.edi.OneErrorAllError=

Type= String
Default Value : False
Description : If the user wants the b2b server to stop processing all messages in a batch, set this flag to true., otherwise B2B server will process all valid messages and rejects only the messages that fail validation.

15) Is it mandatory to have Functional Acknowledgement in EDI.

No it is optional.

16) Consider the following batch criterion

Canon, 850, 4010, 1
Canon, 810, 4010, 1

Will B2B batch 850 and 810 documents into two separate wire messages?

By specifying No condition using 1 in the criterion column, B2B will create two batches one for 850 documents with revision 4010 and another for 810 documents.

Examples of specifying Criterion

- X12_ONE_TP will combine all X12 messages for one trading partner into one wire message
- X12_ALL_TP will combine all X12 messages for all the partners into one wire message

17) Is it required to turn on validation/translation to generate 997 in B2B.
Yes, it is a must to turn on either validation or translation to generate FA in B2B


18) How to delegate the Functional Acknowledgement generation to Back End Appliaction
Following are the two property of interest while defining the Operational Capability of the Trading partner .

a. Functional Acknowledgement Required : Set it to true to enable the Functional Acknowledgment
b. Is Acknowledgement Handled by Integration B2B : To determine whether B2B handles the Acknowledgement or Back end Application.

XMLGateway Integration

Most Prefferred way of integration of Oracle AS B2B to XMLGateway is throguh AQ i.e through a set of ECX_Inbound and ECX_outbound queues.

The following are the headers XMLG should set before it enqueues ino to ECX_OUTBOUND (like from, to, doc_type and doc_rev in case AQ),

MESSAGE_TYPE
MESSAGE_STANDARD
TRANSACTION_TYPE
TRANSACTION_SUBTYPE
DOCUMENT_NUMBER
PARTYID
PARTY_SITE_ID
PARTY_TYPE
PROTOCOL_TYPE
PROTOCOL_ADDRESS
USERNAME
PASSWORD
PAYLOAD
ATTRIBUTE1
ATTRIBUTE2
ATTRIBUTE3
ATTRIBUTE4
ATTRIBUTE5

among them TRANSACTION_TYPE ,TRANSACTION_SUBTYPE,PARTY_SITE_IDATTRIBUTE1 are mandatory. ECX* queue are not preseeded in B2B, instead they can be created by using the following script.

connect apps/apps

drop type ECXMSG;
/

create type ECXMSG as OBJECT (
MESSAGE_TYPE VARCHAR2(2000) ,
MESSAGE_STANDARD VARCHAR2(2000) ,
TRANSACTION_TYPE VARCHAR2(2000) ,
TRANSACTION_SUBTYPE VARCHAR2(2000) ,
DOCUMENT_NUMBER VARCHAR2(2000) ,
PARTYID VARCHAR2(2000) ,
PARTY_SITE_ID VARCHAR2(2000) ,
PARTY_TYPE VARCHAR2(2000) ,
PROTOCOL_TYPE VARCHAR2(2000) ,
PROTOCOL_ADDRESS VARCHAR2(2000) ,
USERNAME VARCHAR2(2000) ,
PASSWORD VARCHAR2(2000) ,
PAYLOAD CLOB ,
ATTRIBUTE1 VARCHAR2(2000) ,
ATTRIBUTE2 VARCHAR2(2000) ,
ATTRIBUTE3 VARCHAR2(2000) ,
ATTRIBUTE4 VARCHAR2(2000) ,
ATTRIBUTE5 VARCHAR2(2000)
);
/

begin
begin
dbms_aqadm.stop_queue('ECX_INBOUND');
exception when others then null; end;
begin
dbms_aqadm.stop_queue('ECX_OUTBOUND');
exception when others then null; end;
begin
dbms_aqadm.drop_queue('ECX_INBOUND');
exception when others then null; end;
begin
dbms_aqadm.drop_queue('ECX_OUTBOUND');
exception when others then null; end;
begin
dbms_aqadm.drop_queue_table('ECX_INQUEUE');
exception when others then null; end;
begin
dbms_aqadm.drop_queue_table('ECX_OUTQUEUE');
exception when others then null; end;
end;
/

declare
begin
dbms_aqadm.create_queue_table('ECX_INQUEUE','apps.ECXMSG',multiple_consumers=>FALSE);
dbms_aqadm.create_queue_table('ECX_OUTQUEUE','apps.ECXMSG',multiple_consumers=>FALSE);
dbms_aqadm.create_queue('ECX_INBOUND', 'ECX_INQUEUE');
dbms_aqadm.create_queue('ECX_OUTBOUND', 'ECX_OUTQUEUE');
dbms_aqadm.start_queue('ECX_INBOUND');
dbms_aqadm.start_queue('ECX_OUTBOUND');
end;
/

connect system/welcome1
grant execute on apps.ECXMSG to b2b
/

exit;

ENQUE SCRIPT :

The property values 'XML', 'OAG', 'POPI','POPI','1234','1234','1234' etc map to
MESSAGE_TYPE, MESSAGE_STANDARD, TRANSACTION_TYPE,
TRANSACTION_SUBTYPE, DOCUMENT_NUMBER ,
PARTYID,
PARTY_SITE_ID,
PARTY_TYPE,
PROTOCOL_TYPE



>>>>>>>>>>
create sequence poid_counter;

-- replace the TERMID 10193 with OM2N

CREATE OR REPLACE PROCEDURE enqueue_oag_message
IS
enqueue_options dbms_aq.enqueue_options_t;
message_properties dbms_aq.message_properties_t;
msgid RAW(16);
xmlgin SYSTEM.ECXMSG;
xmlgout SYSTEM.ECXMSG;
agent_in sys.aq$_agent;
agent_out sys.aq$_agent;
xml_payload varchar2(30000);
poid number(10);
BEGIN
select poid_counter.nextval into poid from dual;
xml_payload := ''||
''||
'John Smith'||
''||
'Ola Nordmann'||
'

Langgt 23

'||
'4000 Stavanger'||
'Norway'||
''||
''||
''||
'Special Edition'||
'1'||
'10.90'||
''||
''||
''||
'1'||
'9.90'||
''||
''
;
/*message_properties.Correlation := 'WEBLOGIC';*/
message_properties.Correlation := 'ORACLE-AS-B2B';
/*msgid:='ORACLE-AS-B2B';*/

xmlgout := SYSTEM.ECXMSG('XML', 'OAG', 'POPI','POPI','1234','1234','1234',
'S', 'B2B', 'http://ap100jvm.us.oracle.com:8003/oa_servlets/oracle.apps.ecx.oxta.TransportAgentServer', 'saiqa', 'chowdry', xml_payload,
null, null, null, null, null);

dbms_aq.enqueue(queue_name => 'ECX_OUTBOUND',
enqueue_options => enqueue_options,
message_properties => message_properties,
payload => xmlgout,
msgid => msgid);
commit;
END;
/

Ensure to configure the ECX_OUTBOUND/ECX_INBOUND Internal delivery channel in B2B with appropriate IP address and SID.

Trading Partner Identification in EDI Domain

Oracle AS B2B provides Identification of Trading partner at various levels.

1. Exchange level : This is the default identification based on the exchange Identifier. For e.g if the Exchange protocol used is AS2, then AS2 identifier i.e AS2-FROM is used for identification by comparing against the AS2 Identificer of the Trading partner.

2. Interchange/Group

This is a latest enhancement in B2B where in the identification happens in the order of sequence. Ideally it should be Exchange, Interchange and group. Currently B2B has facility to turn on TPIdentification based on Interchange or Group. This can be done by setting property in tip.properties

Example:
oracle.tip.adapter.b2b.edi.identifyFromTP=Interchange

OR

oracle.tip.adapter.b2b.edi.identifyFromTP=Group

If property is set to Interchange, B2B tries to identify TP using Interchange and if property is set to Group, B2B tries to identify TP using Group.

3. Trading partner Identification Any (newly Added)

If property is set to ANY, B2B will first try to identify TP using Interchange. If no TP found using Interchange, B2B will next try to find TP based on Group.

Example:

oracle.tip.adapter.b2b.edi.identifyFromTP=Any

Use of Document Routing ID in B2B

Oracle AS B2B comes with two different internal queues and are created based on IP_MESSAGE_TYPE structure whose definition is

as follows.
Name MSG_TYPE

MSG_ID Varchar(128)
INREPLYTO_MSG_ID Varchar(128)
FROM_PARTY Varchar(512)
TO_PARTY Varchar(512)
ACTION_NAME Varchar(512)
DOC_TYPE_NAME Varchar(512)
DOC_TYPE_REVISION Varchar(512)
MSG_TYPE Number(38)
PAYLOAD Clob
ATTACHMENT Blob

1. IP_IN_QUQUE

This is a default Internal Delivery Channel which is used for inbound communication i.e If the agreement do not have any

Internal Delivery Channel B2B uses this as the default internal delivery channel for sending the message to the back end

application. This comes pre-seeded with the product.

2. IP_OUT_QUEUE

This is a default Internal Delivery Channel which is used for outbound communication i.e for an internal application to send the message to the Trading Partner.This comes pre-seeded with the product.

Both of these are multi-consumer queues. Back end application uses consumer name attribute in the AQ message header to selectively deque the message from the IP_IN_QUEUE. For e.g If the BPEL Process has to deque only the HL7 message then the AQ adapter deque those messages whose consumer name is the same as what is configured in Document Routing ID for defining the HL7 Document type as part of B2B configuration.

Document Routing ID in Oracle AS B2B is part of the Document Type parameter in Document Definition Parameters page for a specific Document Type and is available as for all Document plugin in Oracle AS B2B. The default consumer name is b2buser when B2B Server enqueues to the IP_IN_QUEUE. This can be overrided by the Document Routing ID.

Following are the typical use cases supported by configuring the Document Routing ID.

1. TO distinguish between two Trading partner using the same Document Type.
2. To distinguish between two different Document Type belong to the same Trading partner.

You can change/Define/Override the Document routing ID for an existing Document Type for a specific Trading partner. This is done while defining the operational capability of a specific trading partner by unchecking the check box Use default Document definition and specifying appropriate Document Routing ID.

Anonymous Trading Partner for HealthCare Protocol

Anonymous TP is a generic Concept in MLLP Exchange protocol, where in B2B will consider any Unrecognised Trading partner as "Anonymous" and honour the inbound HL7 message. Hence it is not possible to set any Trading partner specific configuration such as FA Required etc. as it is a generic Trading partner concept. Please set

oracle.tip.adapter.b2b.defaultTP=Anonymous

in tip.properties, and make sure to create a Trading Partner as Anonymous.

If B2B fails to Identify the Trading partner details from the incoming message it will consider the Trading partner as "Anonymous". Also, ensure to apply the patch # 6139949 for this feature.

HL7 Best Practice Series

Following are some of the best Practice for HL7 Document Processing.

1. Validate the Edifecs xml document against the respective XSD in the back end application such as BPEL. This will ensure the validity of the document before sending it to BPEL.
2. Turn on the Validation for both inbound and Outbound HL7 Message for getting appropriate error message related to the validity of the document.
3. It is needed to either to enable validation/Translation for generating FA in B2B.
4. Make sure to use the same Document routing ID in B2B and BPEL for respective Document Definition.
5. Make sure to use the proper line delimiters in the document, also to define the same in the B2B configuration.

Many more to follow..

Acknowledgement in Oracle AS B2B for HealthCare Protocol

Oracle AS B2B supports various types of Acknowledgement as part of HealthCare Protocol offering.

1. Functional Acknowledgement : The flag isFunctionalAck required controls whether an HL7 ACK) is needed are not. The flag isFunctionalAclHandledbyB2B controls when FA is required whether it is generated in B2B or it comes from Back End application such as BPEL. This option is useful only when isFunctionalAck required is YES. The flag isFunctionalAclHandledbyB2B should be set to 'YES', unless there is special way ACK is generated outside B2B. Functional Ack is generated using the XEngine in B2B and captures all the translation and validation errors.

2. Immediate Ack : The turn around time of Functional Acknowledgement is considered to be little high for some business critical healthcare application as it captures both translation, validation error and is generated by Xengine. An alternative in which case is Immediate Ack which is generated and transmitted in the TCP transport layer instead of the Document layer in case of FA resulting in response time as low as 1 sec.

Oracle AS B2B can send immediate acknowledgment in three modes and the same can be mentioned using the tip.property

oracle.tip.adapter.b2b.hl7.immediateAck= <mode>

default : B2B will parse the incoming HL7 message and generate ack from it.
In this mode b2b can send the ack to the sending application with correlation details (ex. Control number from the incoming Message, Sending App.. etc)
Hence TP Application can correlate the incoming ACK message.

simple : B2B will send the pre-defined ack message to the sender and will not parse the message.

custom : B2B will read the custom HL7 ack message based on a configurable file content.
oracle.tip.adapter.b2b.hl7.immediateAckFile = < file path >

Reads the file from the above location and send it as in ACK to the sender.

SSL Setup for Oracle AS B2B

Please follow the below steps to configure B2B for SSL.

1. Configure SSL.

a. Edit Oracle_Home\opmn\conf\opmn.xml. Search for ssl-disabled and change it to ssl-enabled.
b. Startup Oracle Wallet Manager. Open the default wallet* in Oracle_Home\Apache\Apache\conf\ssl.wlt\default. Password is welcome.
c. Right click on “Trusted Certificates” Node and import the Remote Trading Partners Certificate.
d. Save the wallet in location Oracle_Home\Apache\Apache\conf\ssl.wlt\default and save as text file i.e b2bwallet.txt
e. Edit Oracle_Home\ip\config\tip.properties
f. Search for wallet location and change it to Oracle_Home\\Apache\\Apache\\conf\\ssl.wlt\\default\\b2bwallet.txt
g. In the Host Trading partner change the wallet password to "welcome"
h. Stop and start opmn – opmnctl stopall / opmnctl startall


* Note: Usage of default wallet is recommended only for Test. Request for a Server Certificate from a CA for actual usage.

2. Test SSL Configuration

a. Access Oracle Enterprise Manager.
b. Find the SSL port
c. Access the B2B Transport Servlet through the following the URL: https://hostname:sslport/b2b/transportServlet

3. Configure SSL for Trading Partners.

a.Log into the B2B UI Tool.
b. Click on Partners>>Trading Partners>>Select the Trading Partner>>Capabilities>>Select the Business Protocol>>Communication Capabilities>>Select Delivery Channel
c. Update Delivery Channel to enable Transport Security.
d. Update Transports details to select HTTPS 1.1 secure as the Transport Protocol.
e. Update Transport Server details to include the SSL port.
f. Repeat this for the remaining Trading Partner.
g. Create a Configuration and Deploy.

For a new wallet, please follow.

1. Create a new wallet with OWM (Oracle Wallet Manager).
2. Generate a certificate request from wallet manager for the host Acme.
3. Sign this certificate request from OCA (Oracle Certificate Authority).
4. Import the approved certificate in the wallet. The wallet now contains the ready certificate of host Acme.
5. Import the CA certificate. Wallet now contains the host certificate and CA root certificate. Also import the remote trading partners certificate. Wallet now has host,CA and remote trading partners certificate.
6. Export the wallet and save it as wallet.txt.
6. Update the tip.properties for wallet location to Oracle_Home\Apache\Apache\conf\ssl.wlt\default\wallet.txt. Also update opmn.xml for ssl-enabled.
7. Create the wallet password in host trading partner.
8. Create the delivery channel for host and remote trading partners with transport security enabled.
9. Create the agreement with working collaboration and secured delivery channels and deploy it.
10. Stop and start opmn – opmnctl stopall / opmnctl startall

Oracle AS B2B Firewall Setup

Please find below the step by step instructions to setup and access B2B via DMZ.

This configuration is assumed to install B2B with in the firewall and standalone OHS in the DMZ and to obtain the firewall clearence for the Following port.

1. HTTP Port of OHS which sits in DMZ
2. HTTP Port of B2B which is with in the firewall.

Append the following lines to LoadModule section of standalone OHS
httpd.conf file

LoadModule proxy_module modules/mod_proxy.so (If it is already there then not required)
LoadModule proxy_http_module modules/mod_proxy_http.so

Add following lines to end of standalone Apache2.0 httpd.conf file

ProxyPass / http://:/
ProxyPassReverse / http://:/)

To work above configuration, HTTP port on which B2B listens should be opened on internal firewall.

Testing of DMZ setup
----------------------
Restart standalone Apache 2.0
Invoke the following URL from any machine in DMZ using browser
http://:/b2b/transportServlet

Above request initially goes to DMZ Apache and we have configured Apache to forward the request to B2B instance in intranet.It should display the
'transportServlet' parameters if everything goes well.

Above testing confirms that request is being passed from DMZ layer to Intranet layer but not from outside world to Intranet layer.

Testing from outside public network
-------------------------------------
Configure external firewall to accept the data for DMZ standalone Apache HTTP port.
Use the URL http://:/b2b/transportServlet
It should display the 'B2B server' parameters if everything goes well.

DMZ setup with load balancer
-------------------------------
Optionally you can configure Load balancer like 'BigIP' on external firewall to route the requests to DMZ layer.
If you have DMZ layer front ended by load balancer then configure the load balancer to communicate with standalone HTTP server in DMZ.
In this case we expose the URL http://:/b2b/transportServlet to outside world to communicate with B2B .

Proxy configuration for B2B
-----------------------------
If you want to configure B2B to use proxy for all outgoing messages then read below.
Proxy server information needs to be provided in opmn.xml file of B2B midtier.

1) look for tag in opmn.xml
2) then look for tag 3) with in that tag make sure we should have
4) look for tag
5) then look for tag
6) with in that tag make sure we should have

In the above tag we also have some additional security attributes keep them as they are.

Now restart B2B and oc4j_b2b components or all components.

Refer the following documents for various High availability questions.

http://download-east.oracle.com/docs/cd/B14099_19/tru64.1012/install.1012/install/topo.htm#BABCFDBI

http://download-west.oracle.com/docs/cd/B14099_19/core.1012/b14003/mt_comp.htm