Weird issue causing tn.doc:view to fail

, ,
1

Hi,
We tried to implement a new integration last night into Production, but, it was intermittently failing with the following error:

com.wm.app.tn.err.EXMLException: wm.tn.doc:view com.wm.app.tn.db.DatastoreException Couldnt instantiate document {0} (0) com.wm.app.tn.db.DatastoreException: 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…

David

2

Can you try with wm.tn.doc:viewAs service, which has the same signature.

3

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.

4

Yes there is a weird issue with view and at one point SAG support suggested to use wm.tn.doc:viewAs 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.

HTH,
RMG

5

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

Cheers,
David

6

your welcome:)

7

Reset Cache for wm.tn.doc:view service. and Reload the package.

8

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)

HTH,
RMG