Weird issue causing tn.doc:view to fail

We tried to implement a new integration last night into Production, but, it was intermittently failing with the following error: Couldnt instantiate document {0} (0) Couldnt find doc {0}; no doctype {1}

The flow of the document is as follows:
  • MfgPro sends data to wM via Web Service
  • wM Provider Web Service routes the data to TN using tn.doc.xml:routeXml
  • Processing Rule identifies the document and initiates custom flow service “processTNMessage”. (many different document types are included in this processing rule)
  • Custom flow service “mfgPub:processTNMessage” determines the type of document it has, creates a CommonDoc to be published that has only the sending ID, destination ID and the TN InternalID of the TN Document. “mfgPub:processTNMessage” then publishes the CommonDoc to the Broker, updates attributes and status of the TN Document
  • Trigger subscribes to CommonDoc that has been published and invokes a another custom flow service “ihubSub:processTriggerMessage” to process it.
  • “ihubSub:processTriggerMessage” uses the TN InternalID from the CommonDoc in tn.doc:view to retrieve the TN Document. This is where the above error is occurring.

We put in an emergency sleep step just before the tn.doc:view, but, it was still intermittently failing.

This same type of logic is currently being used by other documents in production (by different processing flow services that update other D/B’s) that are much larger than the ones that are failing only in Production that was implemented last night.

Has anyone seen the above error before ?? I have googled it, but, nothing much came up. Does anyone have any idea what could be the cause ??

Thanks for any assistance you can provide…


Can you try with service, which has the same signature.

Capture the internal id from the pipeline and try running the service tn.doc:view independently with this internal id as input. Check the server log for any details by keeping the logging level as DEBUG for a moment.

Yes there is a weird issue with view and at one point SAG support suggested to use service in its place and Senthil also mentioned as replacement.

Either internalId could be corrupted when some one copied/paste in the service inputs or you may need to delete/recreate whole service and test it.At one time we also wasted so much precious time on this debugging and recreated.


Thanks for the confirmation guys. Hopefully this will save us some time and grief…


your welcome:)

Reset Cache for service. and Reload the package.

Yes this should work too…but normally when the internalID input for a service corrupts you should plan to build that service from scratch (not copy paste)