Tried to pass TN_parms for a XML document - it successfully recognized the set value for /TN_parms/DoctypeName but did not recognize the set values for /TN_parms/SenderID nor the /TN_parms/ReceiverID that were passed into wm.tn.doc.xml:routeXml. I currently have this working for flat file documents. Any ideas on why the SenderID and ReceiverId are not being recognized?

Tim,

If you use routeXML service you dont need to pass TN_Params ie Sender/Receiver/DocTypeName,just map the node and execute the service upon receiving TN will recognize the DocType,Sender,Receiver and trigger the processingrule.

But when using routeFlatFile service for routing flatfiles,TN_Params should be mapped

HTH,
RMG.

The XML that we receive is not being validated - passed within <cdata> tags so we do not know the SenderID/ReceiverID. We are pulling the SenderID/ReceiverID from the SOAP header and trying to pass them in with the route call to allow TN to recognize and trigger the processing rule. So is there a way to pass in the SenderID and ReceiverID along with the DocTypeName to get TN to recognize it based off of these three values to kick off the proper processing rule?

Sorry i am not sure this can be accomplished by routeXML and setting TN_Params for Sender/Receiver.

let c if anyone have done some custom routing of this type.

Regards,

I would suggest to retrieve these Sender/Receiver values from your Soap header and then to add them to the received functional xml document (populate a TN_parms ISDoc that you transform into an XML string that you concatenate with your own functional xml document). You could then send this resulting xml string out to TN (routeXml) for recognition using your TN_parms tags.

You can later remove these additional xml tags within the first service invoked by TN to process this xml string

Philippe

“The XML that we receive is not being validated - passed within <cdata> tags so we do not know the SenderID/ReceiverID. We are pulling the SenderID/ReceiverID from the SOAP header …”

Is the SOAP header within the cdata tags? If so, would having the entry service simply extract the xml doc from the cdata tags and then submit that to TN for processing work?

Side note: what’s the reason for using the cdata tags? I ask because in the past when I’ve seen those used it’s usually to try to get around the need to HTML encode the values within tags–which makes life (somewhat) easier for the doc creator but simply causes grief for the doc receiver.

Tim,

Another option is once you extract the SenderID/ReceiverID from the SOAP header map it to your xml(ISDocument that you are routing for processing)so add 2 more additional fields in the ISDocumentType for Sender/Receiver,once you have final xml string convert to node and map it to routeXML then upon receiving TN will recognize the sender/receiver/doctype and also make sure in the TN DocumentType section in the Extract tab for Sender/Reciever set the new XPath which you have added above in the XML document.

Sorry if it is not clear,actually some customization needed for accomplishing your task.

HTH,
RMG.

Is there any other way to submit the SenderID and ReceiverID through TN_PARMS when invoking TN routeXML/receive? The messages submitted to TN does not have SenderID. I am relying on FTP user for finding the SenderID.

If I am adding SenderID, ReceiverID to original message, I need to load the whole document in memory for wrapping XML. This will defeat the purpose of TN large file handling.

Is there any other way to submit the SenderID and ReceiverID through TN_PARMS when invoking TN routeXML/receive?–>
No I don’t think it will work and it isn’t like routeFlatFile where you explicit set those params:The source XML must send it in the payload or consider creating an XML wrapper doc type which contains (senderid/receiverid) and xmlstring (CDATA) for TN recognition:

HTH,
RMG

Thank you RMG.

I have written a wrapper service to stream the content to TN receive. While doing streaming, I have injected the senderID as a attribute in rootNode. Thanks to Rupinder Singh for his XMLWrapperInputStream

[URL]wmusers.com

It works perfectly as planned. Large files are not loaded in the memory and TN is kicking off its large file handling mode.

Regards,
Leo