BizTalk 2013 known issues: Cannot find itinerary designer project template after installing ESB Toolkit 2.2

The itinerary designer for the ​BizTalk ESB Toolkit is now part of the BizTalk Server installation media.

After installing everything if you find 'BizTalk ESB Itinerary Designer' template is still missing from VS

To resolve the issue, please try running: devenv.exe /setup 
(in a command lind of VS2012 directory)

some Useful open source tools

Notepad++ text editor

PuTTY is an SSH and telnet client (FTP)
Agent Ransack - Free File Searching Utility
Fiddler free web debugging proxy

Sharing a Strong Name Key File Across Projects

If we try to share key files using the Visual Studio 2013 function on the signing property page, you'll find that the key file is copied into your project directory.  In a lot of cases this is exactly the desired behavior since it helps to group all of the artifacts that go into building your project into one location.  However, it is a common requirement that the key file not be copied into every project directory and instead referenced from a single common location.  You can still pull this off using Visual Studio 2013:

Step 1: Add the key file to your project using the Add Existing Item menu.

Step 2: In the add dialog, instead of choosing to add the key directly (which will make a copy into your project directory), hit the arrow next to the Add button and choose to add the key as a link.

Step 3: Go to the signing page of the project properties.  Your key file should now be on the drop down list of available keys.

Since the key is already a part of the project, Visual Studio will not  make a new copy of it.  One thing to notice, Visual Studio will reference your key as a relative path from the project file.  This may be exactly what you want -- but if you'd rather have a hard coded path, you can open up the project file and change the AssemblyOriginatorKeyFile (and the Include path of the Link to your key).

You'll also want to make sure that on the property sheet of the key file, the Build Action is set to None and Copy to Output Directory is set to "Do not copy" -- You don't want to accidentally start distributing your key file as an embedded resource!

Finally, there are a couple of tweaks you can make for asthetics. After setting up signing, some people like to add the key as a solution item, then edit the project files and add a False tag to the None tag including the key.  This presents the key in the Solution Explorer at the solution level rather than in each individual project.

Personally, I like to see the key file that each assembly will be signed with, but I don't want it cluttering the root level of the project's files.  The tweak I make is to edit the project files and change the Link tag to have a Properties prefix.  For instance, we might have:

Properties\App.snk

Easy Promotion of Context Properties

As you’ll probably know, there are two types of properties in the context of a message: properties based on field values (MessageDataPropertyBase) and properties not based on fields (MessageContextPropertyBased). I’ll call the first ones Message Properties and the other ones Context Properties.

Message Properties based on message fields are automatically written and promoted into message context by BizTalk.
Context Properties not based on message fields can be assigned inside an orchestration using the expression Message(Property) = “value”;
One of the most interesting stuff about Context Properties is that are not tied to a concrete schema, so they can be used regardless the message type. A sample of a system context property is FILE.ReceivedFilename.

The problem of promoting context properties:
When you create a context property, not based on a message field, and you assign a value inside an orchestration, it is written, but not promoted. What does it means? it means that you cannot route the message based on this property.
Some days ago I had the situation where needed exactly this: content based routing based on a custom context property that had a value calculated inside an orchestration.

The trick:
In my case, the pipeline solution is not an option, since I’m routing between orchestrations via Direct Port Binding. Also, coding a custom component to promote a property seems to complex for me…
Somebody told me a good trick to promote context properties inside an orchestration, easy and direct:
Create a CorrelationSet based on the property.
Even if you are not going to use it, when you initialize a CorrelationSet, the Orchestration engine makes the promotion of the properties involved, since correlation is just an special kind of routing.

So now I have some dummy CorrelationSets, that I call Promote_CorrelationSet

nice and easy! :-)

Calling .Net assembly from Biztalk Orchestration: Where to put Config

BizTalk uses its own configuration file called btsntsvc.exe.config which is in the BizTalk program files directory. You can add your configuration sections into this file and then bounce the biztalk host instances to pick up the changes.

HOWEVER, this is not good practice. It's OK to do this when you have only a single BizTalk app server but if you need to scale out suddenly you have multiple config files to maintain.

The recommended approach is to use SSO to store app-specific Config data, since it's BizTalk's Config storage solution and therefore always available. I always use this method and have never had any problems (although there is some overhead associated with development and management).

Ref: http://stackoverflow.com/questions/10107460/call-net-assembly-from-biztalk-orchestration-where-to-put-config

http://seroter.wordpress.com/2007/09/21/biztalk-sso-configuration-data-storage-tool/

http://geekswithblogs.net/paulp/archive/2008/05/16/122205.aspx

http://geekswithblogs.net/paulp/archive/2008/06/09/122746.aspx

http://stackoverflow.com/questions/11744571/store-configurable-values-in-sso/11746059#11746059

How to save password for WCF Adapter in BizTalk binding file

Generally, it is not recommended to store passwords in the binding file and by default BizTalk administration UI clears it out when exporting binding to the xml file. But in development environment where you have automated continuous integration build and deployment not having password in the binding file will prevent application from starting and CI process fail. It can become tedious in staging deployments (TEST, UAT) as well, especially if you have multiple endpoints that use accounts with passwords. In such cases, having password for development account (hopefully not the same as production) in binding file can make life easier.

To do that, export binding file after application is fully configured. Open it and locate section(s) with configuration for the ports/locations of interest. For example for the WCF receive location it will be in:

<ReceiveLocationTransportTypeData><CustomProps>...</CustomProps></ReceiveLocationTransportTypeData>

Find emtpy password tag in this section that will look like:

"& lt;Password vt="1"/& gt;"

Change it to enclose you password value and vt attribute value to "8":

"& lt;Password vt="8"& gt;MyPassword& lt;/Password& gt;"

Save and use this binding for an automated deployment script.

XPath Inside Orchestrations in BizTalk

Working with XPath inside Orchestrations is a powerful and simple feature of BizTalk.

The help guide does a good job describing the process (under Using XPath in Message Assignment).

XPath queries can only be done against a Message and the results can be set to a Message, XML Document or other orchestration variables. XPath queries can also be executed against untyped messages. That is, a Message that is of type System.Xml.XmlDocument.

CRITICAL: BizTalk xpath can be used to both read values and set values inside your Message. To set values in message, we need to be inside a Message Construct shape.

Here are some of the things which we can do with xpath and how to do them:

- Set a single values inside a Message using xpath
   xpath(SingleXML, "//LineTotal") = nLineTotal;

- Extract a single piece of data out of a Message
  sCustomer = xpath(InXML,"string(//Customer)");

- Extract a single node out of a large XML Document and assign it to a message or  variable
 sXPath = System.String.Format("//Item[{0}]",nCount);
 xDoc = xpath(InXML, sXPath);

- Count the number of nodes or occurrences of something inside your message
  nNumberItems = System.Convert.ToInt32(xpath(InXML, "count(//Item)"));

A great resource for xpath functions and expressions is the W3Schools.