we have a certain flow that uses wm.tn.submit to send docs into TN. after invoking that service, there is a deliveryId variable on the pipeline, so we repeatdely run wm.tn.delivery:getDeliveryStatus to get delivery status on the document.
another of our flows uses wm.tn.doc.xml:routeXml (and therefore, wm.tn.doc:recognize and wm.tn.route:routeBizdoc) and routeBizdoc doesn’t seem to be supplying deliveryId variable. is there some way we can get this variable while continuing to use wm.tn.doc.xml:routeXml ?
If you have the internal doc id for TN you can run a query to return the tasks for that document… perhaps that’s the way…? You could also call deliver yourself, although that may yield the sort of auditing you require…
It’s just a case of finding which of the query/retrieve services in the WmTN package you need to hook together. The query mechanism might be a little strange, but the basic idea is that you build a query object, then run the query and then iterate over the results…
Hope that gives you some idea,
regards, Nathan Lee
Luke: Would caution against relying on deliveryId being in the pipeline. TN is infamous for being a pipeline litterbug, though it has gotten better. Unless the service description states that a variable will exist upon return, it shouldn’t be relied upon.
Nathan has pointed out a good approach. Look up the task(s) for your doc. That will be much more reliable.
Side question: Why are you repeatedly calling wm.tn.delivery:getDeliveryStatus to get delivery status on the document? If it is to capture delivery errors and send alerts/notifications, there may be a better way.