none
Project Structure of Canonical Solution RRS feed

  • Question

  • Dear Friends,

    Need your help in deciding Project Structure of Canonical Solution.

    Flow is Source Systems -> Canonical ->Destination Systems   and vice versa.

    In Canonical Solution currently we have BizTalk Projects per interface, each project having its own artifacts like schemas, maps and Orch etc. For 10 interfaces this solution will have 10 Projects and number of projects will increase as the number of interfaces will increase.

    As per the best practice, we want to split the projects so that one project contains only one type of Artifact.

    To do above, Currently we have 3 approaches:

    1. Canonical Solution will contain one Project for each artifact type like one for Schemas , One for Orch, One for Map, One for Pipeline and so on... irrespective of Interface.

    2. Canonical Solution will contain projects respective to interfaces and also respective to artifacts type. So If I have 10 interfaces and all has 3 types of artifacts Schema, Maps and Orchestrations Canonical Solution will have 30 Projects.

    3. Create 10 different Solutions for 10 Interfaces and Each solution will have Projects respective to Artifact Type.

    Can you guys give your expert advice to what should be the best Project Structure and Pros and Cons of Each approach, which will help us in deciding the approach.

    Thanks

    Vikingsss

    Thursday, January 30, 2014 6:16 AM

Answers

  • My preference is to define the boundaries at the deployment unit, meaning all artifacts that are likely to be deployed as a single unit.  This is then maintained as a single Solution in Visual Studio with at many Projects as needed.

    I still prefer to do this even if there are 'shared' schemas and take advantage of the various techniques to disambiguate them at runtime (yes, duplicates can be deployed and there is not wrong with that specifically).

    Don't worry so much about the number of projects so much, the computer doesn't really care.

    For a particular interface, it's really a judgment call on whether you want a simple project structure or stick to the 'standard'.  If an interface has 2 Schemas, 1 Map and 1 Orchestration, I wouldn't bother with 3 separate projects.  But if there's 10 Schemas, 15 Maps, 7 Orchestrations, then it makes sense.

    • Marked as answer by Pengzhen Song Friday, February 7, 2014 8:01 AM
    Thursday, January 30, 2014 1:37 PM
    Moderator

All replies

  • I would advise you to go through an article on project organization/naming written by Leonid http://blogs.msdn.com/b/mvpawardprogram/archive/2013/09/23/biztalk-integration-development-architecture.aspx

    In a cannonical solution, you may choose to keep the cannonical schema as a project separate from the orchestration handling the schema. Then for each of the partners you may choose to create ONE project with the partner specific schema + MAP and/or pipeline. This way everything to do with one process is in one place and movement into and out w.r.t deployment does not impact others.

    Regards.

    Thursday, January 30, 2014 8:47 AM
  • In your case it is better to keep projects separate based on Interfaces, This would provide more isolation of each project from other 9 projects. You may need some changes in first project and you need not build remaining projects again.

    If however you have schemas listed in one, Orchestrations in other etc.. You will end up re-building all projects.

    Pros: Isolation of each Project

    Cons: When you deploy the solution as a whole, Schemas are deployed first, then maps, then orchestrations etc..,  The other approach based on artefacts is more suitable for this.

    Experts may list more pros and cons, For my projects I have a mix of both types depending on what my requirement is..

    Thursday, January 30, 2014 9:16 AM
  • My preference is to define the boundaries at the deployment unit, meaning all artifacts that are likely to be deployed as a single unit.  This is then maintained as a single Solution in Visual Studio with at many Projects as needed.

    I still prefer to do this even if there are 'shared' schemas and take advantage of the various techniques to disambiguate them at runtime (yes, duplicates can be deployed and there is not wrong with that specifically).

    Don't worry so much about the number of projects so much, the computer doesn't really care.

    For a particular interface, it's really a judgment call on whether you want a simple project structure or stick to the 'standard'.  If an interface has 2 Schemas, 1 Map and 1 Orchestration, I wouldn't bother with 3 separate projects.  But if there's 10 Schemas, 15 Maps, 7 Orchestrations, then it makes sense.

    • Marked as answer by Pengzhen Song Friday, February 7, 2014 8:01 AM
    Thursday, January 30, 2014 1:37 PM
    Moderator