I am getting an error message when sending XML (pub:routeXml) to trading networks. I am sending EDI information like sender, receiver, version, etc… I have tested the XML that I am sending with the document type in TN. It finds the correct document. I then try to test the processing rule but the Sender cannot be found. I have the sender set up as a trading partner so I am not sure why it is not working. Also, if I change the version of the EDI document from 04010 to 00200 it finds the sender. I am getting the following error:
Transform for SenderID of doctype EDI Batch Envelope 4010 810 invoice data failed to produce a value. The transform function was FN_PARTNER_LOOKUP, the first original value was 12345678
Why would it work with one EDI version and not another? Any help will be greatly appreciated.
Are you trying to send EDI or XML document to TN?I believe its EDI 810 4010 right…
What is the senderid qualifier in ISA envelope?Please make sure the id and qualifier (ExternalID/Type) matches according to TP profile setup and TPA’s if defined.So it will recognized the sender and right rule will be triggered.Also in the rule did you selected 4010 810 doctype?
I am sending an XML document with sender, receiver, edi version, group, etc… Yes, I am using the EDI 810 4010 document. The sender Id in the EDI document matches the DUNS number that is setup for that Trading Partner profile. There are no TPA’s defined. Why would the XML that I am sending work when I change 00401 to 00200? If I do that TN is able to recognize the sender. Also, I have picked the correct doc type in my processing rule.
When I try 00400 it no longer recognizes the receiver or the sender. When I use 00401 it recognizes the receiver but not the sender???
What I am doing is taking an EDI string and getting information from that and putting it into a document (EDIMetaEnvelope). I then convert that document to XML and publish it to TN. From there, TN should find the document type and then process the correct rule which will then kick off a service to format the EDI file into a flat file. This is not happening because the sender is not being recognized by TN. If you know of a better way of doing this please let me know.
Why dont you straight away route the original EDI string(edidata with envelopes) to TN via routeXML,so that your rule kicksoff and convert the edi to FF.This way you can minimize the flow steps extra customization of XML document etc…
Please make sure the senderID doesnt have any spaces or typo etc in the xml file.Also check the documentType query criteria for sender/receiver in documentType section matches with your input xml data.
Definetly the TN profile/data setup is wrong for recognizing the document.
We tried sending the entire EDI string to TN via route XML but had issues. When we converted the EDI string to XML and tried to send it, it failed. After doing some digging I found that there were some characters in the EDI file that were causing the XML to not be recognized (&). So what we did was took just the information that was needed from the EDI string (Envelope) and published that instead of the whole file. We then use TN to kick off a service to process the rest of the file. We have other partners set up on a similar process and it works fine, that is why I am confused. What setups should I be checking? The sender id is the exact same as the DUNS number for that partner. Are there any other setups that I can check?
Thanks again for your help on this issue. I have been trying to figure it out for the pas few days.
ollie1 ,
I trying real hard to recall what i did to fix this error as i have seen it the past…But im super-sure that it had something to do with a mismatched ID.
Please let us know what you did to fix your problem.
I sincerely hope this little bitty thing helps you.
Scooby
These seem to be conflicting statements. Which document type are you expecting TN to see? I assume EDIMetaEnvelope.
For that doc type, how are the attribute extractions for sender, receiver, doc ID, etc. defined? For the sender and receiver, which external ID are they intended to match (for XML, they can only match one type, unless you’re doing a custom transformation)?
How are the external IDs defined for each sender and receiver? When you map the sender/receiver IDs from the EDI string to the XML fields, are you accounting for the qualifiers?
It seems like there may be a mixing of EDI-oriented configuration and XML configuration, where EDI identifiers are being used in the doc and defined in the profiles, but the doc recognition step assumes a consistent external ID type.
What sort of issues? It seems like you’re going through a lot of work to make EDI function like XML.
“Better” is always a subjective thing and any qualitative evaluation needs to consider all the info available–how’s that for a disclaimer! . Given the limited info I have about your situation it’s risky to make a recommendation but I’ll offer one anyway–you should try to treat EDI as EDI, not XML. There are a lot of things that WmEDI and WmEDIforTN give you out of the box and if you avoid using them, then you’ll either forego those benefits or have to reimplement them yourself.
Perhaps this thread can turn toward addressing the issues you faced when submitting the EDI string directly to TN?
You should try to treat EDI as EDI, not XML even if EDI has some special chars & in the data TN can handle it and transform to bizdoc/content (edidata) using bytesToString and followed by convertToValues for parsing and map to XML structure.
Ok, Maybe I should clarify what we are trying to do. We receive an EDI document from an external source. I then take information from the EDI document and create the EDIMetaEnvelope. I convert the EDIMetaEnvelope to XML using the pub.xml:documentToXMLString process. I then use pub.xml:xmlStringToXMLNode. I then take the node and send it to TN using wm.tn.doc.xml:routeXML. Within TN I have the document type set up and it recognizes it correctly (Standard = X12, Version = 00401, GroupType = IN). I then have a rule set up that if the sender is = ‘A’ and the receiver = ‘B’ and the document type = ‘C’ then take the following action. When I run my process the document it getting recognized, the receiver is recognized, but the sender is not. No matter what sender I put in the file it does not get recognized. The other thing that is confusing me is that if I run the file through as a version 00200 it works fine.
Hopefully this will clear up the process that I am running.
Basically its not a standard EDI process you have done,i guess there could be good reason behind.As per your flow you are creating additional complexity of processing document to TN.Why dont you route EDI document directly to TN instead of treating EDI as XML extra mapping.
IS the xml delivering to trading partner or just for any internal processing?
Its weird that version with 00200 working fine,but 00401 not working.it sounds XML documenttype query is looking for 00200 for Sender?
To tell you the truth, we had a webMethods consultant work with our company a few years ago because we were new to using webMethods. He helped someone create the process that I have explained. I duplicated it for what I was doing. That is why I am doing it the way I am. Could you please explain to me how I can EDI directly to TN so that it can recognize what I am sending or at least point me in the right direction. I would greatly appreciate it.
Basically first you need to install EDI X12 4010 810 doctype in TN using ISAdminConsole/WmEDI homepage,look for install edi document types and create processing rule for Sender/Receiver,documenttype and trading partner profile with External ID’s depends on the EDI sender/receiverid’s,qualifiers (say DUNS=01,ZZ=MutuallyDefined,12=Phone etc…).So the document will get recognized matching with EDI ISA/GS envelopes in the transaction analysis.
Once they are in place you can either use EDI document submission in the WmEDI homepage which will hit tn:receive or build a flow i hope you have edidata string and use routeXML for routing this edidata to TN.
These steps are the standard used for EDI processing via TN.
Also please reply with Rob’s queries which helps for debugging root cause of Sender recognition.
I ran the EDI file through the WmEDI homepage and TN recognized the sender and receiver. I plan on changing my process to eliminate the sending of XML data to TN. Thanks for all of your help on this issue. I looked through WmEDI and I did not see a recieve service. Does this exist so that I can use it in a flow?
Ok, I found wm.tn:receive. I tried to take my EDI string and convert it to a node. I then used the node as input to wm.tn:receive. This does not work. Is this the right service? If so, what do I give it for inputs?
. Given the limited info I have about your situation it’s risky to make a recommendation but I’ll offer one anyway–you should try to treat EDI as EDI, not XML. There are a lot of things that WmEDI and WmEDIforTN give you out of the box and if you avoid using them, then you’ll either forego those benefits or have to reimplement them yourself.