本次汇报将由三部分组成：upp平台缺失功能\upp进展\下一步推进计划：
这个接口用于集成节点单据，当业务流转到特定任务时，需要去完成特定的事项，如果相关事项未通过认证，将无法进行流程流转。
审查单场景：合同审批在业务部分需要确认合同的业务需求与技术方案，在财务部分需要关注付款方式以及合同预算等，在法务部门将需要就进行风险防控与法律事项以及业务合规等事项确认。在不同的节点需要提供不同的验证内容，这些信息可能分散在合规子系统/案件子系统/项目管理子系统/风险控制子系统等，不管在哪，upp平台将调用业务中台服务，由业务中台完成相关事项确认。
在.net平台中，我们为解决某粮集团不定层级审批需求，引入了树节点支持按发起人所属业务层级，向上查找到特定层级人员后流转到下一节点功能。
这个业务场景在规模企业中一定存在，所以，我们需要扩展类型，支持不定层级审批自循环审批功能。这将大大提升upp平台的支持能力。
upp平台已完成子流程的集成实现，并在某省港集团上线运行，子流程的推出确实大大降低了业务运维难度，并且形成了大量公用业务子流程，让分子公司能只关注自身业务，在需要上报集团公司时，引入相应的集团子流程进行串联即可。
在实践中，分支命中子流程。但在子流程内部未命中审签环节，而出现流程在子流程中直接穿透。这种场景在upp平台中暂时未解决。
flowable自身采用了hi、ru两套表来加速运行性能，当相关的数据达到一定量时，运行性能将降低到不可接受状态。为此，需要在外围对flowable运行沉积库进行迁移，让flowable标准的hi、ru表在一定的数据量内，使upp平台能持续提供可靠的运行能力。
近日在客户现场业务数据接近100w级，让upp平台的审批性能有所下降。我们对flowable辅助数据进行了迁移操作，性能有所提升但未达到期望值。基于对业务数据及net工作流程平台运营改造经验，在流程终审后相关的审批记录将进入只读状态，不再进行业务计算，这时数据对upp平台来说完全是性能干扰数据，为此引入了审批记录数据迁移方案，在默认状态下，这个方案是关闭的，当有一定数据量后，启动相关配置激活迁移计划，upp平台的性能将进入一个长期稳定期。
在现实生活中，企业员工有请假/借调/出差等不方便进行相关事项处理情况，这时需要业务平台能提供代理审批能力。让企业运营不会因某人出差而受到影响。在工作流引擎的支持下，外围实现相关配置及被动代理信息填充方案，让upp平台最终支持相关业务。
由于进入100w级数据量，由于早期为完成upp平台全能力服务，在业务实现过程中采用了大量串行工序链式化调用。
由于时间关系与认证关系，业务功能没有从整体出发，使整个链路存在大量的重复查询。本次进行了之下而上与至上而下的数据传输模型改造，让链式调用中使用尽可能少的数据访问完成调用，最终实现性能优化目的。
我们将尽可能的优化性能，让平台能长久稳定运行。并尽快完成待完成任务支持。
upp平台将在合适的时机对外开放，让业务管理平台的核心组件不再那么难用......................