Via our blogs, we frequently write articles about new and improved capabilities in our BizTalk360 product and how they can be used from a user perspective. However, besides that, we also want to bring good BizTalk Server related content. By doing so, we hope to bring articles with real-world value. Today’s blog is about using naming conventions when developing BizTalk solutions. Before we come to several proposals for naming conventions in BizTalk solutions, let’s first look at the reasons why you should use naming conventions.
Although developing BizTalk Server solutions is done in a bit more graphical way compared to hardcore code typing .NET development, it is of similar importance to properly name the components that you are developing. Source code that you frequently touch now, might not be touched for years, after it has been deployed. Still, even after such a long time, you want to quickly understand how a solution has been designed/developed. Documenting your solution, by using descriptive names for the components that you are developing, can play an important role in quickly understanding your solutions.
Using consistent naming conventions in your BizTalk solutions helps in different ways. Think of:
Now we understand the importance of using naming conventions, let’s have a look at commonly used naming conventions for BizTalk Server solutions. We’ll segregate the conventions in the following sections:
You could name your BizTalk applications as follows:
<Company>.<Domain>.<Solution>
The conventions for BizTalk artifacts are divided in 5 categories. There is a separate section for the naming conventions of orchestration shapes, etc.
|
Property |
Description |
|
Filename Standard |
<RootNode><Standard>.xsd <DescriptiveName><Standard>.xsd |
|
Filename Example |
PurchaseOrderAcknowledge.xsd PurchaseOrderAcknowledgeFF.xsd |
|
Notes |
<Standard> includes XML, X12, FlatFile (FF), and other custom formats. XML is optional, because it is default. |
|
Property |
Description |
|
Filename Standard |
<Schema file>PropertySchema.xsd. |
|
Filename Example |
PurchaseOrderAcknowledgePropertySchema.xsd |
|
Notes |
Property Schema File should be named to reflect its common usage. Post fixed with “PropertySchema” to help distinguish it from standard message schema (unless it is a general property schema) |
|
Property |
Description |
|
Filename Standard |
<Schema file source>_To_<Schema file destination>.btm If xslt file is specified: <Schema file source>_To_<Schema file destination>.xsl |
|
Filename Example |
PurchaseOrder_To_PurchaseOrderAcknowledge.btm |
|
Notes |
In case of multi part maps in the source and/or destination side, schemas should be separated with an underscore (_). I.e.: <Schema file 1 source>_<Schema file 2 source>_To_<Schema file 1 destination>_<Schema file 2 destination> If the name of a map becomes too long, it is allowed to abbreviate schema names, but try to be as descriptive as possible |
|
Property |
Description |
|
Filename Standard |
Receive: Rppl<Function>.btp Send: Sppl<Function>.btp |
|
Filename Example |
Receive: RpplPurchaseOrderAcknowledge.btp Send: SpplPurchaseOrderAcknowledge.btp |
|
Notes |
|
Property |
Description |
|
Filename Standard |
<Process description>.odx |
|
Filename Example |
EvaluateCredit.odx |
|
Notes |
When deployed, Orchestration “type name” is the name that is used and displayed by the BizTalk Server Administrator tools to refer the Orchestration. Make sure the type name is the same as the Orchestration filename. |
When you are adding BizTalk orchestrations to your BizTalk solutions, you should also properly name the Shapes and Types that you create in those orchestrations.
|
Shape |
Standard |
Example |
|
Scope |
Scope_<DescriptionOfTheFunction> |
Scope_CreditServiceCall |
|
Receive |
Rcv_<MessageName> |
Rcv_msgPurchaseOrder |
|
Send |
Snd_<MessageName> |
Snd_msgPurchaseOrderAcknowledge |
|
Expression |
Exp_<DescriptionOfTheFunction> |
Exp_GetFindingsReport |
|
Decide |
Decide_<DescriptionOfTheDecision> |
Decide_ApprovalRequired |
|
If branch |
If_<DescriptionOfTheCondition> |
If_ApprovalRequired |
|
Else branch |
Else |
Else |
|
Construct message |
Construct_<Message> |
Construct_msgPurchaseOrderAcknowledge |
|
Assign |
Assign_<Message> or |
Assign_PromotedProperties |
|
Transform |
Name of the map |
PurchaseOrder_To_PurchaseOrderAcknowledge |
|
Call Orchestration |
Call_<OrchestrationName> |
Call_EvaluateCredit |
|
Start Orchestration |
Start_<OrchestrationName> |
Start_EvaluateCredit |
|
Throw Exception |
Throw_<ExceptionType> |
Throw_SystemExcepion |
|
Parallel |
Parallel_<DescriptionOfTheParallelActions> |
Parallel_CreditVendorCalls |
|
Delay |
Delay_<DescriptionOfWaitingFor> |
Delay_PurchaseOrderAcknowledgeTimeout |
|
Listen |
Listen_<DescriptionOfOutcome> |
Listen_PurchaseOrderAcknowledgementOrTimeout |
|
Loop |
Loop_<ExitCondition> |
Loop_WhileErrorFlagTrue Loop_UntilAllMsgsSent |
|
Suspend |
Suspend_<Reason> |
Suspend_ReEstablishCreditLink |
|
Terminate |
Terminate_<Reason> |
Terminate_TimeoutsExpired |
|
Call Rules |
CallRules_<PolicyName> |
CallRules_CreditApproval |
|
Compensate |
Compensate_<WhatIsCompensated> |
Compensate_TransferFunds |
|
Type |
Standard |
Example |
|
Multi-Part Message Types |
<LogicalDocumentType> PascalCased |
InvoiceReceipt |
|
Multi-Part Message Parts |
<SchemaNameOrPart> PascalCased |
InvoiceHeader |
|
Messages |
msg<MessageDescription> camelcased |
msgPurchaseOrder |
|
Variables |
<variableFunction> |
transportType |
|
Ports |
<function>Port PascalCased |
ProcessPurchaseOrderPort |
|
Port Types |
<function>PortType PascalCased |
ProcessPurchaseOrderPortType |
|
Port Operations |
Send<Message> Receive<Message> |
SendPurchaseOrder ReceivePurchaseOrder |
|
Correlation Sets |
<WhatisCorrelatedOn> camelCased |
PurchaseOrderNumber |
|
Correlation Types |
<whatisCorrelatedOn> PascalCased |
purchaseOrderNumber |
|
Orchestration Parameters |
<matchCallerVariableNames> camelCased |
transportType |
Besides the artifacts that you develop in Visual Studio, after deployment, you will also create ports in the BizTalk Server Administration Console. For easy understanding the purpose of all those ports, you need to give them a descriptive name that follows a naming convention.
|
Type |
Standard |
Example |
|
Receive Port |
RP_<FunctionalDescription> RP_<PartyOrApplication>_<FunctionalDescription> |
RP_PurchaseOrder |
|
Receive Location |
RL_<FunctionalDescription> RL_<PartyOrApplication>_<FunctionalDescription> |
RL_PurchaseOrder RL_AX_PurchaseOrder |
|
Send Port |
SP_<FunctionalDescription> SP_<PartyOrApplication>_<FunctionalDescription> |
SP_FaultToAdministrator SP_SAP_PurchaseOrder |
|
Send Port Group |
SPG_<FunctionalDescription> |
SPG_PurchaseOrder |
In this article, we have started with explaining why naming all your BizTalk artifacts is a good practice. After we got that out of the way, we have shown naming conventions for the artifacts that BizTalk developers create in Visual Studio and the ports you create in the BizTalk Server Administration console.
As mentioned in the beginning of this post, in this blog, we don’t want to just promote BizTalk360, but we also want to bring posts with real-world value. Whether you are a developer or an administrator, we got plenty of resources that you might be interested in.
Feel free to check the following websites/sections:
We hope that you find those resources useful. Feel free to get in touch in case you are looking for specific information you cannot find.
