相关推荐

• 3.4.3 函数的相关特性

  本小章会从oinone的函数拥有三方面特性，展开介绍 面向对象，继承与多态 面向切面编程，拦截器 SPI机制，扩展点

  史, 昂

  Oinone 7天入门到精通 2024年5月23日

  1.1K000

• 陈浩

  自2017年中国推进数字建设以来，数字经济规模持续增长，“十四五”规划和2035远景目标纲要中明确强调企业和政府需大力推动数字化转型，中国正在迈进一个崭新的数字经济时代。 在这个过程中，软件已经从工具变成信息化的基础设施，如何有效应对该变化所带来的一系列新的核心技术挑战，是整个软件行业发展遇到的另一难题。我认为，开源创新是解决这些难题的有效手段之一，也是未来软件发展的重要方向。如果说，数字化转型是时代趋势，那么开源创新也已成为时代主流。十四五规划纲要首提开源，2021年11月工信部印发《十四五软件和信息技术服务业发展规划》中提到开源重塑软件发展新生态，并将开源重塑软件发展新生态作为十四五期间我国软件产业的四大发展形势之一进行重点阐述。支持国产化开源创新体系发展，建设自己的开源社区和开源平台，其所具有的大众协同、开放共享、持续创新等特点，可有效推动各行业自主可控的数字化转型。 Oinone所倡导的开源理念和生态共建，与国家开源战略不谋而合：将开源作为一种合作手段，通过完善社区注重开源治理，吸引更多的企业和个体参与其中。湖南大学作为首批国家示范性软件学院的双一流建设高校，一直致力于推进和引导国产化开源软件体系的建设，并为此开展多种形式的产学研研究和实践。基于Oinone微服务分布式的设计理念和面向生态的开源特性，湖南大学结合自身在大数据分布式存储、多元异构数据汇聚融合和大数据智能分析等方面的研究成果，与Oinone展开了深度的技术创新合作，并在多个大中型企业数字化应用和数字政府应用中取得了良好的效果。 随着Oinone的开源，相信能激发更多的开发者参与到国产软件建设中，通过开源模式实现更广泛参与方的共享、共创、共生、共赢，构建价值驱动的数字创新生态平台，为我国数字经济发展贡献科技力量。 湖南大学教授：陈浩

  史, 昂

  Oinone 7天入门到精通 2024年5月23日

  1.5K000
• Oinone 7天入门到精通

  2.4.1 Oinone独特性之单体与分布式的灵活切换

  企业数字化转型需要处理分布式带来的复杂性和成本问题。尽管这些问题令人望而却步，但分布式架构对于大部分企业仍然是必须的选择。如果一个低代码平台缺乏分布式能力，那么它的性能就无法满足客户的要求。相比之下，Oinone平台通过对部署的创新（如图2-6所示），成功实现了分布式架构的支持，而且能够按照客户的业务发展需求，灵活选择不同的部署模式，同时节约企业成本，提升创新效率。这一创新是Oinone平台与其他低代码平台的重要区别，能够满足客户预期发展并兼顾成本效益。 图2-6 传统部署方式VS Oinone部署方式 实现原理 要实现灵活部署的特性，必须满足两个基本要求： 开发过程中不需要过多关注分布式技术，就像开发单体应用一样简单。代码在运行时应该能够根据模块是否在运行容器中，来决定路由走本地还是远程。这样可以大大减少研发人员的工作量和技术复杂度。 研发与部署要分离，即"开发单体应用一样开发分布式应用，而部署形式由后期决定"。为此，我们的工程结构支持多种启动模式，并逐一介绍了针对不同场景的工程结构类型（如下图2-7所示）。这样可以让客户在后期根据业务发展情况和需求，选择最适合的部署模式，从而达到灵活部署的目的。 图2-7 Oinone工程结构梳理 在整个工程结构上，我们秉承了Spring Boot的规范，不会改变大家的工程习惯。而Oinone的部署能力则可以让我们更灵活地应对各种情况。现在，我们来逐一介绍几种常规的工程结构以及它们适用的场景： 单模块工程结构（常规操作） a. 这是非常标准的Spring Boot工程，适用于简单的应用场景开发以及入门学习。 多模块工程结构（常规操作） a. 这是非常标准的多Spring Boot工程，可以实现分布式独立启动，适用于常规的分布式应用场景开发。 多模块工程结构-独立boot工程模式 a. 这种工程结构在多模块工程的基础上，通过独立的boot工程来支撑多部署方式。适用于中大型分布式应用场景开发。 b. 然而，随着工程越来越多，我们也会面临一些问题： ⅰ研发：环境准备非常困难，每个模块都要单独启动，研发调试跟踪困难。 ⅱ部署：分布式的高可靠性保证需要每个模块至少有两个部署节点，但在模块较多的情况下，起步成本非常高。同时，企业初期业务不稳定且规模较小，使用多模块工程的第二种模式会增加问题排查难度和成本。 c. 此时，Oinone的多模块工程下的独立boot工程模式部署就可以发挥其灵活性，让研发和业务起步阶段可以选择all-in-one模式，等到业务发展到一定规模的时候，只需要把线上部署模式切换成模块独立部署，而研发还可以保留all-in-one模式的优势。 d. 值得注意的是，分分合合的部署模式在传统互联网架构和低代码或无代码平台上都是有代价的，但是Oinone却可以灵活适配，只需要在boot工程的yml文件中写入需要加载的模块就可以解决。此处我们仅介绍多模块加载配置，选择性忽略其他无关配置，具体配置（如下图2-8所示）。 pamirs: boot: init: true sync: true modules: – base – resource – sequence – user – auth – web tenants: – pamirs 图2-8 Oinone yml配置图大型多场景工程结构-独立boot工程模式： a. 在多模块工程结构基础上的加强版，增加CDM层设计，让不同场景即保持数据统一，又保持逻辑独立。这种工程结构特别适用于大型企业软件开发，其中涉及到多个场景的情况，例如B端和C端的应用，或者跨不同业务线的应用，能够保证数据的一致性，同时也能够保持逻辑独立，避免不同场景间的代码冲突。 b. 这种工程结构是我们Oinone支撑“企业级软件生态”的核心，我们可以把场景A当作我们官方应用，场景B当作其他第三方伙伴应用。在这个工程结构下，我们的客户可以定制化开发自己的应用，同时我们也可以通过这种模式来支持我们的伙伴们进行开发，实现多方共赢。 c. 基于独立boot工程模式，我们同样对应多种部署模式应对不同情况，并统一管理所有伙伴应用。这种工程结构的优点是扩展性好，可以支持不同规模的应用，并且可以根据需要进行快速扩展或缩小规模，具有很高的灵活性。 基于标准产品的二开工程结构，是指基于标准产品进行二次开发，满足客户特定需求的工程结构。这种模式下，Oinone提供标准产品，客户可以根据自己的需求进行二次开发，实现定制化需求，同时可以利用我们的模块化开发特性，将每一个需求作为一个模块进行开发和管理。这种工程结构的优点是能够快速满足客户特定需求，同时也具有很好的可维护性和可扩展性，因为每个需求都是一个独立的模块，可以方便地进行维护和扩展。在下一篇“Oinone独特性之每一个需求都是一个模块”文章中有详细介绍。

  史, 昂

  2024年5月23日

  1.5K000
• Oinone 7天入门到精通

  1.4 Oinone对软件特性的思考

  我在个人的微信公众号上《浅谈企业IT架构的十年困局》一文中写了“企业或者软件公司在工程领域都关注哪些特征，而这些特征又应与具体研发人员的个体能力无关”的相关内容。收到很多业内人士的留言，也引起了很多同行的共鸣，所以今天在这里也打算针对这个话题，跟大家再做个深入的探讨。 一、首先为什么强调要跟研发个体能力无关 我们先来看一个故事： 轮扁是春秋时期齐国的木工，齐桓公召其入宫打造物件。有一天，齐桓公在堂上看书，轮扁在堂下用椎、凿等工具做车轮。 齐桓公看书看到得意处，不由得读出声来。轮扁听到读书声，想了想，放下手里的工具，走上堂来，在齐桓公面前几步远的地方停下，恭恭敬敬地说：“请恕臣斗胆问一下，君王读的是什么书？”齐桓公没想到这个老木匠会走上堂来，倒有点意外。不过看在他年纪大的份上，倒也不去斥责他，就回答说：“寡人读的是圣人写的书。”轮扁问：“圣人还在吗？”齐桓公说：“已经死了。”轮扁说：“这样看起来，君王所读的，不过是古人的糟粕而已！”齐桓公勃然大怒，说：“寡人读书，你一个做车轮的怎么敢议论？你说，这书上怎么会是古人的糟粕？说出道理便罢，说不出道理便难逃一死！” 轮扁不慌不忙地说：“臣是根据臣所从事的活计而明白这个道理的。砍削轮子，榫头做得宽了则松滑而不牢固，做得太紧就必然涩滞而安不进去，臣制作的榫头松紧适宜，是因为心里怎样想的手便怎样去做。然而尽管所需要的分寸度数心里都明白，要把它用言辞表达出来却实在不可能，全靠自己手与心的配合。所以，臣无法将其中的奥秘传授给儿子，臣的儿子也无法从臣这里学到其中的奥秘。因此，臣如今七十多岁了，还只好亲手去干制作轮子的活。这样看来，古人之道的精华都已随着古人死去而无法传世，那么君王所读的，不就是古人的糟粕了吗？” 这就是著名的成语故事——轮扁斫轮，出自《庄子·天道》。庄子通过轮扁的言论，深刻地揭示了高妙之技的难以言传。 而当我们转换视角，在企业数字化转型领域，无论是软件公司还是甲方IT团队，核心上是应用级开发需求，更多的精力应该放在业务场景理解、需求把控以及业务系统实现上。但往往在一个项目进入研发之前，会花很大力气在技术架构设计、技术栈选型、通用能力对接、扩展点设计这些跟业务场景无关的技术事项上，且需要高级别的架构师来主导。大部分情况下，架构师会选开源框架来实现，慢慢沉淀为企业的研发标准体系，所以底层架构的能力往往依赖架构师个人能力。不禁发现他们与轮扁有着异曲同工之处。架构师所积累的个人经验和技术能力，往往难以通过简单的手把手教学、技术评审会完全传递给团队中的其他成员。即使有所传授，其效率也可能仅达到50%，并且随着团队成员数量的增加，这种效率还可能持续递减。因此，我们需要更多地依赖于技术手段，将架构师的经验和能力固化下来，形成一套可复制、可推广的标准技术产品。这样，每个团队成员都能够通过学习和运用这些技术，达到至少70%的传递效率，从而确保团队整体技术水平的稳步提升。这也正是开篇所强调的，企业或软件公司在工程领域所关注的特征，应当与具体研发人员的个体能力相剥离，而更多地依赖于标准化、系统化的技术手段，来确保团队整体的高效运作。 二、软件公司在工程化领域都关注哪些特征 接下来，我将从技术角度深入剖析设计初衷和技术实现原理，以展现技术公司应当“被标准化的特征”究竟长什么样。 先做个名称解释，下文中涉及“标品”、“升级”、“扩展逻辑”，这是站在软件公司角度出发描述的，如果是企业内部可以把标品理解为特定业务应用平台，升级则是业务应用平台的正常规划迭代，扩展逻辑理解为脱离平台发展的临时性需求。 1. 可逆计算 可逆计算，在应用上的特征图 场景：调查发现企业研发至少有40%的精力在跟各条业务线的团队在评审项目需求，判断需求是否合理。而且业务线对需求完善时间要求紧，每天盯着研发进度，经常问“这个需求什么时候支持，我们等着用”。导致产研部门的研发抱怨产品节奏乱，无法按照自身节奏进行迭代，被项目推着走，没有时间思考，人手不足，加班多，工作压力大…… 价值：该特性很好的规避了研发因为时间紧迫，写的一些临时代码腐蚀核心业务系统。它需要做到不论从数据模型、业务逻辑、交互展示都能有扩展能力，并且这些扩展能力与个体研发无关才行。它同时所描述的也是一个具备差量计算能力的软件架构模式，它允许用户通过添加或移除扩展包来定制标准应用，同时保持应用的可逆性和独立性。这种架构模式的核心优势在于其灵活性和可维护性，使得应用的定制和恢复变得简单而高效。 技术原理：它所描述的是一个基于元数据驱动和差量计算的软件架构模式，它允许用户通过添加或移除扩展包来定制标准应用，同时保持应用的可逆性和独立性。这种架构模式的核心优势在于其灵活性和可维护性，通过元数据来驱动应用的构建和变更，使得应用的定制和恢复变得简单而高效 在这种架构中，元数据起到了至关重要的作用。元数据是关于数据的数据，它描述了数据的结构、属性、关系等信息。在软件应用中，元数据可以用来描述应用的组件、功能、配置等信息。通过元数据驱动应用可以根据元数据的描述来动态地构建和配置自身的功能和结构 差量计算则是实现应用可逆性的关键。当添加或移除扩展包时，系统会根据扩展包中的元数据与标准应用的元数据进行差量计算，确定需要添加或移除的功能和组件。这种差量计算可以确保在添加扩展包后，应用能够保持原有的功能和稳定性，同时新增扩展包带来的新功能，而在去除扩展包时，应用能够恢复到原始的标准状态，不会留下任何冗余或冲突的代码和配置。 为了实现这种架构模式，元数据注册表和分布式部署能力是非常重要的。元数据注册表需要能够存储和管理大量的元数据信息，并且提供高效的查询和更新机制。分布式部署能力则能够确保应用在不同的环境中都能够稳定运行，并且能够快速地响应扩展包的添加和移除操作，即差量(扩展包》可独立存在又相互作用。 总的来说，这种基于元数据驱动和差量计算的软件架构模式为应用的定制和恢复提供了强大的支持，使得应用能够根据不同的需求进行灵活的定制和扩展。同时，它也提高了应用的可维护性和可靠性，降低了开发和维护的成本 2. 协同演进 协同演进，在应用上的特征图 场景：它所描述的场景是一个复杂的软件升级过程，其中涉及了标准应用的升级以及用户个性化扩展的保留。通过面向对象的方式扩展标准应用的功能，可以在升级过程中保持用户自定义逻辑的完整性，并同时集成新版本中的新特性。 价值：很多号称产品型的软件公司，在交付客户项目的时候，都是从标品复制一个分支，然后客户个性化直接在这个分支上改。这种模式会带来两个问题： 是当客户数量变大，每个客户的版本都不一致，维护成本很高； 是当标品升级带来的新特性无法复制给客户，导致客户满意度下降甚至流失。协同演进就是要解决这个问题。 技术原理：它需要在第一个差量计算的特性基础上才能得以完成，同时在这种升级能力中，元数据驱动和模型驱动是关键所在。元数据驱动确保了应用能够理解和处理不同版本之间的变化，包括功能的增删改以及结构的调整。模型驱动则提供了描述和管理应用结构、组件和行为的能力，它不仅能够描述模型间的关系，还能够支持面向对象的特性，如继承、重写和重载等。 具体来说，当标准应用从V1升级到V2时，元数据驱动机制会首先识别和分析两个版本之间的差异。对于用户应用1中已经扩展的A功能，由于采用了面向对象的方式进行扩展，因此在升级过程中，A+逻辑作为A功能的重写或重载版本会被保留下来。同时，V2版本中新增的B功能也会被集成到用户应用1中，因为它是作为标准应用的新特性而存在的。 这种升级能力的实现依赖于一个强大的元数据注册表和模型管理能力。元数据注册表需要能够存储和管理不同版本应用的元数据信息，包括功能、组件、结构等。模型管理能力则需要能够解析和应用这些元数据，以生成正确的应用结构和行为。同时，还需要一套高效的升级机制来确保升级过程的平滑和可靠。 总的来说，通过元数据驱动和模型驱动的结合，可以实现标准应用的平滑升级，同时保留用户个性化扩展的完整性。这种能力对于提高软件的可维护性、可扩展性和用户满意度具有重要意义 3. 公民研发和专业研发共同参与 专业研发与公民研发共同参与，在应用上的特征图 场景：它所描述是在应用开发的整个生命周期中，专业研发专注在标品的长期规划与迭代，当出现临时性的需求或者应急性的辅助场景则由非专业人士进行即公民研发方式进行。这种模式下，专业研发可以按照规划有节奏的迭代产品，做更高级的事情，不至于忙于应对临时性的事务没有深度思考，更加避免了因为临时代码堆积导致产品从内部腐化。同时利用独立的扩展逻辑包和无代码方式解决了业务的紧迫感，毕竟业务需求的合理性是很难争论出高低的。它在前两个特性基础上让研发效能进一步得到释放。 价值：它的本质是，在专业研发在以低代码的方式下实现应用，并通过无代码的方式，快速扩展逻辑功能和创建辅助性应用。整个过程无缝衔接，我们给他取个名字专业名称叫：“低无一体”。它大大降低了技术门槛，使得专业和非专业的研发人员都能参与到应用扩展和定制中来。此外，它还提高了业务响应能力，使得企业能够更快速地适应市场变化和客户需求。 技术原理：它的核心要求就是元数据在线，元数据在线能力是指能够实时地、在线地管理和操作元数据，这种能力为企业或组织带来了诸多优势。通过无 代码的方式，用户可以更加灵活地进行应用的个性化扩展，以应对各种应急性需求，从而显著提升业务的响应能力。此外，元数据在线管理还确保核心应用、核心应用扩展以及辅助应用都是基于一套统一的技术体系构建的，这为不同角色的用户（包括专业和非专业的研发人员）提供了多样化的参与方式。同时，元数据在线管理需要符合开闭原则，这确保了系统的稳定性和可扩展性，使得新的功能或需求可以通过添加新的元数据或配置来实现，而非修改现有系统。 这种低代码开发与无代码一体化的优势在于，它大大降低了技术门槛，使得专业和非专业的研发人员都能参与到应用扩展和定制中来。此外，它还提高了业务响应能力，使得企业能够更快速地适应市场变化和客户需求。 总之，从用户应用到业务实施的过程通过元数据在线得到了优化和升级。低代码开发与无代码一体化的优势使得整个过程更加高效、灵活和易于维护，为企业带来了显著的价值和竞争优势。 4. 基于平台级别的AOP能力出现反向集成 反向集成，在应用上的特征图 场景：平台级别的AOP（面向切面编程）能力允许开发者在应用程序的特定点“切入”额外的逻辑，而无需修改原有的业务代码。这种能力特别适用于横向追加平台逻辑，即在多个不同服务或功能点插入通用的处理逻辑，如日志记录、权限检查、审计、多租户、多语言等。过往在微服务架构中，这些能力都需要业务系统各自主动去对接，有了平台级别的AOP能力，则这些通用能力可以反向为所有业务系统增加特性能力，无需业务系统研发感知。这种现象我们称之为“反向集成”，能让业务研发更加专注在业务研发本身，不需要关心与业务无关的通用功能上。 价值：AOP的核心思想是将这些横切关注点（cross-cutting concerns）从业务逻辑中分离出来，使得业务代码更加清晰和专注于其核心功能。在平台级别的AOP中，标准化协议是实现这一能力的关键。平台具备统一的入口和扩展能力是非常重要的，因为它允许开发者在不修改现有代码的情况下添加新功能或修改现有功能的行为。这种能力对于快速响应业务需求变化、减少维护成本和提高代码质量都是非常有益的。 技术原理：标准化协议确保了不同组件之间的通信与语义是统一的，从而使得AOP能够更容易地实施。例如: a前后端通信要标准协议(与端无关): 这意味着无论前端是使用Web、移动应用还是其他类型的客户端，后端服务都应该能够以一种标准的方式与之通信。 bORM层要有标准协议(与数据库无关): 对象关系映射 (ORM)层应该提供一个标准的接口来与数据库进行交互，这样无论底层使用哪种数据库(如MySQL、PostgreSQL、Oracle等)，上层的业务逻辑都不需要改变。 cRPC需要标准协议(与Dubbo和Spring Cloud无关): 远程过程调用 (RPC)应该遵循一种标准协议，以便不同的服务可以无缝地进行通信，而不受特定框架 (如Dubbo、Spring Cloud等)的限制。 d所有逻辑调用统一fun调用: 这意味着平台上的所有功能调用都应该通过一个统一的入口点(如一个函数或方法)进行，这样AOP就可以在这个入口点切入额外的逻辑。 总的来说，平台级别的AOP能力通过标准化协议和统一的调用入口，为开发者提供了一种强大而灵活的方式来管理和扩展平台的逻辑功能。 5. 应用研发与部署无关 应用研发与部署无关，在应用上的特征图 场景：现在研发在选择部署方式的时候往往会选择分布式部署，或者你的客户招标需求里就写着“微服务”，构建一个微服务系统并不是一件容易的事，构建的复杂度远远超过单体系统，开发人员需要付出一定的学习成本去掌握更多的架构知识和框架知识。服务与服务之间通过HTTP协议或者消息传递机制通信，开发者需要选出最佳的通信机制，并解决网络服务较差时带来的风险。另外服务与服务之间相互依赖，如果修改某一个服务，会对另一个服务产生影响，如果掌控不好。会产生不必要的麻烦。由于服务的依赖性，测试也会变得很复杂，比如修改一个比较基础的服务，可能需要重启所有的服务才能完成测试。前段时间有篇很火的文章，《从微服务转为单体架构、成本降低 90%！》，无论是选择何种部署方式，我认为这都应该跟应用研发无关。 价值：应用研发与部署无关的理念确实为现代软件架构带来了显著的优势，它使得研发团队能够专注于业务逻辑和功能实现，而无需担心具体的部署细节。这种分离带来了灵活性、效率以及成本效益的多重提升。应该采用一种同时支持分布式和单体部署、且可以自由切换的架构，我们称之为可分可合。 首先，可分可合的能力使得系统能够灵活应对业务量的变化。在业务量小的时候，可以采用单体部署的方式，简化部署流程，降低初期成本。随着业务量的增长，系统可以平滑地过渡到分布式部署，通过拆分微服务来提高系统的处理能力和扩展性。这种灵活性确保了系统既能满足未来发展的需要，又能兼顾当下的成本效益。 其次，应用级别扩容的能力使得系统性能不再受限。通过增加微服务实例或调整资源配置，系统可以按需进行扩容，从而确保在业务高峰期或突发流量下仍能保持稳定的性能。这种按需扩容的方式不仅提高了系统的可靠性，还降低了运维成本。 技术原理：核心在于逻辑调用的统一执行和智能判断。通过如funEngine这一统一调用引擎，系统能够智能地选择最适合当前业务场景和性能需求的fun调用方式。无论是同步调用、异步调用还是基于消息队列的调用方式，funEngine都能进行智能决策，确保调用的高效性和可靠性。这种统一调用的方式简化了开发过程，降低了开发难度，同时也提高了系统的可维护性和可扩展性。 此外如果作为低代码或者其他研发平台来说。被集成特性也是实现该特性的关键所在。它提供了一套标准化的接口和协议，使得其他系统或应用能够轻松地与其进行集成。这种平台框架化的特性能够作为一个统一的、可扩展的框架来支撑整个系统的运行。 综上所述，具备可分可合的能力、应用级别扩容以及逻辑调用的统一执行和被集成特性，共同构成了应用研发与部署无关这一核心特性。该特性使得软件系统能够灵活地应对业务变化，实现高效、可扩展和可维护的运行，从而满足客户的长期发展需求并兼顾当下的成本效益。

  史, 昂

  2024年5月23日

  1.6K100
• Oinone 7天入门到精通

  7.3.2 原业务加审批流程

  场景说明 场景描述：全员营销标准产品的功能并未有任务发放的审批流，在实际执行中，当营销专员配置好任务后，需部门领导对整个活动如该任务内容、形式、参与人员进行审批。 业务需求：在发布任务这个流程中增加审批节点。 实战训练 Step1 原业务分析 点击菜单【任务中心】通过URL上的model参数找到对应模型编码为【gemini.biz.GeminiTaskProxy】 进入模型设计器主页面，应用选择【全员营销】、选择【系统模型】、通过搜索关键字【任务】选择【Gemini任务代理】，展示方式从图模式切换到表单模式，对比【模型编码】 但目前模型为代理模型，代理模型是用于代理存储模型的数据管理器能力，同时又可以扩展出非存储数据信息的交互功能的模型。因为在代理模型中新增的字段都是非存储字段，所以如果要增加【审核状态】的字段一定以要在存储模型增加。其父模型的查看有两种方式 表单模式下可以直接看父模型 在图模式和表单模式下点击继承关系 点击【Gemini任务】，进入【Gemini任务】的模型设计界面，可以看出该模型所在模块为【全员营销核心业务】，从【系统字段】中找到【任务状态】字段，点击查看字段详情，我们可以看到【业务类型】为数据字典，字典类型为【任务状态】。 在模型设计器的管理页面上方点击【数字字典】选项卡，模块选择为【全员营销核心业务】，选择【系统字典】就可以查看到【任务状态】数字字典 总结如下： 给【Gemini任务】模型增加一个【任务审批状态】，记录审批状态 在任务创建的时候，修改【任务状态】为【关闭】确保任务未审批通过的时，用户无法操作该任务。 审批通过后，恢复【任务状态】为【初始化】 我们先来整理下核心流程即：任务审批流程。 Step2 利用模型设计器设计模型 在模型设计器的管理页面上方点击【数字字典】选项卡，模块选择为【全员营销核心业务】，点击添加【数据字典】按钮，设置对应数据项 设置【字典名称】为【审批状态】 设置【字典项类型】为【文本】 通过【添加数据字典项】按钮增加对应数据字典项，如审核中、审核失败、审核成功 在模型设计器的管理页面上方点击【模型】选项卡，模块选择为【全员营销核心业务】，选择【系统模型】、搜索任务选择【Gemini任务】，点击添加字段 为模型【Gemini任务】添加字段 设置【字段名称】为【任务审批状态】 设置【字段业务类型】为数据字典，并选择关联数据字典为【任务审批状态】 最后点击【创建】按钮完成操作 回到【Gemini任务】设计区，我们可以看到在模型的【自定义字段】选项卡下方多了一个【任务审批状态】字段 Step3 利用界面设计器，设计出必要的审核页面 进入界面设计器，应用选择全员营销，模型选择【Gemini任务】，点击添加页面下的直接创建 设置页面标题、模型（自动带上可切换）、业务类型（运营管理后续会扩展其他类型）、视图类型（表单）后点击确认按钮进入【Gemini任务】表单设计页面 进入页面设计器，对【Gemini任务】表单页面进行设计（更多细节介绍，请参考界面设计产品使用手册） 左侧为物料区：分为组件、模型。 【组件】选项卡下为通用物料区，我们可以为页面增加对应布局、字段（如同在模型设计器增加字段）、动作、数据、多媒体等等 【模型】选项卡下为页面对应模型的自定义字段、系统字段、以及模型已有动作 中间是设计区域 右侧为属性面板，在设计区域选择中组件会显示对应组件的可配置参数 在左侧【组件】选项卡下，拖入布局组件【分组】，并设置组件【标题属性】为基础信息 在左侧【模型】选项卡下，分别系统字段中的【任务标题】、【任务开始时间】、【任务结束时间】、【视频标题】、【视频风格】、【任务描述】拖入【基础信息】分组，并点击【任务描述】，在右侧属性面板的【交互】分组中设置宽度为1。最后别忘了点击【发布】按钮完成页面的发布 Step4 通过流程设计器，设计对应业务流程 进入流程设计器，点击【创建】按钮 注意：流程中需要获取【关系字段】的除关联字段(一般为ID)以外的字段需要通过【数据获取】节点单独获取【关系字段】的对象数据。所以在流程设计中经常会用到【数据获取】节点 左上角编辑流程名称为【任务审批流程】，点击第一个【触发】节点，触发方式选择模型触发，模型选择【Gemini任务】，触发场景选择【新增或更新数据时】，【筛选条件】设置为【任务审批状态】为空或【任务审批状态】等于【审核中】，点击该节点的【保存】按钮 点击流程图节点间的【+】图标选择增加【获取数据】节点，或者拖动左侧物料区【获取数据】到特定的【+】图标 点击【获取数据】，在右侧属性面板中设置【获取数据条数】为多条，选择模型为【Gemini用户任务实例】，点击【筛选条件】的【{X}】图标，进行数据获取的条件设置 选择条件字段为【任务ID】条件操作符为【等于】，条件为变量的导购字段的ID。当上下文只有一个变量时默认不需要选择，这里默认的是【模型触发：[Gemini任务]】，设置好以后点击确认，回到属性面板设置【未获取到数据时执行方式】为【终止流程】，并点击节点【保持】按钮 增加【更新数据】节点，在右侧属性面板中 【更新模型】选择【模型触发：[Gemini任务]】 【字段列表】点击【创建】按钮 字段选择 更新【任务状态】字段 表达式设置为：【已关闭】。 【字段列表】点击【创建】按钮 字段选择 更新【任务审核状态】字段 表达式设置为：【审核中】。 最终完成的【模型触发：[Gemini任务]】更新设置 a. 【模型触发：[Gemini任务]】的【任务状态】字段等于数字字典的【已关闭】，任务审核状态为【审核中】 b. 最后点击节点【保持】按钮。 再增加【更新数据】节点，在右侧属性面板中 【更新模型】选择【获取数据[Gemini用户任务实例]】 【字段列表】点击【创建】按钮 字段选择 更新【任务状态】字段 表达式设置为：【已关闭】。 最终完成的【获取数据[Gemini用户任务实例]】更新设置 a. 【获取数据[Gemini用户任务实例]】的【任务状态】字段等于数字字典的【已关闭】 b. 最后点击节点【保持】按钮。 增加【审批】节点，在右侧属性面板中 【审批模型】选择模型为【模型触发：[Gemini任务]】 【选择视图】选择前面新建的页面【流程中的任务编辑页】 【审批人】选择角色为【超级管理员】 【数据】权限全部设置为【查看】 其他配置项默认，需要了解更多请查看产品使用手册 最后点击节点【保持】按钮。 新增【审核分支】，在【通过】分支中增加两个数据更新节点，跟审核前的两个数据更新节点对应 【模型触发：[Gemini任务]】的【任务状态】字段等于数字字典的【初始化】，任务审核状态为【审核通过】 【获取数据[Gemini用户任务实例]】的【任务状态】字段等于数字字典的【初始化】 流程确保保持并发布过，点击右上角【发布流程】完成流程的保存与发布 Step5 检验效果 创建任务后，任务状态为【关闭】状态，任务列表中的任务状态为多个状态的计算值 审核通过后，任务状态为【进行中】状态，任务列表中的任务状态为多个状态的计算值

  史, 昂

  2024年5月23日

  1.1K000