Shrinking SQL Server Log file

The logfile of the BizTalk Server Message Box database (BiztalkMsgBoxDb) is rapidly growing if you the recovery model is set to "full".

At first you should try this (taken from here):


ALTER DATABASE BiztalkMsgBoxDb
SET RECOVERY SIMPLE;
GO

DBCC SHRINKFILE (BiztalkMsgBoxDb_log, 1);
GO

ALTER DATABASE BiztalkMsgBoxDb
SET RECOVERY FULL;
GO


In some cases you're not able to shrink this file.
This may refer to some dead processes and unfinished transactions.

Your can check for the oldest transactions using:

DBCC OPENTRAN ('BizTalkMsgBoxDb')

If you find a very old transaction there you may kill the PID with the Acitvity Monitor of the SQL Server Studio.
Repeat the last two steps until all old transactions are disappeared.
Finally do
BACKUP LOG BizTalkMsgBoxDb WITH TRUNCATE_ONLY

DBCC Shrinkfile ('BizTalkMsgBoxDb_log',2) (where "2" is the targeted Logfile size)

and enjoy the new log sizes.

Error message can be found in BizTalk's Message Flow window

Sometimes it seems like BizTalk is trying to hide error messages. So, if you can't find any sufficient message neither at the suspended instances nor in the event viewer, here is another source of information:



1. Open the Message Flow using the instance's context menu of HAT or Administration Console
2. Use the link "Show tracked Orchestration Exceptions".

This will show you an error text, which actually explains the error. :-)

Error: BizTalk receives"empty" messages from WebService

Biztalk could receive "empty" messages from the Web Service, as it is deployed. Empty in this case means that the message looks like this:

<?xml version="1.0"?>
<account xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:nil="true" xmlns="http://schemas.microsoft.com/crm/2006/WebServices" />

As you can see, only the root element "account" was given (so it's not really empty).

However, the system that invokes the Web Service is definitly setting the input parameters.

This happens, if the input schema of the orchestration is changed, but the Web Service is not created and deployed afterwards (e.g. using Visual Studio's wizard). Then, the out-dated Web Service receives unexpected parameters and passes only the root node to BizTalk.

Workaround for the BizTalk 2006/CRM Problem stating "Error in XML document (2, 2)"

After upgrading from BizTalk 2004 to BizTalk 2006, an error occured when receiving an error from the CRM WebService saying that there is an "Error in XML document (2, 2)".

The message received by the orchestration changed, as the namespace was now given (the red part has not been given in BizTalk 2004):

<?xml version="1.0" ?>
<guid xmlns="http://schemas.microsoft.com/crm/2006/WebServices" >E4096CF2-2777-DC11-B068-001A4BAF607E</guid>

And, the namespace http://schemas.microsoft.com/crm/2006/WebServices indeed does not have a root name entry for "guid" (as you can see in the Administration Console/Application X/Schema).

I unfortunately don't know the reason for this, but, at least, we found a work around: We wrote a CRM wrapper, that encapsulates the functionality of envocing the CRM Web Service. This wrapper is published as a Web Service that receives exactly the same object BusinessEntity like the CRM Web Service does. Than it invokes the CRM Web Services and returns the GUID. BizTalk than has no problem taking this GUID and work furtheron.

HAT error: ActiveView.ColumnAxis is null or not an object

When opening the BizTalk HAT, the following error occurs, if you have not installed Office XP's Web Components.



Install it from here: http://www.microsoft.com/downloads/details.aspx?FamilyID=982B0359-0A86-4FB2-A7EE-5F3A499515DD&displaylang=en

BizTalk Error 916 duplicate 'Microsoft.XLANGs.BaseTypes.DesignerPosition' attribute

If you receive the following error while building an BizTalk orchestration:

Error 916 duplicate 'Microsoft.XLANGs.BaseTypes.DesignerPosition' attribute

you now know that it's because you've copied a shape from orchestration A' to orchestration A, while A' has been a copy of A before. Because (only?) this copy produces a new orchestration shape in A that has the same GUID as the already existing shape.

I guess, this error message pops up really, really seldom :-)

Export/Import large amounts of Parties using BindingImport

The party management of Biztalk gets a little bit slow and unhandy with a a large amount of trading Partners.

Exporting about 12.000 BizTalk parties with the Binding Export tool takes about 6 hours on a fast machine resulting in a 200 MB XML binding file.

For an import in smaller slices you can split the binding file in smaller pieces with a small program using XPathNavigator and XmlTextWriter:
XPathDocument xPathDocument = new XPathDocument (@"Bindingfile.xml");
XPathNavigator nav = xPathCocument.CreateNavigator();
XPathNodeIterator partyCollection = nav.Select("/BindingInfo/PartyCollection/Party");

Iterate over the partyCollection and create XML documents
XmlTextWriter xmlWriter = new XmlTextWriter(@"SmallBinding.xml",Encoding.UTF8);
xmlWriter.WriteStartDocument();
xmlWriter.WriteStartElement("BindingInfo");
xmlWriter.WriteStartElement("PartyCollection");
...

Finally use BTS-Task to import the slice:

Process process = new Process();
process.StartInfo.FileName = @"C:\...\BTSTask.exe";
process.StartInfo.Arguments = "importbindings -Source:" + @"SmallBinding.xml";
process.Start();
process.WaitForExit();

Limitations in EDI pipeline and Direct Submit Port

We found two limitations with BizTalk 2006 R2 Beta2 (and RTM Bit's):

(a) Invoke a direct submit port inside a biztalk orchestration (you have to implement and invoke a web service for direct submit)

Thanks to Vishy (http://geekswithblogs.net/Vishy/archive/2005/10/06/56217.aspx)


(b) Using the EDI send or receive pipelines in conjunction with the MSMQ adapter (you can use the FILE adapter, though)

There was a failure executing the receive pipeline: "Microsoft.BizTalk.Edi.DefaultPipelines.EdiReceive, Microsoft.BizTalk.Edi.EdiPipelines, Version=3.0.1.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35" Source: "Pipeline " Receive Port: "ZES.ReceiveEdi.FL_Batch" URI: "FORMATNAME:DIRECT=OS:.\PRIVATE$\TESTMSMQ" Reason: The integer property value is not valid.



Microsoft will release a hot fix for this issue!

Sending large messages to MSMQ via Dynamic Send Ports

I had troubles figuring out how to send large messages to MSMQ when using a dynamic send port in BizTalk. Developing a connection to MSMQ with "late binding" is straightforward, as you just have to configure a send port - however, doing this via code is less easy.

However, if you follow these steps, it's not a big clue:

1. Create a queue in Computer Management > Services and Applications > Message Queuing.

2. In your BizTalk Projekt, import the library Microsoft.BizTalk.Adapter.MSMQ.MsmqAdapterProperties.dll, stored in %Program Files%\Microsoft BizTalk Server 2006.

3. In a construct message shape, assign the following port properties to the output message:

// to set the admin queue:
Message(MSMQ.AdministrationQueue) = @"FORMATNAME:DIRECT=OS:.\PRIVATE$\MSMQADMINQUEUE";

// to make it transactional:
Message(MSMQ.Transactional) = true;
Message(MSMQ.MaximumMessageSize) = 10240;
Message(MSMQ.SegmentationSupport) = true;

// to assign a special name:
Message(MSMQ.Label) = System.Convert.ToString("ABC");

... and define the target MSMQ queue in the send port object:

SendPort(Microsoft.XLANGs.BaseTypes.Address) = @"msmq://FORMATNAME:DIRECT=OS:.\PRIVATE$\TESTMSMQ";

Voilà!

Thanks to Scott Colestock (http://www.traceofthought.net/PermaLink,guid,cbd9b038-f952-479c-85b2-84398c451623.aspx) and MSDN's MSMQ Properties Page (http://msdn2.microsoft.com/en-us/library/aa577593.aspx)

Opener - or: This developer is (not only) driven by chocolate

My first entry shows an important piece of motivation: an extra large chocolate that I just received as a gift from one of my colleagues. So, if you ever need an answer to a question, don't forget to send some chocolate! ;-)

In my daily work as a software developer, I'm used to fight with computer systems. After finding a lot of solutions in blogs, I decided to make up my own blog to publish this or that solution to a pitfall that I discover (or think to discover).

Have fun!