Archive for the ‘BizTalk’ Category

My Take on BizTalk 360

June 24, 2011 1 comment

Just reading Randal’s post on BizTalk 360.

I have to say it looks like it preserves all the BizTalk terminology and is almost a 1-for-1 wrapper around BizTalk Administrator Console.

What we really need is a tool that surfaces real problems for the business.  Users want to know if a file or message was successfully processed.  What’s the history of those loads?  Which failed and when and why?  This is what a real dashboard for BizTalk should bring to the fore.



Categories: BizTalk Tags: ,

BizTalk Server Tuning Tips

May 22, 2011 Leave a comment

Here are a number of things to pay attention to in order to get the most out of your BizTalk system (many of these are for SQL Server in general):

  • Place data and log files on separate disks
  • Create one tempdb data file per CPU (including cores); ensure each is exactly the same size; do not exceed 8 (see Optimizing tempdb Performance for more details)
  • Use dedicated SQL Servers
  • Be careful of constant database auto-growth – set to sensible values
  • Ensure all databases are getting backed up (which reduces transaction log size) – use the generated SQL Agent job to backup the BizTalk databases – it’s the only supported means of BizTalk database backups
  • Ensure all BizTalk Agent jobs are running successfully (there is one that runs in a loop and never terminates so be aware of that) (and another does backups so if doing your own, skip that one)
  • Microsoft does not want you changing any of their customized settings on the databases made during the BizTalk install – this includes any schema changes to the MsgBox database including indexes (See What you can and can’t do with the MsgBox database)
  • Separate the MsgBox and Tracking database and log files onto separate disks (so 4 disks – so I hope you’re reading this before you’ve committed to your kit!)
  • Change the DTA Purge and Archive job to just purge if you don’t need archiving (see documentation below)
  • Place sending, receiving, processing (i.e. orchestrations), and tracking into separate BizTalk hosts (so 4 are needed at a minimum) (and note again, a separate host for tracking)
  • If on a 32-bit system and getting out of memory (host restarted) error messages, try the /3GB OS startup switch – this gives each host 3GB instead of 2 (I’ve used it with great success)

Finally a couple of great resources to check out.

First I highly recommend the BizTalk Server Operations Guide (from which many of the above suggestions were derived).  It’s chock full of goodness.  There’s one for each version but the 2010 may be sufficient:

Also an absolutely fantastic tool to perform an automatic check of the health and configuration of your system and provide tuning tips is MsgBoxViewer.  I think it’s completely misnamed as it does a lot more than just look at the MsgBox database.


Continuous Integration, without exception!

May 19, 2011 Leave a comment

I am a firm believer in Continuous Integration.  And by that I mean every Solution/Project should be built continually on a build server, automatically – without exception.  In the old days I remember having to step into maintenance on a project new to me, only to find the version of the app in source code control would not compile.  How frustrating, and time-consuming.  Thanks to continuous integration, those days are gone!

If it’s the first time you’re doing this, obviously it will require an investment of time.  You need to set up a build server (VM is perfect), install build tools on it, and then create scripts/catalogue your projects.  Once you’ve crossed this hurdle, adding in new projects as you go along is a piece of cake.  It’s a habit worth forming.  Your dev team will thank you for the automatic emails indicating what source was changed, by whom, and if the build succeeded or failed.  The immediacy of this notification means the dev who made the change can quickly make the correction as the subject is fresh in her mind.

Compiling code is just the first step.  You can automatically do a bunch of other things:

  • Build your database from scratch using the source files for each object (e.g. tables, indexes, stored procedures); The database features in Visual Studio are great for this.
  • Run tests including unit tests and integration tests
  • Deploy binaries / runtime to a test area

I hope to blog on all those points in later posts.  For an example of just how much you can do in a script run continuously, see this great blog post on Automated Testing with BizTalk Server. The point is you can and should do the entire enchilada if not on every build, at least daily.  It’s a mundane and repeatable task so why not let the machine do it for you?  It’s all about quality and agility.  We’re having to code changes at warp speed, and this will help maintain our professionalism.

So please take my advice and invest the time to set up an automatic build using your favourite tool (TFS, CruiseControl.NET, etc.).


Categories: Agile, BizTalk Tags: , , , ,