Distinguished Fields vs. Promoted Properties in Biztalk

In Biztalk you can promote a property as either distinguished or promoted properties. Choosing what to use is tricky.

Distinguished fields: In general use Distinguished fields if you want to just use them in Orchestration

• No restriction on field length
• No participation in Routing
• No seperate property Schema
• Not accesible by std pipeline components

Promoted Properties: These are generally used with Routing

• Used in publish and subscribe in the Msgbox
• Field Restictions ( 255)
• Seperate Property schema
• Restricted in the XSD types support compared to distinguished properties

Synopsis: Use Distinguish properties as they are lightweight unless you need them for any special stuff like Routing ,Tracking ,Correlation or custom pipeline behaviour

Using Envelope Schema in Biztalk

What is Envelope Schema: An envelope schema is a special type of XML schema. Envelope schemas are used to define the structure of XML envelopes, which are used to wrap one or more XML business documents into a single XML instance message. When you define an XML schema to be an envelope schema, a couple of additional property settings are required, depending on such factors as whether there are more than one root record defined in the envelope schema

As most of you aware of the fact that you can either

• Split a single message into multiple messages using Receive pipeline.
• Append multiple mesages into a single message using a Send Pipeline

In both the cases you would need to use an "Envelope Schema" to group them together. Following are instructions how to configure the Envelope schema to achieve the above processes.

Splitting a single message into multiple messages:
You need to create an Orders envelope schema, and Order document schema for that.

Steps:

1. Create a new BizTalk project
2. Add the Order document schema with OrderId and Date elements
3. Add the Orders envelope schema with only root element Orders
4. Click on the Schema node and set its "Envelope" property to true
5. Click on the Orders node, and click on the body xPath property, choose Orders and click ok.
6. Deploy the project
7. Create a receive location and choose XmlReceive pipeline
8. Open the pipeline properties dialog, and set envelope schema to the Orders schema, and document schema to Order schema

Append multiple messages into a single message: You need to create an Orders envelope schema, and Order document schema for that.

Steps:

1. Create a new BizTalk project
2. Add the Order document schema with OrderId and Date elements
3. Add the Orders envelope schema with only root element Orders
4. Click on the Schema node and set its "Envelope" property to true
5. Click on the Orders node, and click on the body xPath property, choose Orders and click ok.
6. If you are invoking a send pipeline component within an Orch expression: Open the pipeline properties dialog, and set envelope schema to the Orders schema, and document schema to Order schema
7. Deploy the project

Out of Memory errors while enlisting Biztalk Orchestrations using WMI

Most of the tasks in packaging and deploying Biztalk applications can be done using MSBuild and WMI scripts. All these WMI scripts run under the process 'WMIPrvse.exe'.

Orchestration.enlist is one of most memory consuming task that you could come across while starting applications. When you have many Orchestrations in a single dll, you might come across a 'Out of Memory' error claiming not enough memory is available to complete the transaction, while the server has more than enough memory available.

WMI is used by most management consoles behind the scenes to access certain core functions provided by Microsoft products. Windows Server(2k, 2003) installations come with a smaller memory quota, the default being 128MB for WMI objects.

Problem: When we run trusted scripts, that have to handle large transactions, 128MB is not large enough to complete the transaction and errors out with “Out of Memory” errors.

Solution: There are two ways to solve this:
· Update the appropriate registry(which I still don’t know) setting to a value like 384MB. This can be done HOT and is effective immediately.
· Programmatically increment the ‘MemoryPerHost’ property of the WMI Scripting interface. This would need bouncing the server, before this new quota is effective.

Sample VB Script Code:
'Increase WMI Memory quota from a default of 128MB to 384MB to ensure
'we have enough memory available to complete this process

Dim locator: Set locator = CreateObject("WbemScripting.SWbemLocator")
Dim wmi: Set wmi = locator.ConnectServer("", "root")
Dim quota: Set quota = wmi.Get("__providerhostquotaconfiguration=@")
quota.MemoryPerHost = 384*1024*1024
quota.put_()
Wscript.Echo(quota.MemoryPerHost)


References:
http://blogs.clearscreen.com/tomas/archive/2006/11/13/4234.aspx
http://msdn.microsoft.com/en-us/library/aa394671(VS.85).aspx

Cleaning up Biztalk tracking database

Tracking may tend to grow fast, depending on your how intensive your needs are. Out of the box, BizTalk Server does not offer any tools to "autoclean" the tracking database. However, there's a sample in the BizTalk Server SDK directory exactly targetting the subject. Although it's just a sample, I've never seen this fail and it seems to me that the given SQL script is really high quality coded!!

To cleanup the tracking database:
If you've never done this procedure before, first do this:

1. Open up SQL Server SQL Query Analyzer
2. Connect to the BizTalkDTADb database
3. "File - Open", and go to the BizTalk Server SDK directory and look for the Database Maintenance subdirectory
4. Select the "Purge_DTADB.sql" SQL script file
5. Hit F5
6. You should see a message "Creating stored procedure dtasp_PruneTrackingDatabase", in addition the status bar below should mark the operation as: "Query batch completed".You have just created a new stored procedure called "dtasp_PruneTrackingDatabase". This procedure allows you to prune the tracking database. It takes only one single parameter: @PruneBeforeDate. Executing this SP causes the tracking data to be purged that was older then the given (@PruneBeforeDate) date. So, let's try this.
7. To execute the procedure:
   Select: "File - New - Blank Query Window"
   Type following statements in order to cleanup *all* tracking data before today:
   DECLARE @Today datetimeSET @Today = GETDATE()EXEC dtasp_PruneTrackingDatabase @Today

Depending on how much data is to be purged, after a while the Stored Procedure will notify you with its results. Possibly you may see a message in red, commented as: "Duplicate key was ignored." This is fine and is an expected result.

To verify this:

1. Open HAT
2. Select: "Reporting - Find Message"
3. Try selecting a schema
4. If you've cleaned everything, you should not see any schemas anymore... (Only schemas here should correspond to messages that were tracked, áfter the @PruneBeforeDate date parameter.)

If Tracking database is too huge(> 3 GB), it might be better to truncate the complete content in the tables, rather than trying to clean up one row at a time.

Macros for constructing filenames using Biztalk Send port

Probably every demo of BizTalk 2004 you'll see uses a Send File Port that sends messages to a directory and most of the time these files will have a GUID as a filename, so each message sent will have a different name. The solution is to use "MessageID" macro in the URI property of the Sender Port. So the URI property could look like “c:\temp\out\%MessageID%.xml“. Everything between the percentage signs (including themselves) will be replaced by the GUID which is of course unique.

The files in which the files send handler writes messages can be created dynamically using a predefined set of macros. Before creating a file on file system, the files send handler substitutes all the macros in file name with their individual values. Several different macros can be used in one file name. The file name macros can be used while configuring the file send handler in BizTalk Explorer, or using the Explorer object model.


Below are the list of Macros that could be used for file send ports to generate meaningful names, rather than just a GUID.

• %datetime% : Coordinated Universal Time (UTC) date time in the format YYYY-MM-DDThhmmss (for example, 1997-07-12T103508)
• %datetime_bts2000% : UTC date time in the format YYYYMMDDhhmmsss, where sss means seconds and milliseconds (for example, 199707121035234 means 1997/07/12, 10:35:23 and 400 milliseconds).
• %datetime.tz% : Local date time plus time zone from GMT in the format YYYY-MM-DDThhmmssTZD, (for example, 1997-07-12T103508+800).
• %DestinationParty% : Name of the destination party. The value comes from message the context property BTS.DestinationParty.
• %DestinationPartyID% : Identifier of the destination party (GUID). The value comes from the message context property BTS.DestinationPartyID.
• %DestinationPartyQualifier% : Qualifier of the destination party. The value comes from the message context property BTS.DestinationPartyQualifier.
• %MessageID% : Globally unique identifier (GUID) of the message in BizTalk Server. The value comes directly from the message context property BTS.MessageID.
• %SourceFileName% : Name of the file from where the File adapter read the message. The file name includes extension and excludes the file path, for example, foo.xml.
• %SourceParty% : Name of the source party from which the File adapter received the message.
• %SourcePartyID% : Identifier of the source party (GUID). The value comes from the message context property BTS.SourcePartyID.
• %SourcePartyQualifier% : Qualifier of the source party from which the File adapter received the message.
• %time% : UTC time in the format hhmmss.
• %time.tz% : Local time plus time zone from GMT in the format hhmmssTZD (for example, 124525+530).