Dear Stephen,

I have been working with BizTalk since year 2006, prior to that I was working with .NET since year 2001.

The greatest tip / trick which I have learnt in all these years is that:

If the integration layer (BizTalk layer) of your enterprise application is heavily interacting with databases, then it is not advisable to use any type of SQL Adapter, rather a .NET Data Access Layer should be built in which each entity object should inherit from System.EnterpriseServices.ServicedComponent such that they can take part in COM+ transactions. Now this dll could be registered with COM+ using regsvcs utility. We can check it in COM+ MMC snap in. Now even if we go for multibox BizTalk installation, this data access layer would work fine.

Well, another trick. If you got to deal with large flat files of size more than 10 MB then it is wiser to use SSIS (Sql Server Integration Services) instead of BizTalk. We should spare BizTalk from doing this donkey work. Normally as EAI Architect, I recommend both BizTalk and SSIS together for meeting integration requirements.

Thanks

Ambar Ray

EAI Architect - Microsoft Technologies

Here is a really simple tip that is great to use when building demos and proof of concepts using the file adapter.

1. Create one folder (docs) and place all your test files there.

2. Configure the receive location to use the docs folder and “Copy*.xml” as the filter (for Server 2008, Vista and 7 use “*Copy*.xml”

3. Configure all your send ports to send to the docs folder with filenames like “Order_%MessageID%.xml”.

When you test, select the file and use CTRL+C, CTRL+V to create a copy.

You can then test your application from one folder.

I have an e-Book copy of Richard’s book and it rocks, but having a physical copy would be great! Nothing like holding part of a tree in your hand.

I think that most people that use BizTalk are at least aware of the Business Rules Engine and if they are they know that using vocabularies is definitely a “best practice.” Creating vocabularies can be rather painful.

Tip 1 – Create a vocabulary not based on the process but rather on the fact source. If you have three schemas and a few .NET classes involved in the rule create separate vocabularies for each schema and for each .NET class, not a single vocabulary for the entire process. Ensure that you define all the terms that you even think you might need now or in the future. If for example you are creating a vocabulary for a Purchase Order and there is a chance you might apply a discount and change the Total node provide both a read and a write (Get and Set) vocabulary term for Total. Modifying vocabularies in the future is no fun so getting them right from the start is helpful!

Tip 2 – (This is the Real tip!) When creating vocabularies, to speed creating terms, select the item (say an Element in a schema) in Fact Explorer and while holding the mouse button drag the item to the Vocabulary tab, (the focus will shift) and then drag it to the vocabulary you wish to add the term to before letting go of the mouse button. The vocabulary wizard will launch and all you have to do is to fill in the name, and choose whether it will be a get or set term!

John Callaway

QuickLearn

You can generate C# files representing the orchestration, schemas, and maps using Visual studio if you set the following registry key.

1. Create a key called BizTalkProject at the following location: HKEY_CURRENT_USER\Software\Microsoft\VisualStudio\7.1

2. create a DWORD key GenerateCSFiles, and set its value to 1

3. Restart visual studio, load a BizTalk project and rebuild.

Hi Stephen,

Two little tricks ive posted before from my biztalk black magic book are:

1. When you hand edit your binding files and suddenly you cant enlist ports anymore and cant work out why

geekswithblogs.net/.../118488.aspx

2. You ge the CLSID_BizTalkPropertyBagFactory error message but you didnt really do anything and start to wonder if BizTalk just hates you

geekswithblogs.net/.../115103.aspx

A few people have bought me drinks for saving their skin with these two babies.

Ive already got the book so im just in this for fun

Mike

Check this out if you want to win a copy of the SOA Patterns Book www.biztalkgurus.com/.../biztalk

Many people developing BizTalk applications find themselves creating maps with a lot of functoids doing a lot of logic or database lookups. These maps inevitably become large and unwieldy, and are a maintenance nightmare.

A great way to keep maps simple is to use the Business Rules Engine (BRE) for database lookups and logic operations. Before (or after, as appropriate in your case) sending a message to your map, send it to the BRE and let it do the work.

Another reason you may wish to leverage the BRE is to leverage fact retrievers. Fact retrievers are long-term rule stores that let you cache lookup values for long periods of time, and even refresh them at timed intervals. This is a great place to store frequently-accessed items like lookup tables. It's also a lot easier to maintain than having the logic buried within your maps.

Another tip from my side:

If you are interacting with 20-30 database tables in your integration layer, you are definitely going to end up with deadlocks, because SQL Adapters are very poor in maintaining transactions and locks. So use the data access layer with objects derived from ServicedComponent as I mentioned in my earlier post as well as revisit all your stored procedures and tune them appropriately, never ever use cursors in stored procedures use DECLARE @table instead, prefer joins to super nested queries and don't use *, use explicit column names instead for the sprocs and you can alleviate the deadlock problems in your integration layer.

Well, one more tip:

Try to make your BizTalk application as loosely coupled as possible. Use proper design patterns like recipient list pattern or process manager pattern and scatter-gather patterns for they are all loosely coupled.

not very specific to biztalk.but here is one tiny one..

#during development time, when you have multiple send and receive locations to monitor use a html page with multiple iframes to accommodate all file/ftp/sql tables locations to see all at once :),

instead of Alt-Tab

Hi Steve, Some tips I had came across while developing with Biztalk 2009 the last days:

1) Visual Studio 2008 fails to Create new BizTalk projects

I was stuck getting the error message: Creating project ‘project name’… project creation failed

Solution is going to the registry to make the following change:

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\VisualStudio\9.0\Projects\{FAE04EC0-301F-11d3-BF4B-00C04F79EFBC}]

"PossibleProjectExtensions"="csproj"   - Original VS install reg value. "PossibleProjectExtensions"="csproj;btproj" - Post Biztalk installation reg value

The following is the entry for the 64 bit version of VS:

HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\VisualStudio\9.0\Projects\{FAE04EC0-301F-11d3-BF4B-00C04F79EFBC}

The full post is here: blogs.msdn.com/.../visual-studio-2008-fails-to-create-open-biztalk-projects.aspx

And it really saved me a lot of time and headaches.

2) Constructing an If-Then-Else logic in a mapper

I needed to make this simple logical function and did not want to use a Script. Finally I came across with this post and currently I have something pretty similar working out perfectly:

blogs.msdn.com/.../to-be-or-logical-not-to-be.aspx

3) HTTP GET and HTTP POST

I needed to send messages via Http POST with parameters in plain text.

This post helped me a lot as it shows how to use the RawString class to construct the body of the message and also suggests the use of Fiddler to monitor and try your request. After having working my request with Fiddler I was able to make it work within Biztalk, realizing that is necessary to set [Content Type= application/x-www-form-urlencoded] in the send port (I commented this out in the post).

Full post: kentweare.blogspot.com/.../adventures-with-http-adapter-and-yahoo.html

The sample is with the Yahoo API but it applies to any HTTP POST request.

4) BizTalk and COM+ Transaction

This is another problem that I faced making a POC. I had to call COM+ for making a distributed transaction and had exceptions.

After making some search I came across this post: biztalkers.blogspot.com/.../biztalk-and-com-transaction.html

The problem was in fact the attribute “RequiresNew”. I changed it to “Requires” and everything worked out.

5) ESB Toolkit – How to invoke an orchestration within an Itinerary

This is actually something I had the pleasure to talk with Richard. I was figuring out how exactly say within an itinerary “I want to call this orchestration, afterwards this other one and so on..”. In fact, despite having many orchestrations deployed they did not appear on the Orchestration Service combo box to be selected in order to be invoked.

I was about to be done because I couldn’t find the way to set this up and couldn’t find useful help either. I only had available the 2 orchestrations that come with the ESB, not my orchestrations.

Finally this video was the only source I found about how to do that: cid-04bc12b1f7b2979a.skydrive.live.com/.../ESBT%7C_How%7C_Two%7C_5%7C_CustomOrchestrations.wmv

The main problem is that you have to explicity register the orchestration (type and assembly) on the esb.config file. Obviously, not productive at all but that is the answer. After doing this I was able to select my orchestrations within itineraries.

6) I made some modifications on the BTSNTSvc.exe.config and after starting my host I got the error:

Error: The type initializer for 'System.Data.SqlClient.SqlConnection' threw an exception.  

This has nothing to do with Sql indeed. The issue is in the .config where I mis-spelled something.

I think it is important to bear in mind this and the error description has nothing to do with the error itself.

Hope it helps.

If you are looking for ways to display business rules outside the Business Rule Composer, you want to look at the RuleDisplayStringExtractor object in the  Microsoft.BizTalk.RuleEngineExtensions namespace. This object allows you to turn a Rule object into a human-readable business rule similar to the one displayed in the composer. This namespace also contains the RuleSetDeploymentDriver object, which you can use to programmatically import, export, deploy, undeploy, retrieve deployment characteristics, and set tracking configuration for rule sets and vocabularies.

Use the BizTalk Software Factory (www.codeplex.com/bsf) to build BizTalk solutions the easy way. This software factory supports BizTalk developers in creating a solution structure and creating artifacts, implementing best BizTalk practices.

If you are building custom pipeline components, then I guess this tip will save you lot of time

blogs.digitaldeposit.net/.../Biztalk-Custom-Pipeline-Component-Development-Tip.aspx

Developing Orchestration:

You don't need to deploy your orchestration all the time, majority of the times you can get away by just re-gacing your orchestration dll. Example: if you are adding removing code inside your expression/message assignment shape.

Orchestration Development: TIP #2

You don't need to have a "Construct Message" and "Message Assignment" shape inside the orchestration to construct a message. Instead you can use the "Expression" shape with the following statement

construct MSG_VARIABLE

{

MSG_VARIABLE = Helper.GetMessage()

}

for example Helper.GetMessage .NET helper method can return an xml document.

This will avoid having lot of Construct Message shapes in Orchestration saving lot of valuable space.

Orchestration Development #3

Dont forget System.Diagnostics.Trace.WriteLine and DebugViewer combination :-)

Here is a way to figure out which Itinerary step was executed when working with ESB toolkit 2.0

urikatsir.wordpress.com/.../how-to-determine-which-itinerary-step-was-executed

I would like to share a trick that will help you to receive any messages as it is inside orchestration.

1. Create a message of type System.XML.XMLDocument in orchestration

2. Set this in the orchestration receive shape.

3. Use the RawString class provided by Microsoft and convert them to stream in a .net class

4. After deploying the solution, use passthru receive pipeline and this will allow you to recieve the raw message inside orchestration..

Let me share few more details on how the above tip is useful. This will be handy in cases where you don’t want to do any disassembling of messages, but need to implement some business logic inside the orchestration.

Following was one such scenario we faced - We had to send message to destination in the order of filename. Since FTP/FILE adapter doesn't allow ordered delivery an option was to create a custom adapter. But due to limited time, we decided to use a .net component inside above orchestration which will hold the messages received for a time period. Messages were stored inside a 'List' (of class with filename and datastream). Once all the messages are received the List was sorted using the filename. Then messages were retrieved from the sorted list and sent to the destination in a loop.

DON’T...

...load the entire message into an XmlDocument in a pipeline component

DO…

…use forward-only streaming instead (blogical.se/.../screencast-building-pipeline-components-with-forward-only-streaming.aspx)

USE…

…tools like PAL and LoadGen to test your environments and solutions (http://pal.codeplex.com & www.microsoft.com/.../details.aspx)

LEARN…

…about automated deployment (channel9.msdn.com/.../MSDN-TV-Use-Team-Foundation-Server-for-BizTalk-Server-2009-development)

BUY…

…the book if you don’t win it, it’s a great book(www.packtpub.com/.../book)

Tip: - If there is process triggered by Database Polling, then BizTalk designer has to think of using BizTalk adaptor for Database Polling operation. Generally this requires a stored procedure with custom schema generated by BizTalk. There might be changes in the stored procedure as per project requirements, which impacts schema directly and shaken significant part of solution results in rework. Using SELECT AS statement in the Stored Procedure will make sure that it will not impact the custom schema in some cases.

e.g.

SELECT DISTINCT ir.EMAltMsgId AS ID,

CONVERT(VARCHAR(10),ir.ReqRcvTs,101) AS FileDate,

ir.Acct1st11DigNo + ir.AcctLst4DigNo AS Account,

ir.MailCd+ir.BagId             AS BagID,  

XML AUTO, ELEMENTS

This will make sure that even if there are changes in the Stored Procedure logic the schema will have following elements.

ID, FileDate, Account and BagID.

Resequencer pattern - a scalabale approach

if you intend to implement end-to-end ordered processing using ESB Toolkit 2.0 and moreover wish to ensure that the solution be scalable then there is one small caveat which needs to be overcome. That is dynamic send ports do not support ordered delivery property. Now in order to overcome this the following needs to be done.

1. In the orchestration receive port set the ordered delivery to true.

2. It is assumed that BatchID would be there for a batch of messages, hence use that in correlation set to set up a sequential convoy such that only one orchestration instance serves a batch of messages. For next batch another instance and so on.

3. Add a SequenceNo to the property schema and set its property schema base property to MessageContextPropertyBase.

4. Within orchestration, depending upon the message content, set the SequenceNo of the message and use an updategram to push the message to a SQL Server table. The stored procedure used for this purpose should fill the value of an extra "status" column as "Initialized".

Now another orchestration has to be used. For this first add a receive location with adapter as SQL Adapter.

5. The SQL adapter polls the table where message is srored and picks up one message with highest/lowest SequenceNo value depending upon in which order you wish to process the messages. Upon picking up the message the "status" column should be updated to "Processing" such that when SQL adapter tends to pick up another message from the table eventually to fire another orchestration instance, it finds that the message with highest/lowest SequenceNo has status as "processing" and it doesn't do anything.

6. Once the processing is over, at the end this orchestration uses an updategram to change the status to "Completed".

7. The SQL Adapter at the receive side continues polling and finds that the message with highest/lowest SequenceNo is having status as "Completed" and hence it goes ahead and picks up the next highest/lowest SequenceNo message.

Thus end to end ordered processing is ensured irrespective of whether you use MSMQ at the receive side or not. This solution would give optimum performance alongwith high scalability as no in-memory processing is done like normal resequencers in BizTalk. So even if thousand messages arrive in a batch, it would pose no problem to the application.