UAP.-RIA流程平台关键技术说明format

关键技术UAP6.5流程平台关键技术说明版权2014用友集团版权所有。未经用友集团的书面许可，本文档任何整体或部分的内容不得被复制、复印、翻译或缩减以用于任何目的。本文档的内容在未经通知的情形下可能会发生改变，敬请留意。请注意：本文档的内容并不代表用友软件所做的承诺。目录版权3目录41.前言82.流程平台92.1.概述92.1.1.流程平台整体架构92.1.2.UAP流程平台特性112.1.3.流程平台与业务产品的关系122.2.交易122.2.1.交易132.2.2.流程组件注册192.2.3.单据动作及脚本202.2.4.单据函数232.2.5.分单依据注册262.2.6.单据转换规则272.2.7.单据接口定义292.3.业务流平台302.3.1.业务流设计器302.3.2.业务流定义322.3.3.流程配置332.3.4.单据转换规则392.4.审批流平台402.4.1.流程定义402.4.2.工作项502.4.3.流程用户组管理522.4.4.流程结果与单据状态542.4.5.反向流转562.4.6.流程监控572.4.7.流程日志592.4.8.审批侧边栏592.5.工作流平台602.5.1.展现612.5.2.工作流组件622.5.3.流程模板622.5.4.流程嵌套632.5.5.流程实例的状态632.5.6.工作流工作项632.6.审批术语643.开发使用说明663.1.平台缓存数据663.2.动作处理673.2.1.UI端调用-PfUtilClient693.2.2.BS端调用743.2.3.返回值753.3.动作脚本753.3.1.执行脚本编写763.3.2.返回值793.4.审批流平台API803.4.1.审批状态回写与查询803.4.2.送审813.4.3.审批833.4.4.弃审863.4.5.删除883.4.6.审批流相关接口893.5.工作流平台933.5.1.单据开发，并注册流程平台相关信息。933.5.2.工作流组件开发。933.5.3.工作流相关方法：933.6.业务流平台943.6.1.动作驱动943.6.2.单据VO交换943.6.3.单据UI菜单填充与响应963.6.4.业务流相关接口994.开发流程1035.附录1045.1.UAP5.0短信服务1045.1.1.应用模式1045.1.2.短信发送1065.1.3.短信接收1065.2.UAP6.0动态组织1075.2.1.实现类图1075.2.2.注册1085.3.流程平台消息模板整合说明1085.4.业务流程跳转1185.4.1.应用场景1185.4.2.流程跳转规则1195.4.3.一些说明1195.4.4.实现方案1195.5.数据交换升级方案1205.5.1.概述1205.5.2.方案说明1205.5.3.升级步骤1215.6.VO对照给予业务组设置下游交易类型机会方案1235.6.1.描述1235.6.2.方案1235.6.3.说明1231 前言流程管理（process management），是一种以规范化的构造端到端的卓越业务流程为中心，以持续的提高组织业务绩效为目的的系统化方法。它应该是一个操作性的定位描述，指的是流程分析、流程定义与重定义、资源分配、时间安排、流程质量与效率测评、流程优化等。因为流程管理是为了客户需求而设计的，因而这种流程会随着内外环境的变化而需要被优化。2 流程平台2.1 概述2.1.1 流程平台整体架构UAP流程平台是对企业的流程进行建模的平台。其工作流模型由四部分组成，分别是过程模型、组织模型、功能模型以及信息模型（工作流相关数据）。过程模型用来定义工作流的过程逻辑，包括组成工作流的所有活动以及活动之间的依赖关系。组织模型用来定义企业人员的组织结构，包括几种不同形式的组织元素以及每种组织元素内部的递阶层次关系。功能模型说明企业中需要完成的工作或者任务是什么，或者说功能模型说明了企业的目标是通过哪些具体的功能活动来实现的。它确定了企业业务功能的逻辑结构和相互关系。信息模型说明了企业处理的业务对象中所包含的信息以及业务对象间的关系。过程模型采取基于活动网络图的过程模型，与其他的过程模型（如事件驱动过程链EPC、Petri网、语义-行为模型等）比较，活动网络图具有直观自然、可读性好的特性。图表 21 业务流程框架UAP流程平台整体框架图如图表 21 业务流程框架。UAP流程平台基于WFMC的标准，它包含一个核心引擎和4大接口（注：WFMC的标准中包含五大接口，UAP流程平台提供了其中4个，还有1个是不同工作流管理系统之间的协同工作，目前UAP流程平台没有涉及）。其中流程引擎是整个流程框架的核心。它负责解释执行由流程设计器设计的流程定义。调度和监控过程中每个活动的执行，在需要人工介入的场合完成计算机应用软件与操作人员的交互。接口主要有这几大类：1) 过程定义接口：对应流程设计器，用于对流程过程进行建模。流程定义可以引用UAP系统建立的功能模型、组织模型以及各种元数据。2) 客户应用接口：对应消息中心的代办任务列表。UAP用户可从工作列表中查看到工作流引擎分配给他的工作项。通过单据动作（比如提交、审批、弃审、驳回等）来处理工作项，从而驱动流程流转。3) 被调应用借口：这是流程平台和业务产品之间交互的通道。工作流引擎在流转过程中可以调用各种自动应用，包括电子邮件、脚本以及Web服务等。对于流转过程中涉及到的数据交换，工作流引擎将调用交换引擎根据规则进行数据映射。4) 管理和监控接口：UAP流程平台提供了管理监控工具对运行中的流程实例和工作项进行状态查询和管理。以下是流程平台各部分运行时的一个交互过程：图1流程运行时的交互过程用户先进入消息中心选择代办任务，再导航到审批交互界面进行审批，然后提交审批结果给业务层，在业务层我们会调用业务组件，执行审批的业务操作。然后，审批任务被提交到任务层，任务层处理完审批任务后，驱动引擎，继续流转，引擎会将任务的处理结果发送给任务层，任务层再将结果返回给业务层。2.1.2 UAP流程平台特性UAP的流程平台，根据不同的特点，把企业中遇到的流程分为审批流程、工作流程和业务流程。审批流程：以单一单据实例作为处理对象的流程，一般不包含除网关节点外的自动节点，人工活动的内容是做审批。仅改变单据审批状态，有待审批、审批中、已审批（通过/不通过）。工作流程：以单一单据实例作为处理对象的流程，人工活动的内容不限于审批，可包含大量自动活动。单据实例数据在流程中会被改变，涉及改变的单据状态也会比较复杂。业务流程：业务流程的最大特点是流程实例中上下游单据是不同的对象，id不同，单据类型可能相同也可能不同。业务流程引擎要处理上下游单据对象之间的数据映射、转换、合并或分单。工作流程中会含审批流程；业务流程中会含工作流程。UAP的流程平台具有以下特性：（1）标准的过程模型，遵循WFMC标准，为多系统的集成奠定了基础；（2）预置通用的处理模式，积累UAP多年应用经验，能满足绝大部分应用；（3）提供丰富的扩展，便于业务的接入和实施；（4）针对UAP，做了很多增强，使用UAP平台开发的产品可以很方便地实现工作流。2.1.3 流程平台与业务产品的关系流程平台是业务产品的基础平台，作为基础构件之一包含在UAP的底层应用架构中。流程平台负责定义业务处理过程和规则并驱动业务过程的执行，产品组负责提供基础功能组件并按照平台约束的接口规范来与之交互。从模型角度，流程平台负责管理过程模型，产品组件负责功能模型。过程模型和功能模型都以组织模型为基础，并受权限模型约束。2.2 交易交易一般指一个完整的业务交易场景，也对应为一个有明显过程边界的功能，例如销售接单、发货、报销、委托付款。业务单据是描述企业业务信息的载体，是对业务数据的抽象。通过业务单据，可以清楚地反映企业的业务发生情况。企业中如请购单、采购订单、报销单、付款单等均为业务单据。在UAP系统中，一张业务单据的实现包括许多内容，比如单据类型、单据VO、单据UI、单据动作等。我们把这些用于描述某单据的信息统称为单据元模型。其组成如图4所示。图2单据元模型2.2.1 交易从V6开始，产品中的单据类型用交易代替。V5我们的产品中一个交易用一种单据类型来代表，例如销售订单、发货单、委托付款单。支持多少个交易代表了我们产品应用覆盖的边界，扩展交易代表着要同时提供一个新的业务场景的功能模型，所以交易通常是出厂时预置或二次开发提供的，操作用户不能随意编辑。2.2.1.1 单据类型管理单据类型是对单据的分类。单据的元信息都是基于单据类型来定义。在定义单据类型时，单据类型必须属于某个系统类型。单据类型的注册信息比较多，由功能点开发平台-开发配置工具-交易管理-单据类型管理维护，如图5所示，一般由各个产品组预置。图3单据类型管理项目说明： 类型代码：手工输入，最大长度为20个字符，可以输入字母和数字，不允许重复。 类型名称：业务单据名称，手工输入，不允许重复。 单据大类：表示单据类别（应收应付101-），用于区分单据类型的主子关系。从V55开始该字段不再使用。 节点编号：标识单据类型的关联UI，一般为关联的制单功能节点编码。 审批节点编号：标识单据类型的关联UI，一般为关联的审批维护类功能节点编码，也可以是UI类。所有功能节点UI类必须实现UI关联接口, V65后提供单据类型关联节点注册表（参见3.3.6.7节）。 主表参照的固定条件语句：被其它单据参照时自己填写的固定的SQL条件语句。 参照查询对应的DMO类：用于查询单据VO数据的业务逻辑类。必须实现接口以及2（参见第三章节）。 审批流检查类：通过编写审批流检查类，并在该类中实现审批流相关接口，来达到使用审批流管理业务单据以及控制审批流行为的目的（参见第三章）。实现IcheckState，IbackCheckState(可不实现)的接口的DMO类文件。 会计平台类：财务会计平台所需的类。实现IaccountProcMsg IAccountRetVoucher的接口的DMO类文件。 是否为根节点：针对单据大类，用于实现单据主子关系。从V55开始不再使用。 是否发送会计平台：用于财务会计平台。如果该单据不直接传送财务会计平台，则不选择。支持按交易类型控制（详见） 自定义1(def1)：流程配置的单据业务关联（业务流程）更新后的处理类。 自定义2(def2)：存取会计平台的产品组自定义查询。 自定义3(def3)：动作执行前的UI端处理类。如果单据类型关联了多个功能节点，该类还需要实现节点查找接口， V65后提供单据类型关联节点注册表（参见第三章3.3.6.3节）。 是否可扩展交易类型：表示该单据类型下是否可定义交易类型。 元数据组件：该单据类型对应的元数据主实体所属的元数据组件。流程平台要求所有单据必须有对应的元数据。 来源数据查询类：用于联查来源单据。 Web节点编号：标识单据类型关联的web节点编号。 是否业务流单据：标识该单据类型是否可用于业务流。只有勾选了此选项，在业务流定义时才能配置该单据类型。 是否审批流单据：标识该单据类型上是否可定义审批流。只有勾选了此项，在审批流定义界面才能看到该单据。（5系列通过在审批节点编码前加或来标示该单据类型是否要走审批流。V6新增了这个字段来表示。） 可编辑单据属性：流程中单据可编辑属性的配置开关。 可用按钮：流程中单据可用按钮的配置开关。 修订审批流：单据类型是否能走修订审批流。提交单据时候匹配流程定义新增了一个维度。需要实现IEmenedFlow接口。 编码对象编码：编码对象的编码。 是否支持交易类型编码规则：在编码规则定义时，可以按交易类型分配编码规则，不同交易类型可使用不同的规则，需要具体单据开发支持。在获取编码规则时，使用接口（其中subbilltype为交易类型编码，leveltype指定为billtype）。下游单据类型：V6要求有上下游关系的单据类型必须明确定义出来。定义上下游关系时必须指定是流程中的单据还是非流程单据（即可以跨集团）。“是否流程中”和“是否跨集团”这两个选项是互斥的，且必须选择其中的一个。流程配置中，可选的上下游单据类型受上下游交易关系注册表中支持单据配置为是的那些关系约束；单据接口定义中可选的上下游单据类型受上下游交易关系注册表中是否跨集团为“是”的那些关系约束。单据类型子类： 审批流查询：工作项历史自定义查询类，必须实现 ISpecFlowQuery。 审批流参与者限定：对流程活动的参与者进行限定，业务组可以扩展自己的参与者限定器，如财务报销单上的费用承担部门负责人限定。必须实现 IParticipantFilter。 消息配置接收者：消息配置中的自定义接收者，必须实现 IPfMsgCustomReceiver。 功能复制插件：V6不再使用。 平铺VO查询类：V6不再使用。 交易类型扩展编辑器类：注册交易类型扩展属性对应的Panel，必须实现ITranstypeEditor。 交易类型扩展业务类：用于处理交易类型扩展属性的后台业务处理类，必须实现ITranstypeBiz。 用户组规则器：注册规则型流程用户组所使用的规则类,必须实现 IWfUserGroupResolver。 审批流前台业务处理类：用于在点击审批按钮以后，审批对话框弹出之前，进行业务处理。必须实现 IPFClientBizProcess。 业务流程跳转的回写处理类，必须实现IBusiBillStatusCallBack接口。 流程定义持久化监听类, 必须实现IProcessPersistListener。 移动应用单据构造监听类。必须实现IMobileBillConstructListener接口。 审批流UI业务后台执行类：审批流前台业务处理的后台执行接口，业务组适配portal时使用。需要实现IPFClientBizProcessBS接口。 消息优先级处理类：设置工作项的优先级。利用消息中心发送消息时候会附加该信息。需要实现IMessagePriorityCallback接口。 VO对照下游单据交易类型处理类：供应链提出，需要给予业务组VO对照后自行设置交易类型的机会。需要实现IDestTranstypeProcess接口。 组织限定：报表提出，审批流参与者为职责，限定模式为上级限定时候，返回组织树。需要实现IOrgFilter4Responsibility接口。 流程实例状态改变监听类：流程实例状态的监听类，用于对流程的挂起、终止、恢复提供事件机制，必须实现IPFInstanceStateChangeListener。 自定义参与者：自定义参与者限定类，必须实现 IParticipant。 消息信息处理类：消息相关信息处理类，用于具体单据根据单据属性控制消息中心的消息显示效果，必须实现IMessageCenterInfoCallBack。2.2.1.2 交易类型管理交易类型是一个交易的细分，比如报销，会分差旅报销、部门活动报销、交通费报销等。用户可以根据业务需要扩展自己的交易类型。扩展交易类型是在单据类型支撑的功能模型基础之上再描述一些规则、模板、流程的差异。新建一个交易类型时会自动复制其所属的单据类型上的一些属性，以及对应的单据动作和单据动作组。交易类型可以封存和启用。封存的交易类型不能再被业务使用。是否传会计平台，同单据类型的“是否发送会计平台”，支持按交易类型控制。交易类型可以发布为功能节点。发布界面如下图所示：交易类型发布为功能节点，就意味着会在功能注册表中把其所属单据类型的功能注册信息复制一份，包括对应的页签、参数、按钮、业务活动、业务活动与按钮的关联以及相关的模板分配关系。同时，还会新增一个菜单项。V63可以将交易类型发布为集团级节点。根据交易类型所属集团确定发布节点所属集团。V61已经发布为全局级节点的，全局可见。但仍然是组织级节点（每个组织复制一份）。V65之前当单据类型支持多个节点时，交易类型发布节点只能从单据类型注册的功能节点复制，无法选择其他的制单或审批节点。V65新增选择单据类型的功能节点生成交易类型节点。可选择根据那个单据类型节点发布交易类型节点。注意，制单节点发布后仍为制单节点，审批节点相同。在交易类型流程定义时，活动上选择的功能节点可选择发布的功能节点。交易类型的功能节点号默认由其所属单据类型的功能节点号衍生而来，如单据类型的功能节点号是“101601”，交易类型发布以后的节点号即为”1016XX01”,最后两位按序递增。如果发布时勾选“发布为Web节点”，那么新的功能节点号将根据所属单据类型的web功能节点号按同样的规则衍生而来。交易类型的功能节点号由系统自动生成，因此发布时用户只需选择新的功能节点期望放置在哪个菜单下即可。同一个交易类型可以发布多次，生成多个不同的功能节点。发布产生的多个功能节点号在一个单独的数据库表（pub_funccodetocode）中存放。注意：交易类型重复发布节点时，不在使用的旧的功能建议停用掉，不要通过数据。接删除或者修改节点编码。功能节点本身关联的资源比较多无法全部删除，如果直接删除功能节点，会导致后续发布节点报错。交易类型上可以配置业务规则：配置单据动作前约束规则、动作后约束规则，可细化组织和参与者维度（可空、明细优先），即可以针对交易类型，不同组织和参与者配置不同的单据动作前后约束规则。约束规则支持基于单据函数和元数据进行配置。支持基于交易类型配置动作脚本，未配置时使用默认的动作脚本。只能配置无流程单据（即“是否流程单据”为false的单据类型）的单据动作约束。交易类型可以有扩展属性。从应用场景上来说，单据类型下细分出交易类型，每个交易类型除了拥有共同的单据类型的属性，还可以有自己特殊的属性。交易类型要支持扩展属性，需要业务组在单据类型管理界面注册UI端的交易类型扩展属性编辑器（实现接口ITranstypeEditor），以及后台的扩展属性业务处理类（实现接口ITranstypeBiz）。集团初始化时，流程平台会把预置的交易类型拷贝到当前集团，同时也会拷贝交易类型的扩展属性。但拷贝交易类型扩展属性的前提是，必须在bd_billtype表的transtype_class字段中注册交易类型扩展属性对应的VO类，且有对应的元数据，且元数据上要实现对应的交易类型扩展属性接口（ITranstypeExt）。2.2.2 流程组件注册流程组件，即流程活动上对应的业务活动。由功能点开发平台-开发配置工具-交易管理-流程组件注册维护，如图8所示。流程组件必须实现接口IWorkflowGadget，组件上可以注册参数，参数类型支持字符型、布尔型、下拉框、主键参照，可以给参数设置默认值，对于参照类型的参数，可以设置是否多选。如果组件有参数，在流程定义时需要给参数赋实参。对于工作流，必须在单据类型上注册了流程组件，才可以定义流程。对于审批流定义，这不是必要条件，注册了流程组件以后，可以在流程上给某个活动绑定一个组件。组件被调用的时间点有两个：一是当前活动启动后，新任务发送前；二是当前活动完成后，转移执行前。2.2.3 单据动作及脚本单据动作是对单据业务处理行为的抽象，具有可定制的动作脚本。业务单据通过单据动作与流程平台进行交互，从而驱动流程的流转。可对应于单据UI上的某个菜单。2.2.3.1 单据动作管理由功能点开发平台-开发配置工具-交易管理-单据动作管理维护，如图8所示。图4单据动作管理项目说明： 动作选择：提供四种动作各供选择：保存、审核、推式动作、其它。保存、审核是单据的基本动作，动作代码有严格规定；推式动作表示该动作可被其他单据推式驱动。V6这个属性已经没有什么作用了？ 动作编码：当前单据动作的编码。以前的版本对动作编码有严格规定，V6提供了一个新的属性来表示动作类型，所以对动作代码的命名规定已经弱化了。仍然兼容旧版本。 动作名称：当前单据动作的显示名称 动作执行前提示：如此处输入文字，则在该动作被触发时，会弹出一个带有提示性文字的对话框，如：是否保存？ 动作控制：提供三个选项：动作可配置、进行驱动配置、进行约束检查。勾选“动作可配置”，表示该动作可在流程配置中进行配置；勾选“进行驱动配置”，则该动作在流程配置中可以对其他单据动作进行推式操作，驱动其他单据；勾选“进行约束检查”，则此动作要根据业务流程的配置在执行前进行条件检验，满足条件动作才执行，否则就不执行。 动作类型：有8种：启动审批流（即提交）、收回审批流、驱动审批流（即审批）、回退审批流（即弃审）、启动工作流、收回工作流、驱动工作流、回退工作流。V6用动作类型来替代原来靠动作代码来区分动作类型的情况。2.2.3.2 单据动作脚本图5单据动作执行脚本单据动作的处理统一由平台API来调用。详见第三章第3节。2.2.3.3 单据动作组管理对单据动作的分组。由功能点开发平台-开发配置工具-交易管理-单据动作组管理维护，如图10所示。图6单据动作组管理2.2.4 单据函数服务于单据的业务功能的抽取，是进行业务逻辑处理的组件。可用于动作脚本和条件判定。由功能点开发平台-开发配置工具-交易管理-单据函数注册维护，如图11所示。图7单据函数(组件)管理界面打开以后默认是浏览态，要点击“编辑”按钮才变成编辑态，可以增行、删行、保存、取消。项目说明： 函数编码：函数的标示。 函数说明：函数所实现的功能的说明性文字，建议尽量说明清晰，以便于系统实施。如果以“”括起来，表示该函数是用于VO交换的自定义函数，且这种情况下函数参数不能是VO类型。（这种隐晦的规则需要改掉！） 函数说明多语资源ID号：支持注册函数说明的多语资源ID，界面显示时，根据多语资源ID进行翻译。 返回类型：该功能函数返回值的类型。 函数类名称：功能函数所属的全路径类名。 函数方法名称：该函数在类中所对应的方法名称。 函数参数：该函数正确调用所需的参数。参数的格式见下一小节。 是否组件：标识该方法是否为组件。单据组件一般是没有返回值的一段业务处理逻辑，它不可应用于审批条件、动作约束、工作项配置中。 备注信息：用于对函数的具体功能进行描述。 备注信息多语资源ID号：同函数说明多语资源ID号。 函数类别：函数使用的场景，包括全部、单据函数、分单函数。其中，单据函数在审批流或工作流定义中使用。分单函数在业务流定义中使用。全部是即可作为单据函数、也可作为分单函数函数。注册单据函数时，要求函数的类名、方法名、参数名、返回类型、函数说明都不能为空。2.2.4.1 参数格式函数参数分为运行参数、属性参数和VO参数三种。分别有特定的格式，如下所示：格式示例：运行参数 STRING类型 &a:STRING；属性参数单据主键 pkBillid:String；VO参数nc.vo.pub.AggregatedValueObject:01；运行参数 INTEGER类型数组 &aryData:INTEGER。其中属性参数可选择的范围如下：注意：VO参数和属性参数的实际值由流程上下文在运行时赋予。运行参数可在动作脚本中赋值。2.2.4.2 返回值函数方法返回值支持的类型有：void，String，Boolean，Integer，Double，UFDate，UFDateTime，ArrayList，DLG，Panel。2.2.5 分单依据注册分单是指在业务单据转换过程中，可能会出现上游的一张单据要按某种规则拆分成下游的多张单据。分单依据注册就是注册单据上可以用于分单的属性和单据函数。由功能点开发平台-开发配置工具-交易管理-分单依据注册维护，如图所示。项目说明： 目的单据：表示该分单依据用于当前单据类型到目的单据类型之间的转换。 必选：表示该依据在分单时是必选的规则。默认就会出现在单据转换的分单规则中，不能取消。2.2.6 单据转换规则单据类型之间存在相互转换的需求，平台提供了定义单据VO模型间的相互转换规则的机制。V6支持三个层面的转换规则：全局级、集团级和流程级。全局级由功能点开发平台-开发配置工具-交易管理-单据转换规则维护，集团级由功能点企业建模平台-流程平台-流程设计-单据转换规则维护，流程级直接在业务流定义的图形上维护。实际使用时采用明细优先的原则，即存在流程级的转换规则时优先使用流程级的，其次是集团级、全局级。有交易类型时优先使用交易类型上定义的转换规则。功能界面如下图所示。项目说明： 交换前处理类：由业务组注册，在交换前做一些额外的业务处理，必须实现接口IChangeVOAdjust。 交换后处理类：由业务组注册，在交换后做一些额外的业务处理，必须实现接口IChangeVOAdjust。 来源单据显示类：参照来源单据时，使用的来源单据显示UI。默认为“”。业务组可以通过继承AbstractBillSourceDLG来扩展。 来源单据查询类：查询来源单据需要使用的查询模板ID或UI。格式有以下几种：“”：以尖括号开头的一个类，表示使用产品组定制的来源单据查询对话框，必须实现接口IBillReferQuery。“”：查询模板id，表示使用该查询模板。NULL：使用单据类型对应节点的查询模板，会根据来源单据查询模板标识（即对应模板的nodekey）来过滤。 来源单据查询模板标识：来源单据对应查询模板的Nodekey，用于选择查询模板。转换规则界面如下图所示：转换规则包含3种类型： 赋值：给下游对象的某个属性赋上某个常量或系统变量（系统变量支持：TODO）。 映射：把上游对象的一个属性值赋给下游对象的某个属性。这里我们支持多子表对象之间的映射。（多子表时有限制的TODO）。 公式：可以是单据函数，或者平台公式解析器定义出来的公式，它主要用于下游属性值不能通过简单的赋值和映射来获得的情况。V6在单据转换时支持分单。需要先注册分单依据（见2.5），然后在设置转换规则时，才能选择适用于当前转换的分单规则。分单的设计思想基于以下逻辑：一个分单规则由多个分单依据组成，每个分单依据对应业务实体的一个属性，或者是一个单据函数。转换时按分单规则来分组，属性值或者函数值都相同的划分到同一组，它们会出现在同一张下游单据上。2.2.7 单据接口定义单据接口定义用于描述非流程中单据的上下游关系，由功能点企业建模平台-流程平台- 单据接口定义维护。单据接口定义集团级功能，定义的关系在集团范围内有效。来源单据（交易类型）与目的单据（交易类型）的关系是多对一。但是对于确定的来源单据类型、来源交易类型、目的单据类型，只能有唯一的交易类型与之对应，不能重复。2.3 业务流平台UAP业务流平台的设计思想是基于以下认识：业务流程是由单据组成的，而单据是由动作驱动的，动作又是由组件组成的；单据、动作以及组件可以由业务系统开发实现。UAP业务流提供一种平台机制，在此可以根据用户的实际业务重新组织这些单据、动作及组件，包括每种单据的来源单据是什么、又驱动生成哪些单据、完成什么动作、动作生效的约束条件以及动作生效后将配置哪些组件等，以此更好地满足企业个性化的需求。2.3.1 业务流设计器UAP流程平台在V6提供了新的业务流设计器。图8流程设计器流程设计器界面由以下各部分组成： 菜单栏：文件，编辑，视图，格式，图形，图表，选项菜单，帮助。 工具栏：新建，打开，保存，打印，剪切，复制，粘贴，删除，撤销，Redo。字体，字号，加粗，斜体，居左对齐，水平居中对齐，居右对齐，居上对齐，居下对齐，垂直居中对齐。 搜索：可以进行模糊搜索 工具箱：增加了对泳道的支持。泳道可以对图元进行分组，用以区分不同的功能和职责，使得流程图更加清晰明了。 设计区：对业务流程进行建模。 属性面板：可以编辑属性，有属性的简单描述。 微缩区：有缩略图和图元树形结构两种形式，用来对图形元素进行快速定位 提示输出区：保存时候给予成果或者失败的提示。 流程元素： 泳道：对图元进行分组。 单据：配置业务单据。 开始：业务流程的起点。 结束：业务流程的终点。 动作：配置推式生单。 拉式生单：配置拉式生单。 连接器：连接各个流程元素。 注释。 VO交换：配置业务单据的之间的交换规则。2.3.2 业务流定义由功能点企业建模平台-流程平台-流程设计-业务流定义维护，如图所示。图9业务流定义项目说明： 编码：业务流的编码。 名称：业务流的名称。 核心单据：一个流程中跟开始节点相连的单据被称为“核心单据”，查找流程定义时根据核心单据去匹配。核心单据可以是自制单据，也可以参照其它单据生成。一个流程中只能有一个核心单据。且只有核心单据才能自制。 类别：有采购，销售，购销，应收应付，项目成本，其他，人力资源，调拨等。 助记码。 自定义项2。 自定义项3。 自定义项4。 自定义项5。 组织：业务流定义所属的组织。 优先级：定义业务流的优先级。如果根据流程四要素明细优先原则找到了多个可启动的流程，执行优先级高的。 流程状态：分初始态、启用态、停用态三种。流程新建出来是初始态，启用以后就变成启用态，已启用的流程可以停用，变成停用态。 版本号：业务流程支持多版本。流程新建出来版本号是1.0，如果没有启用或者流程是停用状态，那么修改流程不会产生新的版本；流程如果处于启用状态，对其修改保存，就会产生一个新的版本，在原来的版本基础上加0.1，新版本的流程默认是初始态。2.3.3 流程配置一个业务流程由相互关联的多个单据组成，通过定义单据间来源与动作驱动关系来定义业务流程。图10流程配置项目说明： 单据类型：显示选择的单据代码的名称，不能编辑，选择单据代码后自动带入 交易类型。 参照制单：勾选此项，表示该单据的业务数据可以参照其他单据（来源单据）的数据生成（将进行单据VO交换）。勾选此项，在流程配置中才可配置该单据的来源单据，否则不可配置。 是否自制：勾选此项，表示该单据的业务数据可以手工输入。只有核心单据才有这个属性。 向下游单据发送消息：上游消息是下游单据完成某种处理之后，向上游单据的操作员发出的通知消息。 向上游单据发送消息：上游单据审批通过后，则单据可以被其下游单据作为参照，会给下游单据的参与者发送拉式消息。上游单据的推式动作执行完后会驱动下游单据的动作，并给下游单据的参与者发送推式消息。 单据动作前约束：本步骤配置的是业务单据的单据动作(指单据界面上的某些功能按钮)在发生前需要进行的条件的检查。若发生的业务满足定义的条件，则该单据动作将被执行，否则不允许执行。流程配置通过本步骤，即可实现对当前业务环节的事前控制。 单据动作后约束：判断动作完成后约束条件是否满足，如果不满足动作回滚。 动作脚本：为业务流程配置个性化动作脚本。在这里，用户可以针对不同业务类型对公共的单据动作执行脚本进行定制。使单据动作按照自己定义的规则来执行，以此来完善企业的业务流程，并对当前业务环节实现事中控制。 上游消息配置：用户需要配置哪些下游单据需要向上游发出上游消息，并配置如下信息： 消息发出动作：下游单据发出上游消息的动作。 消息接收单据：所有本流程的单据都待选。 消息接收者：可以选择制单人、审批人，多选。 下游消息配置：上游单据审批通过后，会给下游单据的参与者发送拉式消息。上游单据的推式动作执行完后会驱动下游单据的动作，并给下游单据的参与者发送推式消息。 推式消息流程配置中动作驱动如果产生了下游单据，且下游单据尚未走审批流，则给下游单据的负责人发送这种消息。消息处理方式为直接打开该单据UI进行维护。 拉式消息流程配置中如果某单据审批通过，则给下游单据的负责人发送这种消息。消息处理方式为打开该单据UI，并参照上游单据。2.3.3.1 单据来源配置是对当前单据类型的数据来源单据进行定义的界面。被定义为当前单据来源单据的业务单据，可以在业务流程中为当前单据提供业务数据（使用单据VO交换），以保持业务数据的一致性。图11单据来源配置项目说明： 来源单据类型：定义来源单据类型 目的单据类型：定义目的单据类型2.3.3.2 动作约束配置配置业务单据的单据动作（可能为单据界面上的某些功能按钮）在发生前需要进行的条件检查。若发生的业务满足定义的条件，则该单据动作将被执行，否则不允许执行。流程配置通过本步骤，即可实现对当前业务环节的事前控制。图12动作约束配置项目说明： 自编号：系统自动带入。 约束条件：单击字段右侧参照按钮，打开规则编辑界面进行规则定义。同审批流条件编辑界面，此处的单据函数为分单函数。（详见） 操作员相关：选择与操作员或组有关，则此条件仅对选择的操作员或组制作的单据进行约束条件检查。 操作员与角色：根据前面的“操作员相关”的结果选择用户或角色。 消息提示：检查的提示信息。2.3.3.3 动作事件控制配置为业务流程配置个性化动作脚本。在这里，用户可以针对不同业务类型对公共的单据动作执行脚本（参见第三章第3节）进行定制。使单据动作按照自己定义的规则来执行，以此来完善企业的业务流程，并对当前业务环节实现事中控制。图13动作脚本定制项目说明： 应用函数：选择应用函数，可以将直接将UAP业务单据的函数插入到单据动作中。 常用语法：提供了JAVA标准语法的快速选择。 数据类型：包括JAVA标准数据类型及UAP定义的各种数据类型。 VO类型定义：包括UAP业务单据的VO类型。2.3.3.4 动作驱动配置配置单据之间的动作驱动关系。具体参见第三章5.1节。左树列示了当前单据在单据动作管理中被定义为“进行驱动配置”的单据动作（参见1.2节）。图14动作驱动配置项目说明： 目的单据：在当前单据动作完成时，将要进行动作处理的单据。 操作员相关：选择与操作员或角色有关，则该动作仅在所选择的操作员或角色执行时，才会驱动目的单据的动作。 动作：参照选择，选择目的单据被驱动的动作，该类动作在单据动作管理中被定义为“推式动作”（参见1.2节）。 自编号：系统自动生成。 约束条件。 运算符。 值。2.3.4 单据转换规则此处定义的是流程级别的单据转换规则。（参见2.6节）图15单据交换规则2.4 审批流平台审批流平台为单据的审批处理提供平台支持。基于任务驱动的执行引擎使得流程流转与用户交互分离开来，具有更强的健壮性。支持分支/汇总（Split/ Join）、优先级（Priority）、子流程（Subflow）、可指派、抢占/会签、流程代理人、改派、加签、驳回、弃审等流程特性。2.4.1 流程定义UAP的审批流定义模型遵循WfMC的XPDL1.0过程定义规范，具有严格的语义和丰富的描述能力。图16审批流定义-浏览图17审批流定义-设计审批流定义按照单据类型（+交易类型）进行了分类。用户可以基于单据类型定义审批流，也可以基于单据类型+交易类型来定义审批流。一个单据类型（+交易类型）下可以定义多个审批流，这里可以把单据类型（+交易类型）理解为过程包的概念。2.4.1.1 流程模型过程（Process）由许多被执行的活动和一系列决定活动执行次序的转移构成。活动（Activity）审批流程中的一个个步骤统称为活动（或任务），包括制单活动、审批活动、消息活动、虚活动、子流程。第一个拖放到审批流设计器中的活动为制单活动。虚活动也叫路由，主要用于对分支/汇总进行建模。子流程可实施流程重用。参与者（Participant）人工活动的一个属性，即活动的执行者，是对系统中组织模型的引用。目前支持操作员、角色、用户组、角色组、流程用户组、岗位、业务汇报关系和职责种类型的参与者（HR岗位就是一种动态组织实现，具体扩展机制可参考附录）。公共参与者支持扩展，详见：限定模式审批活动的一个属性。主要用于对参与者设置的范围进行进一步限定。例如根据前面活动参与者或者与单据的属性过滤参与者范围。预置的限定模式有：同部门、同部门、上级限定等（职责除外，职责的预制限定模式有：同组织限定、指定组织限定、无组织限定、同部门限定、单据组织限定）。支持公共限定模式的扩展，详见转移（Transition）活动间的流转，是两个活动间的有向连接。每个转移都具有转移条件（Condition），只有满足条件的转移才可流转。转移条件表达式有：审批结果表达式、单据函数表达式，元数据表达式。每个转移还具有优先级（Priority），优先级高的转移分支将被优先选择。转移可手工选择：分支/合并（Split/Join）活动具有前驱条件（Join）和后继条件（Split）两个属性，可通过Split/Join-AND/XOR属性组合为过程的选择、并行结构进行建模。加上顺序和循环，这四个基本结构就可描述大多数过程结构。同时，审批流还支持三种反向流转模式：收回、驳回和弃审（参见3.4节）。分支/合并方式：可选择与/或，“与”代表进入/转出（合并或分支）的多个转移线同时成立。“或”代表多个转移线只有一个成立。抢占和会签审批活动的一个属性，仅在参与者类型不是操作员是有效。会签：有按比例和按数量两种会签策略，只有审批活动的参与者中完成审批的用户达到一定比例或者数量，该审批活动才能结束。抢占：只要审批活动的参与者中任何一人完成审批后，该审批活动即结束。会签可配置阈值，可按照数量或百分比配置。达到阈值后流程结束。可指派审批活动的一个属性。如果审批活动定义了可指派属性，则该审批活动的实际执行者需要从其参与者中手工选择。指派的分支优先被选择。V63对可指派做了更严格的限制。流程定义如果A环节是角色，B环节可指派。A环节的每个有代办工作项的人员都有一个独立的指派列表。如果指派列表中存在重复的数据，系统会自动合并，只发送一次任务。 环节审批人A环节A1B1、B11A2B2、B21A3B3、B23每个审批人都有独立指派列表代理人（Agent）审批活动的一个属性。制单活动不可设置代理人；只可为参与者为操作员类型的审批活动设置多级代理人；代理人只可为操作员。消息（Message）V63消息不再是独立成节点（活动），作为流程节点的附属属性（在图示上区别），增加消息配置的易用性；消息签收改为消息回执；消息回执不影响流程执行；流程历史信息中增加消息回执的发送和回执接收的记录。消息签收改为消息回执，消息回执不影响流程执行；流程历史信息中增加消息回执的发送和回执接收的记录；提高了消息配置的易用性。消息支持通知消息与任务消息的配置：通知消息需要指定发送条件和接收人，例如审批通过、不通过或者驳回等。发送的是通知消息。任务消息是在工作项执行通过是发送给下游任务的审批人的工作任务消息，不需要指定条件和接收人，如下图。通知消息配置界面任务消息配置界面消息支持消息模板，可通过消息模板配置消息内容（不配置显示默认内容），同时消息模板支持附件，邮件通知时，可根据消息模板的打印模板生成单据详细信息的Html或者pdf格式的附件，详见消息模板的相关文档。加签目前只支持前加签。当前审批人在审批中，可以进行加签操作。流程会流转到加签的用户或者角色。加签人员处理完毕后，流程回到当前审批人处。加签的结果不影响流程。V63会在消息里会有加签记录。改派当前审批人认为工作任务应该由其他人员来处理。可使用此操作。V63版本，改派后会生成新的工作任务，原有工作任务被废弃，流程与转出人不再相关。V63会在消息里有改派记录。本人自动审批当前环节的参与者在之前的环节已审批过（或者为单据提交人）时，本环节不需要审批系统在任务创建后自动默认审批通过。注意环节的参与者不唯一时（参与者不为操作员且会签模式）不执行自动审批。2.4.1.2 导入/导出在审批流定义-浏览界面，选中某个流程，可导出为本地XPDL文本文件。1) 不导出包定义。2) 一次只能导出一个流程。从本地XPDL文本文件导入流程定义到当前单据类型包下：1) 如果包定义不存在，则先新建包定义保存，再保存导入的流程定义。2) 在导入含子流程的XPDL时，提示“导入的XPDL文件中含有对N个子流程的引用，导入后需要修改流程以重新建立引用关系，是否继续？”。3) 不能导入同制单人的流程定义。2.4.1.3 流程定义支持“隐藏不批准”选项V63开始，流程定义支持“隐藏不批准”功能。使用该功能流程，用户无法再审批对话框和审批侧边栏中对单据进行“不批准”操作。2.4.1.4 流程定义的多版本以及启用/停用新建一个流程定义，保存以后默认的初始状态是“未启用”，版本是1.0。V63开始支持流程定义双人审核。双人审核指流程定义需要有人审核才能生效。流程管理预置集团级参数，由企业自行配置是否需要双人复审才生效。下图是双人审核流程和非双人审核流程的场景。双人审核流程非双人审核流程新增流程定义和修改流程定义用一下状态图表示：新增流程定义状态图修改流程定义状态图同一单据类型（+交易类型）同一组织下，同样的制单环节参与者，不允许存在多个启用的流程。停用的流程不允许修改，V63开始提供了预览停用流程的途径。2.4.1.5 流程定义的选择对于某个单据类型（+交易类型），根据组织或制单人的不同，可定义多个审批流程定义。制单人类型支持操作员、角色、角色组、用户组、职责、虚拟角色等多种。虚拟角色目前只有“制单人”。一个操作员制单后，究竟走哪条流程定义，系统根据几个要素（单据类型/交易类型的、单据组织、流程定义组织、制单人、优先级、修订审批流枚举项）采用明细优先的原则来确定。具体选择的顺序如下：1 满足单据类型、交易类型、组织，制单人，修订审批流枚举为操作员类型的流程；2 制单人为角色类型的流程若制单人委派了多个角色，则只找第一个角色定义的流程；3 制单人为动态组织类型的流程。4 没有组织，满足单据类型、交易类型，制单人仍然按照前面几步的顺序依次查找5 没有组织、交易类型，满足单据类型，制单人按前面的步骤依次查找6 查到相同的流程定义，组织级流程优先，如存在相同级别的流程定义，按优先级确定启动流程7 若存在多条满足上述条件到的流程，且流程的所属组织及优先级相同，给出提示，不启动流程。2.4.1.6 提交至驳回人有些单据在某个环节驳回后，可直接提交驳回环节，中间环节的审批人可不再进行审批。 属性编辑器中的流程属性中增加“驳回单据处理方式”枚举项，默认为提交至下一环节，表示单据驳回给之前环节后，需要提交给下一个环节的审批人审批。2.4.1.7 条件表达式企业的审批会依据单据上某个属性的不同值，由不同人来进行审批。条件表达式界面在流程转移线上可定义条件表达式，条件表达式包含三个页签：自定义函数、单据函数、元数据。元数据，同V63之前版本，下可选择单据类型对应的元数据实体属性建立表达式如上图。单据函数：可选择单据函数注册节点注册的单据类型下的单据函数作为左值建立表达式。自定义函数（65新增功能）：可使用公式编辑界面自定义公式作为左值建立表达式。如下图定义自定义函数公式编辑界面使用自定义函数定义表达式2.4.1.8 支持电子签名V63支持对审批人意见和审批结果电子签名。防止数据通过非法途径进行修改。是否进行签名在流程定义环节上进行设置。2.4.2 工作项工作项是是工作流引擎在流程流转过程中，对活动的参与者根据基本组织单元（操作员）进行任务分配的产物。2.4.2.1 分配策略工作流引擎将产生的工作项直接推给用户，用户登录后可选择优先执行哪些任务。 自动审批：流程定义的活动上设置了“本人自动审批”属性。流程引擎将会自动忽略在前面的流程环节中已经审批过的用户。 参与者出差后，审批工作项将会分配到代理人。见流程代理人设置。2.4.2.2 工作任务消息配置工作项的标题可由从单据元模型中获取到的信息组成，以便更人性化的显示在待办事务。审批环节上可以设置发送任务工作项还是邮件通知，邮件审批类的消息。根据用户的不同应用要求，对不同单据需要显示的消息标题或者消息内容存在差异，因此需要用户设置模板来确认发布的消息内容。V61关联打印模板，但是打印模板没有消息维度，无法满足一个单据的审批人有不同语种要求的场景。V63开始关联消息模板，发送消息时候按照用户档案上设置的语种来发送不同语种的内容。图27 任务消息配置 发送方式：工作任务，邮件审批，短信审批。工作任务中可以带附件。消息模板中可以使用系统变量、元数据、业务函数。 消息内容：参照，流程定义单据上设置的消息模板。 推送：只有工作项可以配置是否推送。2.4.2.3 关联UI工作项与UI的关联全部采取功能节点方式。工作项与哪个UI关联是由单据类型决定的（参见1.1节）。同时关联的UI必须实现UI关联接口（参见第三章节）。2.4.2.4 审批历史打印V63之前支持单据打印时候附加审批历史信息，要求打印所有审批历史。V63新增支持：打印有效审批历史。在配置打印模板的附件审批信息时，由用户选择是否只打印有效的审批信息。有效的审批信息是指：审批环节上的参与者的最后一次审批意见。数据项名称取值范围默认值隐藏不批准是、否是参数取值范围2.4.2.5 流程代理人设置流程代理人设置V6支持全局级和流程级的代理人。当人员出差时候，如果设置了代理人，会发送工作项给人员的代理人，有代理人进行处理。查找代理人的过程按照明细优先的原则：流程级的代理人优先于全局级的代理人。在代理人设置节点，可对用户的代理人进行设置，左侧围单据类型列表，选择单据类型时代理人仅对该单据类型的单据起作用，选择ALL时