Next, you must connect the ReceiveTradeOrderFromExternal action with the port. During the XML Configuration Wizard, specify the Message type as Trade, which is the root name for the response document. This value is important, because when documents arrive at BizTalk Server, this Action shape will only retrieve the documents with Trade as their root name. Leave the instance ID alone, since you aren't dealing with the message queue now. After you finish the configuration of the BizTalk Messaging shapes on the business page, there is still something you must do to get the whole thing to work. You've provided the channel and URL that are used to receive the response document on the port, as is shown in Figure 10-28. Next you must send them along with the document to the external system provider. To do so, you need to link the port reference and the ReplyTo field in the document, as shown in Figure 10-29. The value of the ReplyTo field is dynamically created when an instance of this schedule is started. You'll see what value it takes later. Figure 10-29. Connecting the port reference to the ReplyTo field in the documentIf you caught the document posted to the external service provider, you would see that the ReplyTo field contains the following value: <ReplyTo>http://w2kserver/B2B_Anonymous/receiveresponse.asp?Channel= C_TradeOrderResponse_ExternalTradingSystem& QPath=W2KSERVER.myhome.com\private$\c_tradeorderresponse_externaltradingsystem {8c2786fd-7e6f-4d07-a96b-92852f4151ec}</ReplyTo> This ReplyTo field contains a URL to an ASP page with two query string items: Channel (Channel=C_TradeOrderResponse_ExternalTradingSystem) and Qpath(QPath=W2KSERVER.myhome.com\private$\c_tradeorderresponse_externaltradingsystem {8c2786fd-7e6f-4d07-a96b-92852f4151ec}). In order for the schedule to correlate the response document with the right running schedule instance, the sender (external system provider) must post the response document to the URL that is embedded in the document. If you have a question about where the QPath value in the query string is coming from, just check the local message queue. You'll find that the QPath is actually the path to a local queue that is created by the schedule at runtime (see Figure 10-30). The name of this queue is formed by combining the channel name and the instance ID of the schedule. This name is unique, since the instance ID is always unique. With orchestration correlation through BizTalk Messaging, BizTalk Server actually creates one message queue for each running instance of the schedule for correlation purposes. Figure 10-30. A local queue is created by BizTalk Server for storing the incoming After the trade schedule sends out the trade order, the schedule will be dehydrated while it waits for the response document to arrive. In order for the dehydrated schedule instance to continue, the response document must arrive at the BizTalk Server. To be exact, a response document mustarrive at this message queue, which is dynamically created to handle the document returned to this port for this particular schedule instance. As soon as a message arrives at this c_tradeorderresponse_externaltradingsystem {8c2786fd-7e6f-4d07-a96b- 92852f4151ec} queue, the schedule will be rehydrated and will pull the message out of this queue, bring it into the rehydrated schedule, and continue with the rest of the orchestration. After the schedule is complete, this local queue will be automatically removed. The external trading service provider doesn't have to know how to get the message to the dehydrated schedule instance. All they need to do is post message.The response document using the URL stored in the ReplyTo field. Your job is to create an ASP page that will transfer the posted documents to those dynamically created local queues. BizTalk Server provides an ASP page for this task. The file is located under [BizTalk Server installation directory \SDK\ReceiveScripts\ReceiveResponse.asp. In this ASP page, there are a number of key lines of code that will do the trick: 'retrieve the parameter in the query string queuepath = Request.QueryString("qpath") queuepath = "queue://Direct=OS:" & queuepath channelname = Request.QueryString("channel") 'add you code to extract the posted document 'submit to the BizTalk Server call interchange.submit (4,PostedDocument,,,, queuepath,channelname) The submit call uses 4 as its first parameter to specify that the document is sent to an open destination. The destination value for this document is queuepath, which will be used as the destination target for the open port. The channelname is the channel that connects to the open destination port. NOTE The channel information is optional, but it's helpful to provide it in the submit call if it's available. In order for BizTalk Server to find a channel on its own, you have to make sure the source and destination information provided is sufficient for BizTalk Server to find a distinct channel. In many cases, it's easier to provide a channel name in the submit call than to decide whether less information is sufficient. If you do provide a channel name, BizTalk Server will recognize it and will bypass the search for the channel and use the one you provide. This also applies to the Receive Function. When channel information is provided on the advanced properties page of the Receive Function, BizTalk Server will use it to pass the document to the port. To complete the process, you also must create a channel and an open destination port to be used for correlating the posted document back to the schedule-instance message queue, where the schedule instance will pick up the document and continue on its processes. I discussed open destination ports in BizTalk Messaging in Chapter 10. This isCwhere the destination of the port is unknown until it's provided by a data field in the document or in submit call parameters. This concept decouples the destination from the port, and it's very useful when you don't know the destination beforehand. In BizTalk Orchestration, you need to provide either a channel name and message queue path during the configuration of the implementation shapes in order to send a document to BizTalk Messaging or to a message queue. You may be wondering whether there is a way to decouple the destination address from the implementation shape so that your schedule can have the flexibility of an open destination port. The answer is yes. Dynamic port binding allows you to provide the address information to the implementation shapes at runtime. First, let's take a look at a dynamic port binding connected to aMessage Queuing shape (see Figure 10-31). Figure 10-31. A schedule with dynamic port binding to a message queue When you are using the Message Queuing Binding Wizard, specify a dynamic queue instead of a static queue. AMessage Queuing shape with a shadow will appear on the page. To provide the address, you need to link a data field containing the address information to the port the dynamic messaging queue connects to on the data page (see Figure 10-32). Figure 10-32. Providing the address information by linking the address data field Inside the document, you must have a data field that contains the address information for the message queue or this dynamic port binding won't work. Here is a sample document that can be used in this schedule: <message> <Address>.\private$\DynamicBindingQueue</Address> <Data>this is a test message</Data> </message> When you run this schedule, the message is written to the message queue specified in the message queue information in the document. You can create dynamic binding ports for BizTalk Messaging shapes the same way you did for the Message Queuing shape. When the BizTalk Messaging Binding Wizard asks for the channel information, specify a dynamic channel. You'll also need to link a data field that contains the name of the messaging channel to the port reference on the data page, and the address field in the document must be protocol specific. In other words, if you use dynamic binding on a message queue, the address field must be a queue path. If you use dynamic binding on BizTalk Messaging, then the address field must be a channel name. Here's an example, with C_Message_ExternalClient being the channel name: <message> <Address>C_Message_ExternalClient</Address> <Data>this is a test message</Data> </message>