时间：2004-11-27 作者：Bernardo Perez de Lara 浏览次数： 本文关键字：soa

文章工具  推荐给朋友  打印文章

• 一名指定的候选人
• 利用负载平衡的组中的一名候选人
• 一些用户和组，允许一名候选人受理该任务

报送
　　对于任何签署人，都可以定义一个报送图式（escalation schema）。报送可以定向到一名指定的候选人、一个组或一些用户和多个组（签署人），并且可以有一系列的报送。关于如何报送的信息来自一个简单的控制界面，并且它提供了一种默认实现。每次有一项请求时默认实现读取一个报送图表（escalation chart）文件，并寻找与当前签署人的匹配。如果存在匹配，就返回新签署人，否则保持同一签署人。
　　由于默认实现在文件中查找签署人报送图表，所以可以定义一个集成的流程，它利用该企业最新的员工信息来维护该文件，使该流程能够动态调整。并且，按照默认的实现，每个审批请求文档表明利用什么报送文件进行报送，同时允许为不同的业务流程定义几个报送策略。
　　当然，默认的报送定义的实现可以被自定义的实现所替换，该实现可以利用规则引擎来获取报送模式。报送流程产生了一个副影响：该任务的优先级提高了。因此，即使没有为用户定义报送签署人，也可以定义报送超时设定（举个例子）来提高该任务的优先级，直到签署人解决这个任务为止。

链状审批
　　一些业务流程需要一系列审批。请求审批企业级利器提供了一个简单的机制从一系列有序的签署人获得审批，其中每个签署人都可以是指定的候选人、组或可以遵守所需报送图式的用户和组。如果单个签署人之一返回了一个匹配预定义响应的审批时，有一个选项是停止审批链。

快捷简单
　　利用寻求审批企业级利器的一个主要优势就是不必理解任务控制API和数据结构。需要做的一切就是填写一个审批文档，而请求审批流程负责在您需要时得出所需的答案的所有细节。
　　seekApprovalV3.zip文件包含安装和测试该控制所需的所有文件。以这种方式打包是为了使其方便地集成到需要请求审批的流程。
创建新的应用程序
　　由于请求审批控制将用在业务流程的定义中，所以它可以位于部署到集成服务器上的流程应用程序中。在创建应用程序之后，将所有文件解压缩到新应用程序的主目录，例如：

D:\bea811\user_projects\myApp

　　请求审批需要WLI系统架构。如果您的应用程序并不包含它们，那么选定您的应用程序，右击New -> Project…，选择Schema – WLI System Schemas，并给出名称（如，WLISystemSchemas）。

导入Schema项目
　　approvalDoc.xsd文件包含请求审批控制所用到的XML架构。在本文的“文档架构”一节中，有该文件中文档结构及其意义的描述。要在您的项目中包含它，右击myApp，选择Import Project…，指出这是一个Schema项目，并且在解压缩该文件的目录中查找seekApprovalSchema。

导入Process项目
　　所有流程文件都位于压缩文件的seekApprovalProj路径之下。要导入该项目，再次右击myApp，选择Import Project…，指出这是一个process项目，并找到seekApprovalProj文件夹。将有一条消息表明需要包含额外的文件并接受。该项目在workshop中出现之后，在eekApprovalProj文件夹下查找文件process.jpd并删除它。右击seekApprovalProj并生成它。生成过程应该没有报告任何错误。

导入Control项目
　　从myApp选择Import Project…，指出它是一个control项目，并浏览到seekApprovalCtrl文件夹。在导入它之后，对其进行生成。

使用该控制
　　如果遵守安装过程中描述的步骤，您的流程定义就会有新的控制可用。在设计视图中打开这个jpd文件时，在Data Palette中选择Controls Add，以找到seekApproval控制。您可以在您的项目中以使用其他任何控制的方式使用该控制。

文档架构
　　approvalDoc.xsd文件包含一些文档的定义，这些文档用于请求审批应用程序的接口。使用xmlspy，很容易理解这些文档的结构。下面是我们提供的架构和这些领域的语义的回顾。

元素approvalDoc

　　approvalDoc文档声明谁是请求该审批的originator（发起人）（可选的），以及关于哪个部门请求该审批以及期望谁审批该请求等与该process有关的文本信息。

• originator EMPUID是请求该审批的个体的惟一标识符。这个EMPUID带有escalationCart中的信息，提供它时，能够标识请求该审批的用户。
• process文本信息用于提供关于审批该建议请求的人员有关的信息。
• status允许非常丰富的审批定义，不管是来自个人、一系列个人、一个组、一系列组，还是一些以任何顺序排列的个人和组。

　　审批流程的结果以approvalDoc的形式返回调用流程，同时文档记录审批流程种所涉及的每个个人或组的结果。

复杂类型contextType

　　这些文本用于向审批者提供需要审批的内容以及什么时候应该得到响应的信息。可选的identifier包括关于请求审批的流程的文本的可读描述。例如，一个标识符的name可以是“Salary Revision Process”，step可以是“Borderline Performance”。
　　approvalDescription遵守WLI系统架构中为worklist提供的messageType定义。它应该按照为worklist架构定义的指导进行填充。
　　completionDueDate定义什么时候需要提供请求的响应。如果提供的日期是过去的时间，就将其修改为将来的7分钟（参见minTimeoutMinutes常数），以便至少有一个来自签署人的快速响应。
　　注意：下表给出WLI 8.1 SP2中的worklist Control所接受的不同字段的大小限制。

复杂类型endorsementType

　　对于单个请求，可能要求若干签署。例如，一些公司采用这种策略：对于旅行审批请求，必须有两个审批，一个来自请求者的管理链，另一个来自财政。这是有一系列签署背后的原因。
　　endorser定义谁（users和/或groups）可以提供该审批。一个candidate对应一个WLI用户，一个group对应一个WLI组。单个候选人如果没有定义任何组，则意味着这项任务将被指派给该用户。单个组如果没有定义任何候选人，则意味着该任务将被指派给该组中的一名用户，同时利用默认的负载平衡机制。最后，如果同时提供了用户和组，则该任务将被置成已指派状态，其中受理人列表中的任何用户都可以受理该任务。
当审批流程开始之后，result就被设置成未决状态（pending），并且在有答案（审批或否决）或该流程异常中断之前都会处于这个状态。因此，该结果的值集是：{ pending, approved, denied, aborted }。
　　如果除了该结果，需要对响应提供更多数据时，可以将其存储在userData中。例如，审批信用卡交易时，在提供结果的同时提供审批码。由于并不是所有流程都有这项请求，所以它是可选字段。
　　需要多个连续的签署人时，有时候如果有机会在提供给定的结果之后停止该流程是很有用的。例如，对于带有管理链（除非经理否决该请求，否则必须审批财政请求，经理否决请求时，则不必请求财政审批）的旅行请求流程，stopProcess应该被设置为denied。相反，可能有另一种流程，其中单个请求确定该请求已经被审批；例如，子女对请求父母批准去看电影请求。如果其中一个审批了，孩子们就去看电影。在这种情况下，stopProcess将被设置为：approved。这是一个可选字段。
　　有机会报送一个指派给个人的审批请求时，escalationRules用于为获取这些规则提供method，而minutesTimeout用于确保指派该任务，直到它被重新指派给双亲。这是一个可选字段，如果定义了，则表明有机会报送该请求。

元素escalationChart

　　报送图表（escalation chart）定义了一组报送（escalation）：从child endorserType及其users（WLI用户）和group（WLI 组）到parent endorserType。
用户和组是作为字符串表示的。如果候选人多于一个，则用空格隔开。这同样适用于组。要找到一个报送（escalation），其中必须有一个对子女的匹配；这样将比较这些用户和组（在这些集合中忽略和用户和组的顺序）并且必须相等。那么父母可用于报送。

实现
　　这个请求审批示例是利用3个流程实现的。主流程是seekApproval.jpd，它接收approvalDoc作为输入，并返回approvalDoc以及从初始“pending”值更改的结果值。如果有一个回答，则采取该行为（审批或否决）的候选人将是作为签署人返回的候选人。
　　TseekApproval.jpd流程为approvalDoc中的每个签署人调用endorserWork.jpd流程。endorserWork.jpd负责指派任务、报送流程和从用户获取结果。
　　最后，fileBasedEscalation.jpd是管理escalationChart文档的流程，以获得报送流程所需的用户和组信息。这是一个实用的流程，它提供服务到endorserWork.jpd的映射，并且可以被其他任何实现requestEndorsement服务的控制或规则引擎替代。
因此，请求审批示例惟一额外接口是seekApproval.jpd流程。
　　下面是怎样才能测试它的例子：

示例
　　要利用fileBasedEscalation.jpd文件实现该任务，将samples.zip文件解压缩到C:\，这是因为报送图表应该位于目录C:\seekApproval\V3\escalation中。
　　samples.zip文件包含一个示例报送图表文档（disneyEscalationChart.xml）和一组审批请求文档，它突出显示了审批的一些基本变化，这些审批可以利用seek approval solution enabler实现。

　　要能够执行这些示例，必须在WebLogic Integration Administration Console中定义dharacters组和用户。

　　要执行包括的示例，只需定义组DisneyManager和characters以及用户wdisney、mmouse、daisyd、dduck、gdog、hduck和scrooge。

单签署人例子
　　以下包括一些单签署人例子。

识别特定的候选人

当审批必须来自特定用户并且其他任何用户都不可以时就是这种情况。下面是名为deodorantReq.xml的示例请求XML文档的外观：

登录之后，按照以下步骤：
　　１、回顾mouse有一个已受理的TaskReview并且mmouse有一项已受理的任务。

　　2. 查看细节并启动该任务

　　3. 单击start之后，选择响应

　　4. 下面是如何进行响应；在这个例子中您将否决该请求

1. 最后完成该任务之后（将出现当您选择响应时出现的同一屏幕），并且您将在Workshop测试浏览器中看到返回的响应（在单击refresh之后）
　　所有示例都遵循这些步骤。前面提到过，我们期望这个示例的用户生成一个良好的GUI来提供该响应并且对用户隐藏许多步骤（受理、启动、响应、完成）。

从组中选择一名用户
　　 在这个例子中，选择组中的一个成员来响应（负载平衡）审批请求。要选择的组是groups字段的惟一成员。
　　例如，对于lightsReq.xml：

　　我们将在DisneyManager组中选择一名用户进行审批。另一个例子是waterBreakReq.xml，其中每两分钟就有一个报送策略。

多个签署
　　最后的例子探索需要多个签署的情况，并且其中一些签署可以报送。
　　下面是movieReq.xml文件：

　　该任务先分派给daisyd，并且如果她否决了该请求，就不请求dduck的审批。如果daisyd批准了，则dduck在它报送之前有两分钟时间响应。
　　根据disneyEscalationChart，dduck将首先向用户wdisney、scrooge或组DisneyManager报送。如果在两分钟之内没有审批该请求，那么它就被进一步报送。
第二次报送是向组characters（注意用户的顺序无关紧要），并且最后characters会将其报送到DisneyManager。

版本注解
　　这个版本的请求审批企业级利器建立在WLI现有的能力之上，同时保留了worklist控制台作为人性化界面进行交互的方式。我们期望这个示例的用户提供自定义的用户界面来提供审批流程交互的更适合外观。
　　这个版本孤立了报送图表，它只在需要时使用并且没有被缓存。返回报送结果的流程可以被规则引擎调用替代（如果需要这种灵活性）。利用默认的实现，动态行为是由报送数据在需要时来自一个文件这个事实实现的，并且该文件可以由LDAP、DB等驱动。

• 代码重用：元数据解决方案

您对本文的评价
您对这篇文章的看法如何?
太棒了！5分 不错啊 4分 一般般 3分 有待提高 2分 不好 1分