I am quite new in wM Trading Networks and I need some advise on the following scenario:
I receive a large batch of many individual messages from my Partner to the TN.
I have a service to parse a batch and iterate through batch to publish each individual message to Broker.
A trigger will invoke a service to call my backend business component to process a message (this system is not in webMethods).
My problem is if my backend system failed due network error or other causes, how can I resubmit my failed messages (after exceeding number of retries that configured in my trigger).
You can log the document in broker. For logging document types check the broker administrators guide. If you select the document type for logging, any document which is published to that broker will generate an auidt even and the document data is stored in audit databse if you have configured one. The UI for audit db is webMethods monitor which can display the content of the document and provide the capability of resubmittign the same document to broker.
I wouldn’t use the document logging in Broker as this would be redundant. The docs have already been logged in TN. Using TN Console, find the document(s) that you want to resubmit or reprocess (see the TN docs the definition of the difference between these two activities) and right-click on it and select reprocess or resubmit. Chances are, you want to do a reprocess.
According to the explanation given by John he is doing some batching after TN and then publishing them to broker. So submitting from TN might not be the perfect idea as there might be some business logic over which the batching and then publishing has been done. That was my idea and thats the reason i gave an option if document logging :). May be i completely misunderstood it
Perhaps I misunderstood. My read of the issue is that he is processing a batch, not creating one.
One critical item that I left off–the resulting individual message extracted from the batch should be saved separately in the TN DB. That will give the flexibility of reprocessing just message and not the entire batch.
Yes, posting individual message to TN is one solution.
But do we have any solution that automatically to retry submitting a document.
I saw in the trigger properties: Retries on Errors/Deliver Until Successful, is this a best practice to use it? Currently I only retry for few times and after I reach the max number then a document will be lost.
Yes, using the retry facility on the subscriber side is a reasonable thing to do. The question of whether or not to retry forever or give up after a time is a decision you’ll need to make. Retrying forever can be troublesome when the transient error can never be resolved. Giving up after a while risks needing to manually resubmit.
Probably the best bet is to retry for a reasonable time (“reasonable” being something that is entirely defined by you and the your installation) and then give up. The fall-back position after the system gives up is to manually resubmit from TN. Pick a time-out period that is long enough that you rarely need to manually resubmit.
Side question: is there value is publishing these documents to the Broker?
Until there are multiple subscribers to the same document, it is not required to publish the document to broker in this scenario. As reamon mentioned, route the individual documents to TN again and invoke your service asynchronously in case that is the purpose of broker is executing the subscription service in an async order
Actually, you do have it backwards. Resbumit makes a copy of the document and processes it as though it was new document. Reprocess skips the logging and doc recognition and just evaluates which processing rule to run for the existing document and runs it. It does not pick up from where it failed.