Duplicate 997 EDI file names.

Scenario- Its quite obvious that for each Inbound EDI transaction received from the Trading Partner, a corresponding Functional Acknowledgement(997) needs to be sent back to the TP. In our case we had Adjustment Transaction Set (895) coming from the TP which was quite large in number(traffic wise) and so the 997s also became quite large in number.

Problem- There were some cases where the outgoing 997 files were being created with the same file name by B2B when they are generated at the same moment of time.Thus the TPs were missing some 997s as B2B was overwriting the file with the same name.The outgoing file name format was ("%FROM_PARTY%_%TIMESTAMP%.dat") .

Cause- There was no direct cause to find the reason as why B2B was behaving in such an abnormal way as the 997 was automatically initiated by B2B as soon as it received the inbound file.
PS: Make sure that MLR #15 or later version patch is already applied on your B2B server. If not then kindly apply the same and then check.

Solution-Definitely problem was with the time resolution. If resolution is not in nano-seconds then such problems may occur under heavy load. Oracle B2B internally uses JAVA API's for creating time-stamp and if OS does not have nano second time resolution then time-stamp may not be unique.
To remove the discrepancy of time format in the filename, i made the name unique by using Message ID ("%MSG_ID%") in the file name and prblem was solved.

You can also use InReply to Message ID ("%INREPLYTO_ID%") in filename format to keep it unique.

Happy learning!!

Cheers

Ayush

Overriding of Document Protocol Parameters in B2B

Once we came across a very interesting scenario, wherein we want to have different 'Segment delimters' for different transactions of same protocol revision of same trading partner, e.g
For partner 'ABC ' transaction '894' segment delimter should be 0x7f and for '880' it should be 0x3e.
We followed the below steps-

• Goto - Remote TP --> Operational Capability --> Respecive Business Action --> Document Protocol Parameters



• Update the segment delimiter for each Business Action.



• Re validate and Redeploy the agreement

NOTE:- B2B doesn't allow to set different Document Protocol Parameters for different transactions of same protocol revision and same trading partner. If you change in one of the transactions it will automatically reflect in the other.

We all know that for every EDI transaction, we generate its corresponding XSD(schema) from B2B Document Editor.

To make it work, we need to make use of Internal-properties defined in the transaction's xsd. When you add this xsd in your B2B adapter, you can pass the desired value in any of the document protocol parameters with help of XSLT and this eventually overrides the value set in B2B console at run time.

Regards

Ayush

B2B Batching of transactions not happening

Scenario:- We had to batch all the EDI outgoing transactions for a particular trading partner 's particular EDI transaction. For eg- Lets say we have 100 invoices(810) coming from EBiz/SOA into B2B for trading partner 'A' in one transaction.Now we have to club all the 100 invoices into one EDI file and send it to 'A'.

Problem:- I won't discuss how batching is done in B2B. You can get the complete details in this below link
http://www.oracle.com/technology/products/integration/b2b/pdf/B2B_TN_012_EDI_OutBound_Batching.pdf
We faced an issue where even after applying the logic correctly, the batching was not happening.The transactions remained in the WAIT BATCH state forever in the B2B console.Even if we bounced the B2B server, neither the existing transactions were completed nor the new transactions were batched.
The interesting part was that it was happening only in one of b2b instances because it was working perfectly in another b2b instance which meant that my batching logic was correct.

Cause:- After doing some research in the b2b database, we found that the parameter "job_queue_processes" which specifies the no. of processes allocated to run the "ip_b2b_dbms_job" was significantly low , in fact the value was 0.
This parameter can be seen using sqlplus 'show parameter job_queue_processes'. The sample pl/sql code is as below:
CREATE or REPLACE PROCEDURE ip_b2b_dbms_job AS
x NUMBER;
BEGIN
dbms_job.submit(x, 'B2B_TIMEOUT_PROC;', sysdate, 'sysdate + (1 / 1440)');
commit;
END;

Solution:- We need to increase it's value to 5 or 10 and then bounce the B2B DB and Server.
This worked!!

Regards
Ayush

B2B abruptly fails to communicate to the FTP serverr

Scenario:-There was a scenario in my project where we had Inbound transaction 895s configured for a trading partner and we had to send a Functional Acknowledgement(997) back to the TP for each 895 received.

Problem:- We had hundreds of 895s coming at a time into B2B and while B2B was sending 997 for each 895, some of the 997 edi files failed at the FTP Server. That meant some of the 997 edi files failed to appear at the FTP location while the rest of them were successfully created.
Error in the B2B logs-
oracle.tip.transport.TransportException: Unable to read response from host '$FTP HostServer'
java.net.SocketException: Connection reset

Cause:-As problem was very strange because B2B was abruptly loosing connections to the FTP and the FTP server logs were clean too, we couldn't drill down to the exact cause of the problem, so we concluded that this issue is intermittent and the possible cause could be network or environment issue.

Solution:- Since we were not able to do a root cause analysis (even after seeking help from Oracle support) and at the same time we also needed a workaround to come out of this situation, we used the Retry Count facility available at the Delivery channel layer of the TP. By setting the Retry Count and Retry Interval to some specific value,we were actually cutting down the possibility of the connection failure between B2B server and the FTP.

Result :-The B2B was successfully able to connect to the FTP in the one of the retry attempts if it anyhow failed in the previous attempt.
Its better to configure the retry mechanism for each EDI transaction beforehand.

Cheers
Ayush