Artifact

Standard

Notes

Example

Schema

<DescriptiveName>.xsd

.NET Type name should match, without file extension. 

.NET Namespace will likely match assembly name.

PurchaseOrderAcknowledge_FF.xsd  or

FNMA100330_FF.xsd

Property Schema

Should be named to reflect possible common usage across multiple schemas 

Map

<SourceSchema>2<DestinationSchema>.btm

Exceptions to this may be made where the source and destination schemas share the majority of the name, such as in mainframe web service maps

Orchestration

<DescriptiveName>.odx

Send/Receive Pipeline

<DescriptiveName>.btp

ValidatingXMLReceivePipeline.btp

FlatFileAssembler.btp

Receive Port

A plainly worded phrase that will clearly explain the function. 

Receive Location

A plainly worded phrase that will clearly explain the function.

 ? Do we want to include the transport type here ?

Send Port Group

A plainly worded phrase that will clearly explain the function.

Customer Updates

Send Port

A plainly worded phrase that will clearly explain the function. 

Parties

A meaningful name for a Trading Partner.

If dealing with multiple entities within a Trading Partner organization, the Organization name could be used as a prefix.

Roles

A meaningful name for the role that a Trading Partner plays.

Shape

Standard

Notes

Example

Scopes

<DescriptionOfContainedWork> or

<DescOfcontainedWork><TxType>

Including info about transaction type may be appropriate in some situations where it adds significant documentation value to the diagram.

HandleReportResponse

Receive

Receive<MessageName>

Typically, MessageName will be the same as the name of the message variable that is being received “into”.

ReceiveReportResponse

Send

Send<MessageName>

Typically, MessageName will be the same as the name of the message variable that is being sent.

SendValuationDetailsRequest

Expression

<DescriptionOfEffect>

Expression shapes should be named to 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.

CreatePrintXML

Decide

<DescriptionOfDecision>

A description of what will be decided in the “if” branch

Report Type?

Perform MF Save?

If-Branch

<DescriptionOfDecision>

A (potentially abbreviated) description of what is being decided

Mortgage Valuation

Yes

Else-Branch

Else

Else-branch shapes should always be named “Else”

Else

Construct Message (Assign)

Create<Message>

(for Construct)

<ExpressionDescription>

(for expression)

If a Construct shape contains a message assignment, it should be prefixed with “Create” 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.

CreateReportDataMV

which contains expression:

ExtractReportData

Construct Message (Transform)

Create<Message>

(for Construct)

<SourceSchema>2<DestSchema>

(for transform)

If a Construct shape contains a message transform, it should be prefixed with “Create” followed by an abbreviated name of the message being assigned.

The actual message transform shape contained should generally be named the same as the called map. 

CreateReportDataMV

which contains transform:

ReportDataMV2ReportDataMV

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

ThrowRuleException, which references the “ruleException” variable.

Parallel

<DescriptionOfParallelWork>

Parallel shapes should be named by a description of what work will be done in parallel

Delay

<DescriptionOfWhatWaitingFor>

Delay shapes should be named by a description of what is being waited for. 

POAcknowledgeTimeout

Listen

<DescriptionOfOutcomes>

Listen shapes should be named by a description that captures (to the degree possible) all the branches of the Listen shape

POAckOrTimeout FirstShippingBid

Loop

<DescriptionOfLoop>

ForEachValuationReport

WhileErrorFlagTrue

Role Link

See “Roles” in messaging naming conventions above.

Suspend

<ReasonDescription>

Describe what action an administrator must take to resume the orchestration.  More detail can be passed to error property – and should include what should be done by the administrator before resuming the orchestration.

ReEstablishCreditLink

Terminate

<ReasonDescription>

Describe why the orchestration terminated.  More detail can be passed to error property.

TimeoutsExpired

Call Rules

Call<PolicyName>

The policy name may need to be abbreviated.

CallLendingPolicy

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 simple be Compensate.

CompensateTransferFunds

Type

Standard

Notes

Example

Multi-Part Message Types

<LogicalDocumentType>

Multi-part 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 multi-part type should correspond to the “logical” document type, i.e. what the sum of the parts describes.

InvoiceReceipt

(which might encapsulate an invoice acknowledgement and a payment voucher.)

Multi-Part Messsage Part

<SchemaNameOfPart>

Should be named (most often) simply for the schema (or simple type) associated with the part.

InvoiceHeader

Messages

<SchemaName>

or

<MuliPartMessageTypeName>

Should be named based on the corresponding schema type or multi-part message type.  If there is more than one variable of a type, name for its use within the orchestration.

ReportDataMV

UpdatedReportDataMV

Variables

<DescriptiveName>

TargetFilePath

StringProcessor

Port Types

<FunctionDescription>PortType

Should be named to suggest the nature of an endpoint, with pascal 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 (i.e. one-way, request-response, solicit-response) that all operations on the port type adhere to.

ReceiveReportResponsePortType 

or

CallEAEPortType

(This is a two way port, so Receove or Send alone would not be appropriate.  Could have been ProcessEAERequestPortType etc....)

Ports

<FunctionDescription>Port

Should be named to suggest a grouping of functionality, with pascal casing and suffixed with “Port.” 

ReceiveReportResponsePort

CallEAEPort

Correlation types

<DescriptiveName>

Should be named based on the logical name of what is being used to correlate. 

PurchaseOrderNumber

Correlation sets

Should be named based on the corresponding correlation type.  If there is more than one, it should be named to reflect its specific purpose within the orchestration.

PurchaseOrderNumber

Orchestration parameters

Should be named to match the caller’s names for the corresponding variables where appropriate.