BizTalk Orchestration Naming Conventions

 This is a second part of the BizTalk Naming Convention.

Special Orchestration Objects 

<Message> =: 
      msg_ + <ShortMessageType>

<Variable> =: 
      var_ + <Name>

<CorrelationSet> =: 
      cor_ + <Name>

<OrchestrationParameter> =: 
      par_ + < Name>

<RoleLink> =: 
      roleLink_ + <Name>

Note: These objects are special BizTalk objects. They are used in different language context and sometime they use different language syntax. Prefixes help to differentiate the objects in the XLang expressions.

<Port> =: 
      <prefix> + <Name>

where

Send

Receive

Send-Receive
(Solicit-Response)

Receive-Send
(Request- Response)

prefix

S_+

R_+

SR_+

RS_+

Notes:

  • The Port objects are the only objects which can be seen outside orchestration. We see them while bind orchestration with Ports, not the orchestration Ports but Ports created in the BizTalk Administration Console. Sometimes the orchestration Ports are named as Logical Ports and the Ports as the Physical Ports. Here are some considerations about this ambiguity with Port names.
  • Send-receive prefixes help while Orchestration is binding with Ports. Ports with different Communication pattern are using different prefixes.

Example: S_ OrderAck.

 

Orchestration Object Types

<ArtifactType> =:
      <ArtifactName> + “_type

Note: We can see orchestration types in the Orchestration View window in Types. They are: Port, Multi-part Message, Correlation and Role Link Types. We can use one suffix the “_type” for all different types because different types are seen only in the different lists and never mixed. For instance, we can never see the port types together with message types.

Controversial:Suffixes for types work better than prefixes, because types are mostly used in the drop-down lists not in the XLang expressions.

Orchestration Workflow Shapes

Problems with orchestration shapes:

  •         Shapes are too small to display long names (only 12-18 characters are visible).
  •         We have to hover a mouse over a shape or click shape to see Properties window and to "understand" this shape, to understand which message is processed.

Useful features:

  •          Shapes have names, but names are not the “variable names”, not identifiers. They are descriptions (excluding the Port shapes names, which have not Name parameter but Identifier and Description parameters). Shape names are used only for description not as XLang variable identifiers. Shape names can be long and can include any symbols as spaces, dots, etc.
  •          Icons of shapes give us the useful information. Do not repeat the “icon information” by words. For example, we can a name a Construction shape as “Construct OrderAck” or as “OrderAck”. Last variant give us more clear and short definition because we have the Construction icon + name.
  •          Shape names are used mainly in Orchestration Editor (excluding the Port shapes names). We don’t need the “well-sorted” names, so we don’t need to use prefixes, because the main purpose of the prefixes is creating well-sorted lists.
  •          Group shape is a scalable shape. Nesting other shapes to a Group shape can make a long description visible. Group shape will display as much text as you want. Group shapes add a lot of documentation value to the orchestration.

Rules for shapes

  •          Whenever it is possible use the short MessageType as a shape name.
  •          Do not repeat a type of shape icon by word.
  •          Feel free to use spaces and any other symbols inside the shape names.
  •          Feel free to repeat the shape names.

Note: Purpose of the orchestration and the most of the shapes is in processing the messages. We can unambiguously describe the messages by the message type. A message type gives us the main information about a message. That is why in the most cases using the message type as the shape name gives us the main information about message flow, about the whole orchestration processing.
Example: Send shape with name "OrderAck" means “send OrderAck message”.

Controversial:

  • Orchestration Naming Convetion works not to make easier the administration and troubleshooting but mostly to make orchestration more readable. Most orchestration names are not visible outside the Orchestration Editor. So, do not force the orchestration naming convention to hard! If your developers use differen conventions, it is fine; of course, if they understand each other. Forcing convention can do more harm than help. It can force team to spend more effort for a little.
  • When exception is thrown from a shape, the error description includes a name of the shape. It is a rare case when names are exposed outside of the Orchestration Editor. When we use MessageType as a name of shapes, many shapes can get the same name. So, if we want to differentiate shape names for debugging purpose, we could use numbers or single letters in the end of names.
    Example: “OrderAck 2”

 

Print | posted on Wednesday, December 28, 2011 12:38 PM

Feedback

# Formatting issue

left by Howard Edidin at 12/30/2011 8:51 AM Gravatar
Lenoid,

The article appears to have format tags <!--[if !supportLists]--> in it. It makes is difficult to read.

# re: BizTalk Orchestration Naming Conventions

left by Leonid Ganeline at 12/30/2011 11:15 AM Gravatar
Yeah, sorry for that. I'll try to fix it when have time.

# re: BizTalk Orchestration Naming Conventions

left by north face at 1/3/2012 12:53 AM Gravatar
Your article is very attractive to me.
Post A Comment
Title:
Name:
Email:
Comment:
Verification: