Archive for the 'BizTalk 2009' Category

Fast, Efficient Message Archiving for BizTalk with the BizTalk Message Archiving Pipeline Component. Download a Free 14-Day Trial!

Including Custom Databases in the Backup BizTalk Server Job

I’m sure its common knowledge that other databases can be backed-up using the Backup BizTalk Server Job, meaning that the transaction consistency that is that is written the the BizTalk databases can be included in your own custom databases.

I thought it was pretty easy to include custom databases, simply by adding an entry into the adm_OtherBackupDatabases table in the BizTalkMgmtDb database. In the screenshot below, I’ve added the BizTalk RosettaNet Accelerator (BTARN) databases:

I thought it was that simple, until I tried it for the first time in real life and was greeted with the following error from SQL Agent (notice the error in bold):

Executed as user: NT AUTHORITY\SYSTEM. Processed 17520 pages for database ‘BizTalkDTADb’, file ‘BizTalkDTADb’ on file 1. [SQLSTATE 01000] (Message 4035)  Processed 2 pages for database ‘BizTalkDTADb’, file ‘BizTalkDTADb_log’ on file 1. [SQLSTATE 01000] (Message 4035)  BACKUP DATABASE successfully processed 17522 pages in 10.454 seconds (13.093 MB/sec). [SQLSTATE 01000] (Message 3014)  Processed 2264 pages for database ‘BizTalkMgmtDb’, file ‘BizTalkMgmtDb’ on file 1. [SQLSTATE 01000] (Message 4035)  Processed 3 pages for database ‘BizTalkMgmtDb’, file ‘BizTalkMgmtDb_log’ on file 1. [SQLSTATE 01000] (Message 4035)  BACKUP DATABASE successfully processed 2267 pages in 2.284 seconds (7.751 MB/sec). [SQLSTATE 01000] (Message 3014)  Processed 3280 pages for database ‘BizTalkMsgBoxDb’, file ‘BizTalkMsgBoxDb’ on file 1. [SQLSTATE 01000] (Message 4035)  Processed 2 pages for database ‘BizTalkMsgBoxDb’, file ‘BizTalkMsgBoxDb_log’ on file 1. [SQLSTATE 01000] (Message 4035)  BACKUP DATABASE successfully processed 3282 pages in 2.156 seconds (11.890 MB/sec). [SQLSTATE 01000] (Message 3014)  Processed 256 pages for database ‘BizTalkRuleEngineDb’, file ‘BizTalkRuleEngineDb’ on file 1. [SQLSTATE 01000] (Message 4035)  Processed 1 pages for database ‘BizTalkRuleEngineDb’, file ‘BizTalkRuleEngineDb_log’ on file 1. [SQLSTATE 01000] (Message 4035) Could not find stored procedure ‘BTARNARCHIVE.dbo.sp_BackupBizTalkFull’. [SQLSTATE 42000] (Error 2812) BACKUP DATABASE successfully processed 257 pages in 0.326 seconds (6.158 MB/sec). [SQLSTATE 01000] (Error 3014).  The step failed.

‘Could not find stored procedure ‘BTARNARCHIVE.dbo.sp_BackupBizTalkFull’. Oh really?

It turns out that it isn’t as simple as adding a custom database to the adm_OtherBackupDatabases table – a number of stored procedures and tables also need to be added to your custom database to get the backup job to successfully work, however these can be easily added by executing the two SQL scripts Backup_Setup_All_Procs.sql and Backup_Setup_All_Tables.sql against your custom databases (the scripts can be found in the ‘[BizTalk Installation Directory]\Schema’ directory). You may want to force a full backup to ensure you have full backups across all of your databases:

BEGIN TRAN
UPDATE [BizTalkMgmtDb].[dbo].[adm_ForceFullBackup] SET ForceFull = 1
COMMIT TRAN

Re-run your backup job and you will see your custom databases included in the backup.

The requirement to include additional stored procedures and tables in custom databases is well worth remembering, especially if you are deploying (or re-deploying) custom databases that don’t include these artifacts by default.

The procedure is detailed in more depth on MSDN.

BTARN ‘Service Content’ Error in the RNDisAssembler Component

We came across the following error late last night which was a bit of a show-stopper. We were trying to load a custom PIP (specifically a PIDX OrderChange), but kept hitting this issue time and time again:

Event Type: Error
Event Source: BizTalk Accelerator for RosettaNet
Event Category: None
Event ID: 4096
Description:
Source module:
RNDisAssembler
Correlation information:
Description:
Receive pipeline rejected incoming message
due to the following RNIF exception:
UNP.SCON.VALERR : A failure occurred while validating the service content.
Details:
Event Type: ErrorEvent Source: BizTalk Accelerator for RosettaNetEvent Category: NoneEvent ID: 4096Date: 18/08/2010Time: 10:33:47User: N/AComputer: [COMPUTER NAME]Description:Source module:RNDisAssembler
Correlation information:

Description:

Receive pipeline rejected incoming message due to the following RNIF exception: UNP.SCON.VALERR : A failure occurred while validating the service content.
Details:

At first I didn’t quite understand the cause of the error – the PIDX OrderChange message contained within the Service Content was valid (as far as I was aware), all of the other messages within the payload looked correct and it was 3am….

It turns out that the RNDisassembler does in-fact attempt to validate the message contained within the Service Content against a deployed schema just like the standard XmlDisassembler. The message that our trading partner was sending did not validate and hence the RosettaNet Accelerator threw this error message; once we had corrected the schema and redeployed, the error went away.

This is certainly one to be aware of if you are developing custom PIP’s to use with the RosettaNet Accelerator: ensure that the message in the Service Content validates against your custom PIP schema!

SCOM can cause Unchecked Growth in SSODB

Ok, that’s a bit of an attention grabbing headline, so let me clarify that statement: SCOM can cause unchecked growth in SSODB if you’re not regularly backing up the SSODB transaction log.

We encountered this one today – a client’s SSODB ran out of space overnight, causing the BizTalk environment to shut-down. On further investigation, it would appear that every time SCOM checks the health of Enterprise Single Sign-On, an entry is recorded in the SSOX_AuditXpLookup table:

ESSO appears to be clever enough to manage the size of this table, truncating it every 30 minutes, however this doesn’t help if you’re not managing the size of the database transaction log through backups. To quote the SQL Server documentation:

If log records were never deleted from the transaction log, it would eventually fill all the disk space that is available to the physical log files. Log truncation automatically frees space in the logical log for reuse by the transaction log.

All the more reason to enable and run the supplied Backup BizTalk Server job to help maintain the health of your BizTalk environment.

If you’re looking for more information on the Backup BizTalk Server Job, take a look at my series of posts on the topic: http://www.modhul.com/2009/06/29/configuring-biztalk-for-disaster-recovery-part-1/

Hat-tip to this MSDN Forums posting that helped us identify the issue.

Team Explorer 2010 ‘narks’ Enterprise Single Sign-On

Update 20th July 2010: There is now a Hotfix from Microsoft that resolves this issue, see http://support.microsoft.com/kb/2252691; thanks for the pointer Daniel.

If you’re developing BizTalk projects and using TFS 2010, you’ll probably need to install Team Explorer 2010 to leverage some of the new functionality not accessible through the Visual Studio 2008 TFS hooks. Team Explorer 2010 is a stripped down version of the Visual Studio 2010 environment used solely to access Team Foundation Server services.

Be aware that if you do install Team Explorer 2010, you’ll nark your Enterprise Single Sign-On installation, meaning you can’t make any changes to BizTalk – when ESSO attempts to start, you’ll probably receive the following error in the Application Event Log:

Could not create SSOSQL. To fix the problem, reinstall SSO or try 'regasm SSOSQL.dll' from a Visual Studio command prompt.
Error Code: 0x80131700
To correct the missing SSOSQL assembly, simply run the following command in a Visual Studio command prompt as suggested:
regasm "C:\Program Files\Common Files\Enterprise Single Sign-On\SSOSQL.dll"
ESSO should now start as expected.

Accouncing the New BizTalk Message Archiving Pipeline Component

It gives me great pleasure to announce Version 1.0 of the BizTalk Message Archiving Pipeline Component and my new venture, Atomic-Scope.

The component allows you to archive Xml, flat-file, EDI and binary messages as they pass thru receive and send pipelines, without the need for complex ‘archiving’ Send Port configurations, additional load on the MessageBox database and requires zero developer time – just plug-in, configure and use! Archive filenames are created at runtime from Context-Properties written to the message by receive adapters, custom properties defined in your solution or with the standard Send Port ‘macros’. A free 14-day trial is available – download your copy now.

This new version of the component builds on the excellent feedback received following the launch of the original version on Codeplex and has spent many months in development – this release is a complete re-write and incorporates many of the community requested features, including:

  • The ability to enable and disable the component at runtime;
  • The promotion of the archive filename into the Message Context for use in orchestrations, Send Port filters etc.;
  • Full streaming support, even for messages that fail when being processed by downstream components (such as flat-file or EDI messages);
  • Support for a wide-range of adapter Context-Properties ‘out-of-the-box’ and custom, user-defined Context-Properties;
  • Native 32- and 64-bit versions;
  • Support for all versions of BizTalk Server 2006, BizTalk Server 2006 R2 & BizTalk Server 2009;

The component is also backed by our business-class Enterprise Support Agreement. You can also read more about Atomic-Scope and see how we are supported by the Microsoft BizSpark Programme.

A short video if available which gives an overview of how the component works when archiving files in receive pipelines (opens in a new window):

I plan on posting more information about the Message Archiving Component over the coming weeks. In the meantime, why not download the component and try it out yourself?



Get Adobe Flash playerPlugin by wpburn.com wordpress themes

Nick Heppleston’s BizTalk Blog is Digg proof thanks to caching by WP Super Cache