2

When starting a BizTalk project I generally follow the naming conventions found here. Where you name your projects and assembly's something like:

MyCompany.MyProject.Orchestrations.dll
MyCompany.MyProject.Schemas.dll
MyCompany.MyProject.Pipelines.dll
MyCompany.MyProject.Transforms.dll
MyCompany.MyProject.PipelineComponents.dll

A couple of questions for other BizTalk folks:

1) I usually find myself having more than one project with schemas or a need to separate schemas. Do you stick them in separate assemblies and if yes, what convention do you then follow for naming the project/assembly. If no, do you stick them in a subfolder in one assembly.

2) I believe, could be wrong, that it's been sort of a BizTalk convention to name the project and assembly the same, like above. I've thought about getting away from naming the projects the same as the full assembly name, so I might have the project named Maps and it's assembly is named MyCompany.MyProject.Maps. Do others do this?

Derek Beattie
  • 9,429
  • 4
  • 30
  • 44

2 Answers2

4

Starting with BTS 2009 we named our projects and assemblies according to the application they belong to plus an optional sub-application or concern scope:

MyCompany.Biz.MyFirstApp.dll
MyCompany.Biz.MyFirstApp.Util.dll
MyCompany.Biz.MyFirstApp.ConcernOne.dll
MyCompany.Biz.MySecondApp.dll

We took the path to keep orchestrations, schemas and maps together because multi-assembly dependencies can make deployment a real hassle.

Our main goal was to separate source and target systems to avoid direkt references. We achieved this be introducing "core" components for all concerns we're dealing with:

BTS application MyFirstApp

MyCompany.Biz.MyFirstApp.OrderProcessing.dll
MyCompany.Biz.MyFirstApp.Util.dll

BTS application CORE

MyCompany.Biz.CORE.OrderProcessing.dll

BTS application MySecondApp

MyCompany.Biz.MySecondApp.OrderProcessing.dll

Both MyFirstApp and MySecondApp will reference schemas in CORE.OrderProcessing.

Update

MyCompany.Biz.MyFirstApp.OrderProcessing would contain the message schema for incoming order documents and a map for mapping those into the core order message schema (contained in MyCompany.Biz.CORE.OrderProcessing). If needed it could also contain an orchestration for receiving messages and (receive) pipeline components (when dealing with flat files for example).

MyCompany.Biz.MySecondApp.OrderProcessing would contain the message schema for outgoing documents and a map for mapping from the core order message schema (to outgoing).

In this basic layout CORE will merely be a container for your internal message schemas but it will be the best location to add information to your order documents - for example an orchestration which awards a global discount for class A customers (Business Rules!). In short basically any step you'd do twice or even more times when sending or receiving messages and you do not want to touch if incoming or outgoing message schemas changes or new application is added.

Filburt
  • 17,626
  • 12
  • 64
  • 115
  • So, for non-shared maps schemas you would do: MyCompany.Biz.MyFirstApp.Schemas.dll and MyCompany.Biz.MyFirstApp.Schemas.dll? Also, do you ever attach a concern on to those like: MyCompany.Biz.MyFirstApp.Schemas.Internal.dll ? – Derek Beattie Nov 12 '10 at 19:54
  • "We took the path to keep orchestrations, schemas and maps together because multi-assembly dependencies can mak deployment a real hassle." I see, ignore my first comment. – Derek Beattie Nov 12 '10 at 20:32
  • In your example, what's an example of some of the things MyCompany.Biz.MyFirstApp.OrderProcessing.dll, MyCompany.Biz.CORE.OrderProcessing.dll, and MyCompany.Biz.MySecondApp.OrderProcessing.dll would contain. – Derek Beattie Nov 12 '10 at 20:39
3

Here is a wonderful BizTalk Naming Conventions guide from Scott Colestock

HashName
  • 651
  • 7
  • 17