BizTalk Naming Convention

Why it's important

Keeping a good overview of your environment as it grows is very important, you need to have a good foundation. By this you should follow good naming conventions for your applications, ports, orchestrations and hosts.

Even though it might seem though from the start the advantages of keeping a good naming conventions for all artifact will enhance the usability for everyone interacting with your BizTalk environment, for Microsoft or any other consultants you might need to hire a good naming convention will make it easier to "get to know your environment". This Wiki article will provide you with some information on how to do it however it does not affect resources, maps, BRE. It mainly focus on Applications and hosts, this guidelines may differ from company to company on how it should be. Let's say you work at a company only hosting applications created by your company (where you have internal development adding the company of the developing company to the application might not be necessary) however you might have many different vendors providing you with application, so adding the vendors name to the application will make it easier to know who to "contact" for assistance.

By starting out from day one with a good naming conventions it will be a lot easier as the environments evolve, as well as bring a better surveillance to make sure the critical "jobs" are up and running.

Below are a few examples and scenarios explained for a few different types of companies.

Naming conventions

Applications

Internal development

With many locations (warehouse, factory etc.)

Where you have interactions between 2 systems only
SystemA-SystemB.Location
Example:
ContosoFactory-ContosoStore.USA

Where communication is from or to one system but distributed to many systems
IntegrationName.Location
Example
ContosoUpdatingWarehouse.USA

Note: Location is optional

Internal and external development

With many locations (warehouse, factory etc.)

Where you have interactions between 2 systems only
CreatedBy.SystemA-SystemB.Location
Example:
Microsoft.ContosoFactory-ContosoStore.USA

Where communication is from or to one system but distributed to many systems
CreatedBy.IntegrationName.Location
Example
Microsoft.ContosoUpdatingWarehouse.USA

Note: Location is optional

Receive Locations, receive ports, Send ports (groups) and Orchestrations

Framework:
TypeOfPort.ToOrFrom/Purpose.Location
Example:

Receive Port
RcvPrt.ContosoFactory.USA

Receive Location
RcvLoc.ContosoFactory.NY

Send Port Group
SndGrp.ContosoWarehouse.Europe

Send Port
SendPrt.ContosoWarehouse.Norway

Orchestration
Orc.TransformOrderToUodateInv.Global

Hosts

When it comes to hosts its really up to how you want to do it, some companies don't have that many applications, and often split hosts for each applications, some have too many applications and must create many hosts of the same time to make it work. This guide is for dimension for a large company with many application, you can move out any of the elements you don't feel you need.

<Job>_<bit support>_<seq>_<adapter/functionality>_<throughput>_<priority>_<clustered>

Examples

This is a receive host, with x32, its sequence number 1, it is only running the FTP adapter, it is tuned for low latency and is clustered. It is also marked as critical
Rcv_x32_1_FTP_L_Critical_Clustered

This is a send host, x64 bits, this is the second adapter with this configuration (sequence number 2) and is running many different adapters, its tuned for high throughput, it is not marked as critical and isn't clustered
Snd_x64_2_Random_H_None_None

This is a 64 bit orchestration host, it is tunes for high throughput and is critical.
Orch_x64_H_Critical