Logo
programming4us
programming4us
programming4us
programming4us
Home
programming4us
XP
programming4us
Windows Vista
programming4us
Windows 7
programming4us
Windows Azure
programming4us
Windows Server
programming4us
Windows Phone
 
Windows Server

BizTalk Server 2006 : Starting a New BizTalk Project - BizTalk Naming Conventions

- Free product key for windows 10
- Free Product Key for Microsoft office 365
- Malwarebytes Premium 3.7.1 Serial Keys (LifeTime) 2019
5/3/2013 5:54:47 PM

One of the key benefits of coding business processes using BizTalk orchestrations is the visual representation of the workflow. When building complex orchestrations, naming conventions are critical for orchestration workflow shapes, and are equally important to naming BizTalk artifacts such as maps, ports, and pipelines properly. Using well-defined naming conventions allows both technical and nontechnical persons to view the orchestration and understand the process it is attempting to model. Well-named and comments orchestration shapes enhance the readability and organization of the workflow and allow the reader to follow the flow of messages through the orchestration and understand the source, destination, and content of the message data.

The following sections provide a guide for naming BizTalk artifacts along with orchestration shapes and types.

A BizTalk artifact is any one of the following:

  • Schema: This is an XSD schema that defines the data structure. Schemas can define XML or a flat file.

  • Map: A BizTalk map defines mappings between two different schemas. For instance, a purchase order schema has fields that can be mapped to an invoice schema. The map will transfer the data from the source (purchase order) schema to the destination (invoice) schema.

  • Pipeline: This can be a send or receive pipeline component. Pipelines are used on the send or receive points of BizTalk to do special processing on a message before it is sent out or as it is received.

  • Orchestration: An orchestration is where the business process is designed and executed.

  • Property schema: This is a special type of XSD schema used to define properties to be employed in BizTalk.

BizTalk Artifact Namespaces

Artifacts in BizTalk server are usually in the end .NET classes. As such, it is generally advisable to follow proper .NET naming conventions as would be followed in any regular .NET development project. Specifically, classes should be named based on the following pattern:

Company.Project.Feature

In the case of BizTalk projects, most developers want a clear delineation between objects that are only used within BizTalk Server and regular .NET classes. In these cases, the ".BizTalk" part of the namespace is added to give the following pattern:

Company.Project.BizTalk.Feature

As an example of this pattern, if a Pipeline existed within the FulFillment feature, that pipeline would be under the namespace of ABC.FulFillment.BizTalk.

InBoundReceivePipeline.

A schema uses a namespace to uniquely qualify elements and attributes within that schema to ensure that conflicts do not occur. Ultimately, uniquely identifying your BizTalk artifacts with namespaces is important.

Note that the naming conventions are Pascal cased, and nested namespaces will have dependencies on types in the containing namespace.

BizTalk Messaging Artifacts

All names should follow Pascal-case convention unless mentioned otherwise for the specific artifact, although underscores are used to separate logical entities. For schemas, maps, orchestrations, and pipelines, ensure that the .NET type name matches the file name (without file extension). Table 1 gives patterns for properly naming BizTalk artifacts.

Table 1. BizTalk Artifact Naming Conventions
ArtifactStandardNotesExamples
Schema file<RootNode>_<Standard> vn-ma.xsd or <DescriptiveName> vn-ma_<Standard>.xsdStandards include XML, X12, flat file (FF), and other custom formats.

If root node does not distinguish the schema or if the schema is for a well-known standard, use a descriptive name.

vn refers to major version number,m refers to minor number. For unreleased schemas, use a letter suffix to the minor version (like "a"). Include version in the version attribute of the schema element.

.NET type name should match, without file extension.

.NET namespace will likely match assembly name.
ClaimInvoice.xsd PurchaseOrderAcknowledge_FF.xsd FNMA100330_FF.xsd
Schema target namespacesNonshared schemas should have a target name- space corresponding to the .NET namespace of the associated .NET type, prefixed with "http"..NET type name should match, without file extension. .NET namespace will likely match assembly name.For a PatientClaim.xsd file, http://<Company>.<Function>. PatientClaim or http://<Contoso>. HealthClaims.PatientClaim
Property schema files<PropSchema>_PropSchema.xsdShould be named to reflect its common usage across multiple schemas, if needed.poPropSchema.xsd
Maps<SourceSchema>_To_<DestinationSchema>.btmName should define/describe what is being mapped.PurchaseOrder_FF_To_PurchaseOrderAcknowledge_XML.btm
OrchestrationsA meaningful name that represents the underlying process, likely with a verb-noun pattern. EvaluateCredit.odx ProcessHealthClaim.odx
Send/Receive Pipelinesrcv<SchemaName>.btp or rcv<ProjectName>.btp or rcv<Function>.btp snd<SchemaName>.btp or snd<ProjectName>.btp or snd<Function>.btpA pipeline might be used to ensure reception of particular schema(s) or to perform some other function. A project name might be used when multiple schemas are specified for ASM/DASM.rcvPOAckPipelineFF.btp

rcvCatalogPipeline.btp

rcvHealthClaimPipelineEDI.btp

rcvInvoiceFromSupplier Pipeline.btp

sndPaymentPipeline.btp

sndClaimProcessPipeline.btp

sndOrderToWarehouse sndOrderToWarehouse Pipeline.btp
Receive ports<BizApp> To<OutputSchema>Port<InputSchema< or <BizApp><Functional Description> or rcv<InputSchema>To <OutputSchema>Port or rcv<Functional Description>Port"BizApp" prefix (corresponding to the name of the app deploying to BizTalk) helps when many applications are deployed to the same BizTalk installation. Use functional description if the input schema (and potentially output schema, if request/ response) does not adequatelydescribe the port. One-way ports use functional description form.ERP_PurchaseOrder_XML_To_POAck_XML rcvPurchaseOrderToPOAckPort (for request/response port) ERP_PurchaseOrder_XML (for one-way port) ERP_CheckOrderStatus rcvPurchaseOrderXMLPort rcvERPStatusPort
Receive locations<ReceivePortName>_<Transport> ERPCheckOrderStatus_MSMQT rcvERPStatus_File
Send Port Groups<BizApp>_<Functional Description>"BizApp" prefix—see the receive ports entry.CRM_CustomerUpdateNotification
Send ports<BizApp><Schema> <Transport> or <BizApp><Func Description><DestApp>_<Transport> or snd<InputSchema>To <OutputSchema>Port or snd<Functional Description>PortIn some cases, the schema being sent is descriptive enough. In others, a functional description of the action to be taken by a destination app is better suited.CRM_CustomerUpdate_ERP_MSMQT sndUpdateToERPSystemPort sndOrderStatusPort
PartiesA meaningful name for atrading partner.If dealing with multiple entities in a trading partner organization, the organization name could be used as a prefix.INV_MyTradingPartnerName
RolesA meaningful name for the role that a trading partner plays. Shipper

Orchestration Naming Conventions—Workflow Shapes

The BizTalk Orchestration Designer allows you to create complex workflow automations quickly and easily. If you are not careful, however, a large orchestration can often become confusing and difficult to debug. One way to help ensure that your orchestration is maintainable is to properly name the orchestration shapes so that they are easily readable and self-explanatory. Microsoft has published some patterns on how to name orchestration shapes,[] and Table 2-3 expands upon these.

[] http://msdn.microsoft.com/library/default.asp?url=/library/en-us/BTS_2004WP/html/ffda72df-5aec-4a1b-b97a-ac98635e81dc.asp

NOTE

To add documentation to a group of related workflow shapes, use a Group shape. These will display as much text as you care to associate with them and can add quite a bit of documentation value to the diagram. (Shape names should always follow upper-camel casing after the prefix that is specified in Table 2.)

Table 2. Orchestration Workflow Shape Naming Conventions
ShapeStandardNotesExamples
ScopeScope_<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
ReceiveRcv_<MessageName> or Receive_<MessageName>Typically, MessageName will be the same as the name of themessage variable that is being received.Rcv_rawCreditReport Receive_CreditReport
SendSnd_<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
DecideDecide_<DescriptionOfDecision>Decide shapes should beprefixed with "Decide_"followed by a full description of what will be decided in the "If" branch.Decide_ApprovalRequired
If BranchIf_<DescriptionOfDecision>If Branch shapes should be prefixed with "If_" followed by a (perhaps abbreviated) description of what is being decided.If_ApprovalRequired
Else BranchElseElse 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 OrchestrationCall_<OrchestrationName> Start_<OrchestrationName>  
ThrowThrow_<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.
ParallelParallel_<DescriptionOfParallelWork>Parallel shapes should be named "Parallel_" followed by a description of what work will be done in parallel.Parallel_CreditVendorCalls
DelayDelay_<DescriptionOfWhatWaitingFor>Delay shapes should be named "Delay_" followed by an abbreviated description of what is being waited for.Delay_POAcknowledgeTimeout
ListenListen_<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
LoopLoop_<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. 
SuspendSuspend_<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
TerminateTerminate_<ReasonDescription>Terminate shapes describe why the orchestration terminated. More detail can be passed to an error property.Terminate_TimeoutsExpired
Call RuleCallRules_<PolicyName>The policy name may need to be abbreviated.CallRules_CreditApproval
CompensateCompensate 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
MessagecamelCasedThis 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
VariablecamelCased  
Port Type<function>PortTypePort 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>PortPorts 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 typeUpperCamelCasedCorrelation types should be named with upper-camel-case convention, based on the logical name of what is being used to correlate.PurchaseOrderNumber
Correlation SetcamelCasedCorrelation 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 ParametercamelCasedOrchestration parameters should be named with camelcase convention, and match the caller's names for the corresponding variables where needed. 
Other -----------------
- BizTalk Server 2006 : Starting a New BizTalk Project - BizTalk Assembly Naming and Versioning
- Windows Server 2003 : Protecting Hosts with Windows Host Firewalls - Protocol Filters
- Windows Server 2003 : Protecting Hosts with Windows Host Firewalls - Routing and Remote Access Basic Firewall
- System Center Configuration Manager 2007 : Customizing Configuration Manager Reports (part 3) - Reporting on Custom Data
- System Center Configuration Manager 2007 : Customizing Configuration Manager Reports (part 2) - Customizing Report Data Selection
- System Center Configuration Manager 2007 : Customizing Configuration Manager Reports (part 1) - Customizing Report Layout and Display
- System Center Configuration Manager 2007 : Reporting - Dashboards
- Client Access to Exchange Server 2007 : Getting the Most Out of the Microsoft Outlook Client - Deploying Outlook 2007
- Client Access to Exchange Server 2007 : Getting the Most Out of the Microsoft Outlook Client - Understanding RPC Over HTTPS in Outlook 2007
- SharePoint 2010 : Farm Governance - Configuring Resource Throttling
 
 
Top 10
- Microsoft Visio 2013 : Adding Structure to Your Diagrams - Finding containers and lists in Visio (part 2) - Wireframes,Legends
- Microsoft Visio 2013 : Adding Structure to Your Diagrams - Finding containers and lists in Visio (part 1) - Swimlanes
- Microsoft Visio 2013 : Adding Structure to Your Diagrams - Formatting and sizing lists
- Microsoft Visio 2013 : Adding Structure to Your Diagrams - Adding shapes to lists
- Microsoft Visio 2013 : Adding Structure to Your Diagrams - Sizing containers
- Microsoft Access 2010 : Control Properties and Why to Use Them (part 3) - The Other Properties of a Control
- Microsoft Access 2010 : Control Properties and Why to Use Them (part 2) - The Data Properties of a Control
- Microsoft Access 2010 : Control Properties and Why to Use Them (part 1) - The Format Properties of a Control
- Microsoft Access 2010 : Form Properties and Why Should You Use Them - Working with the Properties Window
- Microsoft Visio 2013 : Using the Organization Chart Wizard with new data
 
programming4us
Windows Vista
programming4us
Windows 7
programming4us
Windows Azure
programming4us
Windows Server