The service wm.tn:submit does not do the recognition part - it assumes that the document is already recognized. Use wm.tn.doc.xml:routeXml instead which recognizes the XML and submits it for processing.
Since routeXML takes xml node as an input, use documentToXMLString and xmlStringToXMLNode in conjunction to get xml node from your xml document - if your invoice is an IS document or just xmlStringToXMLNode if the invoice is just an xml string.
In general I think the scheduled task would work better since processing has to wait until 2 separate files are present. You have more control over how the file is handled. You might want to see [thread=9950]this[/thread] thread which discusses a similar situation.
In the TN Document Type that you have setup for your Invoice, check if the document identification is properly set and also double check the extraction queries SenderID and ReceiverID for that Document type. Then resubmit the data to TN using routeXML and see if it works.
I am pretty sure you would find your solution in one of the above.
Reason for your unknown recognizition is because it is TN defaultrule is selected.Are you sure your TN setup (profiles,externalid’s,documenttype recognition,processing rule are confirgured properly??).Please make sure step by step and see whats going on in the Activitylog/IS logs.
Rohit’s comments above are also pointing in the same direction.Pls check the same.
If your document, sender, and receiver are not getting recognized, then first focus on figuring out why the document is not getting recognized. If TN can’t recognize the document type, then it definitely won’t recognize the sender/receiver, since sender/receiver identification queries are stored in the document type definition.
I suggest opening the TN console, going to the Document Types screen, and using the “Test document types” button to run your XML through. If a message comes back saying “1 Document Type found”, then you know that something your service is causing the problem. Otherwise, you’ll probably have to change your document type defintion (ie. the Root Tag and/or identification queries).
Now, in the TN Document type for above XML, the identification can be based on the Root Tag - ie, Root Tag = DesignClaimRequest
The SenderID Query (under Extract tab) should be set to DesignClaimRequest/SenderID and
The ReceiverID Query (under Extract tab) should be set to DesignClaimRequest/ReceiverID
Besides, let’s say you want to extract RNET_TransactionId, the query for that would be: DesignClaimRequest/DesignClaim/RNET_TransactionId
So you see, you have to set an identification criteria that uniquely identifies your document and then, you set up extraction query, which is the path of the attribute in your XML, to get the attribute(s) that you want to extract.
Thanks to all who have so patiently helped me.
Percio… I had no idea you could test a document thanks for the tip.
I have it recognizing the document type but something is WRONG.
(PIDX 1.0)
root tag Invoice
It finds the document type and handles it
HOWEVER
If any identifying queries are added via the Test Query it STOPS working.
My thinking is… In document set up if I load the file, Test the Query, and have the program insert the Identifying Query when I test that same document IT SHOULD WORK. But is isn’t
Q1: What is the identifying query you are tyring to use?
Q2: Do you really need an identifying query? In other words, will there be more than one document type that have the root tag Invoice?
I believe the root tag should be "pidx:Invoice"?? and not just Invoice as per your PIDX XML document.Did you tried this??What is your current identifying queries set to Sender/Receiver/DocumentID etc…recognition??
I suspect that the identifying queries may be failing due to namespace issues. Make sure you have the namespace stuff configured in your doc type, if you want to use identifying queries instead of just the root tag.
FYI…In general any XML document must/should have this tag starting with <?xml version="1.0"?> otherwise even xmlspy or any other product cannot validate or consider it as proper XML doc nor be well formed.