Example 3: HTTP-Based Schedule Correlation, with BizTalk Server on One End and Any External Business Process on the Other End
This example illustrates a case of schedule correlation where BizTalk Server is at one end, and a non-BizTalk Server external process is at the other. Schedule correlation back to a BizTalk Server orchestration schedule does not require a BizTalk Server on the receiving end. A primary design goal of BizTalk Server was to allow interoperability with other environments not running BizTalk. Let's see how this is possible. The correlation information is passed as part of the message as seen in earlier examples. The message moves from the source schedule to the destination schedule with the correlation information contained in it. As long as the destination application can read and retain the information, the destination application will be able to correlate the response back to the source schedule instance.
This section shows an example of schedule correlation that interfaces with an external process not running BizTalk Server. Let's look at the generic steps involved in such a correlation.
The example assumes that there is no change in the AcctMngSys business process running on BizTalk Server. The ERP system business process is running on a different platform and technology other than BizTalk Server and therefore not using any orchestration schedule.
Understanding HTTP Correlation with a Non-BizTalk External Application
In this example, there is no change to the AcctMngSys application; however, for the ERPSystem application, we will not be using BizTalk Server at all. Instead, we will use an ASP page and a COM component to represent the ERPSystem.
In our next example, the AcctMngSys system is identical to the HTTP-based scenario with BizTalk Server at both ends. In this scenario, the only difference is that there is no BizTalk Server on the other end—that is, the ERPSystem is implemented as an external process not using BizTalk Server. To simplify things further, the ERPSystem will not have a business process. The ERPSystem is composed of the following components:
ReceiveUserAcctInfo2.asp— The ASP page is the same as the ReceiveUserAcctInfo.asp with some modification. First, it extracts the ReturnPort address from the message body. The ReturnPort address will be used later to send a response back to the source system. Second, instead of submitting to BizTalk, the ASP page calls a COM component to implement a business process. There is no other change in the ASP page. The ASP page is located in the ..Chp16ERPSystemWebApp directory. We will visit the code in the ASP page in Listing 16.6 and Listing 16.7.
The COM component with the ProgID of ERPSystem2.ERPSystemUpdate2—It is the same COM component used in the previous section. The only difference between the COM component ERPSystem.dll and ERPSystem2.dll is that we have added a private function SendERPResponseHTTP() to the ERPSystem2.dll component. The component uses this function to directly post the ERP System response message to the AcctMngSys application. Internally, the function uses the MSXML::HTTPPost() method of the MSXML component. The source code for the COM component is in the ..Chp16ERPSystemSource directory. We will visit the code for the COM component ERPSystem2.dll in Listing 16.8 and Listing 16.9.
ERPSystem database—There is no change to the database schema or the stored procedure used earlier. In fact, we will use the same database as in the other HTTP-based example.
The ReceiveUserAcctInfo2.asp is almost same the ASP page ReceiveUserAcctInfo. asp as shown in Listing 16.4. The only exception is that instead of submitting the document into the BizTalk Server in the ERPSystem, the code in ReceiveUserAcctInfo2.asp calls the COM component ERPSystem2.dll. Let's look at the code examples from the ReceiveUserAcctInfo2.asp page that differs from the ASP page, ReceiveUserAcctInfo. asp.
The following code section (shown in Listing 16.6) extracts the ReturnPort address attribute from the message HEADER. Remember that this is the address that will be used by the ERPSystem to send the response message back to the source system. The source system will use this information to correlate the response to the running AcctMngSys schedule.
Listing 16.6. Code from the ASP Page ReceiveUserAcctInfo2.asp
'
'extract RetrunPort address from the message
'
Dim xmlDoc
Set xmlDoc = Server.CreateObject("MSXML2.DOMDocument")
xmlDoc.LoadXML PostedDocument
Dim strReturnPort
strReturnPort = xmlDoc.getElementsByTagName("HEADER").Item(0) .getAttribute("ReturnPort")
Set xmlDoc = Nothing
|
Finally, the following section of code (shown in Listing 16.7) calls the COM component ERPSystem2.ERPSystemUpdate2 to execute the business process. We will see how this component sends the ERPSystem response document back to the source system.
Listing 16.7. Code from ASP Page ReceiveUserAcctInfo2.asp
' ' execute the business process ' Dim erpSystem Set erpSystem = Server.CreateObject( "ERPSystem2.ERPSystemUpdate2" ) erpSystem.UpdateERPSystem PostedDocument, strReturnPort Set erpSystem = Nothing |
Similarly, the COM component ERPSystem2.ERPSystemUpdate2 (ERPSystem2.dll) that is simulating the ERPSystem is identical to the one used in the HTTP-based scenario where BizTalk is on both ends of the interchange. Let's look at the method UpdateERPSystem(). The method takes two parameters, the PostedDocument and the ReturnPort address, as strings (see Listing 16.8).
Listing 16.8. Code from the ERPSystem2.dll Component
Public Function UpdateERPSystem(ByVal strUserInfo As String, ByVal strQueuePath As String) |
As String
Dim strLastName As String
Dim strFirstName As String
Dim strAlias As String
Dim strPhone As String
Dim strStreet As String
Dim strCity As String
Dim strZipCode As String
Dim strState As String
Dim strLevel As String
Dim strTitle As String
Dim strReturnPort As String
Dim status As Boolean
Dim strDescription As String
Dim strXMLResponse As String
Dim strResponse As String
Dim strQueueName As String
Dim strMsgLabel As String
Dim oTS As ADODB.Stream
Dim MsgText As String
On Error GoTo UpdateERPSystem_err
MsgBox "Received UserAccountInfo in ERPSystem." & vbCrLf & _
strUserInfo, , "ERPSytem"
'Debug lines
App.LogEvent "Message Received by the COM Componenet ERPSystem." & vbNewLine &
The section of the code that is different from the one used in the earlier example is the call to the function SendERPResponseHTTP() toward the bottom of the public function, UpdateERPSystem(). The SendERPResponseHTTP() function does an HTTP Post of the ERPSystem response to the source system. The function uses the ReturnPort address (see Listing 16.9).
Listing 16.9. Code from the ERPSystem2.dll Component
Private Function SendERPResponseHTTP(ByVal strMsg As String, ByVal strReturnPort As String)
On Error GoTo SendERPResponseHTTP_err
Dim strResponseText As String
Dim strResponseBody As String
Dim oHTTP As MSXML2.XMLHTTP
'Send the Message via HTTP to the RetrunPort. If the ReturnPort is empty then flag error
If Not IsEmpty(strReturnPort) Then
Set oHTTP = CreateObject("Microsoft.XMLHTTP")
oHTTP.Open "POST", strReturnPort, False
oHTTP.setRequestHeader "Content-Type", "text/xml"
oHTTP.Send strMsg
strResponseText = oHTTP.responseText
strResponseBody = oHTTP.responseBody
Else
Err.Raise 999, "SendERPResponseHTTP", "No HTTP URL found"
End If
SendERPResponseHTTP_exit:
Exit Function
SendERPResponseHTTP_err:
App.LogEvent "Error = " & Err.Number & ", Description = " & Err.Description,
|
Note
You can examine the full source code in the Chp16ERPSytemSourceERPSystem2 directory. For the database component of the ERPSystem, refer to the earlier example.
There is only one change to the BizTalk Messaging configuration for the AcctMngSys application. The Messaging port, AcctMngSys_ToERPSystemPort points to the ASP page ReceiveUserAcctInfo2.asp instead of pointing to ReceiveUserAcctInfo.asp as in the first HTTP example. This is shown in Table 16.9.
| Objects | Options and Settings Chosen | Note |
|---|---|---|
| Port | Name: AcctMngSys_ToERPSystemPort (To an Organization)
Destination Organization: ERP_System Primary Transport: HTTP Address: http//localhost/ERPSystem/ReceiveUserAcctInfo2.asp | The port uses HTTP to send the UserAccountInfo message to the ERPSystem. You will make this change to run the Example 3 in this chapter— that is, HTTP-based correlation with BizTalk Server on one end and some other external System on the other end. |
Running the HTTP-Based Correlation with BizTalk on One End Example 3
Make sure that you have made the change to the BizTalk Messaging port, AcctMngSys_ToERPSystemPort as instructed on Table 16.9. This is the only change required to run this example. To start the example, copy the File2Queue.vbs script and test Test_NewHire.xml to the .Chp16AcctMngSysSource directory. Also make sure that all receive functions except the ones used in this example (AcctMngSys_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.
Note
Steps 1 through 5 illustrate running the HTTP-based scenario, where BizTalk is at one end, and an external process is at the other end.
1. |
The pop-up message box for submission of the AcctMngSys_NewHire.xml message to the queue ReceiveNewHire is the same as shown earlier in Figure 16.28. |
2. |
On receipt of the UserAcctInfo into the AcctMngSys_16_2.skx, the pop-up message box is as shown earlier in Figure 16.29. Note the XLANG schedule name in the message box title is AcctMngSys_16_2.skx. Similarly, the XLANG Monitor shows the running instance of the schedule as shown earlier in Figure 16.30. |
3. |
On receipt of the UserAcctInfo message by the COM component ERPSystem2.ERPSystemUpdate2 (ERPSystem2.dll), the pop-up message box is as shown in Figure 16.37. Figure 16.37. The message box displays the New Hire Information as received in the COM component simulating the ERPSystem in the non BizTalk end of the HTTP-based correlation.
Figure 16.37 shows the message box showing the content of the UserAcctInfo message as received in the ERPSystem business process. Because there is no BizTalk implementation at the ERPSystem for this example, there is no orchestration schedule. This message box is being displayed by the ERPSystem business component. Note that the ReturnPort attribute in the HEADER element is populated. Also the message box title is ERPSystem. Bring up the XLANG Monitor again. Notice that the instance of the schedule AcctMngSys_16_2.skv is running and waiting for the response from the ERP system. |
4. |
On completion of the ERPSystem update, the COM Component displays the response message in the message box as in Figure 16.38. Figure 16.38. The message box, showing the ERPSystem response message after the database update is completed.
Note the attributes ResponseCode and Description in the response element of the message. We are still in the ERPSystem. The message box title again displays the ERPSystem application name. The last step in the ERPSystem business process is to return the ERPSystem update response back to the source system. |
5. |
Finally, on receipt of the ERPSystem response message back to the running AcctMngSys_16_2.skx, the pop-up message box is as shown in Figure 16.35. This is same as in our Example 2. This completes the schedule correlation that began by sending out the NewHireInfo message to the ERPSystem. Note the title on the message box. We are back to the running instance of the AcctMngSys_16_2.skx schedule that originally sent the UserAccountInfo message to the ERPSystem. |
This concludes our example showing how to use HTTP-based correlation when you do not have BizTalk Server on the other end. You do not need BizTalk Server on both ends to do HTTP-based correlation. In the next section, we will see non-HTTP-based correlation.