When you define an element with data type xs:decimal, there is no way that you can control the digits using the XSD schema editor in Visual Studio. However, you can still add the fractionDigit facet, by editing the BizTalk schema in a text/xml editor. Just add the following code under the xs:decimal data type element:

<xs:simpleType>
            <xs:restriction base="xs:decimal">
                        <xs:fractionDigits value="3" />
            </xs:restriction>
</xs:simpleType>

If you than validate an instance the error nicely refers to the fractionDigits facet specified:

The '….' element is invalid - The value '169.5652174' is invalid according to its datatype 'Decimal' - The FractionDigits constraint failed.

Nice feature!

While searching the internet I found this article by Stephen Kaufman describing the fractionDigit feature. It was written before BizTalk 2006 was even there. I'm wandering why this feature was not incorporated in BizTalk Server 2006 (R#).

 tf workspace /delete /server:http://<server>:8080 <computer>;<domain>\<client>

 

When deploying a BizTalk project from Visual Studio, you sometimes run into this error:

"An error has occurred while establishing a connection to the server.  When connecting to SQL Server 2005, this failure may be caused by the fact that under the default settings SQL Server does not allow remote connections. (provider: Named Pipes Provider, error: 40 - Could not open a connection to SQL Server)"

This happened to me when migrating from Visual SourceSafe, VSS, to Team Foundation System, TFS, by copying the projects from a pc to a virtual machine. To solve this error, perform the following steps:

1. Rightclick on the project and choose Properties
2. Go to "Configuration Properties" => "Deployment"
3. Change the "Server" property to be the servername of the SQL Server you are deploying to
4. Save changes
5. Deploy again

The error happens since the servername is listed in the projectname.btproj.user file that is a part of the project.

I often forget the change the servername, so this is to not forget it the next time.

Technorati Tags: BizTalk 2006,BizTalk 2006 R3,VS2008,SQL Server 2008

Today I read a blogpost on BizTalk Server Team Blog announcing the plans to deliver BizTalk server 2006 R3. This new release will support Windows Server 2008, .Net framework 3.5, Visual Studio 2008 and SQL Server 2008. According to Steve Martin's blogpost  a CTP of BizTalk Server R3 is expected later this year and the RTM is planned the first half of 2009.

" at a high level we are planning some new investments in the release that includes:

• New web service registry capabilities with support for UDDI (Universal Description Discovery and Integration) version 3.0 
• Enhanced service enablement of applications (through new and enhanced adapters for LOB applications, databases, and legacy/host systems) 
• Enhanced service enablement of “edge” devices through BizTalk RFID Mobile 
• Enhanced interoperability and connectivity support for B2B protocols (like SWIFT, EDI, etc) 
• SOA patterns and best practices guidance to assist our customer’s implementations"

Could not write to output file '[path]\obj\Debug\[assembly].dll' -- 'The process cannot access the file because it is being used by another process.'

Recently I ran into this when I tried to deploy my BizTalk project from Visual Studio 2005:

"An error has occurred while establishing a connection to the server.  When connecting to SQL Server 2005, this failure may be caused by the fact that under the default settings SQL Server does not allow remote connections. (provider: Named Pipes Provider, error: 40 - Could not open a connection to SQL Server)"

I had run into this error before and after a few minutes I remembered what I did wrong: the server name. Since I moved the solution and projects from Visual Source Safe to Team Foundation System in a virtual machine environment, I needed to change the server name of the project. To change the property, complete the following steps:

• Rightclick on the project and choose Properties
• Go to "Configuration Properties" and select "Deployment"
• Change the "Server" property to be the servername of the SQL Server you are deploying to
• Save changes
• Deploy again

Now let's hope I won't forget it a next time.

"Could not enlist send port '[Send Port]' Exception from HRESULT: 0xC00CE557(Microsoft.BizTalk.ExplorerOM)"

My current BizTalk project involves implementation of the Oracle adapter. In order to improve the current error handling when writing data into and retrieving data from Oracle I tried to implement the suggested way of using a fault message in How to Add a Fault Message. However, I could not get it to work.

According to the documentation the Oracle adapter communicates through the ODBC API via SOAP messages. Instead of using the Fault method I decided to catch the SOAP exception message. Since it involved a request response send port I could not use the DeliveryFailureException by setting the Delivery Transmitted property to Transmitted. In order to catch the SOAP Exception you have to add a reference to the System.Web.Services namespace in your BizTalk project.

Once you have added the reference, you can set the Exception Object Type to System.Web.Services.Protocols.SoapException in the Catch/Error handler block. Note that when you make use of the InnerException object of the SOAP exception object an error can occur when the InnerException object is null. ExSOAP.InnerException.Message will then result in an XLANGS/s error:

Inner exception: Object reference not set to an instance of an object.
Exception type: NullReferenceException

Recently I used the following code to get the value of a promoted property:

propValue = msgIncoming.Property1.ToString();

However, this statement caused the following error during compilation:

Error 48, 'System.Xml.XmlDocument' does not contain a definition for 'Property1'

There is an easy way to solve this; use the System.Convert method:

propValue = System.Convert.ToString(msgIncoming.Property1);

That's it.

OK, in BizTalk FTP adapter: round 1, I was facing some problems when downloading large files.Apparently, this problem is very easy to solve according to this knowledge base article.

"This problem occurs because the value of the Polling Interval property of the receive location that is configured for an FTP site is less than the time that it takes to receive a large file."

The resolution than is set the Polling Interval property in the FTP Transport Properties dialog box to a longer duration. To be safe, the first time I set he first  a very long polling interval.

After extensive analysis and testing, I managed to bring it back to a just a couple of minutes. Further enhancements will be made when files are zipped.

While processing large flat files with BizTalk 2006, I thought it be useful to have the files archived for informational purposes. So, I made a send pipeline subscribing to the large message to archive the file. The flat file coming in was about 230 MB in size, while the size file was about 650 MB. After a moment of being surprised by this large increase in size, I realized that the file being archived is XML format. Sometimes, I forget.

Note that initially the file was much larger, about 3-5 times as large. We managed to decrease the file size by using very short element and node names in the schema.

Recently I had to implement BizTalk's the FTP adapter. However, we're using large files and I mean really large files; 250+ MB. I know BizTalk is not meant for handling bulk messages, but that discussion is past now.

The problem with these large files is that when you're copying the file to the FTP site, BizTalk at the same time is polling for the file and tries to receive it. This results in errors.

1. BizTalk Server 2006 Warning
The adapter "FTP" raised an error message. Details "Unable to receive the file "BMF.txt" from the FTP server. ".

2. BizTalk Server 2006 Error
There was a failure executing the receive pipeline: "Microsoft.BizTalk.DefaultPipelines.PassThruReceive, Microsoft.BizTalk.DefaultPipelines, Version=3.0.1.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35" Source: "Pipeline " Receive Port: "ReceivePortFile" URI: "ftp://server:21" Reason: Unable to receive the file "BMF.txt" from the FTP server.

3..7 BizTalk Server 2006 Warnings
The adapter "FTP" raised an error message. Details "Unable to receive the file "BMF.txt" from the FTP server. ".

I've changed the polling interval and some of the configurations of the FTP adapter. It actually worked once, but I'm still testing if it works in all cases. I'll keep you posted.

Recently I wanted to provide nil values to an Oracle database using the standard Oracle adapter. So I used the handy Nil value functoid in the BizTalk mapper.

However, the Nil value functoid doesn't work for number fields. The value supplied to Oracle is a 0 (zero).  It does fortunately work for string fields. Really annoying to write triggers in Oracle to overcome this nil value 'bug' for number fields.

Recently I wanted to re-organize a BizTalk solution. I had some maps, schemas and orchestrations and wanted them neatly organized in folders with the same name. So I moved a map in the maps folder in my project. However, the mapper complained I couldn't find the schema's anymore.

A simple replacement of the schemas involved did not work, which greatly surprised me. I recalled that if you opened the mapping in a text editor you can see a reference to the schema. This reference is a relative path reference. I ended up changing the mapping in a text editor. Changing the beginning of the reference from .\<path> to ..\<path> solved my problem. Strange?!

Some strange things happened to me last week. I have a mapping in BizTalk and in that mapping I'm calling an external assembly. When I changed the assembly version I updated my mapping, but I got errors using the assembly. So I checked the mapping, but everything seemed to be fine. However, when I opened the mapper the previous version of my assembly was still referenced. After a couple of tries solving the problem, I ended up editing the mapping in a text editor which finally solved the problem. Strange!