Here’s a white paper from Microsoft on creating sequential FIFO orchestrations (this applies to singletons as well), It’s actually very hard to create an orchestration that neatly ends with zero risk of losing messages. This is because a message might come in after the listen shape, but before the orchestration has terminated.
To test this, I created a simple singleton orchestration that adds a deliberate wait of 2 minutes before finishing.
I then deployed the orchestration, and starting sending in messages one by one (by the way, “Do Something” simply writes the one field in the message to the debugger).
So the message with value 1 was sent first, here’s the debugger output:
12880] Field was: 1
Then the message with value 2 was sent in, here’s the output:
[12880] Field was: 2
[12880] Field was: 2
Then, i waited about 45 seconds, just long enough to get us past the first Delay shape in the orchestration (of 30 seconds). I submitted a message with value 3, but received no output (as expected). I waited until the remaining time had finished and saw the orchestration suspend with this error:
The orchestration was not resumable. I then sent in a message with value 4, here’s the output:
[12880] Field was: 4
[12880] Field was: 4
So, what does this prove? If a message comes in before your orchestration has had the time to complete (and you’re no longer waiting to receive a message), you will have unprocessed messages in the orchestration when goes to complete. I guess the good news is that you can see what that message was by clicking on the message tab, so if you’re willing to run this risk, you might go ahead with this decent, but not perfect, design.
To be absolutely fail-proof, the paper offers a few suggestions, such as stopping the receive location via wmi script as part of the shutdown process. This is fine and all, except for this one question – how is it supposed to be turned back on? If you do this as part of the same orchestration, you have the same problem you started with! I guess the one way this could be done would be by adding a “Start Orchestration” shape, which begins with a delay, and then enables the receive location again (the delay is to allow time for the calling orchestration to finish with no risk of losing messages).
Good luck!
For Singleton Design to work
ReplyDeletePlease make sure you have done this:
1) Co-relation on BTS.ReceivePortName
2) First Receive Shape "Activate=True", "Initialize Co-relation Set". Second Receive Shape "Activate=False", "Following Correlation Set".
3) Your loop shape to receive the message one by one (second Receive Shape).