通过

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