During the Bouvet BizTalk Innovation Event, 26/27 September 2012 in Stavanger, Norway, there were 2 presentations about BizTalk360. One was held by Saravana Kumar, the founder of BizTalk360, and I did another presentation about this product. Where Saravana showed many functionalities, including the new V5 functionalities, from BizTalk360 from a Product perspective, I wanted it to turn around and have a look at BizTalk360 from a Customer perspective. Therefore I talked about some Real World scenarios with BizTalk360.
In addition to my presentation I wrote an article on this topic and extended it with describing the most important functionalities in V5, which was released recently.
In the article I explain why having a Shared Infrastructure, like BizTalk, makes monitoring more complex. I also describe how BizTalk360 reduces the number of consoles you need to monitor a BizTalk environment.
To expand the visibility from BizTalk360, I posted the article on CodeProject. You can find it here:
http://www.codeproject.com/Articles/474905/Using-BizTalk360
More information about BizTalk360, can be found here:
http://www.biztalk360.com
Tag Cloud
Archive
Most popular articles of all time
Lex Hegt
Lex Hegt currently works as a BizTalk architect/administrator at Ordina. Although he works in the Information Technology for more than 25 years, he 'only' works with BizTalk for 8 years. His first BizTalk assignments were as a developer, but since a couple of years he works as an administrator.
Besides this blog he also blogs for many years at the BIA blog and does he maintain some tools, namely BizTalk Processing Monitor and BTSDecompress. He has certifications for BizTalk Server 2006, BizTalk Server 2006 R2 and BizTalk Server 2010.
Real World scenarios with BizTalk360
Review BizTalk Server 2010 Cookbook
In April 2012 this book came available through publisher Packt Publishing. This cookbook was written by BizTalk MVP Steef-Jan Wiggers with assistance of fellow BizTalk MVP Randal van Splunteren. In this article I’ll review this book and describe who should buy this book and why.
Forcing a Full BizTalk Backup
BizTalk uses multiple databases. Think about the Configuration database (BizTalkMgmtDb), the MessageBox database (BizTalkMsgboxDb), the Tracking database (BizTalkDTADb) etc. etc. Beside these databases, your system might also have its own ‘custom’ database(s). Together these databases define the state of your application or system.
All these databases should be backed up by the Backup BizTalk Server job on SQL Server. This job makes both Full and Log backups. Normally a Full backup is made every 24 hours and a Log backup every 15 minutes.
In this article I’ll describe how you can force the Backup job to make a Full backup, which might be handy when you are preparing an upgrade of your application or system. Further I’ll describe how you can monitor the progress of the Backup job and how you can see where the backups are written to.
Checklist BizTalk Application Migration
This article describes the steps which must be taken to perform a migration of a BizTalk application. Since each migration has its own specific matters, the attached document can be used as a template and can be modified for each specific migration.
TechNet contributions of our authors
Most of the authors at BizTalkAdminsBlogging.com also contribute at TechNet. Besides editing existing Wiki articles and helping users at the TechNet Forums, they also write new Wiki articles and add new scripts to the TechNet Galleries. This article provides a small overview of the contributions made by our authors.
Clean up the MarkLog table with Terminator
The Backup BizTalk Server job uses the MarkLog table to write marks. These marks are actually timestamps which are used by the job to determine until what time a (Log) backup must be made. Unfortunately BizTalk has no out-of-the-box possibilities to clean up that table.
Luckily Microsoft provides Terminator to clean up this table and do a lot of other things. In this article I’ll describe the capabilities from Terminator in short and more detailed on how you should use it to clean up the MarkLog table.
Backup BizTalk: Don't make ordinary Full backups
Off course you make backups of your BizTalk databases! You have set the Recovery Model from the databases to Full and every single day your Maintenance Plans or (actually) the SQL Server Agent jobs make Full and Log backups. So in case you need to restore your BizTalk databases, you are safe... Well, I've got some news for you... You're not so safe...
If you make BizTalk Backups like described above, you could be in deep trouble in case you need to restore. When it comes to making backups from your BizTalk databases, Microsoft supports only one way. I'll describe this way, and some insides about it, in this article.
C# solution to decompress BizTalk messages and their context
As most of you will know BizTalk messages and context are stored in the MessageBox and the Tracking database as Image types. By several people a number of posts have been written about decompressing BizTalk messages and their context and here's another one!
When we had an incident with quite some suspended (not resumable) instances, we needed to retrieve message content and context. This information should be used to take appropriate actions for damage elimination.
After a search I found this great article from Thiago Almeida. It even contains a sample solution! Good news though for an intermediate developer as me!
I've been working on the solution and made it use just the SQL method. My goal was to create functions in C#, that would decompress the fields that contains the message and the context and enable the user to use these functions in SQL queries they entered in a textbox.
How to back up your system databases
Besides your BizTalk databases your SQL Servers also have the following system databases:
- master - contains all system-level information for a SQL Server system
- model - template for creating new databases
- msdb - used by SQL Server Agent for scheduling alerts and jobs
- tempdb - used for amongst others temporary user objects
Since most of these databases are relatively static, they don't need to be in the Backup BizTalk Server job, but they do need to be in a backup. Such a backup can be made with a Maintenance plan. In this article I show you how to create such a Maintenance Plan in the most easiest way, with the Maintenance Plan Wizard.
Identifying BizTalk databases
Everybody who loves BizTalk and programming might fire SQL queries at the BizTalk databases. Of course you know that you should be extremely carefull when doing this.
Besides giving some tips on do and dont's with the BizTalk databases, I'll show you how BizTalk databases can be identified.
