在不同系统之间交换消息是解决 BizTalk Server 解决的问题的必要部分。 但是，真正的目标是根据应用程序定义和执行业务流程。 BizTalk Server 引擎使用编排来定义这些业务流程的逻辑。 若要创建和评估业务规则组，它使用业务规则引擎。 本部分介绍编排和业务规则引擎。
使用编排
自动化业务流程的逻辑可以直接以 Microsoft Visual Basic 或 Microsoft Visual C# 等语言实现。 然而，使用传统编程语言创建、维护和管理复杂的业务流程可能具有挑战性。 与前身不同，BizTalk Server 采用不同的方法。 它使业务经理或开发人员能够以图形方式定义业务流程。 这样做的速度可能比直接使用编程语言生成过程更快，并且它还使该过程更易于理解、解释和更改。 通过这种方式构建的业务流程还可以更轻松地进行监视，这是由业务活动监视（BAM）技术利用的事实。
对于开发人员来说，创建业务流程依赖于三个主要工具：用于创建 XML 架构的 BizTalk 编辑器、用于定义这些架构之间的转换的 BizTalk 映射器，以及用于指定业务流程逻辑的业务流程设计器。 所有这些工具都托管在 Visual Studio 中，为开发人员提供一致的环境。 本部分介绍这些工具的用途以及它们如何协同工作。
创建架构：BizTalk 编辑器
业务流程使用 XML 文档，每个文档都符合一些 XML 架构。 BizTalk 编辑器使开发人员能够使用 XML 架构定义语言（XSD）来定义这些架构，这些架构实质上定义了文档信息的结构和类型。
创建没有某些工具支持的原始 XSD 架构并不简单。 为了使这一必要步骤更易于访问，BizTalk 编辑器使用户（可能是开发人员）能够通过在图形层次结构中定义其元素来生成架构。 也可以从文件或可访问的 Web 服务导入现有架构。 无论这些架构是如何获取的，它们都会被用作 BizTalk 映射的基础。
架构之间的映射：BizTalk 映射器
实现业务流程的编排通常会接收一些文档并发送其他文档。 通常，收到的文档中的一部分信息会转移到已发送的文档，也许以某种方式转换。 例如，订单履行过程可能会收到一些项的订单，然后发送一条消息，指示订单因某种原因而被拒绝。 订单中的信息（如请求标识符和订购数量）可能从收到的订单消息中的字段复制到拒绝消息中的字段。 BizTalk 映射器可用于定义从一个文档到另一个文档的转换，称为映射。
如上图所示，每个映射都表示为两个 XML 架构之间的图形关联，用于定义这些架构中的元素之间的关系。 万维网联盟（W3C）将可扩展样式表语言转换（XSLT）定义为在 XML 架构之间表达这些转换的标准方法，因此 BizTalk Server 中的映射实现为 XSLT 转换。
映射中定义的转换可能很简单，例如将值原封不动地从一个文档复制到另一个文档。 此类直接数据副本是使用链接表示的，该链接在 BizTalk 映射器中显示为将源架构中的相应元素与其目标架构中的对应元素连接在一起的行。 还可以使用 functoid 进行更复杂的转换。 functoid 是一块可执行代码，可以定义 XML 架构之间的任意复杂映射，如上所示，BizTalk 映射器将其表示为连接所转换元素的行上的框。 由于其中一些转换非常常见，BizTalk Server 包含许多内置的 functoid 功能模块。 这些内置功能模块分为多个类别，包括：
在源文档中使用数学函数对象执行诸如对字段值的加法、乘法和除法等运算，并将结果存储在目标文档的字段中。
转换功能块，用于将数值转换为其 ASCII 等效项，反之亦然。
根据源文档中指定值之间的逻辑比较，用于确定是否应在目标文档中创建元素或属性的逻辑功能体。 这些值可以比较是否相等、大于/小于或以其他方式进行比较。
累积函数块计算源文档中各个字段的平均值、总和或其他值，并将结果存储在目标文档的单个字段中。
可以访问存储在数据库中的信息的数据库功能模块。
还可以直接在 XSLT 中创建自定义 functoid，或使用支持 .NET 的语言创建，如 Visual C# 和 Visual Basic。 Functoid 也可以按顺序组合，将一个的输出链接到另一个 Functoid 的输入中。
必须能够定义文档的 XML 架构，以及跨具有不同架构的文档映射信息的机制。 BizTalk 编辑器和 BizTalk 映射器解决了这两个问题。 然而，定义架构和映射只是过程的一部分。 还必须指定将使用架构并调用映射的业务逻辑。
定义业务逻辑：业务流程设计器
业务流程是一组动作，它们共同满足某些有用的业务需求。 借助 BizTalk Server，开发人员可以使用业务流程设计器以图形方式定义这些作。 开发人员可以通过以逻辑方式连接一系列形状来创建编排，而不是用某种编程语言表达步骤。 编排设计器中可用的形状包括：
“接收”形状，允许业务流程接收消息。 接收形状可以有一个筛选器，该筛选器定义将接收的消息类型，还可以将其配置为在新消息到达时启动业务流程的新实例。
“发送”形状，用于允许编排过程发送消息。
端口形状，用于定义消息的传输方式。 端口形状的每个实例都连接到“发送”或“接收”形状。 每个端口也有一种类型，用于定义端口可以接收的消息类型等内容：方向，如发送或接收;以及一个绑定，用于确定消息的发送方式或接收方式，例如，指定特定 URL 和其他信息。
“决定”形状，表示一个 if-then-else 语句，该语句允许业务流程根据布尔条件执行不同的任务。 业务流程设计器的表达式编辑器可用于指定此条件语句。
用于控制当某个条件为真时重复执行某项操作的循环。
构造消息形状，用于生成消息。
转换形状组件允许将信息从一个文档传输到另一个文档，并通过调用使用 BizTalk 映射器定义的映射来对信息进行转换。
并行作形状，允许开发人员指定应并行执行多个作，而不是按顺序执行。 在所有并行动作完成之前，后续形状不会执行。
范围形状允许将操作分组到交易中，并定义异常处理程序进行错误处理。 支持传统的原子事务和长时间运行的事务。 与原子事务不同，长时间运行的事务依赖补偿逻辑而不是回滚来处理意外事件。
消息赋值形状，它允许向协调处理变量赋值。 这些变量可用于存储业务流程使用的状态信息，例如正在创建的消息或字符串。
下图显示了使用编排设计器中的一些形状创建的编排。 在此简单示例中，收到一条消息、基于该消息的内容做出决策，并且两个路径中的一个是由于该决定而执行的。 解决实际问题的业务流程可能比这要复杂得多：为了使这些更复杂的关系图更易于使用，业务流程设计器包括放大和缩小功能。开发人员只能查看他们当前感兴趣的业务流程的那些部分。
开发人员在定义某个编排后，形状及其之间的关系组会被转换为 .NET Framework 的公共语言运行时（CLR）使用的 Microsoft 中间语言（MSIL）。 最终，BizTalk Server 开发人员定义的形状组最终变成一个标准的 .NET 程序集。 您也可以根据需要通过从形状内部调用 COM 或 .NET 对象来向编排添加显式代码。
Web 服务的角色
Web 服务允许应用程序使用 SOAP 交换 XML 文档，并且对集成平台产生了重大影响。 若要访问外部 Web 服务，编排的创建者可以使用 Visual Studio 中的“添加 Web 引用”选项以及 Web 服务适配器直接调用操作。 同样，BizTalk Server 提供了一个 Web 服务发布向导，该向导可以生成一个 ASP.NET Web 服务项目，将业务流程的一个或多个操作公开为可通过 SOAP 调用的 Web 服务。 这两个选项允许开发人员从业务流程中访问现有 Web 服务，并将业务流程的功能作为 Web 服务公开给其他业务流程。
Web 服务的兴起也对定义业务流程的方式产生了影响。 例如，考虑两个组织使用 Web 服务进行交互的情况。 若要有效互作，可能需要每个参与方进行交互，才能了解另一方正在使用的业务流程。 如果两个组织都使用 BizTalk Server，则这不是个大问题;贸易合作伙伴管理技术等工具可用于分发此知识。 但是，如果他们使用不同的产品呢？ 对于此类情况，通过某种方式以非供应商特定方式描述业务流程的各个方面非常有用。
为此，Microsoft、IBM 和其他人员创建了业务流程执行语言（BPEL）。 可以使用业务流程设计器定义的业务流程导出到 BPEL，BizTalk Server 还可以导入 BPEL 中定义的进程。 虽然该语言可用于描述和共享业务流程的外部可见部分，但 BPEL 更专注于解决此问题，而不是跨平台执行完整的业务流程。 此外，请务必了解 BPEL 完全基于 Web 服务构建，而支持此语言的 BizTalk Server 和其他产品可提供更多内容。 例如，BizTalk Server 支持在不同 XML 架构、本地对象中调用方法以及 BPEL 中不可用的其他功能之间的映射。 出于这些和其他原因，BPEL 不是定义业务流程的完整语言。 鉴于BPEL仍在被结构化信息标准组织（OASIS）标准化的过程中，现在很难将其视为一种完全成熟的技术。
BizTalk Server 中的业务编排是创建业务流程的基本机制。 然而，某些编排的方面往往比其他方面更频繁地变化。 具体而言，业务流程（业务规则）中嵌入的决策通常是其最易失的方面。 经理上周的支出限制是10万美元，但由于她的晋升，这一限制提高到了50万美元；而对于延迟付款客户，允许的最大订单量从100个单位减少到仅仅10个单位。 可以使用业务规则引擎指定和更新这些规则。
使用业务规则引擎
业务流程设计器与 BizTalk 编辑器和 BizTalk 映射器一起提供了定义业务流程及其使用规则的有效方法。 但是，有一种更简单的方式来定义和更改业务规则会很有用。 为此，BizTalk Server 提供业务规则引擎（BRE）。 开发人员通常会使用 BRE，但面向业务的用户可以使用名为业务规则编辑器的工具创建和修改业务规则集。
BRE 非常有用的一种情况是必须评估一组复杂的业务规则。 例如，决定是否授予贷款可能需要根据客户的信用历史记录、收入和其他因素处理一组大规则。 同样，确定是否向申请人出售人寿保险取决于许多事项，包括申请人的年龄、性别和健康。 将所有这些规则表示为条件语句，例如使用编排中的“Decide”功能进行设置是可能的，但实现起来相对比较复杂。 对于此类规则密集型流程，BRE 可以使开发人员的生活更简单。
使用 BRE，开发人员可以根据需要快速轻松地更改规则。 若要了解其中原因，可以考虑更改在编排工作流中实现的业务规则所需的条件。 开发人员必须先在 Visual Studio 中打开业务流程，修改相应的形状（也许是它们调用的 .NET 或 COM 对象），然后生成和部署修改后的程序集。 执行此作还需要停止并重启包含此业务流程的 BizTalk 应用程序。 如果改用 BRE 实现此业务规则，则可以对其进行修改，而无需重新编译或重启任何内容。 只需使用业务规则编辑器更改所需规则，然后重新部署新规则集。 此更改会立即生效。 虽然业务流程通常由开发人员创建和维护，但业务规则已足够可读，在某些情况下，业务分析师可以对其进行修改，而无需涉及更多技术人员。
一组业务规则的创建者通常首先使用业务规则编辑器来定义用于指定这些规则的词汇。 词汇中的每个术语都为某些信息提供用户友好名称。 例如，词汇可以定义术语，如“发货数量”或“项目的最大数量”或“审批限制”。 每个术语都可以设置为常量，也可以映射到某些 XML 架构中的特定元素或属性（因此在传入消息中），或者映射到针对某些数据库的 SQL 查询的结果，甚至映射到 .NET 对象中的值。
定义词汇后，业务规则编辑器可用于创建使用此词汇的业务策略。 每个策略可以包含一个或多个业务规则。 规则使用某些词汇中定义的术语以及逻辑运算符（如“大于”、“小于”、“等于”）和其他术语来定义业务流程的运作方式。 业务规则可以定义接收的 XML 文档中包含的值应如何影响在发送的 XML 文档中创建的值，或者这些值应如何影响在数据库中写入的值或其他内容。
若要执行业务策略，业务流程使用 CallRules 形状。 此形状创建 BRE 的实例，指定要执行的策略，然后传入此策略所需的信息，例如收到的 XML 文档。 可以通过基于 .NET 的对象模型以编程方式调用 BRE，这使得不使用 BizTalk Server 的应用程序也可以调用它。 这意味着 Windows 窗体应用程序、公开 Web 服务的软件以及 .NET Framework 上构建的任何其他内容都可以随时使用 BRE，只要它有助于解决问题。
词汇和业务规则可能比此处所述的简单示例复杂得多，而且功能更强大。 但定义词汇的核心理念，然后定义使用该词汇的规则集是业务规则引擎的核心。