A White Paper Introduction – Increase Customer Satisfaction and your Bottom Line with More Effective Business Transaction Processing
Microsoft BizTalk helps automate business processes by interconnecting different IT systems across one or multiple organizations. When an IT system sends a message, the BizTalk server receives it. It then goes through a multi-step process that translates the message into a format BizTalk can handle, takes whatever course of action is required and translates the message back to a format the other application understands before sending it on.
For instance, an e-retailer is a prime example of how implementing Microsoft BizTalk can make ordering products from your site a breeze. Except for physically packing the order – the entire process, from the customer clicking submit to the product leaving your warehouse goes on behind the scenes.
Customers will no doubt appreciate the speed and efficiency of their shopping experience while having no clue as to how your company seems to process orders so quickly. That level of service though will keep them coming back and provide you with one of the best forms of advertising, word of mouth, at no cost.
Learning how this all works is important to understanding the value BizTalk integration can provide your organization. Continue reading to learn more about how each of the BizTalk server components helps automate business processes.
First read about BizTalk adapters, the fundamental aspects the BizTalk server uses to interconnect different information technology systems. Also, learn how BizTalk developers can easily create adapters and the new ways Microsoft makes them available for easy integration.
Next, see how the BizTalk server takes messages it receives from applications through adapters and translates them into a format the utility can understand using what is known as a pipeline. The BizTalk server has pipelines on both ends of the process to translate messages.
After a message is translated, it is ready to go through orchestration, or a graphical representation of a business process a BizTalk developer can easily create. See an example of one of these representations and learn more about how BizTalk developers create a vocabulary and business rules to easily customize orchestrations for specific processes.
BizTalk Adapters – Making Interoperability a Reality
Adapters send and receive messages to and from the BizTalk server to particular applications. They are the fundamental building blocks Microsoft BizTalk uses to make interoperability a reality.
No matter if it is sending or receiving a message, an adapter has to know how to communicate in a way the other application will understand it. So when an adapter receives a message, it must know what it is and what to do with it or the entire process cannot move forward.
The type of adapters BizTalk developers choose depends a lot on the applications the BizTalk server has to communicate with. Several adapters are included with the software but they can also come from third party sources or be custom made if necessary.
Microsoft BizTalk Server introduces a new way to create adapters
Unlike previous BizTalk server versions that used an adapter framework, the newest version constructs them as WCF channels. Adapters shipped with the newest BizTalk server are compatible with SOAP and SOAP with WS-* technologies.
BizTalk developers can use an existing WCF channel to easily create an adapter themselves or create an entirely new channel for a specific purpose.
Adapter packs available from Microsoft include WCF-based adapters for various line-of-business (LOB) applications like SAP, Siebel and Oracle databases. Microsoft uses a generic framework, the WCF LOB Adapter SDK, to create these packs and adapters for LOB applications. These BizTalk adapters are versatile and compatible with any .NET Framework application, even without the BizTalk server.
Another adapter Microsoft develops for the BizTalk server is the MSMQ, which allows the exchange of messages using Microsoft Messaging Queuing. A similar one, the WebSphere MQ Adapter, provides the same messaging capacities for IBM’s WebSphere Message Queuing.
The file adapter makes interaction among file storage mechanisms a reality. Specifically, the file adapter provides the ability to read and write files in the Windows system. Some business process applications are able to access the same file system which makes exchanging messages through files a less cumbersome option. Similar adapters are also available for SharePoint, IBM and Oracle databases.
Another important type of adapters are those that allow connection to commonly used business applications – BizTalk Microsoft has adapters available for such programs as PeopleSoft, SAP R/3, Siebel e-business application, JDEdwards One World and others.
Processing and Translating Messages – How BizTalk Microsoft Moves Requests Between Different Applications
After a message from an application is received by a BizTalk adapter, it goes through two other steps in what is called a receive port before being sent to a message box for orchestration. In order for BizTalk Microsoft to correctly implement business processes, it has to know how to correctly handle messages. Therefore, they must be in a format the BizTalk server can understand.
BizTalk server’s receive pipeline transforms a message to a useful format
BizTalk Microsoft works with XML formatted documents. Many applications though do not read XML documents. Therefore, original formats from different applications need to be converted to XML format AND back to a format the other application can read once the orchestration process is complete and the message is sent on.
Authenticating message senders may also be required so to handle all this, pipelines are constructed in some number of stages by a BizTalk developer. Each pipeline contains one or more components that handle a particular part of processing a message.
BizTalk Microsoft Server 2006 provides standard pipeline components for common applications. If one is not available, the BizTalk developer can easily create one. But for messages already in XML format, BizTalk Microsoft provides a simple receive/send pair to handle these messages.
Once a document is converted to XML, a BizTalk developer has to define what a XML representation looks like – that is, specify what schema should be used
Schemas are defined using the XML Schema Definition (XSD) language – a complex, yet powerful way to describe a XML document’s structure. BizTalk Microsoft provides a tool called the BizTalk Editor that allows a developer to create schema by using graphical hierarchy to define elements.
Once messages are in a known XML schema, it’s possible to map between them – BizTalk developers can create maps to transfer information between different messages and documents. Each map represents a correlation between two XML schemas that define a relationship between elements in each schema.
Maps are used in many ways. For example, an incoming purchase order has basic information like name, address, phone, etc. that needs to be transferred to an outgoing invoice. A BizTalk developer can create a map to do this without the request having to go through orchestration. More complex maps might originate within a BizTalk orchestration.
A graphical tool called the BizTalk Mapper allows a developer to easily specify how information in one message should be mapped to another message. More complex transformations are possible using functoids – or pieces of executable code that arbitrarily define complex mappings between XML schemas.
Being able to define a document’s XML schema along with a mechanism to map information across documents with different schemas is an essential component to automating business processes.
Defining Business Processes – How a BizTalk Orchestration Makes Defining Process Logic Easy
Automating business processes requires communication between different systems, which is what the BizTalk server facilitates. BizTalk orchestrations provide a way to define and execute process logic – a necessary part of automating business processes.
It’s entirely possible to create an automated process in a common language like C# or Visual Basic – but writing, maintaining and managing complex business processes can be very time consuming and challenging.
BizTalk orchestrations create easy-to-understand graphical representations of business processes
Creating a business process graphically using BizTalk orchestrations is not only less time consuming, but easier to understand, explain and modify.
A business process is basically a set of actions that works together to meet a business need…examples include a purchase order approval process, work order approval or even inventory control.
BizTalk developers and business managers/owners must work together in order to successfully create an automated business process. BizTalk Microsoft provides different software tools so equally important players in the organization can communicate with each other.
BizTalk developers use an add-on tool that runs in Visual Studio specifically designed for software programmers. Owners and managers use an add-on to Visio so they can easily collaborate with their IT peers and understand what is going on.
BizTalk developers define actions by connecting “shapes” in a logical way using the BizTalk Orchestration Designer
When a BizTalk orchestration receives a message from a send adapter, a decision is made based on the message’s content after which an action resulting from that decision takes place.
Actions are defined by a BizTalk developer by connecting various “shapes” using the Orchestration Designer utility included with BizTalk Microsoft. These shapes include:
Receive shape – allows the orchestration to receive a message
Send shape – allows the orchestration to send a message
Port shape – connected to a receive or send shape, this shape defines how messages are transmitted – different types of port shapes define the types of messages it can receive
Decide shape – represents an if-then-else statement which allows an orchestration to perform different tasks. An Expression Editor included with the Orchestration Designer allows a BizTalk developer to specify conditions
Loop shape – allows for an action to be performed repeatedly provided some condition is true
Transform shape – allows the transfer of information from one document to another
Parallel Actions shape – allows BizTalk developer to specify multiple operations be performed in parallel to one another and not in sequence
Scope shape – allows the grouping of operations into transactions and the defining of exception handlers for error processing
Message Assignment shape – allows BizTalk developer to assign values to orchestration variables
A BizTalk developer or BizTalk consultant organizes these shapes into an orchestration – see an example below that uses a few of the shapes detailed above. With this simple example a message is received, a decision made based on the content of that message and one of two paths is executed as a result of that decision.
BizTalk orchestrations are much more complex than this in real life but you can get a pretty good idea of what one looks like here…to try and help simplify matters, the BizTalk Orchestration Designer provides the ability to zoom in and out.
After a developer creates a BizTalk orchestration, the group of shapes and their relationship to one another is converted into a standard .NET assembly.
SOAP based web services have become a more significant consideration for BizTalk developers recently. In order to access external web services, a WCF Service Consuming Wizard that comes with each BizTalk server allows developers to create orchestrations that use web-based services via SOAP or any other WCF mechanism. The WCF Service Publishing wizard helps a developer easily expose one or more of an orchestration’s operations as WCF services.
Business Rule Engine – an easier way to define and change business rules in a BizTalk Orchestration
Some aspects of a BizTalk orchestration change more often than others. Decisions entrenched in a business process, or business rules, are the most volatile aspect of an orchestration.
A manager’s spending limit may change from $100,000 to $500,000 or a slow-paying customer’s maximum allowed order decreases from 100 units to 10 are just a couple of examples. To allow an explicit way to specify and update these types of rules without having to create an entirely new orchestration, the BizTalk server provides a tool called the Business Rule Engine (BRE).
The BRE makes changing rules within an orchestration quick and easy. Without it, a BizTalk developer would have to open the orchestration, modify the appropriate shapes, build and deploy the modified assembly. During this process, the BizTalk application that includes this orchestration must be shut down and restarted with the new assembly.
BizTalk developers use what’s called the Business Rule Composer to define a vocabulary for use in specifying business rules. Each term provides a user-friendly name for some information like “Number Shipped”, “Maximum Quantity of Items” or “Approval Limit.” Each of these terms can be mapped to a specific element in an XML schema.
After a vocabulary is defined, the BizTalk developer uses the Business Rule Composer to create business policies that use this vocabulary. Each of these policies contain individual business rules, who use the vocabulary in conjunction with logical operators like “Greater Than”, “Less Than”, “Equal To” and others to define how a business process operates.
An orchestration uses a CallRules shape to execute a business policy. This shape creates an instance of the BRE, specifies the policy to execute and transfers the information from an XML document or .NET assembly.
Both business rules and vocabularies are much more complicated, and powerful, than this. But the heart of the business rule engine lies in the fundamental idea of defining a vocabulary and then defining sets of rules that use that vocabulary.
Proper Installation of your BizTalk Server Suite
It’s entirely possible for you to install and operate your BizTalk serve on one machine. But thinking for a minute might lead you to conclude this is not a good idea.
Will the quantity of messages and requests overwhelm only one machine? Would redundancy make your system more reliable?
The BizTalk server can be deployed in different ways to meet these challenges.
Components can be spread across multiple hosts on multiple machines
Hosts are simply logical constructs that are a fundamental concept for deploying a BizTalk server. Each host can contain various things like orchestrations, adapters and pipelines. A BizTalk developer must prompt actual host instances, or Windows processes, to use these logical constructs.
The example below shows Machine A has two host instances, one containing orchestrations P and Q and the other a receive port. Machine B has only one host instance that contains orchestrations P and Q only. Machine C has two host instances, both are separate send ports. All of them tie into the MessageBox database stored on Machine D.
Having the orchestrations on two separate machines allow the BizTalk server to scale up as needed for high-volume processes. As seen in this example, each host instance is isolated from the other, in effect separating Windows processes. Although this example has only one MessageBox, it’s possible to replicate this database for greater scalability or cluster it to avoid a single point of failure.
Bookmark and check back often with your one-stop IT outlet, bookstore and information technology knowledge center XComPC.com. New articles will be added periodically that explore Microsoft BizTalk, SharePoint and general concepts that make business integration a reality.