您的位置：首页 > 编程语言

BizTalk Server : 提高 BizTalk 编程能力的 8 点技巧和窍门

2008-06-17 15:46 197 查看
目录
1. 始终使用“多部分消息类型”
2. 始终尽可能使用“直接绑定端口”设计业务流程
3. 始终使用单独的内部和外部架构
4. 永远不要在 WSDL 中直接公开您的内部架构
5. 始终为 Web 服务优化 BizTalk 注册表
6. 始终使用相对路径设置程序集密钥文件
7. 永远不要忽视免费的示例代码
8. 在 Visual Studio 中调试 XSLT
总结

有 一次，Marty 要与一个大客户进行概念证明，就在要开始前半天，他接到一个需要修复的复杂的 BizTalk® 解决方案。 该解决方案的主要组件是一个业务流程，它集成了几个后端系统，要对每一个后端系统执行多次对外调用。 他看到“业务流程设计器”屏幕上几乎全部由黑色线条构成，将几十个“接收”和“发送”形状连接到 40 多个入站和出站端口 — 这种设计几乎不可能对其进行调试。 他的解决办法： 使用“多部分消息类型”和“直接绑定端口”（下面的技巧 1 和技巧 2）重新开始，沿流程路线执行单元测试。 结果如何？ 他成功了！

 

Marty 的成功部分归功于 BizTalk Server 的设计 — 它的设计可以应对互连系统编程中固有的特殊难题，在某些情况下甚至不必编写代码。 但是，尽管它有简洁的拖放式流程图，而且代码很少，您也不要高兴过了头 — 事情没这么简单。 BizTalk 是一种使用范围广而且功能强大的产品，熟练掌握它需要几年的时间。 如果您打算成为一名 BizTalk 专家，您会遇到很多需要您基于 Microsoft® .NET Framework 编写代码的情形，以与 BizTalk 中复杂的内置消息处理能力形成补充。

直到最近，BizTalk 新手们都一直很少有机会利用大师的心得和技巧来加快掌握 BizTalk。 （请参阅侧栏上的“学习 BizTalk Server 2006 编程”以查看相关资源。） 我第一次深入接触 BizTalk 是在参加 Marty 主办的为期一周的 BizTalk 培训活动中的一次课程期间，在这一周的时间里，他不断告诫我们要正确设计系统，并在使用之前在实际负载条件下用 PerfMon 对其进行测试。 通过这次活动，我们汲取了大量技巧，这些技巧可以帮助您成为更高效的开发人员。 本文的目的旨在与大家分享这些有用的技巧，下面转入正题。


1. 始终使用“多部分消息类型”

BizTalk 的目的旨在处理消息，顺便说一下，所谓消息并非只是电子邮件。 文档、InfoPath 窗体、大型二进制文件、SQL 记录、平面文件以及任何 XML 文件都可以作为消息来处理，同时您还可以获得异步通信带来的好处。 一旦您熟悉了该工具，您会发现面向消息的编程与面向对象的编程一样酷，都是非常有用的编程范例。

BizTalk 中的消息是数据，每个消息都必须属于一种选定的消息类型。 BizTalk 中最常见的消息类型是架构，也就是说，此类消息基于一个 .XSD 文件，此文件指定了消息中的记录和字段结构。 请参阅 msdn2.microsoft.com/en-us/library/ms942182.aspx，查看有关 BizTalk 中的架构和映射的详细讨论。

在用 BizTalk 进行编程的过程中，总有一天您会希望更改某个消息所基于的架构。 但问题是，如果您已经为“发送”或“接收”形状选择了此类消息并将其连接到一个业务流程端口，则在您尝试更改“消息类型”时将收到以下错误：

Property value is not valid: One or more Send or Receive actions are
connected to Ports and are using this Message. Please disconnect the
actions before changing the Message Type.
[p] 

在按错误消息的建议进行操作之前，让我们先想一想它涉及哪些工作。 首先，您必须检查每个“接收”和“发送”形状，以确定它是否使用了与您要更改的架构关联的 Message 变量（已设置了其“消息类型”）。 目前，BizTalk 中没有可提供此类审核或生成依赖关系映射的功能；实际上，若创建的一个业务流程有太多的“接收”/“发送”形状，以至于需要有这样一种功能，只能说明这一流程的创建没有采用良好的做法。 在前面提到的让人发怵的业务流程中，大多数“接收”和“发送”形状都使用不同的 Message 变量，但它们都指向同一架构定义（都是同一消息类型）！[/p]

第二，一旦找到所有“接收”/“发送”形状，必须删除它们的端口连接。 第三，必须更改 Message 变量，以便将“消息类型”属性设置为新的架构，然后重新将 Message 变量与每个“接收”/“发送”形状关联起来。

第四（您认为您已经完成了），必须找出与已经从“接收”/“发送”形状断开连接的端口关联的所有“端口类型”，并重新设置其“操作”的“消息类型”属性。 您知道，在您最初将“接收”或“发送”形状与一个端口关联时，BizTalk 会自动将“端口”类型中的“消息类型”属性设置为与此“接收”/“发送”形状的 Message 变量的“消息类型”相符。 在删除“端口”和“接收”/“发送”形状之间的连接时，BizTalk 将丢失该“端口”的“消息类型”。

幸运的是，有一种更好的方法。 计算机科学领域有一条公理指出，添加一个中间环节可以解决许多问题。 本例再次证明了此言不虚；我们需要做的就是使用一个多部分消息类型来包装底层的架构。 最初的工作量可能会稍大一些，但是灵活性会大大提高，并且从长远看可为您节省时间。 下面介绍如何实现这一点。

在您右键单击“业务流程视图”选项卡中的“消息”来创建新消息时，有四种消息类型属性可供选择（参见图 1 中的右下角）。 为消息类型选择一种架构是通常的做法，但是在这里我们所使用的技巧是要尝试一种全然不同的做法。 单击 + 号展开“多部分消息类型”，然后选择“创建新的多部分消息类型”。 为您的多部分消息类型命名，然后单击 + 号展开它，以便您可以查看其 MessagePart_1 成员（这是 BizTalk 为新的多部分消息类型的第一部分建议的名称）。 现在，将“标识符”属性从“MessagePart_1”更改为更好识别的值，如“Body”（但是不要使用小写“body”，因为它是保留字）。 不要忘记将“消息正文部分”属性设置为 True（以便其行为与常规的消息一样）。


图 1 在业务流程视图中设置“消息类型”属性 (单击该图像获得较小视图)
图 1 在业务流程视图中设置“消息类型”属性 (单击该图像获得较大视图)

需要做的额外工作到此结束。 最后，将新消息部分（如，Body）的“类型”属性设置为常规的基于架构的消息类型所使用的同样的架构。 现在，您的逻辑端口和“接收”/“发送”形状都在使用您的多部分消息类型，将来您可以轻松地更改底层的架构，而无需断开端口与接收形状的连接。


2. 始终尽可能使用“直接绑定端口”设计业务流程

请看一下图 2，该图显示了在业务流程设计器中配置端口时可用的选项。 在使用端口配置向导时，您将从此图的顶部移动到底部。 注意此图中的三个“直接”选项。 虽然 BizTalk UI 提供了“直接”作为端口类型，但是我们这里将使用行话，称它们为“直接绑定”。


图 2 业务流程设计器端口配置向导中的“端口”选项 (单击该图像获得较小视图)
图 2 业务流程设计器端口配置向导中的“端口”选项 (单击该图像获得较大视图)

要理解 BizTalk 中的端口术语，关键要理解逻辑端口（也称为业务流程端口）和物理端口的概念。 一句话说，两者的区别是，在业务流程设计器中创建的是逻辑端口，使用 BizTalk 浏览器或 BizTalk 管理控制台创建的是物理端口。

开发人员在业务流程设计器中创建“以后指定”端口时，他是在配置一个逻辑端口，将相应的物理端口属性留给 BizTalk 管理员在以后进行配置。 “以后指定”是最常使用的选项，关键原因是为了让管理员能够在生产环境中灵活地配置物理端口。

使用“立即指定”选项，则开发人员完成所有配置（包括逻辑和物理配置），得到的解决方案是硬绑定的。 除了要进行快速试验以外，不建议使用此选项。

使用“动态”端口时，物理端口属性的最终配置同样也是由管理员完成的。 但是，在这种情况下，开发人员还可以编写代码，在运行时设置特定出站消息属性。 这对于 SMTP 或 HTTP 非常有用，在这两种情形下，业务流程逻辑包括带有如下语句的“表达式”形状：

DynamicSendPort(Microsoft.XLANGs.BaseTypes.Address)=
“mailto:john@contoso.com”;
[p] 

虽然图 2 中有许多选项，但此图中显示的仅是业务流程设计器中的选项。 “静态”端口适用于哪些环境？ 当您在 BizTalk 浏览器或 BizTalk 管理控制台中创建物理端口时，会遇到这一术语。 如果开发人员在业务流程设计器中创建一个“以后指定”或“动态”端口（逻辑端口），那么管理员在 BizTalk 浏览器或 BizTalk 管理控制台中创建相应的物理端口时，将从图 3 中所示的四个选项中选择。[/p] 学习 BizTalk Server 2006 编程

如果您刚开始学习 BizTalk 编程，您会发现，如果查看 2005 年 11 月份的《MSDN 杂志》上由 Aaron Skonnard 主持的服务站专栏以及 2005 年 12 月专栏，将对您有很大帮助。 在 BizTalk Server 开发中心，您可以找到数十种免费的网络广播。

如果您处于中级水平，请阅读由 Mark Beckner 编著，Apress 出版的 《BizTalk 2006 Recipes: A Problem-Solution Approach》；并阅读 2006 年 12 月份的《MSDN 杂志》中的 Alex Starykh dives into adapter programming topics（针对 BizTalk Adapters）。

如欲获得中级到高级资料，请参阅由 George Dunphy 与 Marty 合著、Apress 出版的《Pro BizTalk 2006》，以及由 Darren Jefford 编著、Wrox 出版的《Professional BizTalk Server 2006》，在您阅读本文时，这两本书应该已经面世了。 不要因为看到标题中的版本号而感到失望；由 Scott Woodgate 编著、Sams 出版的《Microsoft BizTalk Server 2004》也是非常适用的。 这些书中包括几个使用 C# 代码将 BizTalk 带入更高级别的示例。

为增强您在集成系统理论和设计方面的实力，您需要阅读由 Gregor Hohpe 编著、Addison-Wesley 出版的《企业集成模式》一书。 乍一看，您可能会认为这对您学习 BizTalk 不会有什么帮助，但是，了解一下 BizTalk Server 2006 如何隐式实现这几种模式是很有趣的。 如想了解有关技巧 1 的详细信息，以下由 Kurt Guenther 和 Charles Young 撰写的博客是很好的参考资料：

 

对于技巧 4，请查看以下由 Brian Loesgen 和 Kevin Lam 撰写的专家博客：

 

如欲了解更多 BizTalk 技巧，请参阅 Alan Smith 撰写的“七个习惯”一文和 Scott Colestock 撰写的有关 BizTalk 命名约定的短文：


Close [x]

请记住，“动态”物理端口对应于“动态”逻辑端口（相当简单），但“静态”物理端口对应于“以后指定”逻辑端口。 另外，要注意“要求响应”和“请求响应”这两个术语之间的不匹配。 就这些。

完成了这些初步准备之后，我们终于可以讨论“直接绑定”端口的优势了。 “直接绑定”端口在将消息从 BizTalk 发送到 BizTalk 方面是很出色的。 顺便说一下，正是由于这一点，BizTalk 没有必要为 Web 端口提供“直接”选项。 Web 端口用于从 BizTalk 到 Web，而不是从 BizTalk 到 BizTalk。

“直接绑定”端口是自我配置的，不会影响灵活性或性能。 “直接绑定”端口的便捷性在于开发人员和管理员都无需在 BizTalk 浏览器或 BizTalk 管理控制台中创建相应的物理端口。 因此，“直接绑定”端口会形成更独立的业务流程，因而可以更好地重复使用，而且更便于独立地重新部署。

有以下三种“直接绑定”端口类型： 消息框路由、自我关联，以及业务流程到业务流程（也称为合作伙伴端口）。 这三个单选按钮在业务流程设计器中的实际文本要冗长得多，但是，您只要略加观察，就能轻松地把我们的这些短名称与 UI 上的名称相对应。

在这三种端口类型中，“消息框”是最常使用的一类。 它允许您的业务流程完全独立于其他业务流程，尽管您可能只是让它与其自身通信。 没错，这确实意味着有可能出现无限循环。 我们马上就会谈到这一问题。

如果为“消息框路由”配置了一个“激活”属性设置为 True 的“接收”形状，则意味着当消息到达符合给定的订阅筛选器的“消息框”时，将启动业务流程的一个新实例，不管消息来自何处，也不管发送给谁。 这可以帮助您构建一个可重复使用的业务流程，如工具库中的泛型函数。 Marty 使用此技巧构建了一个巧妙的基于消息的异常处理系统，此处暂且不论。

假设您想用以下两种方法启动您的业务流程： 第一，操作员在某个文件夹中对单向静态 FILE（物理）端口发出“启动”消息；或者，第二，业务流程向其自身发送一个启动消息以运行另一个实例。 您首先想到的可能是使用一个“接听”形状（如，用于业务流程的 OR 运算符），并使它下面有两个“接收”形状（“以后指定”用于 FILE 端口，“直接”用于消息框）。 但“直接绑定消息框”端口的最妙之处恰恰是 — 它们不关心消息的来源。 因此，您只需要一个“接收”形状就可以启动此业务流程！

“自我关联直接绑定”端口通常在您想要以异步方式将消息从一个业务流程发送到下一个业务流程时使用。 假定您有两个业务流程：A 和 B。只需进入业务流程 B，在参数部分下创建一个逻辑“发送端口”，并将其设置为使用在业务流程 A 中创建的“端口类型”。现在，您通过业务流程 B 中的该端口发送的任何消息都将立即路由到您在业务流程 A 中创建的逻辑“接收”端口。基本上，我们利用 BizTalk 的发布/订阅特性来转发消息，此外还通过隐藏的独特的关联令牌为这些消息加盖印记，因此称为“自我关联”。 在这种情况下，由于您在各业务流程之间共用一种端口类型，因此各业务流程都对其他业务流程有所了解。 您可以将“端口类型”上“操作”的“消息类型”设置为 System.Xml.XmlDocument，从一定程度上减小依赖性。这是使业务流程异步运行，同时使某种 broker 能够接收来自其他业务流程的主动确认或被动确认的一种很好的方法。

业务流程到业务流程直接绑定（合作伙伴）端口用于以异步方式发送消息。 您将向订阅中添加与使用“消息框直接绑定”端口时相比更宽泛的限制。 在这种情况下，也就是说您将接受来自合作伙伴业务流程的任何消息。 一个业务流程指定“直接绑定”端口，另一个业务流程（合作伙伴）指定自身。 发送方或接收方都可以成为引用“直接绑定”端口的一方。 这里的关键是，您将把两个已知的解决方案连接起来进行通信，而使用“消息框直接绑定”端口时发送方和接收方之间的耦合更松散。

接下来介绍有意思的部分。 使用“直接绑定”端口（特别是使用“消息框”）时常见的缺陷是会造成无限循环。 假设一个简单的业务流程只包括两个形状，“激活”被设置为 True 的“接收”形状（当然是“直接绑定”）和仅将消息转发给 FILE 端口的“发送”形状。 当此业务流程发出消息后，消息将去往何处？ 和其他情况一样，首先进入消息框。 一旦消息达到消息框，BizTalk 就会进行搜索，看有没有匹配的订阅。 此消息如何与最先激活业务流程的消息区分开？ 无法区分。因此 BizTalk 会不假思索地触发业务流程的另一个实例来处理它，以此类推，直到耗尽内存。 修复此问题的一种方法是将入站消息复制到一个新构造的出站消息，并更改至少一个提升的属性的值，以便“接收”形状上的订阅筛选器无法与新消息匹配。 运行管理控制台，并转到“组中心”|“新建查询”|“打开查询”。 下一步是打开 BizTalk\SDK\Utilities 文件夹中的 BTSSubscriptionViewer.btq。 您将看到，在您为“接收”形状设置消息类型时，BizTalk 将自动创建一个谓词。 在“业务流程设计器”中，将一个谓词添加到“筛选器表达式”属性中，完整订阅将如下所示：

BTS.MessageType == “http://MyInternalSchemas.MyProject#MyRootNode”
AND inbound_message(status) != 1
[p] 

或者，如果您不愿意像上面所说的那样更改架构以添加自定义字段，还可以向“接收”形状上的订阅筛选器中添加一个子句来测试 BTS.Operation 名称与您的业务流程中的名称不同。[/p]

我们前面说过，BizTalk 的目的旨在处理消息，还记得吗？ 嗯，回想一下。 实际上也就是订阅。 在 BizTalk 中，在发送端口或业务流程上对消息所做的操作无非就是订阅。


3. 始终使用单独的内部和外部架构

您应始终将接收到的消息转换为您自己的规范架构，不管架构的简单程度如何，也不管它的源是谁。

对于少量的处理，一旦（更恰当地说是“当”）发送方更改架构时，此做法将使您获得很大程度的灵活性。 您不希望您的业务流程逻辑依赖于由其他人控制的架构中的任何属性或字段。 在发送方更改其架构时，您只需更改您的映射，而不是业务流程。 这同样运用了中间环节的公理。

通过遵循为映射、业务流程、内部架构和外部架构创建单独的 Visual Studio 项目这一最佳做法，可以更轻松地重新部署您更新的解决方案。 这对于 BizTalk Web 服务发布向导生成的 Web 服务确实至关重要。

如果您想偷懒，那么不创建自己的带有新字段名称的架构也可以。 只要复制为您提供的入站架构，并将所有字段按照原样从源架构中映射出来即可，但至少要将副本保存到您的内部架构项目中，自己给它取个名称。

这样做还可以减少您需要的映射数。 假设您需要将三种类型的入站消息映射到三种类型的出站消息（可能不是现在，而是在将来）。 应用此技巧，您可以为每个入站架构创建一个到您的规范架构的映射，然后创建从您的规范架构到每个出站架构的映射。 这样一来只需构建和维护六个映射，而不是九个。

使用禁忌

BizTalk Server 2006 是一个大型应用程序，幸运的是，它通常会为完成一些事情提供几种方法。 但是由于各种各样的原因，一些方法存在陷阱，多数有经验的使用者现在已经知道远远避开它们：

  1. 避免使用 BizTalk Server 2006 中的 BizTalk 浏览器。此功能在 BizTalk Server 2004 中至关重要，因此，Microsoft 决定不将它从 BizTalk Server 2006 中去除，但新的应用程序打包功能和经过重新设计的 BizTalk 管理控制台已使其成为多余的。 不幸的是，在某些情况下使用它会造成麻烦。 在 Visual Studio® 2005 解决方案资源管理器中，永远不要在“项目”一级上单击“部署”。 在解决方案中独立构建项目是可以的，但您只应在“解决方案”一级上单击“部署”。 原因是： Visual Studio 会尝试自动跟踪依赖关系，而单独为 BizTalk 部署程序集可能会导致它无法进行跟踪。 不要指望不仔细编辑命名空间属性（以确保匹配）就能将架构文件 (.XSD) 从一个项目复制到另一个项目。 记住这一点，不然您肯定会遇到让您大为头疼的问题。 BizTalk 专家从不使用 Quick Promote。 等到您采取必要的步骤来纠正它提供给您的类型时（假如您还记得这样做），您会发现其实您自己本来可以快速显式地创建这些类型。 不要将映射放入业务流程中，除非您需要将多个传入消息映射到一个消息中，或者您需要以现有消息的经过修改（映射后）的内容为基础生成一条新消息。 为简化部署，最好将您的映射放到“接收”和“发送”端口上。 如果您的业务合作伙伴对其架构进行了修改，或者如果您添加了需要新映射的新合作伙伴，您将不得不同时更新您的架构和业务流程，而这不是您所希望的。
 


Close [x]
4. 永远不要在 WSDL 中直接公开您的内部架构

也就是说，您永远不应单击 BizTalk Web 服务发布向导中的第一个单选按钮；而应始终单击第二个按钮（请参见图 4）。 第一个单选按钮用于发布业务流程，第二个单选按钮用于纯消息处理解决方案，然而使用第二个选项发布业务流程也不失为一个好主意。


图 4 发布您的外部构架，而不是业务流程 (单击该图像获得较小视图)
图 4 发布您的外部构架，而不是业务流程 (单击该图像获得较大视图)

是的，这样一来就更复杂了，您肯定希望我们给出合适的理由。 理由是：接口。 如果您想要更详细的解释，那就是松散耦合！ 这样做使您在更改业务流程时具有更大的自由性，无需中断调用方。 您可以将这一点看作是技巧 3 中概念的特殊化。

接下来我们讨论一下如何实现这一点。 下面是关于此向导要记住的一点： 进入步骤 2 后，您需要右键单击“Web 服务”对话框（请参见图 5）中的几乎每一项。 您将通过这种方式对您创建的 Web 服务及其方法进行命名。


图 5 在“Web 服务”对话框中编辑您的 WSDL

开始在 Web 服务发布向导中执行此步骤之前，您需要在 BizTalk 中编译您的架构项目，以便您能够浏览到程序集。 实际上，正如您将在下面将看到的一样，在运行此向导之前继续部署您的解决方案是很有必要的。 此外，当您将业务流程发布为 Web 服务时，在构建和部署之前，您必须将业务流程端口类型上的“类型修饰符”属性从“内部”更改为“公用”。 如果您在最初创建此端口时没有更改此属性，那就要下相当大的工夫才能找到它（在“业务流程视图”中的“类型”窗格中突出显示此端口类型 — 而不是在显示不同属性集的“端口图面”上单击此端口）。 将架构发布为 Web 服务的另一个好处是您再也不用执行此操作了！

好了，让我们回到此向导，现在来看看图 5。 您需要右键单击“请求”和“响应”节点以选择 Web 消息所基于的架构。 您发布的业务流程通常会具有用于与 Web 服务的调用方通信的一个逻辑“接收”形状和一个“发送”形状。 这些形状将具有关联的消息，而这些消息将有一个架构类型（不需要多部分消息类型，只是建议采用）。 因此，您需要告知此向导使用您的面向外部的架构（记住技巧 3）。 然后，您将使用“接收”端口中的映射（入站和出站映射）将 Web 服务请求和响应架构转换为您的业务流程所期望的内部架构。 当客户端添加对您的 Web 服务的引用时，他将得到一个代理类，其中包括您的面向外部的架构的类型。 客户端将使用该类型创建并填充一个要发送到您的 Web 服务的请求消息。 此外，他将把来自您的 Web 服务的响应添加到一个对象中，此对象基于您在图 5 中指定的外部响应架构。

您还要记住在“接收”位置选择“XML 管道”，否则，BizTalk 将不会创建“BTS 消息上下文”属性 — 这些属性中的其中一个是传入 Web 服务消息的“消息类型”。 BizTalk 了解此“消息类型”（因为它曾通过管道中的“XML 反汇编程序”解析此消息类型并提升该属性），并使用该类型执行映射，以将请求转换为业务流程期望的类型。

真正重要的是，您在此向导中选择的操作名称必须与您在业务流程的逻辑端口中指定的操作的名称完全匹配。 完全接受每个名称的默认值是不可行的，因为业务流程设计器中默认的操作名称为“Operation_1”，而向导中默认的名称为“WebMethod1”（请参见图 5）。 用动词 — 名词格式（如 UpdateInventory）将其设置为具有特定意义的名称是一种不错的做法。

请记住，各种消息（甚至包括传入 Web 服务请求消息）是基于订阅发送到业务流程的。 当您将一个逻辑端口绑定到一个物理端口时（这是在将“请求响应”端口发布为 Web 服务时的一项要求（即使是通过架构发布），BizTalk 将为您创建一个自动订阅。 您可以从 BizTalk 管理控制台中通过以下方法查看订阅：在查询窗口中选择“Subscriptions”作为值。 订阅与通常为其他逻辑到物理端口创建的非“直接绑定”的 SOAP 略有不同。 BizTalk 为业务流程创建的常规订阅将如下所示：

http://schemas.microsoft.com/BizTalk/2003/
system-properties.ReceivePortID == {some Guid}
AND
http://schemas.microsoft.com/BizTalk/2003/system-properties.MessageType ==
http://schemas.someschema#Root
AND
http://schemas.microsoft.com/BizTalk/2003/
system-properties.InboundTransportType != SOAP
OR
http://schemas.microsoft.com/BizTalk/2003/
system-properties.ReceivePortID == {some Guid}
AND
http://schemas.microsoft.com/BizTalk/2003/soap-properties.MethodName ==
{Inbound Operation Name on Logical Port}
[p] 

您会发现，您键入到向导中用作 MethodName 的名称必须与业务流程中该逻辑端口的“操作”名称相匹配，否则，映射的 Web 请求消息将无法发送到业务流程。[/p]

当您进入向导中的“Web 服务项目”对话框时，请输入您的 Web 服务的 URL，例如： http://localhost/MyBizTalkWebService。 另外，您还可以让 BizTalk 在应用程序中为您创建接收位置。 因为您已部署了应用程序，所以在此您可以从下拉列表中选择它。 要了解有关以上所有内容的更多详细信息，请务必查看 BizTalk 帮助文件中名为“如何使用 BizTalk Web 服务发布向导将架构发布为 Web 服务”一文。

我记得我们说过 BizTalk 的核心就是订阅，但这并不是我们的最终答案。 通过后两个技巧提示，您会发现它的核心实际上是架构。 每个消息和每个映射都依赖于一个（或两个）架构，所以掌握架构对于熟练使用 BizTalk 至关重要。


5. 始终为 Web 服务优化 BizTalk 注册表

如果您的 BizTalk 业务流程被发布为 Web 服务，那么您一定想要调整 BizTalk 使用的一些默认的 ASP.NET 参数。 实际上，这些参数会影响任何使用 CLR 的 BizTalk 项目，包括 XLANG。 BizTalk 会自动将这些建议的值乘以您拥有的 CPU 数。 具体步骤如下：

1. 在修改注册表前，首先对其进行备份。

2. 在记事本中创建一个包含以下代码的文件。

Windows Registry Editor version 5.00
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\BTSSvc$BTSHOST\CLR Hosting]
“MaxIOThreads”=dword:00000064
“MaxWorkerThreads”=dword:00000064
“MinIOThreads”=dword:00000019
“MinWorkerThreads”=dword:00000019
[p] 

在以此方式创建了文件之后，您可以在其他运行 BizTalk 的计算机上轻松地重复使用它。 DWORD 值是以十六进制形式表示的（注册表脚本不使用标准的 0x 前缀表示十六进制值）。[/p]

3. 用您的计算机的 BizTalk 主机名称替代字符串“BTSHOST”。 您可以首先运行 RegEdit 来检查主机上的实际密钥名称。

4. 如果您将文件保存为 .REG 格式，那么双击此文件就能使其在您的 BizTalk 安装上运行。

5. 运行 RegEdit 并导航至 CLR Hosting 项以验证是否已正确添加了这些值。

请参阅 msdn2.microsoft.com/en-us/library/aa561380.aspx，以了解有关此优化过程及其他优化过程的更多详细信息；并参阅 msdn2.microsoft.com/en-us/library/aa475435.aspx，以查看有关针对低延迟消息处理的性能优化方面的优秀文章。


6. 始终使用相对路径设置程序集密钥文件

此技巧将帮助您从版本控制中找到解决方案并在另一个主机上构建它。 您的团队中的一些开发人员可能会用不同的驱动器号来设置其环境，将来您也可以更改您的驱动器号。 这确实非常简单，但是您可能还想了解这些点以后的情况。

建议让解决方案的第一个开发人员在 Visual Studio 解决方案文件 (.sln) 所在的文件夹中创建一个强名称密钥文件。 然后，创建该解决方案文件夹的子文件夹，用于按项目类型（如映射、管道、业务流程、内部架构、外部架构，以及您正在编译的任何 .NET 组件）存放每个 Visual Studio 项目。 顺便说一下，不管您曾经多少次听到此建议，都不必将其视为严格的规则。 如果您了解某些项目将来可能要一起修改（如映射及其架构），那么您就应将它们放在同一项目中，以减少必须重新部署的组件的数量。 在开发过程中，我们可以在解决方案中的各项目之间以及在各开发人员之间共享同一密钥文件。 （为运行环境创建安全的密钥文件是另一回事。） 只需将密钥文件与解决方案中的其他项目一起签入到版本控制中即可。 现在指明解决方案中每个程序集的密钥文件的路径。 对于 BizTalk 项目来说指明路径的方法是“..\..\..\Key.snk”，如图 6 中所示。 这一方法之所以可行，是因为 BizTalk 在名为类似 [YourSolution]\[YourProject]\bin\Development 的子文件夹中生成您的二进制文件。 因此，三个父目录跳转使 BizTalk 返回到您的包含密钥文件的解决方案文件夹。


图 6 为 BizTalk 项目配置程序集密钥文件 (单击该图像获得较小视图)
图 6 为 BizTalk 项目配置程序集密钥文件 (单击该图像获得较大视图)

注意，如果您要向您的解决方案中添加多个 .NET Framework 类库项目，而使用与 BizTalk 项目略有不同的目录结构对这些项目进行编译，那么用于设置密钥文件路径的 Visual Studio UI 一定不允许您输入相对路径。 一种解决方案是将 .csproj（针对 C#）或 .vbproj（针对 Visual Basic®）作为文本文件进行编辑。 搜索您在 Visual Studio 项目属性 UI 中浏览到的密钥文件的名称，然后用一个只包含一级父目录的相对路径（如，..\Key.snk）替换它。 在每次生成后，不要忘记将您的 .NET Framework 程序集添加到 GAC 中。 利用 Visual Studio 中的生成后步骤可以自动实现这一点。 它只需要完整路径和用引号引起来的字符串以及空格，格式如下所示（全部在同一行中）：

“C:\Program Files\Microsoft Visual Studio 8\SDK\v2.0\Bin\gacutil.exe” /i “$(TargetPath)” /F
[p] 


7. 永远不要忽视免费的示例代码
下面是一个非常有意义的小技巧。 BizTalk 帮助文件收录了 50 多个示例应用程序和脚本（安装在 SDK\Samples 文件夹中），您可以从中学习，对其进行修改和重新使用。 在以下页上您还可以找到 30 多个有用的 BizTalk 应用程序： msdn2.microsoft.com/en-us/biztalk/aa937647.aspx。 最后，BizTalk 博客作者指南（位于 GotDotNet.com）中涵盖了 400 多篇技术文章，其中包括许多有用的代码段和示例。 我将此博客作者指南的快捷方式保存到我的桌面上，这是在进入新的 BizTalk 领域时我首先会去看的地方之一。[/p]

我们承认，如果您已经知道了这一点，您可能会认为这个技巧提示没什么稀奇。 但考虑到除此之外很难找到专业水准的 BizTalk 示例代码，我们认为需要提醒您还是应该将它放在手边。 问题是，这些示例不光在您开始了解 BizTalk 时非常有用，它们还是可供反复查阅的宝贵参考资料。

顺便说一下，不要忘记经常回到 MSDN 查看 BizTalk 帮助文件，它是定期更新的。 您可以以 PDF 或压缩的 .chm 格式下载它，也可以在线浏览。


8. 在 Visual Studio 中调试 XSLT

这可能是 Visual Studio 中最鲜为人知的功能了，它不需要安装 BizTalk。 XSLT 调试器使您能够在其运行时查看转换的结果、设置断点、检查局部变量和调用堆栈。 您甚至可以从 C# 或 Visual Basic 单步执行您的 XSLT 脚本。

图 7 显示了一个正在运行的转换示例。 我刚刚创建了一个空白的解决方案，并加载了以下这个将转换为 HTML 格式的很小的 XML 数据文件：


图 7 Visual Studio 中的 XSLT 调试器 (单击该图像获得较小视图)
图 7 Visual Studio 中的 XSLT 调试器 (单击该图像获得较大视图) 

<?xml version=”1.0” encoding=”utf-8”?>
<node attr=”debug” />
然后，我进入 XSLT 文件（您可在图 7 的左窗格中看到）。它将创建一个 Hello World 文档，而如果节点元素有一个 attr 属性等于“debug”，它也会启动调试。 [p] 

现在，将光标放在 XSLT 文件中（这一点很重要），将“输入”属性设置为您将要转换的 XML 数据文件的路径。 注意，在“解决方案资源管理器”窗口中右键单击 XSLT 文件名将显示一组不同的属性，这是“文件”属性，不是“文档”属性。 我希望上述过程更加直观，但是现在只要一学就能掌握。 如果说专业级人员与水平一般的人员有何区别的话，那就是探索精神。 您还可以设置“输出”属性，或体验中间窗格中所示的转换过程。[/p]

当 Visual Studio 中的活动文档为 XSLT 文件时，下拉 XML 菜单（位于主菜单栏上）包括 Debug XSLT 命令。 只需单击此命令即可查看转换代码，甚至深入查看子例程。 图 7 显示了程序执行完 xsl:if 测试后“监视”窗口中 @attr 的值。 正如您可从中间窗口的输出看到的那样，测试结果为 true，并且 <h1> 节点为输出。


总结

考虑到当前公司正在开发的应用程序数量如此之大，使用较好的工具和技术尽快开发出可行的解决方案至关重要。 BizTalk 将帮助您高效地完成从概念到工作原型的过程，同时我们希望这些技巧提示将在您的工作中为您节省一些时间。

内容来自用户分享和网络整理，不保证内容的准确性，如有侵权内容，可联系管理员处理 点击这里给我发消息
标签： 
相关文章推荐
新的分享
章节导航