Login | Register   
Twitter
RSS Feed
Download our iPhone app
TODAY'S HEADLINES  |   ARTICLE ARCHIVE  |   FORUMS  |   TIP BANK
Browse DevX
Sign up for e-mail newsletters from DevX


advertisement
 

Orchestrate Web Services with BizTalk Server 2002 : Page 2

BizTalk Server supports the defining and changing of business processes through BizTalk Orchestration, which enables messaging and the integration of application components. Randy Holloway explains how to use BizTalk Orchestration and Web services integration.


advertisement
Suppose you have a business rule that requires a process to make a customer account history inquiry prior to placing a sales order. If the inquiry determines that the customer's account is current, a synchronous request inquiry will be made to the credit bureau to get a current credit rating and the sales order can be processed. If the customer's account is delinquent, the credit bureau inquiry is bypassed and the sales order is rejected. I'll use this scenario to demonstrate how you can leverage BizTalk Orchestration and Web services to develop a flexible application to perform this type of customer account inquiry.

The task is to create an XLANG schedule drawing that represents all the parts of the business process (see Figure 1). In this scenario, payment terms are granted to customers based on both their account histories with that business and on their credit ratings (determined by a credit bureau's service to which the business subscribes). To access the account history information the process must query the accounts receivable records—but the order entry system resides on one platform and the accounting systems are on another. For this scenario, you need to include two specific actions in the XLANG schedule: one that represents the customer account history inquiry and another that represents the credit report inquiry.

  The XLANG Schedule Drawing
Figure 1 | Click here to get a close-up view of the XLANG schedule drawing.



The process first performs the customer account inquiry, which returns a value that shows whether the customer's account with the business is current or delinquent. In the XLANG schedule drawing, you use a Decision shape to represent a condition to be evaluated at run time. In this case, you want to evaluate the customer account inquiry result to determine the next step in the process. Once you evaluate the result, you can apply a business rule that states that if the customer account inquiry returns "Current", the XLANG schedule should invoke the customer credit inquiry action, which initiates the credit check process. The orchestrated process ends after the credit check is performed. However, if the customer account inquiry action returns a "Delinquent" response, the orchestrated process ends immediately—without proceeding to the credit check process.

Basically, the logic is:

If customer account = "Current" Perform credit check process Else Stop

After developing the business process flow into an XLANG schedule drawing, you must associate the application services with the business process steps to automate the orchestration. You make these associations by defining ports, which are named locations to which messages are sent or from which messages are received. You then use these port implementations to process messages mapped from specific business process actions to the ports themselves. BizTalk Server lets you map ports to COM components, Windows Scripting components, and messages services, including BizTalk Messaging and Message Queuing. However, it does not yet support the mapping ports directly to XML-based Web services. To invoke Web services within a process orchestration, you must map a port to a COM-based proxy client for the Web service, and then use that COM component to call the Web service and implement the message processing.

For this article, I use a sample Web service to demonstrate integrating Web services in a BizTalk Orchestration. These WebMethods help to demonstrate the process orchestration integration with Web services by performing simple functions to validate a customer ID input parameter. Listing 1 shows the code for the WebMethods of the BTWebService sample application.

Listing 1: The BTWebService sample application includes WebMethods for
performing a customer credit check and for performing a customer account
history inquiry.

[WebMethod] public string CustomerAccountStatus(string strCustomerID) { const string strIDFirstCharacter = "1"; if (strCustomerID.StartsWith(strIDFirstCharacter)) { return "Delinquent"; } else { return "Current"; } } [WebMethod] public string CheckCustomerCredit(string strCustomerID) { const int intIDLength = 5; if (strCustomerID.Length < intIDLength) { return "Denied"; } else { return "Approved"; } }

To integrate these Web services into the BizTalk Orchestration process, you need a COM component. Listing 2 shows the code for a VB COM component that serves as a proxy for the BTWebService and its methods. The component uses the Microsoft SOAP Type Library to invoke the Web service methods for the customer account inquiry and the customer credit check.

Listing 2: The BTWebServiceProxy component serves as a COM-based proxy for
the BTWebService application. The VB component includes one class with two
public methods, and implements the Microsoft SOAP Type Library to invoke
the Web service.

Option Explicit Const WebServiceURL As String = "http://localhost/BTWebService/CreditCheck.asmx?wsdl" Public Function CreditCheck(strCustomerID As String) As String Dim soapProxy As SoapClient Set soapProxy = New SoapClient soapProxy.mssoapinit WebServiceURL CreditCheck = soapProxy.CheckCustomerCredit(strCustomerID) Set soapProxy = Nothing End Function Public Function AccountStatus(strCustomerID As String) As String Dim soapProxy As SoapClient Set soapProxy = New SoapClient soapProxy.mssoapinit WebServiceURL AccountStatus = soapProxy.CustomerAccountStatus(strCustomerID) Set soapProxy = Nothing End Function



Comment and Contribute

 

 

 

 

 


(Maximum characters: 1200). You have 1200 characters left.

 

 

Sitemap