Structuring BizTalk projects

Home Page › Forums › BizTalk 2004 – BizTalk 2010 › Structuring BizTalk projects

Viewing 1 reply thread
  • Author
    Posts
    • September 6, 2006 at 12:49 AM #15569
      community-content

        Hi,

        I'm working on a large BizTalk project and we're using Scott Colestocks excellent Deployment framework. The out-of-the-box deployment framework recommends splittng projects based on artifact type e.g. ,<ProjectName>.Pipelines; <ProjectName>.Schema. This works fine however on larger projects where you have common core components you could have a solution that contains common schema, pipelines, maps etc. that may be deployed on all machies in a group. You may also have a solution per Source and Destination system; or per service or a solution for the send, processing and recv side of some integration scenario.
        All of these artificats may be related and therefore form part of a single logical Application. I'm wondering does anyone have any guidance on structuring these projects. So enough of my rambling, onto some real questions
        Do you think that there should be a mapping 1-1 between a Solution and an Application? (There may be many solutions from a developer perspective for ease of development but I'm thinking that there should be a single Solution that maps to an Application for deployment purposes)
        Would it be a good idea if you follow Scott C's model to extend it along these lines Pipelines.Send and Pipelines.Recv to support deployment on the send and recv machines in a group?
        Where should common artifacts be located in terms of BizTalk applications? This really goes to how you manage dependencies between BizTalk Applications
        Does anyone have any thoughts on how coarse or fine grained a BizTalk Application should be e.g. throw everything into a single Application or split send and recv or possibly even more fine grained than that which I doubt is a good idea. If anyone has come up with a decent set of guidelines on this I would really appreciate your opinion.
        Slán
        Gar
      • September 6, 2006 at 7:41 AM #15572
        community-content

          In the past, I have set up a one to one relationship between solutions and applications.  Mostly because that made the most sense for the project I was working on because the application would always be deployed and removed as a single unit of work.  I can’t see a reason why you couldn’t have more solutions but I try to organize the applications more than the solutions.

           

          If you are talking about a whole lot of artifacts, breaking it up would make sense more from a size point of view.   It probably wouldn’t hurt to put the full deployment on each server since you never know when your Receive Server might need to be a Send Server plus then you’d have to build and maintain multiple installation packages.

           

          I’d create a common shared application.  Then have the others reference it.

           

          I don’t have any hard set rules.  The key is to make deployment and manageability easy and structure things logically.  In the 2004 days (before applications), one project I was on had a few solutions, and about 40 projects.  A few Orchestration, a few pipeline, and then many projects with schema and maps for vendors.

           

          Hope this helps.

           

      • Author
        Posts
      Viewing 1 reply thread
      • The forum ‘BizTalk 2004 – BizTalk 2010’ is closed to new topics and replies.