I have an Order document type defined in Trading Networks with the option “Check uniqueness of” set to “Document ID and sender” and “Always”.
I have an Order rule defined to process documents of the Order type and “may have” errors.
Whever I receive a document that has the same ID as one already logged, the new document has an Activity Log line added of Type Error with the Brief Message of “Non-unique ID(s) detected”. The document is processed by my Order rule.
I want to stop processing duplicate documents (i.e. only process the first one). I set the Order rule to “has no” errors, which I thought would do this, but duplicate documents are still processed.
Am I misunderstanding the idea? If so, is there a way within TN to stop duplicate documents from being processed, or do I have to test this in my flow?
You need to test for this in your flow. It seems counter-intuitive but your service gets invoked, even if there are errors. This ostensibly is to allow you to do some notification (send e-mail or something) to alert someone to the problem, but I’m not sure if this was an intentional feature or “a feature”.
Hello - You have to test it in the flow. We faced the same problem with IS 4.0.1/TN 4.0.1-- a helpful support person (thank you PG!) sent us this workaround:
> We do not pass a variable in the bizdoc that signals whether a document is
> unique or not. The closest thing you can get to it is checking the Error
> record in the bizdoc for an entry of class “Saving” and message “Non-unique
> ID(s) detected”. The problem with this is that the class or message may
> some day change resulting in your code being incorrect.
This workaround works very well with IS/TN 4.0.1 and with IS 4.6/TN 4.6 as well.
As for implementing it, its good to defer uniqueness checking to the doctype and set it to the (sender+receiver+documentID) combination. You can also choose to do the duplicate checking on a per-customer basis based on a custom attribute as well.
Note: For the new IS 6.0/TN 6.0 I’m told that “user-definable” fields can be used for duplicate checking (as compared to the choice of three or four fields presently).
Does anyone have a ‘best practices’ for error detection using the TN bizdoc after a processing rule is invoked? I check the SystemStatus for "DONE W/ ERRORS’. There is an ‘error’ record that contains 8 different entry class types - in my case I just want to know if an exception of any kind occurred. Does any check these class types?
You can use wm.tn.doc:getEvents and set the errorsOnly parm to true. This will return only errors in the events list, which you can wade through to find specific conditions.
The vars eventCount, errorCount and events are in the pipeline during normal TN processing BUT not when reprocess is selected in TN Console. So you should always call this service to get these vars and do your error checking.
Just FYI: I’ve just encounted a bug in IS /TN 4.6 where the TN doctype based duplicate document detection does not work when multiple duplicates come in under load (some are marked duplicate, some are not). I’ve contacted WM support about this.
