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 (11)

  1. 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

  2. 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

  3. Using Prefix is not recommend know says:

    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.

  4. Patrick Wellink says:

    I don’t get the receivelocation…….

    BizTalk Receive Location

    Prefix : rloc

    TransportType : FILE

    Resulting filename : relPOFILE

    shouldn’t this be rlocPOFILE

  5. 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?

  6. 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.

  7. So, we should ‘plug our own’ … and stick to it 😉

  8. 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

  9. Sthonse says:

    Hi,

    any opinions on what will be the graphical notations for BPEL going forward? Will it be BPMN?

    Regards,

    Srinivas.

  10. Abstract: the use of a hierarchical naming convention allow to group messaging artifacts in a tree-like…

Skip to main content