Correlation on MessageBox direct bound ports

I have an orchestration called MyUsefulOrch, hosted in an application MySharedApp.

MyUsefulOrch has an inbound messagebox-direct-bound port to receive requests, and after doing some useful work, an outbound messa开发者_C百科gebox-direct-bound port to send a message to the caller.

Now, I have another orchestration called MyCallerOrch which wants to benefit from the useful processing provided by MyUsefulOrch. However, MyCallerOrch is hosted in a different application, MyCallingApp.

I do not want to have any references to the assembly which contains MyUsefulOrch from MyCallerOrch.

My problem now is making sure I can send a message to MyUsefulOrch from MyCallerOrch and receive a response from it.

Ahah! Correlation should do the trick! But how do I go about getting correlation to work in this scenario?

For example:

• Would I put a correlation id in a property schema and stuff a guid into the message context under this property from MyCallerOrch just before sending it to the messagebox?
• How do I ensure that MyCallerOrch receives only the responses it needs to receive from MyUsefulOrch?
• Do I need to put the correlation id value into the message body of the messages which are sent between the two orchestrations?

I would greatly appreciate any help, ideally as descriptive as possible, about how to acheive this.

Many thanks in advance.

If you use a two-way, request/response send port in the caller orchestration to send messages to the useful orchestration, then you can use correlation to route the relevant messages back to the userful orch from the caller.

The trick is that you will need to modify the useful orch (to make it more useful, of course).

If you do not/cannot control whether or not callers to the userful orch are expecting a response back, then you would need to make the inbound (request) port a one-way port. The orchestration would then complete by sending to a one-way outbound (response) port.

To ensure that messages received from two-way/request-response callers are routed back properly, the construct shape of the outbound message inside your useful orch will need to set the following message properties to true using a message assignment shape:

• BTS.RouteDirectToTP
• BTS.IsRequestResponse

Before setting those two properties, though, also make sure to do something like msgOut(*) f= msgIn(*); in the same message assignment shape to ensure that other properties get copied over. If the inbound and outbound messages are not the same, then you have to manually set each of the required properties, one at a time.

Those properties, of course, in addition to the two above, are what help ensure that the result of the useful orch is properly routed to the caller. They should be inside your correlation set and are:

• BTS.CorrelationToken
• BTS.EpmRRCorrelationToken
• BTS.IsRequestResponse
• BTS.ReqRespTransmitPipelineID
• BTS.RouteDirectToTP

I'm getting a bit ahead of myself, however, as you assign the correlation set to the outbound send shape only if BTS.EpmRRCorrelationToken exists msgIn. This is critical. I have used a decision shape in an orchcestration, with the decision based upon that exact phrase. If the result is true, then send the previously constructed message out and assign the correlation set from above as the Initializing correlation set. This will cause BizTalk to route the message back to the caller as its expected response.

If the result of the decision was false then the caller of the useful orchestration was one-way. You will still likely want to send out a result (and just have someone else subscribe to it). You can even use the same send port as for two-way responses, just do not assign the correlation set.

You will want to thoroughly test this, of course. It does work for me in the one scenario in which I have used it, but that doesn't absolve others from doing their due diligence.

I think you are pretty much on the right track

Since the 2 applications are going to send messages to eachother, if you use strongly typed schemas, both apps will need to know about the schemas. In this case recommend that you separate the common schemas off into a separate assembly, and reference this from both your orchestration apps. (Schemas registered on the Server must have unique XMLNS#ROOTs, even across multiple applications)

However, if you really can't stand even a shared schema assembly reference, you might need to resort to untyped messages.

Richard Seroter has an example here

His article also explains a technique for auto stamping a correlation GUID on the context properties.

Edit : Good point. It is possible to promote custom context properties on the message without a Pipeline - see the tricks here and here - this would suffice to send the context property to MyUsefulOrch and similarly, the Custom context could be promoted on the return message from within MyUsefulOrch (since MyUsefulOrch doesn't need any correlation). However I can't think how, on the return to MyCallingOrch that the custom context property can be used to continue the "following correlation", unless you add a new correlating property into the return message.