“The funny part is when i submit the EDI data from the Home Page of the EDI Module,it is identifying the EDI doc and picking up the correct processing rule.”
This is because the Sender/Receiver set to Any and since the documentType is getting recognized so the correct processing rule is picking up.Is it always picking 1st or 2nd rule in the Activity log?
ramesh,
That is interesting. Please give me the information on the content and activity log for the document in the transaction analysis. It might give us a clue as to why this submission doesn’t work versus the other that does. Compare the results from both and let us know the differnce you see in the document in transaction analysis. The type on the content tab may be the key.
Thanks,
Dawn
RMG,
when i submit the edi data from the EDI Module home page,it is picking up the correct processing rule(1st one).and when i call this custom service which submits the data to TN,it is picking up the 2nd rule.
“This is because the Sender/Receiver set to Any and since the documentType is getting recognized so the correct processing rule is picking up”--------so why does’nt this happen when i submit the same data through a custom service whixh goes as follows:
pub.file:getFile (set loadAs to stream)
MAP body.stream to a new variable named edidata(string type)
routeXML (no inputs–TN just looks for edidata variable in the pipeline)
ramesh
This is a valid transaction set. My system recognized it as a 214 set, even though the sender and receiver were unknown. This held true when I submitted it from the EDI package home page and when I dropped it into a file polling folder that passed it to wm.tn:receive.
This suggests that there is something wrong with the service that’s submitting it to TN. I would want to see the content and attribute tabs from the TN transaction. Specifically, is the edidata there or is there some unknown/unhandled content part.
Tim,
Here is the service code and the edi data.
Can you let me know whatz wrong in the service?
sendDataToTN.zip (1.8 k)
test.edi (20.3 k)
ramesh,
Please let us know what is in the content tab of transaction analysis for this document (both the good one and the bad). What is the type on this tab? Does the contents look the same from the good one to the bad one? Also the activity log for that document will likely give you some recognition error or something that can also give us a clue as to what TN is seeing as the problem in recognizing this document type when submitted this way. Make sure to change your processing rule to “may have errors” and see if it gets selected then. If you see that it works with this change then you identify the error (duplicate document or something) fix the error and then you can change your processing rule back after resolving the error. Process of elimination, one variable at a time, is usually helpful in getting at problems such as these.
Dawn,
Content type under the content tab when i submit through the custom service is application/x-wmidatabin and whereas when i submit through the EDI MOdule Home Page,it is application/EDI; charset=UTF-8.
ramesh
Ramesh,
If it is showing content-type=application/EDI and charset then EDIidata variable will be shown in the content section which is valid processing and recognizes the document.
application/x-wmidatabin is not valid and this is causing unknown recognition.But i bet routeXML should work always and try to convert edistring to node and submit it.
HTH,
RMG
ramesh,
Lets eliminate another variable by using the same service that is used when you submit a sample in the admin console. Use wm.tn:receive to get the document received into TN. Map the stream from your getfile to string edidata. Map the edidata to the node on wm.tn:receive. See what you get in TN after that. If we get this to work then we can trouble shoot the routeXML further, I use both.
Thanks,
Dawn
Hey Dawn,
it worked when i changed the edidata type from string to object and mapped it to routeXml node variable.
Thanks Guys for your valuable suggestions.
Have a Good Day!
I have a small question.I’m processing 204,210,214,990,997 docs for a particular set of trading partners.so, when i create a processing rule,under the document type,do i need to select all the above doc types and also the X12 Group.please suggest.
Note:spiltOption variable in EDITPA is Group.
ramesh.
Ramesh,
I took a look at your service and you are directly mapping the input stream to a string variable called edidata. I think that may be responsible for the unknown content type when it gets to TN. Thanks,
Tim
Ramesh,
Glad to know that it worked finally…see debugging helps a lot…
Hi Guys,
I’m processing 204,210,214,990,997 docs for a particular set of trading partners.so, when i create a processing rule,under the document type,do i need to select all the above doc types and also the X12 Group.please suggest.
Note:spiltOption variable in EDITPA is Group.
ramesh.
Ramesh,
I think the processing rule you need depends on what you’re trying to do. Since you’re splitting at the group level, I assume that you’re using a custom service to extract the individual transactions from the X12 Group document. Your processing rule for that document type only would invoke the custom service. If this service then submits the individual transactions to TN, you would need a separate rule (or rules) for these. I’ve never done splitting at the Group level so someone else can correct me if I’m on the wrong track here. Thanks,
Tim
ramesh,
If all these documents have the exact same requirements of the processing rule then yes one processing rule will do it all. If you need to execute different services for different documents then create a unique processing rule associated to the unique requirements for that doctype or trading relationship.
For example we have the exact same document going to 2 different trading partners. One trading partner requires immediate delivery and the other requires batched documents in a single ISA one time per day. Ultimately they run the same mapping service, but to accomplish the batching the intial program executed is a service that maps and batches while draining a queue. They each have their own processing rule for the same doctype but different receiver Id’s. If the trading partner that wishes to receive the batched EDI file changes their requirements to now have immediate delivery I simply add that receiver to the first processing rule that does not batch and my job is done, no coding necessary. The reverse is also true, less likely, but true. If the immediate delivery trading partner decided they liked batched EDI I simply switch them to the processing rule that batches documents. Again they share the same mapping logic just different delivery processes.
I tend to use processing rules as much as I can to control partner specific requirements to insulate those specific requirements from the coding as often as I can.
One more thing if you do your processing at the document level (210, 214, etc…) then do not add the group envelope as a selected doctype in that processing rule or you will have your service executed twice I believe. Chose your processing to either be at the group level or the individual document level but not both.
HTH,
Dawn