A colleague ask me earlier today about the Send Port Service Window and its interaction with retrying messages – I honestly didn’t know what would happen (although I had a rough idea), so I decided to run some tests; the outcome was interesting and I certainly didn’t expect to encounter one particular gotcha.
Background
Imagine a scenario where a Send Port is setup to send messages over the FTP adapter. It is configured for 3 retries, at 5 minute intervals, and has a Service Window which starts at 06:00 and stops at 18:00. The Send Port attempts to send a message at 17:57, but fails to do so and goes into its retry loop.
I read through the BizTalk Help to try and give me a better idea of what would happen, but it didn’t really help (“Select this check box to configure the port to send only at specified times of the day, then specify the times in the Start time and Stop time boxes.”, not much help there). So, my thinking went something along the lines of:
- The message would either suspend (resumable) when it attempted to re-send as the Send Port was no longer active; or
- The message would wait until the Send Port was active and it would recommence the retries.
My thinking was sort of correct, but during my testing, I discovered a few oddities.
What Really Happens…
In the following scenarios, imagine that the FTP server comes back online within 30 seconds of the first attempt to send the message and that all messages are sent at 30 seconds past the minute.
- Scenario 1 – The retry interval is longer than the ‘stop’ service window (i.e. the service window runs from 18:30 to 18:35, the retry interval is 10 minutes and the retry commences at 18:28). In this scenario, BizTalk will simply leave the message in the ‘retrying’ state throughout the ‘stop’ window and although the Send Port becomes active again at 18:35, the message isn’t sent until the next retry happens at 18:38. Behaviour [sort of] as expected.
- Scenario 2 – The retry interval is shorter than the ‘stop’ service window (i.e. the service window runs from 18:30 to 18:35, the retry interval is 3 minutes and the retry commences at 18:28). In this scenario, BizTalk will retry at 18:31 but the stop service window prevents the message from being sent; when the Send Port becomes active again the message is immediately sent. I presume this is because the EPM sends any messages for the Send Port that are sat as ‘retrying or idle’ to capture messages that have been sent during the ‘stop’ service window, not just those that are retrying. This again is behaviour I would [sort of] expect.
- Scenario 3 – This final scenario throws up the gotcha and wasn’t expected at all. Imagine scenario 2 (i.e. the service window runs from 18:30 to 18:35, the retry interval is 3 minutes but the retry commences at 18:27). In this scenario, BizTalk will retry at 18:30 but the ‘stop’ service window prevents the message from being sent – or so I would have expected. What actually appears to happen is that when the retry occurs in the same minute as the ‘stop’ window finishes (i.e. 18:30) the message is sent…. Not what I was expecting at all – I would have expected that the ‘stop’ service window comes into effect at the turn of the minute (i.e. 18:30:00) and therefore any messages after that time would not be delivered. Certainly a gotcha!
The final scenario really confused me and I would suggest that you under take thorough testing if your BizTalk solution relies on service windows.
To Recap
From this series of test, I *think* I can confirm the following:
- If the retry interval is longer than the ‘stop’ service window, there is no impact to message processing and the interval will work as expected.
- If the retry interval is shorter than the ‘stop’ service window, when the Send Port starts again, the message is immediately sent.
- If the retry interval causes the retry to fall in the same minute as the ‘stop’ service window starts, the message will still be delivered.
Nick Heppleston's BizTalk Blog 