Day 1
Overview
In the overview module we look at the problem domain area BizTalk is trying to cover. We look at the different separate applications that make up the BizTalk Server offering, like the Messaging Engine, Business Process Automation, Business Rule engine, Business Activity Monitoring and much more. We have a look how each piece of BizTalk's offering fits an area of the described problem domain. We also have our first look at the large toolset that comes with BizTalk Server. We'll take the attendee's machine and make it ready for BizTalk use, configuring BizTalk in a developer environment using the "BizTalk Server Configuration" utility. This includes the first touch with security related topics as well, as BizTalk needs to be configured with security credentials next to databases and Internet Information Server.
Messaging Architecture
This module looks at the backbone of BizTalk, its messaging engine. We have a look at how to get messages into and out of the messaging engine. We investigate the "publish-subscribe" pattern used in the messaging engine and see how the Business Process Automation fits into this. We'll have a look at how to configure a port in the messaging engine and how to route messages through those ports. We'll have a look at how subscriptions are set up and how they influence the behavior of the messaging engine. We'll also have a look 'under the hood' and investigate what a BizTalk 'message' really is, how it is manipulated and persisted.
Schemas I - Defining Message Structure
Although BizTalk's messaging engine can handle any type of message format, the toolset provided with BizTalk 2009 focuses largely on XML. We'll have a quick refresher of XML and XML Schema (XSD). We'll see that BizTalk's toolset works on XML and XSD. We'll have a look at the BizTalk schema editor in Visual Studio. We'll create our own message structure schemas and see how to deploy and use them in the messaging engine. We'll have a close look at the BizTalk schema editor and its capabilities. It also provides some easy tools for generating instances, validating instances and validating schemas. We'll have a look at the schema editor and build our own schema that we will deploy in the BizTalk environment.
Schemas II - Message Routing
When you want to route inside of the BizTalk messaging engine you will have to use 'Context' information. Context information is associated with a message and populated by various components of the messaging engine. We'll have a look into this subscription mechanism and which context properties represent what information. If you want to route a message based on a piece of its content you will have to make that content available in the context. This is achieved by using 'property schemas'. We'll create our own property schema and use the property to route messages. We'll use the schema editor to make schemas and property schemas. By promoting values from the content of a message into the context we're able to set up our subscriptions based on the content of messages.
Day 2
Adapters I - Basic Adapters
BizTalk comes with a set of basic adapters. These adapters enable the messaging engine to translate external messages (file on disk, message in an MSMQ Queue, etc.) into internal messages (BizTalk message with context properties). File, Ftp, MSMQ and SharePoint adapters are discussed. We'll use the BizTalk management console to set up a messaging solution using the FILE and FTP adapter in a BizTalk environment.
Adapters II - Database and Line of Business Adapters
We'll have a look at the SQL Server adapter. We'll poll messages from a database and see what the effects are. What additional rules need to be applied when working with database records versus files on the file system? We'll use the "Adapter Metadata Generator" to generate schemas for use in BizTalk projects from our SQL adapter, and we'll discuss the adapter framework and the WCF SQL Lob adapter. We'll survey the availability of the different LOB adapters that come out of the box. We'll use the BizTalk management console and SQL Server to set up a solution using database tables in a BizTalk environment.
Pipelines I - Pre-processing Inbound Messages
When messages are entering the system through adapters, they have not been persisted yet. Before publishing these messages to the message box some pre processing might be desired. This is where pipelines come in. We look at the different stages a pipeline provides and what out-of-the-box functionality comes with BizTalk 2009. Messages coming into BizTalk might consist of many smaller messages. BizTalk provides default functionality for 'splitting up' these large messages into their separate parts. This functionality is provided for both XML and 'flat-files'. We'll take a look how it's done and which items need to be created in BizTalk for this to work. We'll see how to configure a pipeline for use, what its effects are and how you can reuse pipelines. We'll use the BizTalk schema editor to create schemas, property schemas and an envelope schema. We will split up messages into smaller parts, and also have a look at a 'comma separated value' (i.e.flat-) file conversion to XML.
Pipelines II - Post-processing Outbound Messages
When messages are leaving the BizTalk system some last minute modification or addition might be needed (like a departure timestamp or signature). This is where the send pipelines come in. We'll have a look at a send pipeline and the default functionality provided by BizTalk 2009. Using a send pipeline to augment outgoing XML messages we'll be able to introduce "Microsoft InfoPath" into the process. This allows end users to 'fill in forms' and never be exposed to XML. We'll see how to configure a pipeline for use, what its effects are and how you can reuse pipelines. We'll create a send pipeline to process outgoing messages and convert them into a 'flat-file'.
Maps I - Basics
Incoming XML messages often need adjustments before they can be used in business process logic. Sometimes the changes are simple (Translation) like an owning namespace change. Other times the changes are more drastic, more like building a new message using some data from another (Transformation). Both can be handled by maps (AKA. XSLT++).
Some developers install a version of BizTalk just to have access to the XSLT designer. BizTalk comes with an excellent XSLT designer that visually represents the XSLT. We'll create our own map using this editor and apply it to a receive location. All the while, we'll be looking not only at 'what the editor does' but 'how it actually works beneath the hood'.
Using Microsoft Visual Studio 2008, which comes with integrated XSLT debugger, we can now debug our maps. The BizTalk Mapper comes with some tools like "Test Map" and "Validate Map" that we will have a look at. Using maps we'll implement a message normalization pattern in the BizTalk messaging engine. Using the BizTalk mapper.
Day 3
Maps II - Advanced Topics
XSLT itself does not provide a lot of functionality next to the translation/transformation. To make maps more useful, the "Object Extension" methodology is used. This allows for functionality to be added to the XSLT engine. These additional pieces of functionality can be written in 'inline script' or 'compiled types'. BizTalk 2009 comes with a number of these functionalities called 'Functoids'. We explore the functoids and their usage in a map. We also see how we can write our own functoid. We'll add more functionality than just transform to our map. First using the Scripting functoid and also by writing a custom functoid that can then be reused over projects and teams.
Orchestrations I - Basics
In this module we'll have a look at what an orchestration is, how it is developed and how to deploy and run an orchestration. We'll see how the orchestration engine fits into the larger whole that is BizTalk Server 2009. The orchestration editor is an elaborate editor integrated into Visual Studio. It allows us to create/edit orchestrations in a visual manner. In this module we'll take a look at the basic shapes that make up an orchestration, and see how to use them and what behavior they exhibit. We'll use the orchestration designer to create our own orchestration, taking into account all the steps required from a blank project to the deployment and starting of the orchestration. This orchestration will use many of the basic shapes any orchestration will consist of.
Orchestrations II - Persistence
"Bad things happen!" - power failures without UPS, crashes of hardware. These circumstances happen and cannot be avoided. They can, however, be prepared for and that's exactly what orchestration persistence is about. Whenever an orchestration is considered idle (waiting for a message before continuing), the resources used by this orchestration can be considered 'wasted'. To maximize resource usage, BizTalk persists idle instances to disk and removes them from memory freeing up resources. When needed (the awaited message arrives) BizTalk automatically recreates the instance with the correct state. We'll have a look at how this works and how we can influence this behavior though configuration. To guarantee consistency, even over long periods of time, BizTalk writes orchestration states to the database. When required an instance can be 'restarted' from a point in time where the state was saved for. This is a major safeguard in BizTalk but can also cause performance bottlenecks. We'll see how it works and how we can influence this behavior through how we design our orchestration. We'll create an orchestration with a long running message exchange pattern. This will cause BizTalk to dehydrate the orchestration. Using the BizTalk management console we'll closely investigate the message and the orchestration acting upon the message.
Day 4
Orchestrations III - Scopes
Just like in any other programming environment, BizTalk can define scopes. Scopes allow for variables, messages, transactions, thread synchronization and exception handling. There are two types of transactions in BizTalk. Atomic and 'Long Running' (also known as 'resource compensation'). The atomic version integrates with the MSDTC. The 'LRT' is a mechanism that is not as expensive as the atomic one while still providing 'commit' and 'undo' functionality. Just like any other program, exceptions can happen. If no exception handling is implemented, BizTalk will be the exception handler and suspend/terminate the instance. If we want to incorporate logic for dealing with exceptions we'll use the scope again. This time it's an exception handler scope. We'll create a BizTalk application which simulates a resource compensation process. Using the BizTalk management console and event log we'll trace the steps BizTalk is performing when 'things go wrong'.
Debugging BizTalk Solutions
Debugging BizTalk applications is different from debugging a .Net application. BizTalk does however provide debugging functionality. In this module we'll investigate how to debug BizTalk applications. When messages don't arrive in an orchestration, or error reports are generated by BizTalk for 'routing failures', it's time to debug the routing that is happening. BizTalk's administration console provides functionality for locating and analyzing failed messages. When debugging an orchestration you are really 'replaying' steps already completed by BizTalk - hence the name "Replay Debugging". BizTalk also allow for "live" debugging. This is still based on the "replay" principle but acts on living instances instead of completed ones. We'll take a look at how to set up a debug session for an orchestration. We'll use a complete BizTalk application which has problems which we'll need to investigate problems to solve. Using the BizTalk management console, the event log, and the orchestration debugger, we'll debug the application until it is fully functional again.
Web Services I - Consuming Web Services
Web Services work with XML, XSD, WSDL (xml format) and SOAP (xml format). This closely fits with what BizTalk has as core capabilities, and therefore BizTalk and Web Services are a perfect match. To enable BizTalk to quickly use Web Services all kind of tools are provided. We'll have a look at how to consume a WCF web service from BizTalk. BizTalk's messaging engine alone is very capable of calling web services without the use of orchestration. In this module we'll have a look at how to set up a scenario with WCF web service and BizTalk's messaging engine only. For more complex scenario's orchestrations are needed. An orchestration by itself will often interact with different systems and Web Services are an excellent choice in how to do so. In this module we'll have a look at how to build an orchestration that calls an external web service. We'll integrate web services into a BizTalk application. Using the different tools provided by BizTalk to integrate with WCF technology, we'll extend an existing order process with additional functionality. This functionality is provided by a WCF service and will also include 'compensation' logic.
Web Services II - Exposing Web Services
No one likes XML, but Web Services IS the way to communicate with systems. Exposing functionality implemented in a BizTalk solution as web service is vital for easy integration scenarios. BizTalk's messaging engine alone is very capable of exposing web services without the use of orchestrations. In this module we'll have a look at how to set up a scenario exposing a WCF web service using BizTalk's messaging engine only. For more complex scenario's orchestrations are needed. An orchestration by itself can be reused by others or in larger scenarios, and again Web Services is a perfect fit. Tools are provided to expose functionality implemented by a BizTalk orchestration through a WCF web service. In this module we'll have a look at those tools and how to use them. We'll integrate web services into a BizTalk application. Using the different tools provided by BizTalk to integrate with WCF technology, we expose the existing business logic through a WCF service.
Day 5
Business Rules Engine
"Separate things that change from things that don't change". A good design principle not applied enough in many scenarios. BizTalk Server 2009 comes with a 'stand-alone' Business Rules Engine. This engine is usable from inside as well as outside BizTalk. BizTalk Server 2009 also comes with a "Business Rules Composer" which is a graphics user interface for designing policies (collection of rules). In this module we'll have a look at this tool and how to create vocabularies, facts, rules and policies. Rules aren't much use if they aren't applied. Once you have created policies, they still have to be used inside of the business flow. In this module we'll see how to use policies from both .Net code and inside an orchestration. We'll take an existing 'complex application' and move certain pieces of that logic outside of compiled code, and we'll use the business rules composer editor to create a policy with several rules. These rules will then be called from inside a BizTalk orchestration. This will demonstrate how modifying the rules in the business rules engine allows for changes over time without the need for redeployment.
Business Activity Monitoring
When a BizTalk solution is in production, visibility of the current runtime is often required. This insight is however on a higher level of abstraction than the shapes defined inside an orchestration (that includes exception handling for instance). To create a higher level view abstraction of the technical implementation of an orchestration we can use the 'BAM'. Before we can make a report, we have to define what we are interested in reporting about. In BAM terminology this is called defining an 'activity' and the 'view' upon it. BizTalk comes with add-ins for "Microsoft Office Excel" and "Microsoft Visio". In this module we'll have a look at the Excel add-in and create an activity and view. After the creation of the definitions, nothing happens yet. The definitions need to be associated with events happening inside BizTalk. To associate events with the definition we'll use the "Tracking Profile Editor". At any time after gathering has started the data can be queried and used. BizTalk comes with a query portal for the BAM's data. We'll have a look at this portal and how to retrieve data from it.
BizTalk Deployment
After the design, development and testing phase it's time for deployment. BizTalk comes with a number of tools to ease deployment of applications. To optimize the use of these tools the deployment has to be 'designed' too. To correctly deploy an application we have to know what our application is made from. In this module we'll have a look at the various resources inside and outside of BizTalk that make up our complete application. BizTalk allows us to add custom artifacts to its resources store. An application is a container for resources. These containers can be addressed as standalone units in a BizTalk environment and we can manage our resources per application. We'll have a look at what applications are and how to create/edit them. BizTalk comes with a MSI generator. Based on the application's resource artifacts a complete MSI installer can be generated and we'll have a look at its capabilities.
