Browse DevX
Sign up for e-mail newsletters from DevX


Integrate Applications Across the Enterprise Using Microsoft BizTalk : Page 2

When it comes to EAI, you have to let enterprise-level requirements drive the architectural implementation. BizTalk, Microsoft's enterprise integration framework, provides two ways of managing your integration project. This article explores a sample integration project in BizTalk and shows you how to manage the decision-making along the way.




Building the Right Environment to Support AI, Machine Learning and Deep Learning

Solution One: Post to Web Services (cont.)
There are two ways to hand off the message to BizTalk. An Orchestration flow walks the document through a process that handles things like routing a notification to a manager or an archiving routine. The other option is to submit the message directly to the BizTalk Messaging engine, which transforms and routes it to the SAP application. The correlation token is a GUID that the BizTalk Server generates for each submission. By submitting directly to BizTalk, you can extrapolate the correlation token and pass it back to the client to check later.

Although you're operating within your own enterprise, security is still important. For example, if documents contain sensitive personnel data, you don't want unauthorized users to view or compromise that data. Encrypt the document with your solution's public key and pass it through the Web Service. Then you can configure BizTalk to decrypt it for us.

Submitting documents to BizTalk via Web Services provides other flexibility as well. If decoupling is important, then the Web Service can submit the transactional document to MSMQ and return a response different from the submission GUID. BizTalk polling the queue can also enhance the performance of the service since it doesn't need to wait for BizTalk to return the GUID.

The Web Service takes an XML document and posts it to BizTalk, which works with the XML as a string type and not as an XML Document type. BizTalk takes the string and parses the XML. A benefit to using the string type is that it allows you to manage the business message contract between BizTalk and the remote application (client) in the BizTalk product. This decoupling is beneficial because a change in the contract does not require code recompilation. It also allows you to place the business message inside a SOAP envelope for reliable messaging (discussed in the BizTalk Framework section). Plus, there's no need worry about the actual business message validation at the Web Service layer. The inability to validate the business message at the Web Service layer may be an issue for some architects, but should not cause a large problem. Basically, using Web Services to interface with BizTalk provides flexibility because it allows you to layer enterprise critical requirements. However, there is a cost in complexity since there is more code to manage and maintain. Performance can also suffer since the Web Service must first validate the SOAP message, then strip off the business message to deliver to BizTalk.

Figure 3 shows how a client can post a document to BizTalk Server through the HTTP Receive Function.

Solution 2: Posting Directly to BizTalk
Submitting documents to the BizTalk server (and thus the legacy system) through a Web Service is great for flexibility, but a simpler, quicker option exists: BizTalk Server's HTTP Receive Function. The Receive Function is an ISAPI filter that takes posted HTTP requests and submits them to the BizTalk Server.

Figure 3 shows how a client can post a document to BizTalk Server through the HTTP Receive Function.

Notice that the Receive Function replaces the Web Service. As mentioned in the previous section, BizTalk processing can be separated from the HTTP Receive functionality.

Posting directly to BizTalk Server has some advantages. The biggest is that BizTalk will perform the decoupling for you. When the ISAPI filter receives the document, it submits it BizTalk, regardless of whether the messaging service is running. Submitting directly to the HTTP Receive Function provides the correlation token mentioned before. Figure 4 is a sample output of a submission to the HTTP Receive Function.

Figure 4 is a sample output of a submission to the HTTP Receive Function.

This is not a SOAP response, but rather an HTML document and a well-formed XML response. The Web client parses it and retrieves the token. This is particularly useful for solutions requiring an audit trail on vital data. The token can be persisted and used to retrieve the document through BizTalk's tracking interface.

This approach benefits because of the simplicity involved. You can quickly structure a BizTalk architecture that receives documents from your resource planning application. The drawback is the loss in flexibility that may hinder you from satisfying critical requirements. BizTalk is flexible enough to build a preprocessing component, but it can quickly become lost in an enterprise architecture.

Comment and Contribute






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



Thanks for your registration, follow us on our social networks to keep up-to-date