随笔 - 181, 文章 - 2, 评论 - 85, 引用 - 0
数据加载中……

6月14日-----业务流程建模

什么是业务流程建模?

流程是指定的活动顺序,包含明确确定的用于提供业务值的输入和输出。例如,技术文档搜索流程从 Web 页面提取客户的搜索请求,并生成可选的文档列表。

对流程进行建模是非常大的挑战。建模应当确保捕获的相关信息的一致性及完整性,以便业务分析员及开发人员能够理解模型所捕获的业务需求。在建模过程中,除了正常操作以外,标准流程的其它操作和异常必需获取。具有不同领域兴趣的专职人员和专家可以构建适合于大范围业务对象的流程模型。例如,分析员需要对流程有高度的见解以做出战略性决策,并进行诸如仿真之类的流程分析。开发人员将流程模型作为输入来实现解决方案。

分析员基于从业务需求所有者中所收集的需求构建业务流程 (BP) 模型。通过使用适当的工具(例如 PowerPoint、spreadsheets、IBM® Rational® Requisite Pro 或者其它任意工具组合,并且在适当的时候可能是流程建模工具本身)来收集这些需求。分析员将这些需求及对现有流程的分析作为构建模型的输入条件。现有的流程模型用于对其进行分析或者通过修改现有的模型来创建新的流程模型,而不用从头重新创建。

通过将 BP 分成子流程开始建模过程。随后是对感兴趣的各子流程进行分析以确定组件、服务、输入输出数据、策略及测量。通过使用 WebSphere® Business Integration Modeler 软件工具 (Business Integration Modeler) 将这些元素编码到 BP 模型中。

使用一种名为流程元素的建模构件来定义 BP 段,将其设计为可复用。流程元素是一种定义流程段的构件资产,在 BP 模型中,这种流程段被设计为可复用的构件来管理。它们将已建立的一系列任务、决策、对数据对象的引用、策略、角色及测试合并起来。例如,登录流程元素包含一系列活动,登录证书数据以及完成用户登录过程的登录规则。

这些流程元素表示可接受的操作行为,类似的需求也可复用它们,例如,作为子流程模型以检验和为购物篮中的商品定价。

服务元素是预先定义的服务,可以被导入到 Business Integration Modeler 中以集成到模型中。这些服务元素指定了输入、输出以及发布的 Web 服务的操作。例如,服务元素可以指定发布远程部件提供者的 Web 服务。







进行 BP 建模的工具

Business Integration Modeler 为分析员提供了工具以进行建模、分析、仿真,并在将它们转换或导出到 Rational XDE 的 UML 模型或 WebSphere Business Integration Server Foundation (Business Integration Server Foundation) 的 Web 服务的业务流程执行语言 (Business Process Execution Language for Web Services,BPEL4WS) 中之前改进了业务流程。我们使用 Business Integration Modeler V5.1 来创建 BP 模型并且将它们导出到 WebShere Studio Application Developer Integration Edition V5.1.1 (Application Developer) 中,如图 1 所示。


图 1. 从分析员到开发人员的模型转换
从分析员到开发人员的模型转换

Business Integration Modeler V5.1 提供了一套丰富的流程建模功能,包括许多图形化及文本编辑器、业务操作模型 (business operations model,BOM),以及用于将 BOM 转换成相应的目标平台构件的转换机制。


图 2. Business Integration Modeler 编辑器、模型及转换
Business Integration Modeler 编辑器、模型及转换

图 2 所示,分析员在适当的编辑器(例如,用于 BP 工作流(包括活动及它们之间的连接)的图形表示的用户流程编辑器)中创建了各种流程元素。这些流程元素作为 BOM 存储在磁盘文件中。Business Integration Modeler 自动应用 BOM 上的相应确认。在模型导出的后期,分析员将应用适当的转换机制将 BOM 转换成相应的目标构件。图 2 显示了受支持的四种类型的输出构件:

  1. Business Integration Modeler 构件(业务流程执行语言 (BPEL)+/XML Schema 定义 (XSD)/Web 服务描述语言 (Web Services Description Language,WSDL))
  2. MQ 工作流的 FlowMark 定义语言 (FlowMark Definition Language,FDL)
  3. UML
  4. 受限文本

业务流程建模包含:

  1. 收集 BP 需求。
  2. 模型业务项目。
  3. 模型角色和资源。
  4. 模型服务。
  5. 模型策略。
  6. 模型关键性能指示器 (Key Performance Indicators,KPI)。

我将在接下来的部分中详细地介绍每一步。







收集 BP 需求

BP 分析员与 BP 所有者及领域专家协作来获取所需的全部信息以构建 BP 模型。例如,分析员使用适当的工具收集角色、任务、序列信息、资源、数据、叙述、需求,等等,并将它们作为构建 BP 模型的输入内容。通过在 Business Integration Modeler 中创建流程模型,业务分析员所获取的信息可以轻易地导出给工作流开发人员,使他们在 Application Developer 工具中使用这些信息。







模型业务项目

业务项目是业务文档、工作产品或者在业务操作中使用的商品。业务项目的一些实例包括订单文档、客户地址及材料帐单。分析员可以导入以 XML schema 格式定义的数据模型或者使用 Business Integration Modeler 来创建新数据模型。

数据建模的元素包括创建如下内容:

  • 数据目录
  • 业务项目
  • 业务项目模板
  • 业务项目实例

数据目录是用于组织业务项目、模板及项目实例的文件夹。数据目录的创建是可选的;如果没有选择,那么将会以 Business Integration Modeler 默认的业务项目数据目录来创建数据模型。

创建业务项目并将其添加到现有的数据目录中。随后将业务项目属性添加到业务项目中。例如,我们有 order 业务项目,它有诸如 orderItemsvalid 之类的属性。这些属性可能是简单类型(String、Integer、Boolean 等等),也可能是同一或不同数据目录中的业务项目。例如,order 业务项目可能包括 OrderItem 类型的属性 orderItems,该类型位于同一或不同数据目录中。

业务项目模板可以用于创建具有公共属性的业务项目。新建的业务项目可以添加新的模板中没有的属性。例如,可以创建具有适当属性的 orderItem 模板,然后使用该模板无需输入完整的 orderitem 属性就可以创建 purchase ordermanufacturing bill of materials 项目。此外,可以通过添加新的属性来添加适当的扩展名。例如,您可以从 orderItem 模板中创建 purchase order 项目,然后加入额外的属性,如 purchase datelocationstore 等等。业务项目实例表示具体的业务项目事件,例如,制造号码为“1xDBCS”的订单。

对业务项目进行建模的指导

可以将规则与业务项目和它们各自的属性联系起来。但是,由于目前 BPEL 输出不支持该功能,所以它应当被添加到模型中以帮助开发人员开发。我们推荐将创建数据目录及业务项目作为流程建模的第一步,以便它们可以与其它任务相关联。

通过设置项目属性的最小值和最大值来创建业务项目的定购序列(数组)。无论何时只要可以就使用 WBI 模型中的 XSD 引入选项从现有的 XML schema 元素中引入业务项目。将数据目录映射到 java 包及 XSD schema 的目标命名空间中,因此我们推荐使用适当的使用数据目录名称以避免开发问题。







模型业务角色和资源

资源是指人、设备及执行任务所用的材料。角色为资源添加了额外的特征。例如,雇员可能是经理。为任务指派角色主要为了在具有员工活动的流程中使用。例如,管理员可能处理任务中的异常(例如,无效的命令、系统崩溃)。通过调整资源分配来进行流程分析。该分析提供了资源利用级的详细信息并且有助于计算耗费及周转时间。这有助于优化和改进流程。此外,对于工作流而言,角色用于将人分配到员工活动中。







模型服务

在 Business Integration Modeler 中,服务被定义为外部实体(不包括在被建模的流程之内),可以从组织流程的内部使用这些外部实体。

在 Business Integration Modeler 中,可以将一套输入分组作为输入标准。每个输入标准都定义了特殊的输入组合,这些组合可以启动流程、服务或任务。如果输入不止一个,那么默认按照的条件。对于条件,可以创建额外的输入标准。向 BPEL 导出时,限制每个元素只能有一个输入标准。类似地,使用输出标准将输出分组。在 Web 服务 WSDL 接口模型(portType 定义)中,这些输入及输出标准分别被映射到操作输入及输出的消息中。

对业务服务进行建模的指导

虽然可以为每种服务创建许多输入及输出标准,但是在 BPEL 中这是不允许的。对于基于 BPEL 的可执行的工作流来说,推荐有限的一个输入标准及一个输出标准。WSDL portType 操作接受单一的输入消息及单一的输出消息。清单 1 展示了如何将输入标准及输出标准映射到 portType 操作的输入及输出消息中。


清单 1:输入标准和输出标准
												
														<portType name="ValidateGenerateTopologyPT">        
<operation name="sendValidateGenerateTopology_InputCriteria">
   <input message="tns:InputCriteriaMessage" 
name="InputCriteriaMessage"/>            
<output message="tns:OutputCriteriaMessage" 
name="OutputCriteriaMessage"/>        
   </operation>    
  </portType>
  					
												
										

目前还不能通过复用现有的服务 WSDL 来创建服务元素。要复用现有的 WSDL 需要更改已生成的代码。随后开发人员应当通过 BPEL partnerLinks 与适当的外部服务相关联。







模型业务策略

分析员可以指定需要的策略,但是需要显式的、可执行的规则来实施这些策略。策略通常是要声明的,例如,“仅美国客户可以定购机器 X”。在实施中每个策略可能需要一个或更多的实施点。实施点可以作为流程的显式步骤或代码中的指定位置来实现。处理事件的时候也可能出现实施点。规则对于实现策略实施点来说是有效的方式。规则是强制性的且在逻辑上是可执行的。清单 2 展示了一个简单规则的实例。


清单 2:简单规则
												
														"If !(location(customer) == "USA") then reject(order);"
												
										

在某些情况下,没有显式地声明策略,但是在实现中隐含地定义了策略。换句话说,实际的已实现的实施点和规则定义了策略。

分析员将策略写入每个任务的注释中。开发人员负责将策略转换成规则。分析员可以向模型中添加服务元素,这代表了提供实施点的现有服务。他们还可以添加任务来表示实施策略的代码的占位符。开发人员为实现该任务添加必要的代码,换句话说,就是执行适当的规则。(详细信息请见“随需应变业务流程的生命周期”系列文章的第 4 部分——请参阅参考资料)。







为流程建模

为流程建模的任务包括定义业务流程的细节,并为所有数据、资源及流程中所使用的其它元素建模。业务流程包含一些流程步骤,它们通过控制流相连接,这些控制流将活动与决策点相连。决策点遵循业务规则(转换条件),使用这些业务规则来确定流程应当依照什么路线进行。建模包括将 BP 分解成子流程并将所需的流程元素添加到模型中。分析员可以将现有的模型构件(例如,服务或流程元素)用于促进并加速模型的构建。文章“使用 WebSphere Business Integration Modeler 进行业务流程建模”(“随需应变业务流程的生命周期”系列文章中的部分)描述了从建模构件中构造流程模型(请参阅参考资料)。







模型关键性能指示器

关键性能指示器 (KPI) 是为跟踪业务的关键因素的成败而设计的。BP 监视功能使流程所有者及管理员能实时监视 KPI。这些功能有助于分析员确定现有流程中的问题及瓶颈,从而结束开发循环,如该系列文章中的第 1 部分中所述(请参阅参考资料)。Business Integration Modeler 提供了将 KPI 添加到流程中的工具,来记录我们希望跟踪的那些流程的关键因素(详细信息请见文章“使用 WebSphere Business Integration Modeler 进行业务流程建模”)。







其他的建模指导

  • 在 Business Integration Modeler 中存在三种模式:FDL、BPEL 和 Operational。如果将在 Business Integration Server Foundation 中执行流程,那么应该使用 BPEL 模式建模。这有助于在导出模型之前在 Error View 中查看并且确定验证错误。
  • 应该使用高级业务建模的用户配置文件来添加运行时需求,如控制任务执行的输入标准和对资源的使用。
  • 业务项目建模细化——可以不定义业务项目的所有细节,随后将其细化成更多的细节,如新的属性。它们也可以从 XSD 文件中引入。
  • 故障处理不应是模型中的内容,而应留给流程开发人员处理(例如,对服务超时的处理)。






流程模型的验证

将模型放置在 BPEL 模式中,这样就启动了 BPEL 验证检查装置。任何错误及警告都会出现在 Error View 中。您可以通过过滤该列表来显示错误信息或警告信息,并且从整个项目到仅所选定的元素中选择模型级别。可以导出有错误的模型,但是最后应该找出这些错误以防止在以后的导出中再次重复出现。







流程模型导出

模型人员将所需的 BPEL、XSD 及 WSDL 文件导出到 Application Developer 工具中——或者导出到现有的服务项目中或者导出到一个文件夹中,以后在导出到服务项目中。


图 3. 生成的文件及其同流程模型元素的关系
生成的文件及其同流程模型元素的关系

图 3 显示了所生成的文件,以及流程模型元素与生成的文件中相应的构件之间的关系。例如,生成复合业务项目作为 XSD Complex 类型。可以导出整个业务建模项目,或者项目中所选定的部分。在导出时另一个重要的选项是流程执行模式。存在三个不同的选项,默认值是长期运行(请求-应答)

流程执行模式

当将流程模型导出到基于可执行的流程构件的 BPEL 中时,三种可用的执行模式是:

  1. 长期运行(接收/应答)——该选项将可执行的 BPEL 工作流模式设置成长期运行的流程并将流程操作指定为具有输入及输出消息的双向操作。长期运行的流程是可中断的,这使得引入员工和其它活动需要可中断的流程。
  2. 长期运行(接收回调)——该选项将可执行的 BPEL 工作流模式设置成长期运行的流程并将流程操作指定为单向操作,即仅接受输入消息而不接受输出消息。然而,创建回调操作使得流程能够将结果返回给调用者。创建了 BPEL 相关性设置,但没有添加相关性属性。期待开发人员以后添加必要的属性。
  3. 微流程——该选项创建了接受双向消息的流程操作。然而,这些流程是不可中断的,所以不能向流程中添加员工活动。如果流程模型包含具备资源的任务及基于员工的角色,那么可以导出具备员工活动的模型。然而,输出的可执行模型存在验证问题,开发人员必需更正这一点。






结束语

业务分析员的组织管理严密的建模过程是随需应变业务流程生命周期方法学的关键。业务流程模型定义了技术架构以校准 IT 开发的业务规范。共享的模型存在于业务流程的整个生命周期中,有助于保持业务和 IT 视图的同步性。本文介绍了一些流程建模概念,通过这些概念分析员可以使用 WebSphere Business Integration Modeler V5.1 来定义业务流程。此外,本文还给出了一些建模指导,并描述了 Business Integration Modeler 中的各种输出选项及生成的作为开发工具输入的构件。







附录

Business Integration Modeler V5.1:核心功能

WebSphere Business Integration Modeler V5.1 是特别为业务用户设计的易于使用的工具,使他们能够捕获并编制业务流程的具体步骤。包括下列核心功能:

用户配置文件:Business Integration Modeler 提供了三种不同的用户配置文件,使得对于同一流程模型可以有不同的视图。这三种配置文件是:初级、中级、高级。这些配置文件与不同的用户角色相联系。业务领域的专家或分析员使用初级配置文件,它将业务任务作为活动序列,而其余的模型信息作为文档来获取。中级配置文件在技术上更针对于数据模型的细节、表达式及基数信息,并且它更适合于业务架构师。高级配置文件提供了更详细的流程及数据模型的信息。此配置文件非常适用于解决方案中或适合于 IT 架构师。注意,转换配置文件不会改变基本的数据模型。

技术模式:存在三种技术模式:操作、BPEL 及 MQ Workflow FDL。依照技术专家对所需细节的看法,您应当在模式之间进行切换。在某些模式中一些选项及符号元素可能失效了,所以选择合适的模式有助于为目标流程的执行环境定义适当的构件。注意,转换模式不会改变基本的数据模型。

目录:这些是对类似的建模实体的逻辑分类。包括:

  • 数据(例如定购、产品之类的业务项目)
  • 流程(主要的流程、子流程、服务、任务)
  • 资源(例如客户服务代表、销售经理之类的角色,或者例如 Web 服务器、应用服务器之类的资源)
  • 组织(组织层次、位置)
  • 报告(总结、比较、文档)

这些分组增强了建模实体的可复用性。

流程:流程是活动的顺序、执行这些活动时所规定的条件的顺序、执行活动所需要的资源顺序,以及活动同服务交互时传递的数据流的顺序。通过使用工具提供的图表符号来将这些流程建模。

仿真:流程模型仿真帮助组织观察在不同的输入下流程是如何执行的。该功能提供了对于输入的更改、对于消耗因素的关联,以及对于资源或当前配置的调整,来模拟真实的业务场景。这些分析增强了对于关键路径、最短路径、周转时间及对于流程模型的耗费/时间的测量的分析。

报告:该功能为流程分析及重新设计提供了非常有价值的指导。存在各种可用的报告功能,包括流程摘要、对于两个流程模型的比较、ROI 测试中的 As-Is 和 To-Be 的比较、文档及过程(规则、策略及过程)报告。

分析:在流程模型中可以进行两种分析:静态分析及动态分析。在静态分析中,大多数信息是从模型中提取出来的,并用于分析消耗、时间管理、性能、流程有效性及资源水平。动态的分析是由基于输出日志或事件的模拟流程的输出过程来完成的。存在两种动态分析:聚合分析(基于多个流程模型元素的执行过程)和实例分析(使用流程元素的特定序列的执行实例)。

posted on 2006-06-14 00:03 wsdfsdf 阅读(386) 评论(0)  编辑 收藏 引用 所属分类: 交流心得


只有注册用户登录后才能发表评论。
网站导航: 博客园   IT新闻   BlogJava   博问   Chat2DB   管理