locked
Best practices for shared artifacts RRS feed

  • Question

  • Put all the shared artifacts (schemas, pipelines ect) in a Biztalk common application ( reference) is kind of a best practice in Biztalk world, however we are having below issues.

    We have a BTS server with one common application (with schemas and pipeline components) and 30-35 BTS applications. Now each time we change the common application are foreced to redeploy the BTS applications dependent on common.  

    Not sure how to address the above issue. Also, whats the best practice on the number of common applications? would like to create separate common application for Schema, Pipelines etc Just to minimize the effort on undeploying applications.

    Your thoughts are highly appreciated !!


    Venkat Kundavaram

    Friday, January 13, 2017 7:53 PM

Answers

  • Hi Venkat,

    This has been one of great debates, always!!


    Not sure how to address the above issue. 

    This is where versioning strategy comes into play. 

    Refer: https://masteringbiztalkserver.wordpress.com/2011/03/02/schema-versioning-in-biztalk-server/

    https://blogs.msdn.microsoft.com/richardbpi/2006/12/19/versioning-strategy-for-biztalk-assemblies/

    MSDN: https://msdn.microsoft.com/en-us/library/ee308955(v=bts.10).aspx


    Keeping copies of artifacts related (which is used by many applications) in application directly, opposed to keeping a common application. If you keep local copies, tthe advantage you see is that you don’t want to undeploy all the referenced application when you update the artifacts.

    But if you do that:

    1) You will have multiple copies of same aritifcats deployed, but in different applications.

    2) You’re will not be following versioning for your artifacts, hence in longer run you may not able to track changes, update all referenced assemblies to have same version, you will have hard time updating all the applications where the web service/other application artifacts are referenced.

    I believe as best practice you should consider below:

    Separate shared/common artifacts: You have identified some artifacts which can share its functionality across multiple applications. When you identified some artifacts as “shared/common” only when these shared artifacts are not updated often. If these artifacts changes more often depends on a specific application, they don’t become a candidate of being “common” artifacts as they depend on a specific application(s) which make these schema/artifacts change.

    Being said this, it’s more logical that even common artifacts tend to undergo some changes. If they do they shall affects the other dependent applications. This is where application reference and versioning of schema plays key role.

    Shared functionality copied across in multiple applications: Other option is to have copies of same schema/artifacts in each application. This does provide some relaxed approach. If you want to change the common functionality later, either you would do it in multiple places/application and update it in a specific application and maintain multiple version of the assembly in different applications. Hence it would become an overhead to maintain, update the changes etc.

    So the best approach if you have identified a correct candidate for common/shared artifact is to have a separate shared application. Ideally this would undergo less change. If changes happen keeping it shared would save you to update in one place rather than changing it multiple places.



    Rachit Sikroria (Microsoft Azure MVP)

    Saturday, January 14, 2017 2:50 AM
    Moderator
  • It very, very simple.

    Do not share Artifacts outside of a single deployment unit, usually a Visual Studio Solution.

    So, sorry :( but what you have with the single project referenced by 35 other apps is not a good practice, in fact, it's a bad practice for which you are suffering the results.

    There is nothing wrong with deploying an artifact multiple times, within it's local solution. The only extra step is creating custom Pipelines with schemas explicitly set in the XmlDisassembler.  See this article for details: https://social.technet.microsoft.com/wiki/contents/articles/35656.biztalk-improve-deployment-and-tracking-by-always-creating-custom-pipelines.aspx

    The best practice on the number of common applications is 0.

    Friday, January 13, 2017 9:32 PM
    Moderator

All replies

  • It very, very simple.

    Do not share Artifacts outside of a single deployment unit, usually a Visual Studio Solution.

    So, sorry :( but what you have with the single project referenced by 35 other apps is not a good practice, in fact, it's a bad practice for which you are suffering the results.

    There is nothing wrong with deploying an artifact multiple times, within it's local solution. The only extra step is creating custom Pipelines with schemas explicitly set in the XmlDisassembler.  See this article for details: https://social.technet.microsoft.com/wiki/contents/articles/35656.biztalk-improve-deployment-and-tracking-by-always-creating-custom-pipelines.aspx

    The best practice on the number of common applications is 0.

    Friday, January 13, 2017 9:32 PM
    Moderator
  • Hi Venkat,

    This has been one of great debates, always!!


    Not sure how to address the above issue. 

    This is where versioning strategy comes into play. 

    Refer: https://masteringbiztalkserver.wordpress.com/2011/03/02/schema-versioning-in-biztalk-server/

    https://blogs.msdn.microsoft.com/richardbpi/2006/12/19/versioning-strategy-for-biztalk-assemblies/

    MSDN: https://msdn.microsoft.com/en-us/library/ee308955(v=bts.10).aspx


    Keeping copies of artifacts related (which is used by many applications) in application directly, opposed to keeping a common application. If you keep local copies, tthe advantage you see is that you don’t want to undeploy all the referenced application when you update the artifacts.

    But if you do that:

    1) You will have multiple copies of same aritifcats deployed, but in different applications.

    2) You’re will not be following versioning for your artifacts, hence in longer run you may not able to track changes, update all referenced assemblies to have same version, you will have hard time updating all the applications where the web service/other application artifacts are referenced.

    I believe as best practice you should consider below:

    Separate shared/common artifacts: You have identified some artifacts which can share its functionality across multiple applications. When you identified some artifacts as “shared/common” only when these shared artifacts are not updated often. If these artifacts changes more often depends on a specific application, they don’t become a candidate of being “common” artifacts as they depend on a specific application(s) which make these schema/artifacts change.

    Being said this, it’s more logical that even common artifacts tend to undergo some changes. If they do they shall affects the other dependent applications. This is where application reference and versioning of schema plays key role.

    Shared functionality copied across in multiple applications: Other option is to have copies of same schema/artifacts in each application. This does provide some relaxed approach. If you want to change the common functionality later, either you would do it in multiple places/application and update it in a specific application and maintain multiple version of the assembly in different applications. Hence it would become an overhead to maintain, update the changes etc.

    So the best approach if you have identified a correct candidate for common/shared artifact is to have a separate shared application. Ideally this would undergo less change. If changes happen keeping it shared would save you to update in one place rather than changing it multiple places.



    Rachit Sikroria (Microsoft Azure MVP)

    Saturday, January 14, 2017 2:50 AM
    Moderator
  • Yes its possible to create canonical to de couple all the artifacts.

    First list our all apps,

    List out dependency 

    Relate dependency for each interface. 

    Now develop dependency artificats(S

    Reference dependency in other artificats.

    only drawback while deploy/undeploy you have dependency with cannonical.

    Its just high level. 


    Ram

    Monday, January 16, 2017 3:02 PM