| Scope | Scope_<DescriptionOf ContainedWork> or Scope_<DescOfContained Work>_<TxType> | Info
about transaction type may need to be included in some situations where
it adds significant documentation value to the diagram. | Scope_CreditServiceCall |
| Receive | Rcv_<MessageName> or Receive_<MessageName> | Typically, MessageName will be the same as the name of themessage variable that is being received. | Rcv_rawCreditReport Receive_CreditReport |
| Send | Snd_<MessageName> or Send_<MessageName> | Typically, MessageName will be the same as the name of themessage variable that is being sent. | Snd_poAcknowledge Send_poAck |
| Expression | <DescriptionOfEffect> | Expression
shapes should be named with upper-camel-case convention (no prefix) to
simply describe the net effect of the expression, similar to naming a
method. The exception to this is the case where the expression is
interacting with an external .NET component to perform a function that
overlaps with existing BizTalk functionality— use closest BizTalk shape
for this case. | GetFindingsReport |
| Decide | Decide_<DescriptionOfDecision> | Decide shapes should beprefixed with "Decide_"followed by a full description of what will be decided in the "If" branch. | Decide_ApprovalRequired |
| If Branch | If_<DescriptionOfDecision> | If Branch shapes should be prefixed with "If_" followed by a (perhaps abbreviated) description of what is being decided. | If_ApprovalRequired |
| Else Branch | Else | Else Branch shapes shouldalways be named "Else". | Else |
| Construct Message (Message Assignment) | Assign_<Message> (forConstruct shape)<ExpressionDescription> (for expression) | If
a Construct shape contains a message assignment, it should be prefixed
with "Assign_" followed by an abbreviated name of the message being
assigned. The actual message assignment shape contained should be named
to describe the expression that is contained. | Assign_paymentVoucher which contains the expression CopyPaymentDetails |
| Construct Message (Transform) | Xform_<SourceSchema>
To<DestSchema> (for Construct) or X_<SourceSchema>To
<DestSchema> (for expression) or Construct_<DestSchema> | If
a Construct shape contains a message transform, it should be prefixed
with "Xform_" followed by an abbreviated description of the transform
(i.e., source schema to destination schema). The actual message
transformshape contained should generally be named the same as the
containing shape, except with an "X_" prefix to save space. | Xform_LoanRequestTo CreditRequestwhich contains transform shape X_LoanRequestToCredit Request or Construct_Invoice |
| Construct Message (containing multiple shapes) | | If
a Construct Message shape uses multiple assignments or transforms, the
overall shape should be named to communicate the net effect, using no
prefix. | |
| Call Orchestration Start Orchestration | Call_<OrchestrationName> Start_<OrchestrationName> | | |
| Throw | Throw_<ExceptionType> | The corresponding variable name for the exception type should (often) be the same name as the exception type, only camel cased. | Throw_RuleException, which refers to the ruleException variable. |
| Parallel | Parallel_<DescriptionOfParallelWork> | Parallel shapes should be named "Parallel_" followed by a description of what work will be done in parallel. | Parallel_CreditVendorCalls |
| Delay | Delay_<DescriptionOfWhatWaitingFor> | Delay shapes should be named "Delay_" followed by an abbreviated description of what is being waited for. | Delay_POAcknowledgeTimeout |
| Listen | Listen_<DescriptionOfOutcomes> | Listen
shapes should be named "Listen_" followed by an abbreviated description
that captures (to the degree possible) all the branches of the Listen
shape. | Listen_POAckOrTimeout Listen_FirstShippingBid |
| Loop | Loop_<ExitCondition> | Loop shapes should be named "Loop_" followed by an abbreviated description of what the exit condition is. | Loop_AllMsgsSent |
| Role Link | | See "Roles" in Table 2-2 earlier. | |
| Suspend | Suspend_<ReasonDescription> | Suspend
shapes describe what action an administrator must take to resume the
orchestration. More detail can be passed to an error property—and should
include what should be done by the administrator before resuming the
orchestration. | Suspend_ReEstablishCreditLink |
| Terminate | Terminate_<ReasonDescription> | Terminate shapes describe why the orchestration terminated. More detail can be passed to an error property. | Terminate_TimeoutsExpired |
| Call Rule | CallRules_<PolicyName> | The policy name may need to be abbreviated. | CallRules_CreditApproval |
| Compensate | Compensate or Compensate_<TxName> | If
the shape compensates nested transactions, names should be suffixed
with the name of the nested transaction—otherwise it should simply be
"Compensate". | Compensate_TransferFunds or Comp_TransferFunds |
| Multi-Part Message Type | <LogicalDocumentType> | Multipart
types encapsulate multiple parts. The WSDL spec indicates "Parts are a
flexible mechanism for describing the logical abstract content of a
message." The name of the multipart type should correspond to the
"logical" document type, i.e., what the sum of the parts describes. | InvoiceReceipt (Might encapsulate an invoice acknowledgement and a payment voucher) |
| Multi-Part Messsage Part | <SchemaNameOfPart> | This shape should be named (most often) simply for the schema (or simple type) associated with the part. | InvoiceHeader |
| Message | camelCased | This
shape should be namedusing camel casing, based on the corresponding
schema type or multipart message type. If there is more than one
variable of a type, name it after its use in the orchestration. | purchaseOrderAck |
| Variable | camelCased | | |
| Port Type | <function>PortType | Port
types should be named to suggest the nature of an endpoint, with
upper-camel casing and suffixed with "PortType". If there will be more
than one port for a port type, the port type should be named according
to the abstract service supplied. The WSDL spec indicates port types are
"a named set of abstract operations and the abstract messages involved"
that also encapsulates the message pattern (e.g., one-way,
request-response, solicitresponse) that all operations on the port type
adhere to. | ProcessPurchaseOrder PortType which might have operations such as SubmitPO or RequestPOStatus |
| Port | <function>Port | Ports should be named to suggest a grouping of functionality, with upper-camel casing and suffixed with "Port". | ProcessPurchaseOrderPort |
| Port Operation | <MethodName> | Port
operations should be named according to the "method"—i.e., what subset
of the port functionality will be exercised. For a port that has one
operation, it can be commonly named "Submit". Note that these operation
names appear in WSDL for webservice- published orchestrations. | |
| Correlation type | UpperCamelCased | Correlation
types should be named with upper-camel-case convention, based on the
logical name of what is being used to correlate. | PurchaseOrderNumber |
| Correlation Set | camelCased | Correlation
sets should be named with camel-case convention based on the
corresponding correlation type. If there is more than one, it should be
named to reflect its specific purpose in the orchestration. | purchaseOrderNumber |
| Orchestration Parameter | camelCased | Orchestration
parameters should be named with camelcase convention, and match the
caller's names for the corresponding variables where needed. | |
