I am using routeXML to send to TN, which recognizes the document properly and tiggers the right processing rule and executes the right service. The flow service triggered by the processing rule, has an output xml string, which I expect to receive the the content part of the BizDoc. Surprisingly, when I do a bytesToString with the content part of the BizDoc, I get the same information that I am sending instead of what I expect back from TN. I checked the TN users guide and it confirms that TN returns something, unfornatutely, I cannot use the respond with option, which is just an message instead the results of the processing action, after the service. EVerything else is good, on both sides, except the response…
a few things I tried are
Used setResponse service to send back the xml string, same story
Tried bytesToString on the bytes element of BizDoc. No Luck…
"The flow service triggered by the processing rule, has an output xml string, which I expect to receive the the content part of the BizDoc. "–> I dont think you will get response back from the TN in the bizdoc…Why you want the response from TN?? You can get the document Task status from the TN unless your rule processing action uses delivery method.
BTW,what is your trigger service do?? send the original document to trading partner or something internally gets processed??
RMG,
thanks for your response. The Trigger Service, sends information to the backend, and gets a document response, which is converted to an xml string. I am supposed to acquire this string right after routeXML> I can see this xml string in the pipeline but am not supposed to use it. It would be nice if it was just the status. I also tried just to test , the respond with option. Just created a string in that text box, but still didn’t get anything.
As you’ve seen, TN does not put anything related to the reply into the original bizdoc. The “Respond with” will only work if routeXml/receive is called directly by the partner, not by your gateway service.
You mention that you see to the response doc in the pipeline after the routeXml call but that you’re not supposed to use it. Is there a reason that you’ve been told not to use it?
There are a couple of options:
The service that processes the original doc places the response document in the pipeline for the caller to use. This would be the service that calls routeXml (or receive). This behavior becomes part of the service interface definition. Downsides: 1) this will only work if the processing rule that invokes the service is synchronous; 2) the response document isn’t recorded anywhere–once routeXml has returned, TN processing is done. This can be overcome by manually creating the bizdoc but have the processing rules do nothing with it–just relate the response doc to the request doc.
If the response can be sent back asynchronously, then you can have the service invoked via the rule submit the response document to TN. There you would handle it just like any other TN process. Downside: only applicable if the response doesn’t need to be sent in the same communication session with the partner.