We are receiving 997s batched in a single transmission from a partner within which each 997 has its own ISA and GS. We have defined TPA with splitOption set to Transaction. TN is able to split the data into multiple transactions and process them accodringly. But, TN doesn’t recognize the EDI data coming from partner which has multiple ISAs. Its stored as X12 Envelope, unknown sender, and unknown receiver in TN.
I tried changing TPA to split at Interchange, and changing the unknown, unknown TPA to split at Interchange, which didn’t help.
I am pasting data sent by partner in a single transmission, below.
If you receive single ISA then no problem with X12 Envelope sender/receiver recognition right?? (regardless of splitOption)…
what is the activiylog error when unknown sender/receiver? Is it lookup fails.
Can you also check if ISA id’s and qualifiers are accordingly sent to your partner profile externalId’s and it shouldnt have no typo or extra spaces in the data??
Yes, If I receive a single ISA then TN recognizes it fine.
Infact each individual 997 within this batch gets recognized and picks up the processing rule fine, so the incoming data is fine, and enveloped with correct IDs.
I removed the extra spaces, newline characters and submitted myself in TN as a single string (containing multiple ISAs) which has same result.
Here is the Activitylog sequence
Routingrule Unknown Sender EDI Envelope process selected.
Document Persisted
Status Changed
Service error: handle exception invoked
com.wm.app.b2b.server.ServiceException: Trading Networks cannot recognize Sender & Receiver on this document.
at BWW_Utility.FlowUtils.throwServiceException(FlowUtils.java:424)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:324)
at com.wm.app.b2b.server.JavaService.baseInvoke(JavaService.java:287)
at com.wm.app.b2b.server.invoke.InvokeManager.process(InvokeManager.java:587)
at com.wm.app.b2b.server.invoke.StatisticsProcessor.process(StatisticsProcessor.java:44)
at com.wm.app.b2b.server.invoke.ServiceCompletionImpl.process(ServiceCompletionImpl.java:229)
at com.wm.app.b2b.server.invoke.ValidateProcessor.process(ValidateProcessor.java:49)
at com.wm.app.b2b.server.ACLManager.process(ACLManager.java:198)
at com.wm.app.b2b.server.invoke.DispatchProcessor.process
The interchange with unknown sender/receiver can be safely ignored. It is an “extra” interchange which represents all of the groups and tx sets in all the interchanges. It is provided automatically in case you want to work with all the data as a single unit. You’ll notice that each of the interchanges, groups and tx sets are all represented within the Transaction Analysis window. You’re not missing anything.
This is covered in the EDI with TN documentation (don’t know the page number). I believe the creation of this “extra” interchange can be disabled too, though I’m not sure which setting it is. A search of the EDI docs should yield the answer though.
You may have to check the above mentioned procedure which is OK for extra interchange with unknown would be created esp when it is a batch EDI doc and looks like there is an option to turnoff the extra interchange.I will look on this info too.
The persistMultipleDocEnvelope variable indicates whether you want the EDI Module to save the original EDI document to the Trading Networks database. The original EDI document that Trading Networks receives typically contains multiple interchange segments. The EDI Module only uses the persistMultipleDocEnvelope variable from the default EDITPA.
persistMultipleDocEnvelope true - The EDI Module saves the original EDI document to the Trading Networks database. Note that the document is saved with the sender and receiver both set to Unknown.
false The EDI Module does not save the original EDI document to the Trading Networks database. If you specify false, you will not have a way to retrieve the original EDI document.