Does anyone know why the test function for processing rules or document types will only accept xml files? I’ve used this in previous versions and I thought there was an option to select ff or xml, but that I’m not 100% sure of. Now trying it in 8.2.2, every time I test I only get the default rule and an “The document is probably not valid XML.” error in the logs. I’ve tried with files containing an x12 4010 850 flat file contain ~,* and spaces as delimiters.
I create all the files I’m testing right out of the content of recognized TN EDIdata. Not sure if there is a setting somewhere or maybe something wrong with the package that this calls.
Any help would be appreciated.
Hi,
What format files are you sending it to MWS/TN and is the document type FF or EDI other than XML you created not showing up or it’s the data you are submitting is not being recognized?
Are you trying to submit test data from the MWS pages to TN?
Can you please pull the error from the activity log that you are facing issue?
HTH,
RMG
Basically I’m doing exactly what the documents say to find out which processing rule is being executed.
I’m hitting the green checkmark in TN or under the advanced tab in my webMethods,
Loading the file that contains data I copied out of a recognized doc,
then hitting test.
results are the same just no matter what the contents of the file are:
2015-10-15 12:20:08 EDT wm.tn.doc:recognize There was an error in trying to get XML header information (DOCTYPE and DTD). The document (apshoh00a1m4qb0100000105) is probably not valid XML.
I’m well aware I’m not sending an xml, I see no option to have this test function any other way.
We are currently using 118 different processing rules, so it’s nice to use the test button to make sure they are in the correct order.
the only way to test it now is to let it run in production and hope the order is correct so the correct service gets executed.
By the way XML processes/documents work fine. Can copy the data, save to file, then test with no issues.
when you call: wm.tn.doc:recognize, the EDI content should be passed as bytes to the “editdata” parameter (which doesn’t show on the service interface), so TN won’t treat it as xml.
Correct.
I would assume the “test button” knows that and would take care of that, since the user has no control over it. I’m assuming something is setup or was converted incorrectly when upgrading to the 8.2.2 version. I’ve used the function 100’s of times in my past positions and it always seemed to just work.
Could it have anything to do with the document type being created by webMethods and the “Document type Details” has xml in it
DOCUMENT
–O xml
+O ST
(this is created automatically when adding an EDI doc type)
Unfortunately I don’t have access to a myWebmethods that you can actually test a document that isn’t XML and works.
No you should add any thing special to EDI docment type or edit it.
Basicall you can you create a service and call the routeXML or tn:receive (pass it as edidata (case sensitive variable) in the pipeline and it should work to resolve your testing and show up in the TN.
Is that not what you are expecting end result?
Also you can still use WmEDI Home page Submit Test EDI Data or MWS thru for EDI data submits,
HTH,
RMG
Thank you for your responses. I’m not sure if I’m being unclear or confusing. All I want is the “test” function to work as the documentation says, and has for me in the past :
“Testing the Order of Processing Rules
You can test the order of your processing rules to ensure that Trading Networks selects
the correct processing rules for your documents. If you find that Trading Networks is not
using the correct processing rule, you can re-order the rules.
To test the processing rules, you must have sample documents available in your file
system. To perform a test, you select the sample document. Trading Networks performs
the following actions on the document:
? Recognizes the TN document type
? Extracts attributes as specified in the TN document type
? Determines all the processing rules the document matches
Note that Trading Networks does not test the sample document against disabled
processing rules even if the Processing Rules screen is currently displaying disabled
processing rules. For more information about disabling processing rules”
I realize submitting data will select a processing rule. I need the ability to see all the processing rules that apply to a specific document and readjust the order to get the correct one to run.
OK I got you what you are looking for 
Sometimes simple things aren’t the easiest things to explain.
Very true 
so… does anyone know how to get the “test” button to work?
Is your new processing rule about the default rule?
Also when you submit the data is the expected rule is being not invoked correctly? If yes can you make sure the criteria is matches and no other rule taking precedence?
HTH,
RMG
New Rules are always above default. Even if it was below, it should actually find both rules in the test.
Even in “Document types” the test button doesn’t work. It is somehow defaulted to xml and errors on anything that isn’t. If I save a x12 4010 997 to a file, then click test, select that file, test. I get an error about an invalid XML header. a X12 4010 997 is not xml, so it should not be expecting an xml header. If I save an EDI_DC40 order, which is xml. Then test. it works fine. I just need that “test button” to stop expecting XML. I’m hoping once we upgrade to 9 this wont be a problem.
Some times it’s not above default anyways if you are sure.
Can you please upload a screen shots when the test fails for this narrated scenario?
If I save a x12 4010 997 to a file, then click test, select that file, test. I get an error about an invalid XML header. a X12 4010 997 is not xml, so it should not be expecting an xml header
HTH,
RMG
ISA~00~ ~00~ ~ZZ~ALTRAxxxxxx ~01~0xxxxxx12PA ~151023~1313~U~00401~000001968~0~P~>
GS~FA~ALTRAxxxxxx~0xxxxxx12PA~20151023~1313~603~X~004010
ST~997~0001
AK1~PO~550
AK2~850~0001
AK5~A
AK9~A~1~1~1
SE~6~0001
GE~1~603
IEA~1~000001968
For the first error basically you cannot edit/open EDI document type this is restricted by default normally via TNC and that might be the reason test only works for XML types but not EDI doc types.
HTH,
RMg
but it should find it
May be it’s better open a incident with SAG support and troubleshoot more.
HTH,
RMG
Thank you for looking into this. I appreciate it. I was hoping it was a simple setting that was missed.