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 which are the hierarchical groups. Think about these lists as namespaces in programming languages.
Composite names are
names composed from several words in Pascal format without separating symbols.
Examples: MySoulution, PatientRecord.
Artifacts can use full names or logical
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
Examples: MyCompany.SeattleOffice, MyDomain-DepartmentA, MySolution_Internal, Schemas.SystemX.
Full names are compounded from logical names separated by separating symbols. Full names express logical hierarchical grouping.
<date> [in YYYY-MM-DD format]
<LogicalName>_FF [for Flat File schema]
<SourceSchema>_to_<DestinationSchema> [for one-to-one map]
<SourceSchema1>_and_<SourceSchema2>_to_<DestinationSchema> [for two-to-one map]
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 more information.
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: http://MyCompane.MyDomain,MySolution.MyProject/2009-05-15
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.
Global lists are in:
Lists with these artifacts are always provided with a BizTalk application name. 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. 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 artifacts by 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.