个人写的总结，希望被指点。我初学Biztalk2006，现在实习，如有错误，请务必指出：）再次说明，发到这里是需要各位的帮助，因为这个方案做不出来，下星期就要变方向了。谢谢！
基于BizTalk Server的工作流实现方案
——基于visio的业务流程实现方案研究
一、 本阶段主要任务(8.11--8.17):基于visio的业务流程实现方案研究
用Visio创建一个典型业务流程，并提交BizTalk执行。通过实验摸清每个环节，并评价该方案是否适合业务人员使用，难点在哪里？提出改进方案，提交总结报告。
二、 Visio创建流程的基本方案
1. 业务流程建模——Visio 流程设计
作为业务流程的催化剂，商业分析师提供了流程的最初提案，然后将其交至负责架构设计的开发人员。过去，提案仅仅是一个书面上的临时设计。但BizTalk Server 2006包含了商业设计师编排设计器（ODBA）,见图1，一个与BizTalk 2006开发环境集成的Viso图形插件。商业分析师可以通过这一图形工具将各种流程形状拖至绘图板上，为形状添加注释，然后将绘图保存为兼容文件，供开发人员导入至Visual Studio .NET。
使用 Microsoft BizTalk Server 2006 业务分析员的业务流程设计器 (ODBA)，可创建用于显示业务流程的常规流程的业务流程关系图。使用 ODBA 可以执行以下操作(注：更详细的内容请参考附件1)：
- 创建业务流程关系图的结构。
- 验证业务流程关系图的结构。
- 将业务流程关系图导出到 .odx 文件，解决方案开发人员可将该文件导入 BizTalk Server 2006 业务流程设计器中。
- 将开发人员实施的业务流程作为业务流程关系图导入 ODBA 中。
- 通过将目标数据和里程碑添加到业务流程关系图中来定义业务活动监视 (BAM) 活动。
- 导航至 BAM 网页并从 ODBA 业务流程关系图内访问实时 BAM 数据。
图1：Visio的ODBA业务流程设计器
2. 不使用ODBA，直接由技术人员在Biztalk2006中创建流程的过程
为了突显ODBA在整个开发过程中的作用，此处描述了用Biztalk2006直接建立一个简单流程的例子。这个例子（图2）可以描述为：当仓库的某类产品的存货量少于10时，则向Biztalk Server发送申请购货的请求（Request）；如该请求的数量超过Biztalk Server所设置的最大值（假设为500），则服务器自动返回一个Denied Request，拒绝该请求，否则同意该请求并向ERP发送一个Approved Request，请求ERP做进一步处理.(该例子更详细内容请参考附件2)。
图2：一个简单的例子
该例子在Biztalk2006中的实现见图3。从该图也能反映出：在一般情况下，建立Biztalk Project时，表单(*.xsd)、管道(*.btp)、映射(*.btm)和调协器(*.odx)是必须的，图3中的红色圈住部分1、2描述了这些文件(更详细的内容请参考附件3)。其中*.odx文件描述了业务的流程，图3的流程图是由Biztalk2006中的Orchestration Designer所设计的，这部分工作由技术人员实现.
图3：在Biztalk2006 中直接建立该流程
3. 使用ODBA建立该流程
首先由业务人员在Visio中定义该流程，见图4；然后通过ODBA把该流程图导出为*.odx文件，见图5.双击打开导出的文件,见图6.
图4:ODBA中定义的流程
图5:ODBA导出*.odx文件
图6:打开导出的*.odx文件
对比图3和图6，可以发现ODBA仅仅导出是一个*.odx文件，要建立一个完成流程的project，仍然需要技术人员对图3中除*.odx等其它文件进行设计。事实上，*.odx文件本身描述了流程定义的信息，是Biztalk中重要组成部分，但从这个例子可以看出，在Visio方案中，ODBA仅是对*.odx文件设计的一个简化，并不能像BPEL文件能直接导入Biztalk2006直接可以部署执行(假设Biztalk2006能完全支持BPEL)。
三、 总结
l 该方案是否适合业务人员使用
下面这几段话为微软公司对“Visio 允许信息工作者设计业务流程”的说明:
由于业务流程会跨越广阔的功能域，与程序员相比，不懂技术的业务分析师更容易理解这些业务流程。因此，在业务分析师和开发人员之间良好的沟通是必要的。在这种环境中，像 Visio 这样的熟悉工具可以帮助保证业务流程能够按预期的方式工作。
“Visio 为业务分析师提供了一种结构化的方法来创建业务流程，然后将它交给开发人员将其作为可执行的业务流程在技术上实现，”Woodgate 解释说。“Visio 给业务分析师提供了理解最初阶段的灵活性，以及随时间修改业务流程并将这些修改与开发人员进行沟通的能力。”
设想这样的一个场景：某个全球金融服务机构的业务分析师，他正在设计更高效的业务流程。假定他希望这个业务流程在某个欧洲客户申请贷款并且该贷款具有某些指定的特征时，申请必须被发送给公司的美国分部。他还可能希望建立其他某些例外条件。例如，如果贷款高于 20 万美元，但这个客户是该银行“Gold Club（黄金俱乐部）”的会员，或者申请者是银行业 20 年的合作伙伴，则该申请将以如此如此的方式进行处理。该业务分析师可以在 Visio 中可视化地设计这个流程，然后在 Visio 和 BizTalk Server 2004 之间使用导出－导入功能将这个设计方案导出给开发人员。
另一个例子是，假定某个开发人员正在使用 Microsoft Visual Studio .NET 2003 (包括在 BizTalk Server 2004 中)，为某个制造公司设计采购流程。业务分析师使用 Visio 绘图工具绘制了这个采购流程的各个步骤：接收订单，将订单发送给后端 ERP 应用，等等，直到绘制出整个流程。然后，她将 Visio 图表直接发送给开发人员，而传统的方法是将设计方案打印出来，然后走过大厅，将图纸交给开发人员——然后希望他能够理解正确。随后，如果开发人员要求业务分析师对业务流程进行修改，她可以很容易地查看 Visio 图表，然后决定在将订单发送给 ERP 应用后需要有一个“经理审批”步骤。她可以简单地对 Visio 图表进行更新来反映这种变化，而不需要对幕后技术是如何运行的有深刻的了解，然后将修改后的业务流程交给开发人员实现。
微软的ODBA工具的目的是：方便业务人员更方便定义流程，直接导出Biztalk中最重要的组件之一*.odx，方便技术人员做进一步开发。但经过实验，我们发现实际效果并没有想象中的那么好，理由如下：
1) Visio下的ODBA仅仅是对Biztalk Server中的Orchestration Designer的一种延伸，经过业务人员画流程图导出*.odx文件供开发人员做进一步处理。事实上，在ODBA中作图也并非很简单（当流程较多时，这时设计流程图将是很具有挑战性的），如果业务人员不熟悉Visio和Biztalk，导出来的*.odx文件可能存在错误、不精确，需要技术人员对该文件检验、优化，而且不熟悉ODBA的业务人员要花费较多的时间去定义该流程图（并且不能保证设计出的图是正确、最优的）。在某种程度上，这种方案还不如“业务人员用纸画图告诉技术人员所要定义的流程，由技术人员直接在Biztalk中设计*.odx”的效率高。
2) 如角色分配等工作流上的概念在这种方案下的实现过于死板，甚至是不可能的，缺乏灵活性。
l 可能的改进方案
1) 在visio ODBA的方案基础上开发自定义工具。按照需求说明，为了减少因为业务变动而带来的工作量，按照Biztalk的“三层开发模式”（请参考上次发过去的“需求疑问”的文档）,实际目的是为了减轻“开发人员”的工作量。最理想的是业务人员设计出来的流程图能直接导入Biztalk中便能部署使用，而不需要技术人员过多的二次开发。在Visio方案的基础上开发自定义工具，目的是希望通过该工具能直接生成图3中尽可能多的文件（而不仅仅是*.odx），据我们目前了解到，如果该工具能导出被Biztalk识别的BPEL文件，则这种方案将可能成功（但根据另一个小组的研究，这种可能性不是很乐观）。
2) 严格按照“三层模式”开发，这种方案能最大程度实现需求，也是最直接简单的方法，但很显然，这并不能减少技术人员的工作量，甚至是增多了。
3) 转向微软提供的一个Work Flow Studio的工具的研究，但该软件的商业性质如何并不清楚；再者它跟Biztalk是怎么样的一种关系需要进一步研究；此外该软件应是微软内部的，所需要的资料较为缺乏。
4) 基于Windows Workflow Foundation（WWF）. 它是微软最新的WinFX平台（已改名.NET Framework 3.0）的一部分，将集成在Windows Vista中，目前尚未发布，可下载Beta2版本。这是微软针对BizTalk不足而提供的Human Workflow产品。
1735
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
