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 |
Receive-Send |
|
prefix |
S_+ |
R_+ |
SR_+ |
RS_+ |
Notes:
%u00b7
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.
%u00b7
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”
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:
- %u00b7
Shapes are too small to display long names (only
12-18 characters are visible). - %u00b7
We have to hover a mouse over a shape or click
shape to show Properties window to “understand” this shape, to
understand what message it is processed.
Useful features:
- %u00b7
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. - %u00b7
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. - %u00b7
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. - %u00b7
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
- %u00b7
Whenever it is possible use the short
MessageType as a shape name. - %u00b7
Do not repeat the type of shape icon by word. - %u00b7
Feel free to use spaces and any other symbols inside
the shape names. - %u00b7
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 whole orchestration processing.
Example: Send shape with name “OrderAck” means “send OrcherAck
message”.
Controversial: When exception is thrown from a shape,
the error description includes a name of the shape. 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 we could use numbers or single letters
in the end of names.
Example: “OrderAck 2”