SSO Config Data Store Tool, BizTalk/WCF Scenario Source Code Available

I’ve finally gotten around to publishing my source code for my SSO Configuration Data Store Tool.  You can download both the runtime application and underlying source code from here.  If you want to mess around with it, great, but please keep my name on there.

Although I’m not finished with my “BizTalk + WCF” series for TopXML.com yet, I have finished the first part of the series on consuming WCF services.  So, I’ve put the source code I used for all those demonstrations right here.  The binding file is in there as well.  Once I finish the last part of the series, I’ll post that source code too.

Enjoy.

Technorati Tags: BizTalk, WCF

You’ve Just Bought BizTalk Server. Congrats. Now What?

It’s just over a year ago that my company switched from their previous EAI platform to BizTalk Server 2006.  Over that time, we’ve learned some best practices for setting up a brand new BizTalk program, and I thought I’d share my “Top 10″ recommendations for organizations getting started with BizTalk.   The below recommendations aren’t in any particular priority-based ordering …

1. The first project should be a quick win.  I’m sure that BizTalk Server was brought into your organization with a particular project in mind.  However, unless you have all the resources lined up to help with a complex project (see tips #2 and #3), I suggest identifying a “quick win” project that can be built with relative ease and minimal complexity in a short amount of time.  This helps establish the platform within the organization and builds confidence among the team.  If you bite off a monster project right off the bat, you greatly increase the risk of failure or disenchantment with your purchase.
2. Get an expert.  If your plan for getting BizTalk Server up and running is to hand a BizTalk Server 2006 book to your best developer and saying “read this over the weekend and be ready to lead a project on Monday”, you’re hosed.  You really need to hire (a) a full-time employee or (b) consultant to help you get the platform established in your company.   Why?  Integration solutions are a different beast than standard custom applications that developers are familiar with building.  There are different paradigms, patterns and gotchas that only an expert can help with.  Now, the tricky part is, there aren’t a lot of experts out there.  In my experience, significantly less than 50% of all folks who put “BizTalk” on their resume are qualified to lead your team.  I suggest seeking a BizTalk expert in your area to help with interviews.  Ping your local Microsoft specialist, or reach out to an MVP.  You want the best person possible brought onboard, and you should be confident that you’re getting someone who knows what they are doing.
3. Invest in training and building a “Center of Excellence.”  Now, a “Center of Excellence” for BizTalk may mean 20 people, or 2 people.  Either way, you want a team of people who are well trained in BizTalk and can provide advice on upcoming projects.   My first year here, I taught 8 BizTalk classes to 100+ folks, and now I can have intelligent conversations about BizTalk with project managers, business analysts, developers, architects and system administrators.  An in-house team of dedicated resources (i.e. not weekend BizTalk warriors) that can evangelize the product and guide your success is critical to stabilizing your platform.
4. Commit to, and enforce naming standards.  This is so important.  As the amount of deployed projects increase, the more critical it is that all developers and administrators use common names for artifacts and configuration items.  Any developer should be able to pick up any other developer’s BizTalk solution and be able to troubleshoot it without the aid of the Rosetta Stone.  It’s just as easy to type a good artifact name as a bad one.  Your “Center of Excellence” leaders should have the authority to halt the deployment of a project if the naming standards have been ignored.
5. Agree upon code review items and processes.  Before any project is deployed, you should require that a full BizTalk code review is executed.  Even the smartest developer benefits by having a second (or third/fourth/fifth) set of eyes on their solution.  Maybe they missed a pattern, or built something that won’t scale.  A good code review will catch that.  I posted our code review guidelines on my blog last year.
6. Set up a standard release management plan.  Let’s assume you have a BizTalk development, test and production environment.  You want clear guidelines as to how artifacts move between each set of servers.  Who does installations?  Where do we drop the installation packages?  How are differences between environments (passwords, server names) managed?  A new build of a deployed solution should have a very clear path to production that any administrator can execute.
7. Identify your disaster recovery / archive  / purge strategy.  Don’t wait until after projects get deployed to commit to platform maintenance.  Your disaster recovery plan needs to be set up right after BizTalk Server is first installed.  Are you using log shipping?  Or doing a more local backup and restore?  What is your Recovery Point Objective (RPO)?  No more than 15 minutes of data lost?  The archiving/purging jobs on the BizTalk tracking database are NOT enabled by default.  You need to consider how long to keep tracking data and get those jobs enabled before projects get deployed.  Otherwise, you end up with an increasingly slower system.
8. Define source code and server access control.  Put BizTalk artifacts in source control.  You don’t want critical project source control sitting in a zip file on a shared drive.  Figure out who needs access to BizTalk source control (which may contain bindings with passwords) and lock that group down.  Also, determine a process for adding folks to the production “BizTalk Operators” group.  At my company, we committed to distributed ownership where a central group “owns” the platform, but, divisions with BizTalk projects are set up as “Operators” and can perform basic maintenance on their own appliations.  This way, the central group only deals with critical issues, while local divisions can resume suspended messages, or turn off their ports for maintenance.
9. Establish error reporting and monitoring solutions.  My company uses Microsoft MOM for BizTalk monitoring.  If you don’t have MOM in house, then use whatever is available, but use SOMETHING.  You don’t want to find out that a particular host has been offline for 2 weeks because no one was alerted that a problem occurred.  Also, consider establishing a standard “error logging” framework for your developers.  Do you write to the Event Log with a specific string pattern?  How about a database logging system using something like Log4Net?  If you don’t do this, I’ll guarantee that you’ll end up with countless different ways that each deployed solution records their issues.
10. Stay actively in tune to hotfixes and upcoming releases.  Microsoft regularly releases hotfixes for BizTalk, and many of them address important areas.  We’ve found a number of hotfixes that solve development or environmental issues that we had been banging our heads against for days.  If web searches for your problems don’t turn up valid results, consider browsing the Microsoft BizTalk Solution Center.  Also, keep an eye on product announcements, toolkits or whitepapers that may help your team continue increase their efficiencies with the product.

So there you go.  My company learned some of those lessons above the hard way, so hopefully I can save someone else a little heartache.

For those of you who have helped establish BizTalk for your own company (or as a consultant), are there other recommendations you’d like to share?

 

Technorati Tags: BizTalk

New BizTalk Server 2006 Hotfixes

A few interesting Microsoft Knowledge Base hotfixes for BizTalk Server 2006 were recently added and worthy of sharing.

• FIX: The Log Shipping feature may not restore database backup files in BizTalk Server 2006.  Really?!?  Seems kinda important.  I love hotfix titles that are all nonchalant, but upon consideration, are pretty freaky. The article says that the only way Log Shipping can restore the databases is if there is already a complete set of backups, and, none of the backups are corrupt.  I can only assume (since it isn’t stated anywhere) that this hotfix allows Log Shipping to restore any available backups, even if some are missing or corrupt.
• FIX: A receive location that uses the file adapter does not retry when a network failure occurs in BizTalk Server 2006.  Apparently even if a receive location is set up to retry on network failure, that behavior isn’t consistent and the receive location may become instantly disabled.  Good times.
• FIX: The per-instance configuration setting does not affect message processing on a computer that is running BizTalk Server 2006.  If you have a request-response receive location, the per-instance pipeline settings on the send (response) pipeline aren’t applied, even though you can see the settings.
• Four properties have been added to the ErrorReport namespace context of BizTalk Server 2006 R2.  We’ll end on a positive note.  If you’d like a few new “ErrorReport” subscription values (ErrorReport.FailureTime, ErrorReport.FailureAdapter, ErrorReport.FailureMessageID, ErrorReport.FailureInstanceID), and are running BizTalk Server 2006 R2, this is the update for you.

 

Technorati Tags: BizTalk

Article Series on BizTalk and WCF: Part V, Publishing Operations Patterns

I just posted another article for TopXML.com as part of my series on BizTalk + WCF.   This post covers the various ways to expose WCF services and endpoints out of BizTalk itself.

Topics include: exposing one-way services, working with services exposed via schemas or orchestrations, handling exceptions, generating MEX endpoints, hosting the WS-Http adapter in-process, using simple type service parameters, and using multi-part messages.

Series Summary
BizTalk and WCF: Part I, Operation Patterns	Get the source code!
BizTalk and WCF: Part II, Security Patterns
BizTalk and WCF: Part III, Transaction Patterns
BizTalk and WCF: Part IV, Attachment Patterns
BizTalk and WCF: Part V, Publishing Operations Patterns	Get the source code!
BizTalk and WCF: Part VI, Publishing Advanced Service Patterns
BizTalk and WCF: Part VII, About the BizTalk Adapter Pack	Get the source code!
BizTalk and WCF: Part VIII, BizTalk Adapter Pack Service Model Patterns
BizTalk and WCF: Part IX, BizTalk Adapter Pack BizTalk Patterns

Technorati Tags: BizTalk, WCF

New Code Samples for WCF Adapter Pack

I’ll admit to being fairly underwhelmed with the sample bits for the BizTalk Server 2006 LOB adapters.  If was often trial and error to figure out how to get the Oracle adapter working right, or figuring out how to do something specific with the Siebel adapter.  Very few details or examples were provided.

That said, looks like the Connected Systems team is much more aggressively sharing information about the new [BizTalk] Adapter Pack.  I just noticed a cornucopia of new code samples for the WCF LOB Adapter Pack.    For each of the three available adapters (SAP, Oracle, Siebel),  you’ll find samples for using the adapter with BizTalk, and, as a standalone WCF LOB adapter.  The Oracle adapter has lots of examples that will prove useful (invoking functions, using cursors, executing select queries, etc).  I also like that each adapter has a brief example of how to convert from using the BizTalk LOB adapters to the new Adapter Pack.

As part of my “BizTalk + WCF” series for TopXML.com, I’ll be demonstrating a few scenarios with the new Oracle adapter.  These samples mean that I’ll spend less time punching myself in the head and more time building useful demonstrations.

Well done Microsoft.

 

Technorati Tags: BizTalk, WCF

Article Series on BizTalk and WCF: Part IV, Attachment Patterns

I just posted the latest in my series of articles for TopXML.com on BizTalk Server 2006 R2 integration with WCF.  The topic this time is SOAP attachments. I cover what MTOM is, and how BizTalk can consume and process binary data from SOAP attachments.

This concludes the “consuming WCF services” part of the show.  Stay tuned next for the “exposing WCF services” articles.

Series Summary
BizTalk and WCF: Part I, Operation Patterns	Get the source code!
BizTalk and WCF: Part II, Security Patterns
BizTalk and WCF: Part III, Transaction Patterns
BizTalk and WCF: Part IV, Attachment Patterns
BizTalk and WCF: Part V, Publishing Operations Patterns	Get the source code!
BizTalk and WCF: Part VI, Publishing Advanced Service Patterns
BizTalk and WCF: Part VII, About the BizTalk Adapter Pack	Get the source code!
BizTalk and WCF: Part VIII, BizTalk Adapter Pack Service Model Patterns
BizTalk and WCF: Part IX, BizTalk Adapter Pack BizTalk Patterns

Technorati Tags: BizTalk, WCF

Article Series on BizTalk and WCF: Part III, Transaction Patterns

I just posted my third article in a series about BizTalk Server 2006 R2 integration with Windows Communication Foundation.  The topic of this piece is Transactions and how to create and consume WCF services using the WS-AtomicTransaction specification.  Transactions are sometimes a tricky thing to grasp, so I included a brief (but hopefully understandable) explanation of the key WCF transaction concepts.  Then I showed how to use BizTalk to flow transactions to services.  A few gotchas arose, which simply demonstrates that while BizTalk Server 2006 R2 is a move forward, it’s still relatively immature with regards to .NET 3.0+ integration. 

As always, if you have any questions or comments on the article, let me know.

Series Summary
BizTalk and WCF: Part I, Operation Patterns	Get the source code!
BizTalk and WCF: Part II, Security Patterns
BizTalk and WCF: Part III, Transaction Patterns
BizTalk and WCF: Part IV, Attachment Patterns
BizTalk and WCF: Part V, Publishing Operations Patterns	Get the source code!
BizTalk and WCF: Part VI, Publishing Advanced Service Patterns
BizTalk and WCF: Part VII, About the BizTalk Adapter Pack	Get the source code!
BizTalk and WCF: Part VIII, BizTalk Adapter Pack Service Model Patterns
BizTalk and WCF: Part IX, BizTalk Adapter Pack BizTalk Patterns

Technorati Tags: BizTalk, WCF

Los Angeles Connected Systems User Group Meeting 2/7/07

If you’re in the Los Angeles area, consider joining me at tomorrow’s Connected Systems User Group meeting.  The topic is “BizTalk Development Best Practices” and the fearless speakers are Chris Romp from Microsoft and that character Brian Loesgen from Neudesic.  Should be fun.

Technorati Tags: BizTalk

Article Series on BizTalk WCF: Part II, Security Patterns

My second article on integrating Windows Communication Foundation with BizTalk Server is now online.  The one deals with all the various WCF security configurations and how BizTalk consumes each one.

Specifically, I address message vs. transport security, certificates, username tokens and declarative code-based security.  It was pleasing to see how gracefully BizTalk accommodated each security permutation I threw at it.

Series Summary
BizTalk and WCF: Part I, Operation Patterns	Get the source code!
BizTalk and WCF: Part II, Security Patterns
BizTalk and WCF: Part III, Transaction Patterns
BizTalk and WCF: Part IV, Attachment Patterns
BizTalk and WCF: Part V, Publishing Operations Patterns	Get the source code!
BizTalk and WCF: Part VI, Publishing Advanced Service Patterns
BizTalk and WCF: Part VII, About the BizTalk Adapter Pack	Get the source code!
BizTalk and WCF: Part VIII, BizTalk Adapter Pack Service Model Patterns
BizTalk and WCF: Part IX, BizTalk Adapter Pack BizTalk Patterns

Technorati Tags: BizTalk, WCF