BizTalk Naming Convention. Names of artifacts in Orchestrations

 

[This article is depreciated. Please, use a new version of the Naming Convention on http://geekswithblogs.net/LeonidGaneline/archive/2009/07/31/biztalk-naming-convention-for-the-biztalk-solutions.aspx ]

BizTalk Naming Convention. Names of artifacts in Orchestrations

"Scott Colestock" <scolestock@community.nospam> wrote in message news:eeY5KIjEGHA.984@tk2msftngp13.phx.gbl...
> In general, try using more "Group" shapes to make orchestrations more
> self-documenting...
>
> A general text annotation feature in the designer would be great, wouldn't
> it?

Of course I use Group shapes, but not across each shape.

 

BTW, name of the most shapes can be based ONLY on the name of the schema. Usualy all what we want to know in orchestrations is the "message flow" and "message transformation". Think of it.

 

Schemas give us the main information about the messages. Icon information is enough to understand what exactly happened in shape under the messages: send, receive, mapping, etc.


If I'm working with the Orch which was created by somebody else, the standard way to review this orch is:
* look for the message of the shape (click the shape and see the properties)
* look for the schema of these messages (click the message and see the properties)
We have to click, click, click... Why?
If creator of the Orch uses the proposed naming convention all these steps disappeared. We can see exactly the "schema flow" and "schema transformation".

 

 

  

Goals of this naming convention:

 

  • Readable names
  • Fast-created names (using Copy-Past)
  • Fast search in the lists of BizTalk Explorer, Visual Studio and BizTalk Administration Manager

Problems with orchestration shapes:

Shapes too small to display long names (12-18 chars).

Frankly it was the main goal this document to take into consideration this problem. If we use the “BizTalk 2004 Naming Conventions” by Scott Colestock

http://www.traceofthought.net/misc/BizTalk%20Naming%20Conventions.htm

the result is pity, we create too long names.  

L We have to “hover mouse over” shape or click shape to show Properties window to "understand" this shape. The names are complicated.

 

Useful features:

·         Shape names are not the “real names”. In reality they are the descriptions (excluding the Port shapes names). It means we can give the same names to the different shapes without conflicts and we can use spaces inside the names.

·         Icons of shapes give us the useful information. We have icons and don’t have to repeat it by words. For example, if we change a name of Construction shape from “Construct Input message” to “Input message” we get more clear definition because we have the Construct icon + name. Unfortunately the meaning of the icons sometimes is not so clear. For example, the icons on the Send and Receive shapes look as mistaken: the arrow on Send shape icon points “inside” and the arrow on Receive shape points “outside”. But it’s the matter of habit. (This is another naming problem in BizTalk. See http://geekswithblogs.net/leonidganeline/archive/2006/12/18/101541.aspx)

·         Shape names are not used in any list (exclude the Port shapes names). We don’t have to use any rules to make the “well-sorted” names (it's the main purpose of the prefixes)

Purpose the most of the shapes is processing the messages. We can unambiguous describe the messages by they type that’s mean by they schema. That is why in the most cases using the schema names as the message names gives us the main information about this message. That is why in the most cases using the schema names as the shape names give us the main information about this shape. Send shape with name "ASC_X12_311" means ... exactly!

Don’t repeat the meaning of shape icon by word.

Don’t repeat words from external shape name into the internal shape name.

Use spaces inside the shape names

 

Construct, Receive and Send shapes:

= name of processed message (usually it is the schema of the message) without “msg_” prefix.

For example: [ORU_Modified]

Note: it’s easy to set and maintain this name: just copy part of it from Properties/Messages Constructed to Properties/Name. For example: From “msg_ORU_Modified” copy “ORU_Modified”

 

Transform shapes:

= “from “ + name of Source message

For example: [from ORU]

Note: it’s easy to set and maintain this name: just copy it (or part of it) from Properties/Input Messages to Properties/Name. For example: From “msg_ORU” copy “ORU”

Assignment shapes:

No strict rules, only advice:

Name it like the methods in classes. But cut a verb if it possible. Use “set” and “get” if it possible.

For example: [set segment OBX]

 

Port shapes:

 

 

Send port

Receive port

Send-Receive port (Solicit-Response)

Receive-Send port (Request-Response)

Port shape:

S_ +

R_ +

SR_ +

RS_ +

 

Note: it’s easy to set and maintain this name: just copy it from Properties/Port type to Properties/Name. For example: From “S_Account_Type” copy “S_Account”

 

Port types:

+ _Type

 

  • The Port shapes and Port type names are the real names! We can’t use spaces inside.
  • In the Orchestration view there are generic lists “Ports” and “Port types” that why we have to distinguish the ports with different Communication directions and pattern (see table below).
  • We can’t use the same name for the ports and for the port types.

 

Other shapes:

Use the short names. They could fit to the size of the shapes.

 

 

Message and variable name:

I use prefixes to fast (Intelly-sense) inserting the names in the expressions.

= “msg_” + schema name of this message without all namespace prefixes or .NET class 

For example: msg_ReportDiseases_request
if type of this message is PHSA.RCD.Orchestrations.ReportDiseases.ReportDiseasesService_.ReportDiseases_request

Note: it’s easy to set and maintain this name: just copy last part of it from Properties/Type field to Properties/Name field.

= “var_” + name

For example: var_XmlDocument
if type of this variable is System.Xml.XmlDocument .NET object

Note: it’s easy to set and maintain this name: just copy last part of it from Properties/Type field to Properties/Name field.

 

Print | posted on Tuesday, January 3, 2006 5:25 PM

Feedback

# re: BizTalk 2004 Naming Convention. Names of artifacts in Orchestrations

left by João Pedro Martins at 1/15/2006 11:01 PM Gravatar
I fully agree with your ideas. Most BizTalk recomendations are excessively verbose and (to me) make no sense.
Post A Comment
Title:
Name:
Email:
Comment:
Verification: