Note: This blog posts pertains to BizTalk 2009. It has not been tested against other versions although I suspect the behavior is the same.
We recently had a situation where a downstream system was having issues processing certain types of messages. We were asked to “queue” messages received from the source system until the issue was resolved. In order to do this we simply stopped the Send Port but left it enlisted. Since the Send Port is still enlisted, a subscription still exists within the MessageBox database. Any messages received while the Send Port is in this state are essentially “queued”.
When you send a message into BizTalk and have the port Stopped(but enlisted) you can expect a Suspended message that has an error description of “Service instance was suspended because the corresponding service (orchestration, sendport, ...) was in the stopped state. Instance can be resumed after corresponding service is started.”
Even with this Send Port stopped, we can still right mouse click on the suspended instance and resume it without issues.
We knew that we had to have this send port stopped for a few days while the issue was resolved. Since we have multiple people working within our Middleware team and also have automated processes to ensure our applications are online, we decided to set a Service Window on the Send Port in addition to having these messages queued as a precautionary measure.
The intent of this Service Window of 1 second allows us to log into the server before 9am to ensure the Send Port is not started. Then we would disable the service window and use a time that is before the current time. The current time, for the purpose of this blog post, is 10:06 am.
If we send in another message with this Service Window we will see a screen much like we saw without the schedule in place.
If we check our BizTalkServerApplicationQ table within our MessageBox database we will discover that no records exist:
If we check our BizTalkServerApplicationQ_Suspended table we will discover that metadata exists for our message that we just received.
So what are these tables? These tables make up BizTalk’s work queues for our BizTalk Server Application Host. Stay tuned and note which tables have records as you will soon see a discrepancy.
With our message “queued” and our Service Window still set for 9:00:00 am to 9:00:01 am I am going to resume this message and it will be delivered successfully even though the Send Port is stopped.
Great! So what is the point of this post? Change your window to be 1 minute instead of 1 second and you will get an entirely different behavior.
With the Service Window set to be 1 minute and with the current time set to 10:21 am, I will now submit another message to BizTalk. Once again I will get a suspended message.
If we take a look at the BizTalkServerApplicationQ_Suspended table we will discover that our message is in there but is not in the BizTalkServerApplicationQ table
When resuming the message this time, it will not get delivered to the end point. Instead it gets into a “Retrying and idle” state.
If we further investigate this message we will determine that the Message Status is set to “Queued (scheduled for later delivery)”
If we check out the status of our tables in the MessageBox we will determine that the message is no longer in the “Suspended” table.
We can now find the message in the “Q” table. Also note the Start and End Windows.
So what can we do if we want to resume this message since the Downstream system is now available and they want the 1800 messages that have been queuing up over the past 3 days?
- Maybe we should remove the Service Window from the Send Port? (hint – it doesn’t help)
- Maybe we should start the app? (hint – it doesn’t help)
- Maybe we should restart the host instance? (hint – it doesn’t help)
- Since the message is in a “dehydrated” state maybe we need to wait 5/10/20 minutes for BizTalk to wake up? (hint – it doesn’t help)
There are really two solutions in my mind:
- Wait for the actual service window, with application online and Service Window checkbox removed, and these messages will get processed – promise.
- Update the service window in the “Q” table so that BizTalk will send these messages when this window is met. To demonstrate this I will update the table with a timestamp that is in the near future. It is currently 10:46 am and I will update the timestamp for the window to start at 10:50 am.
Without any intervention the outstanding message(s) will get processed/delivered at 10:50 am.
Key Takeaways
- Be aware that Service Windows are “attached” to the messages as they are being processed. There is no way to modify this except through the database.
- Changing the Service Window of a Send port where messages already have a Service Window has no effect. (It is too late)
- Setting a Service Window of 1 second has no impact.
