How to handle messages that might correlate (or might not)
In my current project we are in a situation where we receive messages that might correlate with existing orchestration, but just might not correlate as well. The messages that don't correlate are perfectly valid, but just don't belong to an already running orchestration instance. I discovered a way tonight that handles this situation very elegantly. The sample showing exactly how can be found here. Unzip it to the root of c:. Build and deploy the project and then use the drop directory to run the process. First throw in the FirstMessages in their in folder and then the SecondMessages in their in folder.
The key to the solution is the use of seperate orchestration to handle the incoming messages that might correlate. This orchestration uses a direct port which is somehow described in my other post of today.
In short the solution is as follows:
- Build an orchestration with the correlating flow. Let the correlating messages listen to a direct port.
- Build an additional orchestration that listens to the messages that might correlated.
- Send the message to main orchestration inside a scope shape
- Connect an exception catch block to the scope shape, and start the alternative orchestration for noncorrelating message (or do the stuff there and then).
Refer to this article at Jan Tielen's blog for a guide on using exception blocks (I needed it ;-).