经验丰富的.NET＆amp; SQL开发人员从1个月开始成为一个项目的BizTalk专家？我该如何度过有限的时间来获得一些实用的技能呢？ BizTalk的知识，所以我可以“说说话”？
我是自雇人士，不愿意花300多美元。我有Wrox的“Professional BizTalk Server 2006”这本书，但没有发现它是一个特别好的学习资源（非常干燥，需要更多现实世界的例子）。
答案 0 :(得分：6)
MSDN中的BizTalk Virtual Labs是一个非常好的开始。 Pluralsight还有几个很好的BizTalk课程，他们的在线订阅并不算太贵;可能是一个不错的选择。
答案 1 :(得分：5)
我同意迄今为止写的所有内容。所有可靠的信息。
我有一些插件，来自一位自2002年以来与BizTalk合作的自由职业者：
单元测试。
这不容易，但请查看BizUnit。由Kevin Smith编写和维护的基于Codeplex的工具集。早期的BizTalk英雄之一:-) http://bizunit.codeplex.com/
部署/投入生产 但请记住，日常开发工作中没有任何一项能够为您必须部署应用程序并确保操作“可管理”的项目部分做好准备。这可能非常复杂，并且本身就是一个主题。 查看Apress Pro BizTalk 2009，它有一个不错的（IMO）章节。
围绕BizTalk的整个开发过程。 同一本书的前两章将让您对BizTalk项目的内容有一个好的印象。在哪里使用它，在哪里不使用它，如何组织项目，并命名你的东西。真的是一个很好的信息收集，你只能通过阅读5 - 6年的博客回来： - ）
最后一件事。根据项目中的角色，可能会要求您优化和调整BizTalk。如果他们不问你。确保你问其他人是否已经这样做，因为你必须这样做。应该始终将BizTalk调整到它应该做的事情。低延迟与高吞吐量，根据硬件调整，正确设置和SQL框周围的网络配置等等。这可能是毛茸茸的东西，你应该注意不要在阅读之前跳进去。但这是一个主题，我们通常期望自由职业者能够处理......所以我想我可以提出来。
示例... x64盒子上的BizTalk x64进程运行起来非常糟糕，实际上比x86进程差。需要调整64位进程以真正使用可用于它们的所有MEM。
无论如何......一袋混合小贴士，我希望你可以使用其中的一些！还有祝你好运！这可能是一个艰难的开始，但如果使用得当，BizTalk可以是一个伟大的产品/工具集。
请记住......如果它是丑陋的，或是硬的，或两者兼而有之。你做错了。并且不要害怕潜入.net代码，并将其固定到BizTalk框上。我们都这样做......有些人不会承认： - D
答案 2 :(得分：1)
从tomasr的建议开始。
然后，尝试尽可能真实地构建一些东西。 Biztalk是一种产品，当你阅读本书并按照例子，一切都很好，然后你坐下来做一些事情，你正在思考“我现在该做什么”。
答案 3 :(得分：1)
根据Thomas和Shiraz的说法 - 建立一个环境，让你的手弄脏。如果您还没有这样做，请下载并安装BizTalk Server 2010 Developer Edition
但是为了缓和你的期望，恕我直言BizTalk（或任何其他EAI / BPM / ESB产品）的专业知识可能需要数年才能积累。
目前尚不清楚您是否正在为已建立BizTalk安装的客户端开发，或者这是客户端的第一个BizTalk部署。如果是这样，有一点不可低估的是，运行生产BizTalk环境的操作考虑因素（性能，冗余，可靠性，审计，跟踪，使用SCOM进行监控等）与开发和测试一样复杂 - 但对此的理解将是对于“说说话”非常重要。
W.r.t。 dev，从一些简单的EAI类型映射项目开始，然后通过SDK samples进展到一些常见的消息传递模式（例如使用聚合器进行批处理），然后进入BPM类型编排。您可以将BAM和BRE留待以后使用。
祝你好运！答案 4 :(得分：1)
+1 tomasr提及虚拟实验室。 Shiraz Bhaiji也提到，亲自动手是必经之路。希望你不是从BizTalk 2006开始，并且可以使用最新的：2010。如果是这样的话，你可以得到Developer Ed。 BizTalk 2010现在免费提供（参见nonnb的链接）。
我还推荐Richard Seroter的书：'使用BizTalk Server 2009的SOA模式'（available on Amazon.com）。有很多方法可以使用BizTalk来完成“错误”的操作，本书非常出色地介绍了构建BizTalk解决方案的方式和原因（使用the publisher's site提供的代码示例）。是的，它几乎需要整本书才能完成。它是Pro BizTalk 20xx系列的一个好的（更易阅读的）伴侣（对于非常具体的问题/任务通常更好）。