一位BizTalk的MVP在5月2日发布了一个叫做BizTalk 360的CTP（社区技术预览）版本，乍一看以为360安全卫士呢，可以访问这里了解更多信息并下载CTP版本。
需要澄清一下 BizTalk 360不是微软官方发布的产品，而是一位MVP自己开发出来的。
BizTalk 360 介绍
简单来说BizTalk 360是一个基于Web页面的管理控制台，可以通过这个Web应用集中部署我们的BizTalk应用程序，不再需要在BizTalk维护人员的机器上安装所有的BizTalk管理组件了。同时它为我们提供了丰富的授权模块，并允许BizTalk维护人员设置更细粒度的权限验证，不再通过远程访问的方式来访问生产环境的服务器，因为那样做我们无法控制对BizTalk应用级别的权限控制，通过远程访问登录到服务器，就可以操作所有的BizTalk应用程序，这是我们不想看到的。现在BizTalk 360通过Web的方式可以设置对BizTalk应用程序级别的权限验证，某个用户可能只能维护一台生产服务器的其中几个BizTalk应用程序，而其它的应用程序是他没有权限操作的，并且还可以对BizTalk应用程序设置只读访问权限，甚至如果你只想让某个用户看到某项BizTalk应用程序的某个部分，比如某个应用程序的BAM数据等等。
BizTalk 360 处理用户访问机制
- BizTalk 360使用Windows身份认证和授权两种方式，它没有独立的用户身份存储库。
- BizTalk 360授权支持两种方式，一种是Windows身份认证方式，另一种方式是在BizTalk 360中分配用户类型。
- BizTalk 360中包含3种账户类型：超级账户、默认账户和自定义账户。
- 超级账户拥有最高级别的权限，该账户几乎可以在BizTalk系统中做任何事情，默认情况下安装BizTalk 360的账户为超级用户。
- 默认账户用来限制当一个未知用户访问BizTalk 360时的访问权限。
- 自定义账户只能由超级帐户来创建，可以细化访问BizTalk 360的权限，比如访问BizTalk 360的部分功能。
BizTalk 360 安装条件
所需系统配置
- Windows XP SP3, Vista, 7, 2003 R2, 2008, 2008R2
- BizTalk 2006, 2006R2, 2009, 2010
- SQL Server 2005, 2008, 2008 R2
- IIS 5.0, 6.0, 7.0, 7.5
账户权限配置
确保BizTalk 360的应用程序池账户在以下组中：
- BizTalk Server Administrators 组
- SSO Administrators 组
- IIS_IUSRS 组
数据库权限配置
需要赋予BizTalk Admin角色SELECT查询权限，可以通过运行如下T-SQL脚本来进行配置：
- GRANT SELECT ON dbo.adm_OtherDatabases TO BTS_ADMIN_USERS
- GRANT SELECT ON dbo.adm_Server2HostMapping TO BTS_ADMIN_USERS
- GRANT SELECT ON dbo.adm_ServiceClass TO BTS_ADMIN_USERS
- GRANT SELECT ON dbo.BizTalkDbVersion TO BTS_ADMIN_USERS
功能介绍
按照上述步骤安装好BizTalk 360后，使用IE访问部署好的IIS应用程序即可。
BizTalk 360 首页
我安装BizTalk 360的机器使用的是之前几篇文章做演示用的虚拟机，在首页上我们可以看到之前做演示的BizTalk应用程序，例如ConsumeService、OrderProcessing等，加上默认的一共有7项应用程序。主机和主机实例共有4个，我将BizTalk Server、SQL Server都部署在了一台服务器上，并都仅安装了1套，在主页上这些信息都可以很清晰地看到，如果有多台BizTalk服务器，其效果是一样的。
我是以安装BizTalk 360的账户登录进来的，该账户默认被配置为超级管理员账户，因此能看到所有BizTalk的信息，我们可以进行身份认证和授权，控制用户的访问权限，这样每个人进来看到的就只有它们所能够看到的内容，和它们无关的内容则不会被显示出来。我们还可以通过这里监视BizTalk系统的健康状况，我们看到数字的底色有红色和绿色的，红色表明其中存在错误或异常，而绿色的则表示环境正常，没有错误。当有实例挂起时，在主页上也会有红色的提示框来显示挂起实例的数量、具体信息以及时间等信息。
应用程序界面
我们点击主页上的第一个显示有7个应用程序的按钮，找之前介绍WCF那篇当中的应用程序来看一下，还记不记得之前那篇WCF的BizTalk应用？审批贷款申请的，如果想不起来的话可以到这里恶补一下再回来，呵呵，继续往下看也是可以的。找到ConsumeService并双击进入应用程序界面，先来张图吧。
BizTalk Application Dashboard提供给我们了一个单一的视图能够从这里监控并管理BizTalk应用程序，同时它也是非常直观的，可以看到红色字则表示在这个应用程序的接收端口和发送端口都有错误或异常，这是因为我之前把这两个端口给禁用所导致的，我们之前配置的业务流程和这个业务流程所寄宿的主机实例是没有任何问题的。那么既然发现了问题，我们就对这个错误进行详细的追踪和排查，可以点击Detail按钮查看端口的详细信息，它会把我们带到另一个界面当中。
有没有一种越看越兴奋的感觉呢？我们现在进入的是发送端口的界面，在之前的示例中我曾经配置过3个发送端口，其中一个用来调用Web Service方法并获取当中的返回值，在这里我们可以看到关于这个发送端口的详细信息，包括它是否是一个Request-Response双向端口、是否是动态的、它的端口类型是什么，Web Service的URI等等。
我们双击这个端口，可以显示出这个端口的详细视图，通过上面这个详细视图，我们能够看到这个端口的管道、接收和发送的映射、还有端口的过滤条件等等信息，并且可以对它的配置进行备份以及进行更高级的设置。此处不解释太多，一张图胜过1000个字。
下面我模拟一些错误，来看看BizTalk 360当中对消息实例的追踪功能，我故意停掉了调用外部的那个Web Service，这样当消息在流程中走到调用Web Service的时候，会得不到返回值，因为已经停掉了，这样BizTalk会启动长事务机制，将该消息实例进行“脱水”，我们看看这样的一个内部机制，能不能从BizTalk 360中体现出来。
我太欠了，故意让所有的消息实例都因为等待外部Web Service的返回值而“脱水”了，还成心改变了一个消息的XML Schema架构，因此被挂起了，我们通过这个界面很容易地能排查出消息未能达到目标系统的原因，帮助我们判断出是哪里出了问题，当遇到“丢单”或目标系统接收不到数据的时候，能够更加有针对性地找到原因，不至于部门之间互相扯皮了，帮助构建和谐社会啊。
我还是做点好事吧，重新恢复了Web Service，现在调用Web Service完全正常了，刚才“脱水”的消息现在被挂起了。
现在我将这些消息进行恢复，让他们重新去调用Web Service，由于现在已经可以成功调用，所以恢复之后消息会按照流程预期的处理达到目标系统当中。
通过查询“所有处理过程中的实例”这一项来看，我们所有的消息在恢复之后已经成功走完了流程并达到了目标系统（这里是文件系统），看到~Out文件夹里新生成的审批结果的消息了吧？至于是如何得到审批、流程是如何处理的，请看之前我写的那篇WCF - Service，里面有详细的步骤，这里省略一万字。
拓扑图界面
拓扑图界面给我们提供了一个物理的BizTalk组部署架构，在企业级环境中，高可用性的部署架构非常普遍，我们可以通过这个界面随时了解到自己BizTalk的部署环境，并且无需再使用Visio或其它绘图工具去花时间设计自己组织内部的部署架构，通过这张图便可以一目了然，它能够动态的获取到当前BizTalk以及SQL Server服务器的部署方式及每台服务器的用途。
有点不体面，因为是做实验用的虚机，所以所有的东西都部署在一台服务器上了
上网上找了一个图，是部署了4台BizTalk + 2台SQL Server的高可用环境，等有条件了，我也要这么奢华的配一把！！
其他功能
有些功能在网站介绍上看到了，但是安装上BizTalk 360之后发现目前的这个版本还没有，想了解更多的功能目前请访问www.biztalk360.com查看。
通过这次的试用，发现这是一个非常不错的工具，大家有兴趣也可以试试。