Example 4: Non-HTTP-Based Correlation Using Two BizTalk Servers

Non-HTTP-based correlation is much more difficult to implement than HTTP-based correlation. The dynamic orchestration port (the port through which we send a message out of the orchestration schedule to the external entity) and the orchestration BizTalk Messaging receive ports (the ports through which we receive the response message back into the orchestration) support HTTP transports natively.

This is evident when you are required to enter a URL (for the return ASP page) in addition to the channel name in the BizTalk messaging orchestration receive port as shown previously in Figure 16.23. This simply means that there is built-in support for HTTP-based transport. For non-HTTP-based correlation, including MSMQ, SMTP, and file system-based transports, you will need to do this yourself.

We will take the same approach to illustrate the non-HTTP-based solution as we did in the case of HTTP-based correlation. The only difference between the two approaches will be the transport type used in the delivery of the document from one system to the other. The same three basic steps as used in the HTTP-based transport apply here:

Understanding Non-HTTP Correlation Between Two BizTalk Servers

The non-HTTP-based correlation is much the same as the HTTP-based solution. In this case, instead of using HTTP as the mode of transport, we can use any one of the Messaging queue, SMTP, AIC, and file system. In our example, instead of using HTTP transport to send the UserAcctInfo message from the AcctMngSys to the ERPSystem, we will use MSMQ. Similarly, when sending the response from the ERPSystem back to the AcctMngSys, we will again use MSMQ.

We will illustrate the important differences between the HTTP-based and non-HTTP-based example. For the AcctMngSys business process, we will be using a slightly modified orchestration schedule, AcctMngSys_16_3.skv. The important thing to remember is to flow the address of the orchestration port (the port through which the schedule receives the response from the ERPSystem) into the physical message (HEADER@ReturnPort). This is done in the Data Page of the orchestration schedule.

The first step in schedule correlation is to pass the message containing the return address to the ERPSystem. In the schedule AcctMngSys_16_3.skv, this is done by passing the message to the BizTalk Messaging shape in the orchestration schedule. The BizTalk Messaging then uses the channel, AcctMngSys_nonHTTP_SendToERPSystemChannel, and a port to deliver the message to the ERPSystem using a messaging queue. Note that we could have directly used MSMQ Messaging shape in the orchestration to achieve this. However, we need a mechanism to transform the message queue format name to the pathname syntax (queue: //DirectOS :) in the return address. To do this, we will use mapping in the channel.

For the ERPSystem business process, we will be using a slightly modified orchestration schedule, ERPSystem_16_3.skv. To send the response from the orchestration schedule, we will use the BizTalk Messaging shape. The BizTalk Messaging implementation uses a static channel and a port to deliver the response to the AcctMngSys via a message queue.

Let us see how the response is correlated in the AcctMngSys application to the running instance of the AcctMngSys_16_3.skv schedule. Note that that this instance of the schedule is waiting for a response after having sent the UserAcctInfo to the ERPSystem. To do this, an MSMQ receive function picks up the message and submits it to BizTalk Messaging. BizTalk Messaging uses a channel and an open destination port to deliver the response message back to the running instance of the schedule. The process that BizTalk Messaging uses to determine the recipient of the response message is somewhat tricky. The schema file associated to the incoming response message identifies HEADER@ReturnPort as the Destination Value. We do this in the BizTalk Editor, using the Dictionary tab.

Building the Non-HTTP BizTalk-to-BizTalk Example

It is probably clear to you that many of the steps in the non-HTTP- and HTTP-based correlation are similar. The difference is in the transport used to deliver the message across the systems. For clarity, we will define the whole non-HTTP scenario as we did in the case of HTTP. The following sections walk through, in detail, the steps required to accomplish this.

Pick Up the UserAcctInfo Message Using BizTalk Messaging and Deliver the Message to the AcctMngSys Business Process

This step involves picking up the sample AcctMngSys_NewHire.xml and delivering it to the schedule AcctMngSys_16_3.skx.

We will first drop the AcctMngSys_NewHire.xml onto a message queue, .private$ReceiveNewHire, using File2Queue.vbs. The receive function, AcctMngSys_nonHTTP_ReceiveNewHire, monitors the queue. The receive function picks up the message and delivers it to the BizTalk Messaging channel, AcctMngSys_nonHTTP_ReceiveNewHireInfoChannel. The channel in turn delivers the message to the BizTalk Messaging port, AcctMngSys_nonHTTP_ReceiveNewHireInfoPort. Finally, the port delivers the message to a new instance of the schedule, AcctMngSys_16_3.skx.

Table 16.10 shows the BizTalk Messaging setup required for this.

Receiving the UserAcctInfo into the Schedule, Sending the NewHireInfo to the ERPSystem, and Finally Receiving the ERPSystem Response

Open the file Chp16AcctMngSysAcctMngSys_16_3.skv in BizTalk Orchestration Designer. The schedule is shown in Figure 16.39.

This is similar to the schedule for the HTTP-based example. The first action receives the UserAcctInfo XML message from the BizTalk Messaging. In the BizTalk Messaging Binding Wizard for receive request, the value of XLANG Schedule Activation is set to Yes. This means that each time a message arrives at the binding port, a new instance of the schedule is instantiated.

The second action, WelcomeNewHire, is bound to Windows scripting component. The component simply displays the content of the UserAcctInfo message in the body, and in the title it displays the name of the new hire and the schedule filename.

The next action, SendToERPSystem, sends the message out to the ERPSystem through the BizTalk Messaging binding port. In the BizTalk Messaging Binding Wizard for SendToERPSystem, we specify the BizTalk Messaging channel AcctMngSys_nonHTTP_SendToERPSystemChannel. This channel will be used by the schedule to send out the message.

After sending out the message to the ERPSystem, the schedule simply waits at the ReceiveERPResponse action. After a response is received at the binding port ReceiveERPsystemResponse in the message queue .private$ReceiveERPSystemResponse, the schedule instance continues to the next action. Note that in the Message Queue Binding Wizard for the ReceiveERPSystemResponse, the orchestration port is set to create a new queue for every instance, as shown in Figure 16.40.

Finally, the DisplayERPResponse action displays the ERPSystem response message. The action is connected to a Windows scripting component. The component displays the response in the body, and in the title it displays the name of the new hire and the name of the schedule file.

Figure 16.41 shows the XLANG schedule data page.

Note that the port reference for ReceiveERPSystemResponse is passed into the physical message UserAccountInfoToERPSystem. This reference will be used later in the destination system to send the ERPSystemResponse message back. We are passing the UserAcctInfo message and the first and last names of the new hire to the AcctMngSys_nonHTTP_DisplayERPResponsMsg.wsc component. Similarly, to the DisplayERPResponse.wsc component, we are passing the ERPResponse message and the name of the new hire.

Sending the UserAcctInfo Message Through BizTalk Messaging to Another BizTalk Orchestration Schedule Via Non-HTTP Transport

The action SendToERPsystem in the XLANG schedule delivers the message to the BizTalk Messaging channel, AcctMngSys_nonHTTP_SendToERPSystemChannel. The channel in turn delivers the message to the BizTalk Messaging port, AcctMngSys_nonHTTP_ToERPSystemPort. The port is configured to deliver the message on to the queue .private$SendNewHireInfo. Finally, the ERPSystem imports the message into the ERPSystem using an MSMQ receive function, AcctMngSys_nonHTTP_ReceiveNewHire.

In the HTTP scenario, the channel simply delivered the message to the port, and the port posted the message via HTTP to the ERPSystem. In the non-HTTP example, the channel does a little more than that. In the channel, we apply a map to apply the MSMQ pathname to the MSMQ format name by prepending queue://Direct=OS: to the pathname. This is done to the field HEADER@ReturnPort in the UserAcctInfo message before the message is sent out to the ERPSystem.

You will recall that we did the same thing in the HTTP-based scenario, in the ReceiveResponse.asp page. The following code is from the ReceiveResponse.asp page to jog your memory:

    queuepath = Request.QueryString("qpath") 
    queuepath = "queue://Direct=OS:" & queuepath
    channelname = Request.QueryString("channel")

Now in the non-HTTP-based solution, there is no ReceiveResponse.asp page. We will accomplish the same process by using a map in the channel, before sending the document out to the ERPSystem. Open the map file, UserAcctInfo_UserAcctInfo_Map.xml, in the BizTalk Mapper. The source schema and the destination schema are the same, UserAcctInfoXML.xml. The mapping uses the string concatenate functoid to prepend the string queue://Direct=OS: to the value of the HEADER@ReturnPort field. Figure 16.42 shows the map in the Mapper.

After the message is delivered to the MSMQ, the receive function in the ERPSystem picks up the message and delivers it to a channel and port. The port in the ERPSystem delivers the message to the ERPSystem business process orchestration schedule. In the case of the HTTP-based solution, the message was posted to the ReceiveUserAcctInfo.asp page on the ERPSystem. The ASP page then submitted the document to a channel and port and finally to the ERPSystem business process orchestration schedule.

Table 16.11 details the configuration required in BizTalk Messaging to send the UserAcctInfo message from the AcctMngSys schedule to the ERPSystem. Also listed is the receive function used to pick up the message at the ERPSystem, and the channel and port needed to deliver the message to the ERPSystem business process.

Table 16.12 gives the detail of the BizTalk Messaging configuration required on the ERPSystem side to receive the message and deliver it to the ERPSystem business process.

This completes the BizTalk Messaging configuration on the ERPSystem to deliver the message to the XLANG schedule, business process.

Receiving the UserAcctInfo Message and Sending the ERPSystem Response in BizTalk Orchestration

Now look at the XLANG schedule in the ERPSystem. Figure 16.43 shows the XLANG schedule ERPSystem_16_3.skv.

The schedule receives the message UserAcctInfo through the BizTalk Messaging binding port also called UserAcctInfo to a new instance of the XLANG schedule. This is the same way that the message was received into the schedule in the AcctMngSys_16_3.skx. Note that the XLANG Schedule Activation is set to Yes, which means that each time a message arrives at this port, a new schedule instance is created and the message delivered.

The next action in the schedule, DisplayNewUser, sends the message to a Windows scripting host component, which simply displays the message using a message box. The title of the message box shows the new hire name and the name of the schedule file.

The third action in the schedule, UpdateERPSystem, sends the message to the same COM component as in the HTTP-based solution. The component simulates a real-world ERP system, such as the SAP R/3. Refer to the HTTP-based section earlier in this chapter to learn more on the functionality of this component. It is sufficient here to know that the COM component updates a SQL Server database with the new user information. The component then formats a response based on the status of the SQL Server update. The schema of the ERPSystem response message is defined in ERPResponseXML_nonHTTP.xml.

Open the data page of the schedule to see the data flow shown in Figure 16.44, specifically how the ReturnPort information is flowed into the COM component's message UpdateERPSystem_in (parameter strQueuePath). The component then includes this information as part of the response generated.

The next action, DisplayResponse, simply displays the response using the WSH component.

The final action in the schedule, SendResponseToAcctMngSys, sends the previous response message to the source business process. The response is sent out using the static BizTalk Messaging binding port, SendERPSystemResponse.

Returning the ERPSystem Response Message to the Source Schedule Instance of the AcctMngSys

The static BizTalk Messaging binding port, SendERPSystemResponse, delivers the message to the BizTalk Messaging channel ERPSystem_nonHTTP_SendERPResponse, which in turn delivers the message to the BizTalk Messaging port ERPSystem_nonHTTP_SendResponsePort. The port is configured to drop the message to the MSMQ queue Direct=OS:.private$ERPSystem_SendResponse for the source system to pick the response.

Look at Table 16.13 for the BizTalk Messaging configuration needed to accomplish this.

Finally, the next section explains the steps in correlating the ERPSystem response back to the instance of the source schedule that originally initiated the update of the ERPSystem for the new hire.

Returning the ERPSystem Response Message to the Original Instance of the AcctMngSys Business Process Schedule

After the ERPSystem drops the response to the messaging queue, the ERPSystem work is complete. Somehow the AcctMngSys must be able to get the response message and correlate the response message to the original instance of the schedule.

An MSMQ receive function on the AcctMngSys system picks up the response message and passes the message to BizTalk Messaging. A BizTalk Messaging channel pointing to an open destination messaging port delivers the message back to the original instance of the schedule. A point to note here is why the ERPSystem could not use an open destination port to deliver the message to the schedule. The reason is that the open destination port uses a private per-instance message queue, and private queues are not available on a remote machine.

Table 16.14 details the BizTalk Messaging configuration needed to accomplish this task.

This completes the setup for receiving the ERPSystem response message and correlating this message to the original schedule instance that sent out the UserAcctInfo to the ERPSystem for update.

Running the non-HTTP-Based Correlation Example 4

To start the example, copy the File2Queue.vbs script and test AcctMngSys_NewHire.xml to the .Chp16AcctMngSysSource directory. Also make sure that all receive functions except the ones used in this example (AcctMngSys_nonHTTP_ReceiveNewHire, AcctMngSys_nonHTTP_ReceiveERPSystemResponse, ERPSystem_nonHTP_ReceiveNewHireInfo) are disabled. Then type the following at the command prompt:

File2Queue.vbs   AcctMngSys_NewHire.xml 

The following steps list the sequence in which the message moves and the appropriate message boxes that pop up.