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.