Orchestration Correlation Through BizTalk Messaging In the example you just saw, the message label is a critical piece of information that helps BizTalk Orchestration correlate the messages and the correct running schedule instances. However, sometimes you'll want to send the document to a BizTalk Messaging shape instead of to aMessage Queuing shape. In such cases, using message labels to keep track of which schedule instance the document belongs to won't be feasible, since there is no place to store this message label information. You must come up with a different solution to correlate the messages and the schedule instances. Bob decides not to use his internal trading component for some reason. He has found a company on the Internet that can offer the trade execution service to his clients instead. All clients need to do is send the trade order document to the external provider over HTTPS. As soon as the trades have been executed, a response document containing the execution status information is sent back to the clients, who can then update their database or perform any further post trade operations. Bob has decided to use this company's service and asks Mike to replace his trading component with the external trading system, and integrate this trading service into the trade schedule. Figure 10-25 shows the general plan. Figure 10-25. A revised system to process trades for clients To help Mike make this change, you need to revise your trade schedule to replace your trading component and integrate with an external provider. You'll replace the two Message Queuing shapes with two BizTalk Messaging shapes, which are responsible for sending the trade order to the external provider through the Internet, and receiving the response document and correlating it with the correct trade schedule instance. Because you have to remove the message queuing part of the picture, and your external provider is outside theorganization, you need to provide two pieces of information to the external provider. You need to tell them where you expect to receive the response document and what the instance ID should be for this response document. One way to provide this information is to embed it inside the document when it's sent out. Let's modify the trade document specification to add a field called ReplyTo right below the FundCompany field. Figure 10-26 shows the trade schedule revised for this new change. Figure 10-26. BizTalk Messaging shapes are used instead of Message Queuing shapes for sending and receiving documents. As you can see in Figure 10-26, the two message queuing shapes are replaced by the two BizTalk Messaging shapes. The SendTradeOrderToExternal action will send the mutual fund company's trade order document to a C_TradeOrder_ExternalTradingSystem channel, which is connected to a port with the URL of the external trade execution provider as the destination. When configuring this shape with the XML Communication Wizard, you need to pull out the ReplyTo message field to make it available for access on the data page, which you'll see shortly. Give any name for the message label for the XML message-the name doesn't matter here since you aren't writing it to the message queue. Next, you need to add the BizTalk Messaging shape used for receiving the response document. Drag and drop the BizTalk Messaging shape onto the page. The BizTalk Messaging Binding Wizard will open, as shown in Figure 10-27. Figure 10-27. XLANG Schedule activation information You've seen this window many times before in earlier chapters, and in it you've usually selected Yes. This time, though, you need to select No. When Yes is selected, BizTalk attempts to create a brand new schedule instance to process the document. When No is selected, BizTalk Server won't attempt to create a new instance of the schedule. In this case, you already have a running schedule instance-all you want to ask BizTalk Server to do is feed the data into this port. Click Next to proceed to the window shown in Figure 10-28, which you haven't seen before. Figure 10-28. Specifying how BizTalk Server receives the response document In this Channel Information page, you need to provide two important pieces of information to configure how BizTalk Messaging will receive the document before it can pass the document to the running schedule instance. In Figure 10-28, you are instructing the external trade execution provider to send the response document to http://w2kserver/B2B_Anonymous/receiveresponse.asp, and you can add the channel name C_TradeOrderResponse_ExternalTradingSystem as one of its query strings. In other words, you are specifying that your URL for accepting the response document is http://w2kserver/B2B_Anonymous/receiveresponse.asp?channel= C_TradeOrderResponse_ExternalTradingSystem. You might ask why you specify this information in BizTalk Server. Shouldn't you tell your provider this information instead? Bear with me for a second, I'm getting to that. Click Finish to save the change.