Biztalk应用程序结构指导 [英] Biztalk Applications structure how-to

问题描述

我是Biztalk的新手.我希望将工件构建到应用程序中.

I'm new to Biztalk. I wish to structure my artifacts into applications.

我应该为每种工件类型使用一个应用程序-例如3个单独的应用程序，例如'BusinessProcess.Schemas'，'BusinessProcess.Maps'，'BusinessProcess.Maps'，以及与这些程序集相关的所有程序集(通常只有一个) ，还是您认为最好只拥有一个"BusinessProcess"应用程序，其中包含与业务流程相关的所有程序集?

Should I go with one application per artifact type - for example 3 seperate applications, like 'BusinessProcess.Schemas', 'BusinessProcess.Maps', 'BusinessProcess.Maps', with all the assemblies related to these (typically just one), or do you think it best to just have one 'BusinessProcess' application, which would contain all assemblies related to the business process?

推荐答案

我应该为每种工件类型使用一个应用程序

Should I go with one application per artifact type

我认为通常来说，每种工件类型意味着一个项目?尽管应该将多个应用程序共有的工件拆分为一个单独的应用程序/解决方案.

I think in general, you mean one project per artifact type? Although artifacts common to more than one application should be split out into a separate application / solution.

将BizTalk项目分解为组件项目(和程序集)的原理与任何其他.Net项目相似-关注点分离，测试隔离，独立版本控制等.

The rationale for splitting BizTalk projects up into component projects (and assemblies) is similar to any other .Net project - separation of concerns, isolation for testing purposes, independent versioning, etc.

其中大多数问题在>埃里克·韦斯特曼的绝佳答案中解决了

需要详细说明的一点是，依赖项链通常看起来像这样:

One point that to elaborate on is that the dependency chain usually looks something like this:

Schemas (Internal / Canonical, External)
^
Maps
^
Ports + Pipelines
^
Orchestrations

(以及其他带有辅助功能的其他.Net程序集)

(plus other miscellaneous .Net assemblies with helpers)

在部署了多个应用程序的服务器上，有时您可能需要具有跨应用程序依赖性(尤其是如果您选择耦合到确定的模式而不是例如通过多部分消息进行松散耦合)，通常在内部/规范模式，这对于多个项目来说是常见的.

On a server with multiple applications deployed, at some point you'll likely need to have cross-application dependencies (especially if you have chosen to couple to definite schemas and not loosely couple e.g. via multipart messages), usually on Internal / Canonical Schemas which are common to more than one project.

除非将这些架构与其他程序集分开，否则每当整体应用程序发生更改时，每次对整体应用程序进行任何更改时，都将需要承受卸载/重新安装所有相关应用程序的痛苦.通常，由于整个企业都依赖于Canonical模式，因此它们经过仔细考虑，因此相当稳定，而应用程序的地图和业务流程更可能是频繁更改的候选对象.

Unless these schemas are separated from the other assemblies, any time a monolithic application changes, you'll need to go through the pain of uninstalling / reinstalling all dependent apps every time any change is made to the monolithic app. Generally because the whole enterprise is dependent on the Canonical schemas, they are carefully deliberated and thus fairly stable, whereas an app's maps and orchestrations are more likely candidates for frequent change.

这是此情况的结构:

单独的通用/基础解决方案项目:

• 通用内部架构(事件/EDA元信息，内部 错误等)
• 规范域架构(即内部/企业 您的业​​务的发票，索偿，交易等模型)
• 用于与上述内容进行交互的助手程序集

• Common internal schemas (event / EDA Meta information , internal errors etc)
• Canonical Domain schemas (i.e. the internal / enterprise model of Invoices, Claims, Transactions etc of your business)
• Helper assemblies for interacting with the above

您的应用程序解决方案参考上述内容，然后普遍接受的分隔工件类型:

Your application solution references the above, and then the commonly accepted separation is along the lines of the artifact types:

• 外部系统架构(如果有多个，则每个都在自己的程序集中)
• 地图
• 管道
• 业务流程

这篇关于Biztalk应用程序结构指导的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！