{tocify} $title={Table of Contents}
Here we are not going to use the Retry mechanism provided by BizTalk, instead we build custom Retry logic with help of two variables, Loop Shape and Delay Shape.
Var_RetryCount and Var_RetryInterval are variables set in orchestration (hard coded just for the post, ideally it should be configurable like SSO application/Config files or DB).
The logical send port has Delivery Notification set to Transmitted, doing this makes orchestration to wait for an acknowledgement from physical send port - ACK/NACK.
Question might arise, what happens if Delivery Notification is set to None on the Logical send Port and address is incorrect.
The message is sent and the flow continues and process ends as successful,no exception is caught even though Exception handler is there(read no exception raised), but there is error logged in Event Viewer.
It is perfectly valid behavior as the orchestration is not set to hear back from Send Port.
And to decide whether retry is to be done is based on Var_ExceptionOccurred, which gets set to true in Exception block whenever exception is encountered.
If exception occurred, then we just increment the loop counter, wait for the delay set and control is given back to loop shape for another retry(provided retry count is not reached).
And if no exception i.e. the transmission was successful, then the Var_SuccessRetryCount is set to loop counter and Loop counter is set to Var_RetryCount+1 so that no more retry is done.
In this scenario, the input file was successfully dropped to the destination folder
As can be seen in below image, there was delivery exception and current retry count and when will retry done is logged to event log, same happens to next retry also
Then after I correct the address
Thus, message was sent successfully at second retry .
So now we have the RetryCount when transmission was successful.
Introduction
There is a provision in BizTalk to set Retry Interval and Retry Count for both scenarios i.e. Static and Dynamic. For static we set it on the send ports and in case of dynamic we set the context properties in Orchestration/Pipeline.
But, I found no where or no way to get the Retry count of the successful attempt - when message was successfully delivered to destination system/service. If anyone knows, please let me know in comments :) .
So what if there is need to get that Retry count, say if business team wants to track and log it.
But, I found no where or no way to get the Retry count of the successful attempt - when message was successfully delivered to destination system/service. If anyone knows, please let me know in comments :) .
So what if there is need to get that Retry count, say if business team wants to track and log it.
To explain the process will use simple scenario file routing as below
Scenario:
We receive files at a folder which is to be routed to different folder and in case of transmission failure there has to be retries done for every minute but only three times and log the retry count when transmission was successful.
To implement this I have used Orchestration, where I receive a file and send it as it is inside a scope with transaction type set to None and an excpetion handler to catch Delivery Failure exception.
How to do
Creating Orchestration
Here we are not going to use the Retry mechanism provided by BizTalk, instead we build custom Retry logic with help of two variables, Loop Shape and Delay Shape.
Var_RetryCount and Var_RetryInterval are variables set in orchestration (hard coded just for the post, ideally it should be configurable like SSO application/Config files or DB).
The logical send port has Delivery Notification set to Transmitted, doing this makes orchestration to wait for an acknowledgement from physical send port - ACK/NACK.
If transmission goes ok then positive ACK is received and if something goes wrong then exception is thrown to orchestration which is caught by exception handler (provided exception handling is implemented).
The message is sent and the flow continues and process ends as successful,no exception is caught even though Exception handler is there(read no exception raised), but there is error logged in Event Viewer.
It is perfectly valid behavior as the orchestration is not set to hear back from Send Port.
In this case Orchestration is instructed to submit message to Message Box (to which the send port has subscription) and continue to check if exception occurred, if not then write entry to event log.
The logic here is, the Loop shape here is going to do retry based on Var_Retrycount(number of times).
The logic here is, the Loop shape here is going to do retry based on Var_Retrycount(number of times).
And Delay shape is to induce the interval between the retries based on Var_RetryInterval.
And to decide whether retry is to be done is based on Var_ExceptionOccurred, which gets set to true in Exception block whenever exception is encountered.
If exception occurred, then we just increment the loop counter, wait for the delay set and control is given back to loop shape for another retry(provided retry count is not reached).
And if no exception i.e. the transmission was successful, then the Var_SuccessRetryCount is set to loop counter and Loop counter is set to Var_RetryCount+1 so that no more retry is done.
So when Var_SuccessRetryCount is zero it means no retry was done and transmission was successful, when it is one - means transmission was successful at 1st attempt of retry and so on.
Testing
Correct address
In this scenario, the input file was successfully dropped to the destination folder
Incorrect address with Retry count set to 3 and retry interval set to 1 minute (address corrected after 1 minute)
Then after I correct the address
Download Sample
If you have questions or suggestions, feel free to do in comments section below !!!
Do share if you find this helpful ....... Knowledge Sharing is Caring !!!!!!
If you have questions or suggestions, feel free to do in comments section below !!!
Do share if you find this helpful .......
Knowledge Sharing is Caring !!!!!!
Related Post
Tags:
BizTalk