BizTalk Naming Convention

Article
1/17/2024

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

Other Languages

This article is available in the following languages

Share via