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>.Schemas
<PojectName>.<ClientName>.<Module>.Maps
<PojectName>.<ClientName>.<Module>.Pipelines
<PojectName>.<ClientName>.<Module>.Orchestration or <PojectName>.<ClientName>.<Module>.Process
<PojectName>.<ClientName>.<Module>.Utilities (for .net component)
<PojectName>.<ClientName>.<Module>.CustomPipeline
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
Framework:
- 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
Hosts
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
| Schemas | RootNode[_version].xsd Example: Invoice.xsd |
| Property Schemas | PropertySchema.xsd |
| Maps | SourceSchema_To_DestinationSchema.btm |
| 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 World 