I’m sending the EDI document to the TN using a custom service which goes as follows:
pub.file:getFile(reading the file which contains the EDI data)
pub.web:stringToDocument(converting the stream into node)
wm.tn:receive(passing the node as input to this service)
I have created two processing rules, one which handles 214,210 doc types and the other which controls the not recognized document types.so, when i read the EDI file,TN is always the triggering the 2nd processing rule which does’nt recognize the document type.
Are you seeing any error in the Activitylog?
For testing purpose did you tried to disable 2nd processing rule(unrecognized rule)and see if 1st processing rule picking up depends on the documentType you are sending to TN.
Actually try to shiftup and down the processing rules and test the scenarios.
Still problem persists,let us know the in details of your testing.
In the second processing rule, i’ve invoked a service.and whenever i pass the EDI document to TN through my custom service, this service is getting invoked and that means the 2nd processing rule is always triggered.what i see in the activity log is the service being invoked by the 2nd processing rule.no error in the activity log.
i disabled the 2nd processing rule and even then it is not picking up the 1st processing rule.
do i have to set anything else in the wm.tn:receive service other than the node?
You don’t need to map any inputs into wm.tn:receive to pass EDI data to TN. Just have your data in a variable called “edidata”.
I’d further recommend calling wm.tn.doc.xml:routeXml instead of wm.tn:receive – it accomplishes the same thing, but doesn’t waste resources validating the user (which isn’t necessary because you’re already in the IS).
TN should do a better job of recognizing your data this way.
yes always use the routeXML service and follow the instructions given by Dave for processing edidata(casesensitive) to TN.Even though receive service works the same funcionality,but i prefer to use routeXML all the time.
I’m using routeXML service but i’m still the 2nd processing rule is picked up.
pub.file:getFile(reading the file which contains the EDI data)
pub.web:stringToDocument(converting the stream into node)
routeXML(input is the node from the above service)
i dont understand where to set the edidata input parameter
You don’t set edidata in routeXML, and you don’t map anything to the node. Just make sure that there’s a stream or string variable in the pipeline called edidata (it might even work if you map your getFile output there).
What is the current doctype in TN that’s causing the 2nd rule to be selected?
When using routeXML you can send it converting to node or wrap the edi string under a temp record called(rec_scope/edidata-map edistring to edidata)and now set the rec_scope(name)in the Scope section of the routeXML service.don’t need to map edidata explicitly
Can you give some more details on your processing rules setup?
When you see the EDI document in the TransacationAnalysis is the sender/receiver/documentType recognizing and is it as per you 1st processing rule?
pub.file:getFile(reading the file which contains the EDI data)
pub.web:stringToDocument(converting the stream into node)
routeXML(input is the node from the above service)
As Dave Adler pointed out you don’t need to map anything to routeXml and you don’t need the stringToDocument step. Do this instead:
pub.file:getFile (set loadAs to stream)
MAP body.stream to a new variable named edidata
routeXML (no inputs–TN just looks for edidata variable in the pipeline)
ramesh,
I am assuming the routing rule you described is the one you want to use can you give the specifics of the other processing rule. If we have all the details for both processing rules maybe we can determine why the wrong one is being used. It sounds like the doctype is being recognized so what ever means you are using to get the document recognized into TN isn’t the issue it sounds to me like it is your processing rule setup. First describe the documents you see in the transaction analysis then give us the specifics of both processing rules. In transaction analysis make sure the sender, receiver, and doctype are being recognized at the 210 or 204 document level that will tell us a lot. Is there anything coming up unknown in the transaction analysis? Also put the processing rule that you want to select at the very top of the processing rule list, the first one, prior to submitting the document into TN.
Thanks,
Dawn
ramesh,
Another tip is to open the document in the transaction analysis and verify that the document envelope (ISA, GS, and ST) is correctly populated. I had trouble similar to this because one piece of the evelope wasn’t populated and I think that was the GS01 that I was missing which indicates the document function. If you copy the envelope here I can look it over for you, I have worked with EDI for almost 20 years so I’m pretty good at debugging issues with it.
Thanks,
Dawn
Here are the processing rules: #1.Should be selected whenever 204,214 or 210 arrives TN.
sender------Any
receiver------Any
Document Type-----X12 4010 204/X12 4010 210/X12 4010 204
User status------Any
Recognition errors-------Has no errors
under Action tab:
calling a custom service
#2.Should be selected whenever a doc type other than 204,214 or 210 arrives TN.
sender------Any
receiver------Any
Document Type-----Any
User status------Any
Recognition errors-------May have errors
under Action tab:
calling a custom service
splitOption in default EDITPA is at Group level.
As Rob said, i did exactly the same way:
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)
and when i run the above service,what i see in the Transaction Analysis screen is:
DocumentType-----Unknown
Sender-----Unknown
Receiver------Unknown
Processing status------Done
I’m attaching the edi doc.
[img]http://www.wmusers.com/wmusers/icons/attachment_icon.gif[/img]
20.3 K
Here are the processing rules: #1.Should be selected whenever 204,214 or 210 arrives TN.
sender------Any
receiver------Any
Document Type-----X12 4010 204/X12 4010 210/X12 4010 204
User status------Any
Recognition errors-------Has no errors
under Action tab:
calling a custom service
#2.Should be selected whenever a doc type other than 204,214 or 210 arrives TN.
sender------Any
receiver------Any
Document Type-----Any
User status------Any
Recognition errors-------May have errors
under Action tab:
calling a custom service
splitOption in default EDITPA is at Group level.
As Rob said, i did exactly the same way:
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)
and when i run the above service,what i see in the Transaction Analysis screen is:
DocumentType-----Unknown
Sender-----Unknown
Receiver------Unknown
Processing status------Done
I’m attaching the edi doc.
Please also make sure the sender/Receiver profile matching with the same externalID’s/Qualifiers exist matching to that incoming edi document and see if any extra spaces are adding to the DUNS numbers/userdefined.This could be one of the the reason for “unknown” while recognizing the document.As Dawn said it happens some times and after lot of debugging.
Since your processing rule is none sender or receiver specific lets focus on the doctype recognition first. Do one thing for me change your 1st processing rule to error recognition of “may have errors”. This will give us a better chance at seeing what is going on. Do this change, resubmit the document into TN, go to transaction analysis, view the document, go to the activity log tab of the document and give me a rundown on what activities are occurring. Once we get TN recognizing the document contents then we can go from there. Also while you are viewing the document go to the content tab and tell me the name and type you see. Is your EDI document displaying in the content as you had it in the attachment?
Thanks,
Dawn
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.
As RMG said,if the there is any problem with the External ID qualifiers, then the above scenario should’nt work.
I cant understand this abnormal behaviour.If i submit data from http://wexapd05:5555/WmEDI/(submit the data link),the doc is picking up the correct processing rule.
edi doc