[last update: 2013-12-13]
The “Naming guidelines for the .NET Framework types” and "Guidelines for names" are
used as a basis for this document. Also see the “Naming Convention” in Wikipedia.
See the BizTalk Orchestration Naming Conventions for names inside orchestration.
Names should be short, sortable, readable, discoverable, and self-describing.
When constructing name you should ask yourself these questions:
Frequently names are used in the name lists. Think about these lists as namespaces in programming languages. Long name lists are always grouped with some logical hierarchy. Naming Conventions help to organize this hierarchy.
Composite names are names composed from several words in Pascal format without separating symbols.
Artifacts can use full names or logical names.
Logical names are composite or single-word names with or without separating symbols [.-_/]. A logical name defines a logical entity within a logical hierarchy. A logical name could hold some hierarchical information and could be composed from
Full names are compounded from logical names separated by separating symbols. Full names express logical hierarchical grouping.
See this document for example how to use logical and full names.
<Word> =: [A-Z][a-z1-0]*
<CompositeName> =: <Word>[._]<Word>[[._]<Word>]
<LogicalName> := <Word>[.<Word>]
<Domain> =: <Word>
<Solution> =: <LogicalName>
<SolutionNamespace> =: <Company>.<Domain>.<Solution>
<BizTalkApplication> =: <Namespace>
<DotNetNamespace> =: <Namespace>.<LogicalName>
c:\Solutions <SolutionFolder> =: <SolutionsRootFolder><Company><Domain>\
Solution> <ProjectFolder> =: <SolutionFolder>\<Project>
<OrchestrationProject> =: <Namespace>.Orchs
<SchemaProject> =: <Namespace>.Schemas
<MapProject> =: <Namespace>.Maps
<PipelineProject> =: <Namespace>.Pipelines
<PipelineComponentProject> =: <Namespace>.PipelineComponents
<SchemaTargetNamespace> =: http://<Namespace>[.Qualifier][/<Version>]
<Version> =: <integer>.<integer>.<integer>
<date> [in YYYY-MM-DD format]
<Orchestration> =: <LogicalName>
<Schema> =: <LogicalName>
<LogicalName>_FF [for Flat File schema]
<Map> =: <SourceSchema>_to_<DestinationSchema> [for one-to-one map]
<Pipeline> =: <LogicalName>
<ReceivePort> =: <Namespace>.<LogicalName>
<ReceiveLocation> =: <ReceivePort>.<TransportType>
<SendPort> =: <Namespace>.<LogicalName>.<TransportType>
<MapNamespace> =: <OrchestrationNamespace> =: <ProjectNamespace>[.<Qualifier>]*
<MessageType> =: <SchemaNamespace>#<SchemaRootName>
<MessageLogicalName> =: <SchemaRootName>
Prefer strict rules for the XML namespaces, because they are an important part of the XML documents. Those XML documents expose data to the external applications. So the XML namespaces are visible to these external applications. The XML namespaces should
follow the industry standards and the corporate standards. XML namespaces work as the global unique identifiers for the XML documents nodes.
When interface is exposed, it cannot be easily changed, because the external applications depend on it. It should be considered immutable, that's why the
versioning of the XML namespaces is very important.
The URL or URN are used for the XML namespaces. Feel free to use one of these standards. See the “Namespaces in XML 1.0 (Second Edition)”http://www.w3.org/TR/xml-names/ for
URL format is widespread and users are familiar with it. There are several confusions about using URL as an XML namespace:
Example: for the MyCompany.MyDomain.MySolution
solution and the MyProject project the XML namespace should be like this:
Are the shorter names always better?
Usually we have two choices: using logical names or using full names.
When we work with names in global lists, where artifacts of many BizTalk applications are mixed, we have to use full names. In those global lists the leftmost part of the name, which is the namespace (the BizTalkApplication name), helps in grouping and
fast searching of artifacts. But, if, for example, a global list has a separate column with a BizTalkApplication name, we do not have to use a full name because we can use the BizTalkApplication column for the fast searching and grouping. But using logical
names in the global namespace force us to use unique names, which is e a problem with long name list.
Global lists are used in:
Lists with these artifacts are always provided with a BizTalk application name. Visibility of these artifacts is limited the application boundary. We don’t need to use composite names. Use logical names for these artifacts.
Tip: If you see the same word in several places of a full name, consider this as a bad signal. Try to rethink the name design rules. I repeat this rule here again, because exactly in the full names of orchestrations, schemas and pipelines
we can frequently see the repetitive words.
Ports are the primary artifacts of the BizTalk solution. Visibility of send and receive ports, and receive locations (sic!) is limited by the BizTalk Group boundary, not the application boundaries. BizTalk forces us to use unique names for ports across all
applications, so we have to use full names.
Consider this chapter as “out-of-scope”. The artifact and files placement is a separate and wealthy topic. Here only main considerations are. See this
document for examples.
For the BizTalk projects with different artifacts you can add the Schemas, Orchestrations, and
Maps solution folders to group projects by artifact type.
Several BizTalk artifacts are out of scope this naming convention:
Another important place to find a huge amount of BizTalk related articles is the TechNet Wiki itself. The best entry point is
BizTalk Server Resources on the TechNet Wiki.