It looks like the next release of BizTalk Server will be Version 2009 instead of 2006 R3, as previously indicated. It’s on schedule for release in the first half of 2009, and I would expect to see a CTP version sometime before the end of 2008.
Updated Platform Support
-
New Application Platform Support
BizTalk Server 2009 supports the latest Microsoft platform technologies, including Windows Server 2008, Visual Studio 2008 SP1, SQL Server 2008 and the .NET Framework 3.5 SP1. These platform updates enable greater scalability and reliability, and many advances in the latest developer tools.
-
New Hyper-V Virtualization Support
BizTalk Server 2009 now takes advantage of the latest virtualization improvements included as part of Windows Server 2008 Hyper-V, which can lead to reduced costs through lower hardware, energy, and management overhead, plus the creation of a more dynamic IT infrastructure.
-
Improved Failover Clustering
By taking advantage of Windows Server 2008 clustering, BizTalk Server is now able to be deployed in multi-site cluster scenarios, where cluster nodes could reside on separate IP subnets and avoid complicated VLANs.
Service Oriented Architecture and Web Services
-
New Web Services Registry
BizTalk Server 2009 includes a UDDI 3.0 registry which provides support for registry affiliation, extended discovery services, digital certificates and extensibility for a subscription API.
-
Enhanced Host Systems Integration
BizTalk Server 2009 adds a new WCF WebSphere MQ channel by providing the transport, data formatter and encoder to integrate directly with WebSphere MQ via WCF and a new WCF Service for Host Applications has been added to expose the traditional Transaction Integrator to .NET Framework developers. Additionally, BizTalk Server 2009 includes updated platform support for the most recent versions of CICS, IMS, CICS HTTP transport, DB2, DB2/400, DB2 Universal Database, and WebSphere MQ.
-
Enhanced Enterprise Service Bus (ESB) Guidance
ESB Guidance 2.0 delivers updated prescriptive guidance for applying ESB usage patterns, improved itinerary processing, itinerary modeling using a visual Domain Specific Language (DSL) tools approach, a pluggable resolver-adapter pack, and an enhanced ESB management portal.
Business to Business Integration
-
Enhanced Support for EDI and AS2 Protocols
BizTalk Server 2009 provides support for multiple message attachments, configurable auto message resend, end-to-end filename preservation, improved reporting to address new features, and Drummond re-certification for AS2.
-
Updated SWIFT Support
By building on a rich SWIFT foundation, BizTalk Server 2009 updates all message schemas and business rules for compliance with SWIFTReady Financial EAI Gold certification, as a result adds support for SWIFT FIN Flat File message types and business rules, BIC Plus IBAN interface, and Extensibility to support SEPA Routing.
Device Connectivity
-
New Mobile RFID Platform and device management
BizTalk Server 2009 delivers a new lightweight platform for a variety of mobile devices, which simplifies the development of mobile applications that expose relevant, real-time business information. BizTalk RFID Mobile includes support for enhanced device management, Powershell support for administration of edge infrastructures and the ability to monitor RFID infrastructure using System Center Operations Manager 2007.
-
New RFID industry standards support
Support for key industry standards (including LLRP, TDT, TDS, WS Discovery and partial EPCIS support).
Developer and Team Productivity
-
New Application Lifecycle Management (ALM) support
BizTalk Server 2009 provides support for Team Foundation Server (TFS), and allows development teams to be able to leverage the integrated source control, bug tracking, support for team development, Project Server integration and support for automating builds via MSBuild.
-
Enhanced Developer Productivity
BizTalk Server 2009 introduces a number of improvements have been made to the underlying Visual Studio based BizTalk project system which enhances debugging support for artifacts such as BizTalk Maps (XSLT), pipeline components and XLANG Orchestrations, and enables support for unit testing via Visual Studio Test.
Other Enhancements
-
Administration
By continuing to build on the improvements to the BizTalk Management Console made in BizTalk Server 2006 R2, two new query types have been added for tracked message events and tracked service events which consolidates all queries – tracked/archived data, live data and specialized EDI reports, into a single tool.
Full product roadmap at: http://www.microsoft.com/biztalk/en/us/roadmap.aspx
Scenario: I have a need to process two transformations back-to-back. For example, I have Schema1, Schema2, and Schema3, and I have two maps:
- Schema1 -> Schema2
- Schema2 -> Schema3
Schema1 is our canonical schema, meaning this is the schema we always use to "publish" to the MessageBox database. Consider this diagram in which we receive a message and publish the update to two line-of-business (LOB) applications:
Notice what's missing? There is no Schema1 -> Schema3 map.
In the real-life scenario that inspired this test, the maps are very complicated and it would be too much of an undertaking (currently) to invent a new map for transforming Schema1 directly to Schema3. So how do we apply multiple maps in a row using BizTalk?
For this example, I've built out three schemas and two maps, as outlined above. Here are the schemas:
Complicated, I know! =)
First, the easy approach: Orchestration.
This works, however the message in the real-life scenario is over 600MB. BizTalk Server, by default, will swap to disk for transforms performed in an orchestration when the message is over 1MB in size (see the note about TransformThreshold in this article). We can increase this threshold if needed, but 600MB is a bit excessive, I think.
Once orchestration was ruled out, my first thought was to do something in a pipeline component; however, I wanted to see if I could do this without code.
So how about this: I set up a WCF-based NetTCP receive location (and BizTalk sets up its own service host -- how nice) and a corresponding NetTCP send port. (In retrospect NetNamedPipes might have been better? Not sure, but this still worked.) On the way out of the send port, we transform to Schema2, which is published back to the MessageBox by the receive port. Finally, our LOB2 send port applies the second map on its way out.
Yeah, yeah... it's clumsy... it's kind of a hack... but it was fun.
Seriously, however, if anyone has a different approach, I'm all ears. =) Eventually the "correct" solution will be to create a map which transforms Schema1 directly to Schema3.
Sample code:
First, I'll admit the title of this post isn't entirely accurate, because you can't do the grouping and sorting I'm about to show using the BizTalk mapper. We'll be overriding the XSLT for a BizTalk map, so therefore it might be more appropriate to call this "Muenchian Grouping and Sorting in XSLT." But since I'm doing this from a BizTalk perspective, I can live with the subtle difference. :)
Let's say I have a flat file schema to import sales order information. Being a flat file, we can assume that it's completely denormalized, meaning there won't be defined relationships and we'll have redundant data. Let's take a simplified flat file that looks something like this:
Order222|Item123
Order111|Item456
Order222|Item789
Notice that for each line, we repeat the sales header info (in this case it's just "OrderID," but typically this would include customer info, order date, etc.) again and again. Our schema ends up looking like this:
However in our destination schema, we want to group the line data for each header, and we want to sort it, too. Here's the destination schema we need to use.
Sounds like fun, right? Great! Let's get started...
What I like to do first is to create a new BizTalk map, and then steal its XSLT to use as a template. This way we know the namespaces and such are correct. So I've created a new BizTalk map and added our OrdersFF as the source schema and our Orders schema as the destination. Right-click on the map and choose "Validate," then steal the output ".xsl" file. Then click on the functoid grid in the graphical map, and set the Custom XSL Path property to your saved .xsl file.
Within the XSLT, we're going to be using a method called the Muenchian Method to handle the grouping and sorting. This method allows us to group and sort data very quickly (faster than some of the grouping options you can do with the graphical mapper, in fact).
Just below the <xsl:output> block of our XSLT, we're going to create a key value for this grouping. This creates an index which the transform engine can use to loop through each unique value of that key.
<xsl:key name="groups" match="Order" use="OrderID"/>
From there, at the top of where we're going to start our /Orders branch, we can modify the "for-each" block to loop through our key instead of source nodes, like we might typically do.
<xsl:for-each select="Order[generate-id(.)=generate-id(key('groups',OrderID))]">
If we want to apply sorting, we can add:
<xsl:sort select="OrderID" order="ascending"/>
Finally we loop through the "groups" key we created before and output our data:
<xsl:for-each select="key('groups',OrderID)">
The whole /orders branch of our XSLT now looks something like this:
And here's the XML output:
Notice that the orders are now sorted, despite being unsorted in the source file, and the items are now grouped by order. Nifty, huh?
Sample code:
Technorati Tags:
BizTalk,
XSLT
It seems I keep putting this list together again and again, so I think it deserves a "home" of its own. I'll try to keep it up to date.
If you're a developer who would like to learn about developing applications on BizTalk Server, but don't have the time, resources or whatever to take one of the MOC-based courses, this list is for you.
First, take a look at the BizTalk Virtual Labs to get started. I recommend you approach the labs in this order:
- Working with Schemas
- Working with Maps
- Working with Pipelines
- Processing Flat Files
- Creating an Orchestration
- Deployment/Management
- WCF Intro - Building a WCF Service
- (others, as applicable or interesting to you)
After that, take a look at the samples included with the BizTalk SDK. In particular, check out the Messaging, Orchestration, and Pipeline samples (including one of my personal favorites, the Aggregator sample which demonstrates calling pipelines in orchestrations as well as aggregation and assembly of disparate messages).
If books are more your thing, here is a list of BizTalk books I highly recommend. I'll try to keep the list up to date. No affiliate code here; I really truly recommend you check these out.
Finally, start building solutions on BizTalk. Are they going to be perfect? Probably not. I know I'm still embarrassed by some of my own work that's still running in production somewhere (you know who you are), even though it works, and it works pretty well. But actually applying your knowledge is probably the most essential way to learn about building solutions in the BizTalk world.
If you have the opportunity to take some official training, here are your courses:
- 2933: Developing Business Process and Integration Solutions Using Microsoft BizTalk Server 2006 (5 days)
- 2934: Deploying and Managing Business Process and Integration Solutions Using Microsoft BizTalk Server 2006 (2 days)
One more thing (I know, I already said "finally"), try to find a Connected Systems or BizTalk-related user group in your area. Live Search: Click here. If you can't find one near you, feel free to email me and I'll ask around.
The BizTalk Customer Advisory Team and BizTalk UE team are pleased to announce the first edition of the “Microsoft BizTalk Server 2006 R2 Hyper-V Guide”.
The Microsoft BizTalk Server 2006 R2 Hyper-V Guide is the third installment in a series of guides intended to provide easily accessible, hands-on guidance to our customer and partner community. This 145 page guide is available on MSDN, TechNet and as a separate DOCX, PDF or CHM download alongside the already available “Microsoft BizTalk Server Operations Guide” and “Microsoft BizTalk Server Performance Optimizations Guide”
The guide provides relevant information to IT professionals to enable them to make educated decisions about the advantages and tradeoffs of using Windows Server 2008 Hyper-V to virtualize BizTalk Server environments. This guidance was derived from a 6 week performance lab conducted by the BizTalk Customer Advisory Team and Premier Field Engineering. It will be refreshed for future versions of Microsoft BizTalk Server.
The key sections of the guide are:
- Getting Started: provides conceptual information about Hyper-V, the virtualization technology introduced with Windows Server 2008, and an introduction to the Hyper-V architecture.
- Deploying BizTalk Server on Hyper-V: describes the steps that were followed to set up the lab environment, which was used to compare the performance of a BizTalk Server solution running on Hyper-V environment to the same BizTalk Server solution running on comparable physical hardware.
- Evaluating BizTalk Server Performance on Hyper-V: details the important considerations when measuring the performance of a BizTalk Server solution running on a Hyper-V virtualized environment.
- Testing BizTalk Server Performance on Hyper-V: provides detailed results of four distinct testing scenarios that compare the performance of a BizTalk Server solution running on Hyper-V environment to the same BizTalk Server solution running on comparable physical hardware.
Full MSDN URL: http://msdn.microsoft.com/en-us/library/cc768518.aspx
Full TechNet URL: http://technet.microsoft.com/en-us/library/cc768518.aspx
![clip_image002[4]](http://blogs.msdn.com/blogfiles/chrisromp/WindowsLiveWriter/SFBayAreaConnectedSystems_D7A6/clip_image002%5B4%5D_thumb.jpg)
San Francisco Bay Area Connected Systems User Group
On June 26, 2008, please join us for the next scheduled Microsoft Bay Area Connected Systems Division User Group meeting. This month’s topic will be “Patterns for Delivering Enterprise Class Services”. If you would like to join us for this event, please click here to register!
Location:
Microsoft San Francisco Office
Golden Gate Conference Room
835 Market Street
7th Floor
San Francisco, CA 94103
Time: 6:30 PM to 8:30 PM
Food and Beverage will be served at 6:30 PM and session will start at 7:00 PM. Prizes will be raffled off at the end of the session.
Patterns for Delivering Enterprise-Class Services
Presenters: Brian Gaffney and Sandeep Kesiraju
- Planning to grow from the workgroup to the enterprise
- Ways to achieve the goals of staying agile and promoting reuse
- Scaling to new levels
This session will discuss the successful approaches for application delivery in an SOA enabled enterprise. We will cover lightweight approaches that can be undertaken by every developer and follow the discussion through each phase of the software development lifecycle. Special attention with a given to ways of improving the qualitative/non-functional characteristics of services – performance, security, scalability availability, reliability of services in the runtime environment. Points will be illustrated using technology demonstration and real life customer experiences.
Brian Gaffney is a Senior Systems Engineer for AmberPoint. He has been designing and delivering SOA systems for various clients in the commercial and federal marketplace for the past six years. In addition he recently lead the development of the AmberPoint’s monitoring and management solution for BizTalk as part of the ESB Guidance.
Sandeep Kesiraju is a Premier Field Engineer from Microsoft. He has been architecting, designing and developing solutions using BizTalk Server for five years. He was also involved in the development of ESB Guidance Package for BizTalk Server with the Microsoft Patterns and Practices Team.
The Microsoft Bay Area Connected Systems Division User Group is dedicated to helping the Bay Area customers design, develop, deploy, and administrate SOA solutions on Microsoft BizTalk Server technologies. If you would like to join the Bay Area Connected Systems Division User Group, please click here to be added to the mailing list!
Recently I was working with a customer and giving a quick overview of how to retrieve data from SQL Server within BizTalk. We had a stored procedure that would return the first "unfetched" row, lock the record, set the "fetchstatus" and return the data "for xml auto, elements". Simple enough, right?
Turns out, the data we cared about in SQL was already stored as a string of XML. My theory is that since the .NET (non-BizTalk) developer knew the data was going into BizTalk, someone said "hey, let's put the data in as XML since BizTalk uses XML." Again, just my theory. While this may sound nice, it actually makes our job a bit more complicated, because when you serialize XML to XML again, SQL will escape the XML string so it won't "break" the XML schema.
For example, the string <element> becomes >element<.
I think the real solution to this problem would be to re-evaluate the architectural decision to put the data into a column as an XML string, and instead alter the table to have the columns of data we care about, but we had less than a day to get an internal demo going and it would take too long to change this.
So, what do we do to make this work "for now?"
First, retrieve the data just like we would normally. Within our orchestration we now have our SQL message that looks something like this (generated via "Add Generated Items" in our BizTalk project):
...where MyString is the XML data we care about. Good 'nuff. But since we know this string of XML is actually a message we'll want to use, we'll also need to manually create a schema to match what will be coming out of SQL (so let's hope this data is consistent). In this example, let's say our XmlString looks like this:
<XmlTest><Field1><Field2></XmlTest>
...or rather...
<XmlTest><Field1><Field2></XmlTest>
Then we need to create a schema to match:
So what now? When we receive this message (let's call it msgSQLData) into our orchestration, we'll extract our XML string and store it in a string variable (strXml):
strXml = xpath(msgSqlEvent, "string(/*[local-name()='SqlResponse' and namespace-uri()='http://Romp.Demo.SqlXmlStrings.BizTalk.Schemas']/*[local-name()='MyFetchTable' and namespace-uri()='http://Romp.Demo.SqlXmlStrings.BizTalk.Schemas'][1]/*[local-name()='MyString' and namespace-uri()='http://Romp.Demo.SqlXmlStrings.BizTalk.Schemas'][1])");
Please also note that in this xpath statement, we use the xpath string() function.
Now we have a string of encoded XML data in our orchestration. Now what? We need to add our XmlTest message (above) to the orchestration (let's call it msgXmlTest). In a message assignment shape (inside of a construct block for msgXmlTest, of course), I'm going to call a helper function that will need to do two things:
- Convert our escape characters to valid XML characters; and
- Insert a namespace.
It will return this as an XmlDocument type, which BizTalk converts to an XLANGMessage type on the fly inside of the orchestration, so we don't need to worry about it.
msgXmlTest = Romp.Demo.SqlXmlStrings.Helper.XmlStrings.GetMessageFromXmlString(strXml, "http://Romp.Demo.SqlXmlStrings.BizTalk.Schemas");
Here's the code for our helper class:
public static XmlDocument GetMessageFromXmlString(string XmlString, string Namespace)
{
XmlDocument doc = new XmlDocument();
XmlString = DecodeXmlString(XmlString);
XmlString = InsertNamespaceString(XmlString, Namespace);
doc.LoadXml(XmlString);
return doc;
}
private static string DecodeXmlString(string XmlString)
{
XmlString = XmlString.Replace("<", "<");
XmlString = XmlString.Replace(">", ">");
XmlString = XmlString.Replace(""", "\"");
XmlString = XmlString.Replace("'", "\'");
XmlString = XmlString.Replace("&", "&");
return XmlString;
}
private static string InsertNamespaceString(string XmlString, string Namespace)
{
return InsertNamespaceString(XmlString, Namespace, String.Empty);
}
private static string InsertNamespaceString(string XmlString, string Namespace, string NSPrefix)
{
int iLoc = XmlString.IndexOf(">");
string strNamespace = String.Empty;
if (NSPrefix.Trim() == String.Empty)
strNamespace = String.Format(" xmlns=\"{0}\"", Namespace);
else
strNamespace = String.Format(" xmlns:{0}=\"{1}\"", NSPrefix, Namespace);
XmlString = XmlString.Insert(iLoc, strNamespace);
return XmlString;
}
Here's a simplified example of what this would look like in an orchestration:
We now have a message containing the data from the string of XML we got from the SQL database. From this point whatever you want to do with that message is up to you.
In summary, we're going from this:
To this:
Since this is viewed in Internet Explorer, the <XmlTest> is converted to <XmlTest> for display. Here's the source:
And finally, to this:
If we wanted to do this same thing without orchestration (a good idea unless you need to do something requiring orchestration), we would use a custom pipeline component to convert the string of XML the same way, and put the "new" message on the wire for submission to the MessageBox.
Sample code:
A number of you (my customers) have asked about the support of BizTalk Server 2006 R2 and the 2008 wave of products (Windows Server, SQL Server, Visual Studio). Most of us expected a service pack release of some sort to update BizTalk to support these platforms; however, it looks like the work involved was substantial and as a result, Steven Martin has announced BizTalk Server 2006 R3 to support these platforms as well as a number of new features. We should see a CTP sometime later this year, with the release taking place in the first half of 2009.
Some of the new features in R3:
- Support for Windows Server 2008, SQL Server 2008, and Visual Studio 2008
- New web service registry capabilities with support for UDDI (Universal Description Discovery and Integration) version 3.0
- Enhanced service enablement of applications (through new and enhanced adapters for LOB applications, databases, and legacy/host systems)
- Enhanced service enablement of “edge” devices through BizTalk RFID Mobile
- Enhanced interoperability and connectivity support for B2B protocols (like SWIFT, EDI, etc)
- SOA patterns and best practices guidance to assist our customer’s implementations
For customers who purchased BizTalk Server 2006 R2 under SA or EA, you'll get the upgrade free of charge.
The question has come up more than a couple of times: How do I monitor my Send Ports or Receive Locations if I don't have MOM (or monitoring solution of your choice) configured for my BizTalk servers? I've always been positive the answer was in WMI, so I finally decided to see if I could write a very basic port monitor for BizTalk.
First, I needed to build the WMI queries, using the WqlEventQuery class. Most of the WMI-specific classes mentioned here are in the System.Management namespace. Full source code is available at the end of the article.
WqlEventQuery wqlSendPortEventQuery = new WqlEventQuery(
"__InstanceModificationEvent",
new TimeSpan(0, 0, 10), // poll every 10 sec
"TargetInstance isa \"MSBTS_SendPort\"");
WqlEventQuery wqlReceiveLocationEventQUery = new WqlEventQuery(
"__InstanceModificationEvent",
new TimeSpan(0, 0, 10),
"TargetInstance isa \"MSBTS_ReceiveLocation\"");
Next I had to configure a ManagementEventWatcher for Send Ports and Receive Locations:
ManagementEventWatcher wmiSendPortEvents = new ManagementEventWatcher(
new ManagementScope(@"\\.\root\MicrosoftBizTalkServer"),
wqlSendPortEventQuery);
ManagementEventWatcher wmiReceiveLocationEvents = new ManagementEventWatcher(
new ManagementScope(@"\\.\root\MicrosoftBizTalkServer"),
wqlReceiveLocationEventQuery);
Then an event handler for each watcher:
wmiReceiveLocationEvents.EventArrived +=
new EventArrivedEventHandler(WmiEventReceived);
wmiSendPortEvents.EventArrived +=
new EventArrivedEventHandler(WmiEventReceived);
Finally, I fire them up:
Console.WriteLine("Starting event watchers...");
wmiReceiveLocationEvents.Start();
wmiSendPortEvents.Start();
Console.WriteLine("Event watchers started. Press ENTER to exit...\r\n");
The event handler itself is where things got somewhat complicated, because the event itself doesn't contain the BizTalk-specific properties I'm interested in. So I had to dig a little. In this case, we're only interested in the TargetInstance:
static void WmiEventReceived(object sender, EventArrivedEventArgs e)
{
ManagementBaseObject evt = e.NewEvent;
PropertyDataCollection col = evt.Properties;
PropertyDataCollection.PropertyDataEnumerator en = col.GetEnumerator();
while (en.MoveNext())
{
PropertyData data = en.Current;
// Grab TargetInstance only (could use PreviousInstance to get prior state data) :
if(data.Value != null && data.Name == "TargetInstance")
{
ManagementBaseObject mbo = (ManagementBaseObject)data.Value;
if (mbo.ClassPath.ClassName == "MSBTS_SendPort") // Send port event
{
ROOT.MICROSOFTBIZTALKSERVER.SendPort.ManagementSystemProperties prop = new SendPort.ManagementSystemProperties(mbo);
int iSendPortStatus = Convert.ToInt32(mbo.Properties["Status"].Value.ToString());
Console.WriteLine("Server: {0}", prop.SERVER);
Console.WriteLine("Send Port Name: {0}", mbo.Properties["Name"].Value.ToString());
Console.WriteLine("Send Port Status: {0}", GetSendPortStatusString(iSendPortStatus));
}
else if (mbo.ClassPath.ClassName == "MSBTS_ReceiveLocation") // Receive location event
{
ROOT.MICROSOFTBIZTALKSERVER.ReceiveLocation.ManagementSystemProperties prop = new ReceiveLocation.ManagementSystemProperties(mbo);
bool isDisabled = true;
bool.TryParse(mbo.Properties["IsDisabled"].Value.ToString(), out isDisabled);
Console.WriteLine("Server: {0}", prop.SERVER);
Console.WriteLine("Receive Location Name: {0}", mbo.Properties["Name"].Value.ToString());
Console.WriteLine("Receive Port Name: {0}", mbo.Properties["ReceivePortName"].Value.ToString());
Console.WriteLine("Receive Location Status: {0}", GetReceiveLocationStatusString(isDisabled));
}
}
}
Console.WriteLine("");
}
In case you're wondering, the ROOT.MICROSOFTBIZTALKSERVER classes are generated from the Management Classes in the Visual Studio Server Explorer. See this article for more details.
So, how does it look?
So from here you can do anything with these events that you'd like. I supposed you could even have the event handler generate a message that you send to BizTalk... as long as the port doesn't go down. =)
Source code:
Technorati Tags:
BizTalk,
WMI
God help you if you rely on my blog as your only source of BizTalk information. =) I'm a bit behind, but here's something everyone should know about: The BizTalk Server Operations Guide. Check it out.
The idea for the guide originated with Microsoft field representatives, partner organizations, and customers who plan, deploy, and maintain BizTalk Server installations. This group of IT professionals has accumulated extensive hands-on experience with a diverse range of BizTalk solutions. As they gained experience they created checklists, best practices, and presentations to guide future BizTalk Server operations. We collected and organized this information to create the guide.
I've heard about the possibility of another BizTalk TS position (my job) opening in SoCal sometime in the next few months. Got BizTalk skills? Email me: chris.romp [at] microsoft.com.
A customer and former coworker of mine recently sent me a link to this blog post, whose author asks the question "When to use BizTalk vs. roll your own solution." Good question!
BizTalk Server allows developers to quickly develop loosely-coupled, services-oriented applications for connecting multiple desperate systems in a highly-available, highly-scalable way. Can you do everything BizTalk Server does with just writing .NET code? Sure... BizTalk is written on .NET (2.5 million lines of code), and you could develop a similar solution I'm sure with millions of dollars and a large, experienced team of developers.
BizTalk lends itself well to certain types of projects:
- Enterprise application integration (EAI)
- Legacy application integration
- Trading partner scenarios (B2B)
- Message brokering
- Business process management (BPM)
Let's look at an EAI example using BizTalk Server and custom .NET code. In this scenario, we have an ERP system which needs to send customer adds/updates/deletes to our CRM system. Let's assume we'll talk directly to the database for the ERP system -- say, if the customer table has a trigger which writes to an update table that we can poll via a SQL stored procedure -- and for the CRM system we'll send it information using a SOAP web service layer that the application exposes.
.NET way: We develop a windows service which will call the SQL stored procedure at a configurable interval. When we receive an updated record, we will take the columns from the data set and copy each element to its corresponding class item from the SOAP proxy class. Then we'll call the corresponding web service method and pass it the customer object.
BizTalk way: We'll create a receive port using the SQL adapter which will call the stored procedure at a configured interval. Upon receiving an update from the stored procedure, we'll map it in the port to our canonical format (not required but a good practice) and publish the customer record to the message box. Next we'll create a send port using the SOAP adapter pointing to our CRM web service. Within this send port we'll create a subscription to the customer messages and map it from our canonical format to the CRM type.
Scalability and High Availability
Both of these approaches are simple and fairly quick to develop, test, and deploy. Now let's mix it up. After running successfully in production for a couple of months, we're told by the business department that they expect the transaction volume to increase 10-fold. Since we didn't have this requirement up front, there's a very good chance that you'll have to rearchitect your .NET service to ensure it's multi-threaded and able to handle the increased load.
Now a requirement comes down from on high that our application needs to be made highly-available, i.e. we need to enable the service to run on multiple systems in case one of them fails. Back to the drawing board for many .NET applications. With BizTalk Server, we just add another server to the group, and ensure our SQL message box is highly-available, probably using an active/passive cluster.
Business Activity Monitoring
Next comes a requirement for instrumentation of the application, and the statistics should be made available on the company's SharePoint portal. With BizTalk, we don't need to touch the code in production; we simply create a BAM observation model, deploy that model, and apply a tracking profile to the BizTalk service. The BAM data can be viewed using an out-of-the-box portal component which can be dropped into the SharePoint page. There are a number of ways to do the same thing using .NET of course, but needless to say you'll need to create a data repository, and open up your service code to drop data into the repository at set milestones during the process. Should the observation model ever change, you'll be reopening your code to make the changes yet again, unlike with BAM.
Loose Coupling
Finally, a year later your company is going to deploy a customer portal which is hosted offsite and uses its own data repository for customer data, and will need to receive the updates from the ERP system as well. With .NET, you'll likely end up writing a new service for the 1:1 integration. With BizTalk, we just add another send port and have it subscribe to the customer messages already being published by the ERP system.
In this example, I've admittedly oversimplified, but I think the points are valid. Also, I've completely ignored one of BizTalk's biggest advantages in this space: its adapters. There are a huge number of adapters for BizTalk to connect to line-of-business systems. If our ERP or CRM systems have a BizTalk adapter available, we have to do very little custom development to talk to these LOB apps. With .NET, there may be an API available, but you'll be doing a lot of manual development.
Not For Everything / Future Direction
BizTalk Server is not for everything, but what it does, it does very well and at a fraction of the cost of competitors in this space. In the future, I see BizTalk becoming more of a generic application platform. Say, for example, you develop an application using WCF and WF, and then you need to scale these apps out or apply any of the scenarios outlined above. I would expect future versions of BizTalk to be WCF and WF-based, and you should be able to take your WCF/WF applications and host them inside of BizTalk Server. Pretty cool, I think.
To all three of you who read this blog (hi, mom!), if you're in the Los Angeles area tomorrow night Brian Loesgen of Neudesic and I will be presenting on BizTalk Development Best Practices at the Los Angeles Connected Systems User Group. This is a pretty good session that Brian and I have done a couple of times, and it's got some good information if you're brand new to BizTalk or even a seasoned developer!
I also hear one of our newest BizTalk MVP's, Richard Seroter, will be joining us as well.
(Oh, and please register if you plan to attend, so they can buy enough pizza.)
Meeting Location:
QuickStart – Los Angeles
1515 West 190th Street
South Tower - Suite 450
Gardena, CA 90248
A new BizTalk poster is available, in case you're collecting the series. [via]
This one covers BizTalk Scale-Out Configurations, from simply adding servers to your BizTalk group to fully clustering your MessageBox database on a SQL cluster. Scaling out BizTalk is a good idea for any solution which requires high availability.
One of the scenarios displays an active/passive BizTalk clustered host, which is typically only necessary if you have an adapter which doesn't run well in a group (i.e. FTP adapter -- no file locking in FTP). Most of the time I'd argue it's better to have your BizTalk servers in the same group without clustering.
Clustering SQL as active/passive, however, is almost always a good idea. Active/active I'm not such a fan of, because in a high-utilization scenario it's difficult to know if one of the clustered services could handle the load that's usually shared between two. If you like active/active, you should consider active/active/passive, which is also outlined on this poster.
When scaling out your MessageBox database, it's important to remember that you'll be going from one to three or more. The reason is that your master MessageBox database will be used for routing and subscription only, while the other (two or more) MessageBox databases will be doing the processing.
BizTalk Hotrod just published a third volume. This one has fixed a lot of the readability problems with past issues (good luck reading sample code in volumes 1 and 2). =)
Grab it from BizTalkHotrod.com or you can grab the 18MB PDF from this direct link.
