Strange exception error when submitting EDI

Hi, our project involves sending a Purchase Order from WM to another gateway. When i tried to submit a EDI-PO with multiple ST in a single GS, it failed-- "Couldnt insert new document (0) java.sql.SQLException: [wm-cjdbc33-0009][Oracle JDBC Driver][Oracle]ORA-00001: unique constraint (LTM_POC.PK_BIZDOCREL_DOCID_RELATDOCID) violated (1) java.sql.SQLException: [wm-cjdbc33-0009][Oracle JDBC Driver][Oracle]ORA-00001: unique constraint (LTM_POC.PK_BIZDOCREL_DOCID_RELATDOCID) violated"But when I tried again with only one ST in a GS, the error does not repeat.Same is the case when multiple GS are there inside a single ISA.(gives same error).My friends adviced to reinstall the TNDB. But no luck.The issue is still not resolved. Any suggestions over this ???

Please make sure the EDI schema for ST segment is maxRepeat=9999 or not ?applies same for ISA/GS in the the envelope record in WmEDI package
What is another gateway?Is it another WM or other middleware?

HTH,
RMG

When submitting multiple ST or GS blocks, what are the control numbers? Are they unique or are they all the same?

Thanks for all the suggestions.

I change the control numbers of the Interchange,group and all the ST whenever I try to submit.Moreover, as suggested, i tried making maxrepeat to 9999. Still no luck.:sad:

The other gateway is a third party middleware not WM.

Then problem could be in the 3rd party middleware what is the product name?
Well you are on the right track with unique controlnumbers in ISA,GS,ST level.But is this edi document persisting in TN?Just do a simple test routing the document to source TN and validate it.

HTH,
RMG

Am totally confused now…

  1. The Control number problem and max repeat is ruled out now.
  2. The document is persisting in TN.

When I check the activity log, it shows the follwoing:
message: document persisted.
Error: Perisistence service failed (for the saving class)

Please suggest if using of TN queues could be a possible solution to this.

The other middleware is GIS. We FTP EDI to this gateway.

“Couldnt insert new document (0) java.sql.SQLException: [wm-cjdbc33-0009][Oracle JDBC Driver][Oracle]ORA-00001: unique constraint (LTM_POC.PK_BIZDOCREL_DOCID_RELATDOCID) violated (1) java.sql.SQLException: [wm-cjdbc33-0009][Oracle JDBC Driver][Oracle]ORA-00001: unique constraint (LTM_POC.PK_BIZDOCREL_DOCID_RELATDOCID) violated”

The key part of this error message is “PK_BIZDOCREL_DOCID_RELATDOCID”. This constraint is defined by:

ALTER TABLE BizDocRelationship
ADD ( CONSTRAINT pk_BizDocRel_DocId_RelatDocId PRIMARY KEY (DocID, RelatedDocID) ) ;

This is created when the create_TN_6-1_Oracle.sql script is run to create the TN tables. The two columns in question, DocID and RelatedDocID, refer to documents stored in the BIZDOC table which has DocID as the PK. The entry in the BizDocRelationship table is automatically created by the EDI parser when it is de-enveloping and splitting the received file. This failure means that during splitting it is trying to create relationships (e.g. between an interchange and its groups, or between a group and its transaction sets) multiple times–or they already existed from a prior run.

All DocID values are automatically generated by TN when documents are submitted. These values are an internal ID that is essentially a UUID.

So there are two possibilities that I can think of: 1) there is something wrong with the service that creates the DocID values; 2) the code that is submitting the EDI document is doing something out of the ordinary.

Can you describe exactly how the EDI PO document is being submitted to TN? Can you post the FLOW snippet in question?

Is this a variation of the TN timestamp bug that hit a year or so ago?

Mark

Hurray!!! At last it worked:)

Thanks for all your valuable inputs.
There was a flow service in an earlier module that had put some data in pipeline.This has led to corrupt EDI submission.

We had to deactivate that save to pipeline step and cleared the pipeline data. Then, it worked wonderfully as expected. Thanks to all once again.