BizTalk Solution & Naming Conventions

When you start BizTalk development project then need to follow some common naming convention and project structure to be better and easy understanding to others.

As per lasted trends BizTalk development project should be as below:

BizTalk Project Setup:

You should create BizTalk project module wise or Product wise which look more feasible. You should not keep all modules applications in single BizTalk project. Create one solution and under this separate project for each BizTalk component. Create separate BizTalk project for each artifact under one solution.

E.g. Schema, Map, Pipeline, orchestration and any other resources (Helping dlls, Custom Pipeline Component etc.)

It will be helpful to easy to maintenance and support.

Solution Name: <PojectName>.<ClientName>.<Module>

                            Or <PojectName>.<ClientName>.<Module>.Integration

Project Name:




<PojectName>.<ClientName>.<Module>.Orchestration or <PojectName>.<ClientName>.<Module>.Process

<PojectName>.<ClientName>.<Module>.Utilities (for .net component)


Below is sample:

BizTalk Assembly Naming and Version: 

Assembly Name: <PojectName>.<ClientName>.<Module>.<Artifacts>.dll

Below are some examples: 

  • BizTalkTutorial.Blog.Test.Maps.dll
  • BizTalkTutorial.Blog.Test.Schemas.dll
  • BizTalkTutorial.Blog.Test.Orchestration.dll
  • BizTalkTutorial.Blog.Test.Utilities.dll
  • BizTalkTutorial.Blog.Test.CustomPipelines.dll
  • BizTalkTutorial.Blog.Test.Pipelines.dll

Naming conventions of BizTalk artifacts on Admin Console:

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


  • TypeOfPort.ToOrFrom/Purpose.Location

Example Test Integration:

  • Receive Port: Example – RcvPrt.Test or RP.Test
  • Receive Location: Example – RcvLoc.Test or RL.Test
  • Send Port Group: Example – SndGrp.Test.SQL or SG.Test.SQL
  • Send Port: Example – SendPrt.Test.SQL or SP.Test.SQL
  • Orchestration: – ProcessTestData or TestOrchestration


You need to create at least three new host instances at least on each BizTalk Server.

  • BizTalkReceive (Apply on ReceivePorts)
  • BizTalkSend (Apply on Send Ports)
  • BizTalkProcess (Apply on Orchestrations)

If You have many applications, then You can increase the no. of Host Instances based on load balancing and naming convention will be generated on basis of Adapters e.g. BizTalkSQLReceive

BizTalk Artifacts

SchemasRootNode[_version].xsd    Example: Invoice.xsd
Property SchemasPropertySchema.xsd
Pipelines  (Description of function or Module) [PassThru|XML|FlatFile|ESB](Receive|Send).btp
Orchestrations(Indication of function).odx

Orchestration Artifacts

Logical Ports  Indication of direction, combined with type, and/or possibly function    Examples: ReceiveTestdata, SendOrders, ReceiveStockRequest
Port Types  Indication of type, no direction    Examples: MessageTypes, StockService  
Operations  Indication of type of function, preferably no direction   Examples: TestData, FailedMessage
Messages  msg(type indication and optionally direction)   Examples: msgReceive, msgFault, msgSend, msgResponse
Correlation Types  Functional indication  Examples: ESBExceptionPromotion
Correlation Sets   “Instantiation” of Correlation Type name Examples: PromoteParty, CorrelateOnReceivePort
Shapes  It is not possible to define a single naming guideline for naming of shapes. however, below things to avoid are: Keeping default names (“Receive_1” etc)Not giving the “executing” shapes a unique (within the orchestration) and descriptive name Some example for shapes name: Transform shape: “Map LIMS TO J5”Expression shape: “Copy Context”Send shape: “Send TestData

BizTalk Server Monitoring

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

Blog at

%d bloggers like this: