Home/ Questions/Q 6836609
In Process

The Archive Base Latest Questions

Editorial Team
  • 0
Asked: 2026-05-26T23:22:33+00:00

I have the same problem as described here : I am using two orchestrations.

  • 0

I have the same problem as described here:

I am using two orchestrations. First orchestration calls the second using direct binding through a two-way send port. Second orchestrion has a two-way receive port to send the result back to the first. Every thing is working as it should but I am getting the following exception.

A response message for two-way receive port "Unknown " is being suspended as the messaging engine could not correlate the response to an existing request message. This usually happens when the host process has been recycled.

And the suggested solution works as well (set the BTS.EpmRRCorrelationToken value to a random value, new GUID in my case, in the first orchestration before send to the direct binding port and then in the secod orchestration i copy the value from the inputMessage to the outputMessage, so the value remains the same. With this method BizTalk knows how to correlate the response back to the caller). But I can’t understand why this works and if this a good way to solve the problem. The BTS.EpmRRCorrelationToken flow is the following:
UML

When I don’t change the BTS.EpmRRCorrelationToken property, it is the same in all messages which flow in the process, but why on Earth doesn’t BizTalk change it instead if it can’t correctly correlate the messages?

Share

Leave an answer

You must login to add an answer.

Need An Account,

1 Answer

  1. Editorial Team

    Changing this property is certanly OK in your case.

    The problem is direct binding. When you use it, you actually going more “low-level” way and have to deal with how BTS publish-subscribe mechanism works.

    Send-Receive port subscribes to receive a message with a specific BTS.EpmRRCorrelationToken. So when you post receive message again in the Message box (for second orch), receive port grabs it too and unsubscribes then. When you finally try to send a response – there is noone waiting for it. So you have to change that property until you sending response back to the port.

    • 0