Example BizTalk Server 2004 Naming Conventions

I thought you might find these useful (courtesy of Aleksey Savateyev et. al.)

The table below includes prefixes/suffixes that should be used when naming BizTalk 2004 orchestration types and send and receive ports. In addition, each prefix must be followed by a logical object/entity name. For the object name, follow these guidelines:

§ Spell out all words used in the name. Do not abbreviate unless the object name becomes long.

§ Avoid the use of underscores within object names.

§ Object names shall be in standard “Hungarian” (upper and lower) case.

§ No spaces are allowed in object names.

Configuration/Object Name	Prefix	Suffix	Example
BizTalk Orchestration Artifacts
Orchestration Port Types	oprt	Type	oprtPOTypeSend oprtPOTypeReceive
Send Port	prt	Send Receive Both Adapter: FILE SQL HTTP SOAP	prtPOSendFILE
Receive Port	prt	Send Receive Both	prtPOReceive
Orchestration Port	oprt	Send Receive Both	oprtPOReceive oprtInvoiceSend
Mult Part Message Type	mpm	Type	mpmSalesOrderType
Multi Part Message	mpm		mpmSalesOrder
Correlation Type	cor	Type	corMatchPOToSupplierType
Correlation Set	cor		corMatchPOToSupplier
Role Link Type	rol	Type	rolReceivePOType
Role Link	rol		rolReceivePO
Variables (Opt)	.net coding standards		strFoo dtmDeadline intBox
Messages (opt)	msg		msgNWPO
Orchestration Type	orc	Type	OrderProcessType
Message Queue	que		queErrors
BizTalk Receive Location	rloc	TransportType : FILE SQL HTTP SOAP	relPOFILE
BizTalk Schema Specification	sch	(opt) FLATFILE XML EDI IDOC ENV	schPurchaseOrderXML
BizTalk Map	map		mapPOFLATFILEToTriggerXML
Functoid (Within Maps)	fnc		fncCurrentDate

Schema/Document Definition Naming Convention

In addition to the “sch” prefix that is appended to all BizTalk specifications and document definitions, the following convention should be followed:

“sch” + [Description] + [Type of Schema]

where:

§ Description = a document description maybe a project name or entity name or application name

§ Type of Schema: FLATFILE, EDI, XML

Map Naming Conventions

In addition to the “map” prefix appended to all BizTalk maps, the following naming convention should be followed:

“map” + [SourceSpec] + “To” + [DestinationSpec]

where:

§ SourceSpec = name of source specification excluding the specification prefix “sch”

§ DestSpec = name of destination specification excluding the specification prefix “sch”

Comments

• Anonymous
  July 20, 2004
  In the shameless plug category, another set of naming conventions can be found here:
  
  http://www.traceofthought.net/PermaLink,guid,c721d9a7-d518-47b5-a2ce-0ce1cbfa7bd0.aspx
• Anonymous
  July 20, 2004
  What I really don't like with the above are the prefix on filenames, the file extension already indicate this. My view on naming guidelines can be found here (another shameless plug :-): http://www.netologi.se/biztalk.aspx?Contents=BizTalkNamingGuidelines
• Anonymous
  July 20, 2004
  According to mircrosoft .net recommend conventions, it is not likely to use prefix.
  so I see it it is not that good to use prefix here.
• Anonymous
  July 20, 2004
  I don't get the receivelocation.......
  
  BizTalk Receive Location
  Prefix : rloc
  TransportType : FILE
  
  Resulting filename : relPOFILE
  
  shouldn't this be rlocPOFILE
  
  
• Anonymous
  July 22, 2004
  I have to agree with the anonymous commenter above. It feels very wrong to me to use a Hungarian style prefix scheme (e.g. rlocPOFILE) with BizTalk when all the rest of .NET has moved to descriptive names (e.g. PurchaseOrderFileReceiveLocation).
  
  Is there any method to this? Or is it just that some people are stuck in the 90s?
• Anonymous
  July 23, 2004
  I feel that one reason for actually using perfixes with BizTalk Orchestration code is that the development environment is different from normal VS projects:
  * The size of the Expression editor is very limited, so if you use very long names you'll only see the variable and the you have to scroll...
  * Variables, messages, etc. are "graphically declared" in a separate window. I think that by aiding the coder by using varXYZ and msgXYZ you gain some information that is otherwise hard to convey.
  
  However, I do not think that you should use prefixes in Messaging related things, e.g. receive locations.
• Anonymous
  July 29, 2004
  So, we should 'plug our own' ... and stick to it ;-)
  
  
• Anonymous
  August 04, 2004
  Brandon Gross and I came up with these when Brandon was initially creating the labs for Jupiter.
  
  Biztalk artifacts are different and as Mattias said in his earlier post; names can very long and sometimes difficult to read in files/windows.
  
  There is a typo in the receive location name in the above table..it should be rloc. There was an earlier draft that started floating around before we could solidify it. The send port prefixes are sprt and the receive port is rprt and the orchestration port prefixes are oprt.
  
  For an updated list to the above; refer to my June post in our glog in the below link.
  
  http://caffedharma.com/tech/files/naming.htm
  
  
  Look; I am not necessarily disagreeing with some of your feedback here but when you dont like these; I suggest you recommend an alternative like Colestock did. Using nothing is just not a good idea...
  
  Cheers~
  Ananth Krishna
  
• Anonymous
  August 16, 2004
  Hi,
  
  any opinions on what will be the graphical notations for BPEL going forward? Will it be BPMN?
  
  Regards,
  Srinivas.
• Anonymous
  April 28, 2005
  Abstract: the use of a hierarchical naming convention allow to group messaging artifacts in a tree-like...