工作台用于呈现集成相关的统计数据，包括：
快捷连接是通过快捷筛选所需要链接的集成资源（应用/Oinone平台应用/数据库等），进入【数据流程创建页】，同时展示平台提供的数据流程模版，点击开始连接可使用数据流程模型创建数据流程。
开始连接后进入流程创建页：
Oinone社区 作者：史, 昂原创文章，如若转载，请注明出处：https://doc.oinone.top/oio4/9426.html
访问Oinone官网:https://www.oinone.top获取数式Oinone低代码应用平台体验
1. 什么是数据编码 当模型中的字段数据需要有一定的编码规定，可以在模型中设计模型或字段的数据编码。 编码预览：实时展示规则设置后的编码。 2. 编码前/后缀 编码前缀：必须以字母开头，且仅支持数字或字母，最多8个字符。 编码后缀：必须以字母开头，且仅支持数字或字母，最多8个字符。 3. 格式化日期 开关默认关闭，即数据编码中不包含日期。开关打开后，默认的日期格式为“年年年年月月日日”，也可以切换成“年年月月日日、年年月月、年年年年、年年”。 序列归零周期：与格式化日期选择有关，若选择为“年年年年月月日日”，则可选“年、月、日”，选择为“年年年年”，则只可选“年”数据编码序列会按照设置的这个周期归零。 4. 编码序列 编码方式：可选择连续序列或非连续序列，选择会影响后续包含哪些设置。 序列长度：序列包含多少位数字，可以设置1 – 18之间的整数。 序列起始值：数据编码序列的起始值，默认值为3。 当编码方式设置为非连续序列时，展示其余两个配置项。 步长类型：默认值为“自定义步长”，也可以设置成“1 – 10之间随机步长”。 步长：当选择“自定义步长”时，设置的步长即为真实步长。当选择“1 – 10之间随机步长”时，实际步长为1 – 设置值之间的随机整数。
如果把互联网架构比作社会主义，Oinone就是也要做有中国特色的社会主义，才能符合国情。 随着业务和生态的发展，企业对效率、性能、体验和智能化等方面的要求越来越高，但很多企业的系统面临着严重的系统架构落后和系统间割裂等问题，这些问题导致原有系统在业务发展下面临着效率和性能的双重挑战。与此同时，互联网平台的技术水平远远领先于传统企业系统，但是是否可以直接将互联网架构照搬到企业数字化转型中呢？显然，这是不合适的，因为互联网架构在企业数字化转型中面临着许多水土不服的问题。本章节将结合互联网中台架构的发展，分析这些问题的原因。 借鉴互联网中台理念 我们要先看互联网架构的发展，是如何一步步到今天提的中台架构概念的，每一步又解决了什么具体问题，我们以阿里架构变迁史为例来看下（如下图2-2所示）： 图2-2 阿里架构变迁史 在2009年，淘宝上线了五彩石项目，这标志着淘宝从单体应用向服务化应用的时代迈出了一步。那么，淘宝为什么要开发五彩石项目呢？因为当时淘宝面临两个非常严峻的问题，一个是性能问题，数据库连接不足，数据库成为了瓶颈；另一个是效率问题，当时淘宝有百余个研发人员，但核心系统只有一套测试、预发、线上环境，导致研发需求排队等待。在开始五彩石项目之前，淘宝还做了千岛湖项目，用来验证服务化架构的可行性，将用户中心独立出来。随后，淘宝开启了五彩石项目，目标是通过增加人力来提升效率，通过增加机器来提升性能。 随着淘宝的业务发展，他们又面临了一个问题：各个服务之间有很多重复的建设，效率低下。为了解决这个问题，淘宝开始从服务化转向平台化，并创立了“共享业务事业部”，将重复建设的公共业务分配给这个事业部，以避免成本浪费。这些公共业务包括商品平台、交易平台和结算平台等。平台化的目标是规避服务化没有规划导致的重复建设问题。 但是随着业务的快速发展，淘宝变成了一个拥有几十个事业部的巨型企业，而这带来了新的问题：效率问题。例如，如果需要在一个业务线上做出改动，需要与十几个平台进行沟通，这是非常低效的。同时，对于一个平台来说，需要面对来自不同事业部的需求，这需要平台研发人员具备理解和抽象所有业务线需求的能力，这让平台研发人员感觉回到了单体应用时代，所有的需求都要排队，即使增加人力也无法提高效率。这个问题主要表现在交易平台上。 为了解决这个问题，淘宝提出了中台的概念，中台是在一套规范下建立的，让具有专业技能的团队自主决策业务系统发展的平台。中台的目标是弱化平台的业务特性，提供通用能力。简而言之，就是将“共享业务”中的“业务”两个字去掉，只提供通用能力的平台 我们将每个阶段的核心目标总结为一句话： 从单体到服务：通过增加人员和机器来提高效率和性能； 从服务化到平台化：解决服务化阶段因缺乏规划而导致的重复建设问题； 平台化到中台化：在一套规范下，让各业务团队自行决定业务系统发展，适用于多个业务线或多个场景应用的独立发展。 类似地，在企业数字化转型过程中，也面临着类似的问题： 随着企业业务在线化，对系统性能和稳定性提出了更高的要求，但由于内部系统之间的割裂，导致很多重复建设。因此，我们需要进行服务化和平台化； 没有一个供应商能够解决企业所有的商业场景问题，所以需要多个供应商共同参与。我们可以将供应商类比为各业务线，在一套规范下让供应商或业务线自行决定业务系统的发展。 然而，阿里的中台架构方案并不能直接照搬到企业中。因为阿里的中台架构采用了平台共建模式，即让业务线基于平台设计的规范共同开发。这本质上还是平台主导模式，对企业来说历史包袱较大。在企业中，让不同背景的研发一起共建交易或商品平台是非常复杂的事情。平台化已经足够复杂，再加上共建会导致企业架构的负载过重，这对企业来说就不再是赋能，而是“内耗”。 互联网中台架构在企业实践中遇到的问题 在1.3《Oinone的生态思考》一文中，《与中台的渊源》部分提到，在阿里云为企业提供数字化项目时，客户经常会对以下三个问题提出质疑，这些问题非常突出： 1我们听说你们具备敏捷响应能力，但为什么改动需求如此缓慢？不仅所需时间更长，而且成本更高？ 2我们听说你们有能力中心，但为什么当我们引入新供应商或开发新场景时，前期建立的能力中心无法支持我们？ 3我们听说你们的性能很好，但为什么我们需要投入更多的物理资源来支持项目？ 在探讨互联网架构的适用性时，我想提出以下两个问题： 1企业应用程序的性能问题是否与互联网平台公司遇到的性能问题相同？ 2企业应用程序的开发效率问题是否与互联网平台公司遇到的效率问题相同？ 通过比较企业和互联网之间的差异，我们可以了解水土不服的核心原因。 企业 互联网 企业IT组织能力无法与数字化转型的速度匹配，缺乏足够的人才支持。为了提高开发效率，企业需要寻找工具和技术来降低开发难度，同时提高个人开发效率 互联网企业拥有众多优秀的人才，需要解决团队协作和知识共享的问题，即协同开发的效率。 企业无法制定并主导技术规范，这导致了能力复用的不足。为了提高效率和减少开发成本，企业需要建立统一的技术规范和标准，以便能力复用和组织协同。 互联网企业可以自定义技术规范，因此能力复用更易于保障。 企业往往当前业务量相对小，期望数字化建设能打动业务发展，对业务发展的预期比较高，所以企业的诉求是即满足当下成本效应又能兼顾未来对发展预期 互联网企业起步时的系统目标负载就高，通常会忽略资源起步门槛的问题，当然也可以通过自动扩容、云计算等方式来解决初期的负载问题。 表2-1从企业与互联网的对比，看水土不服的核心原因 我们可以看到企业和互联网架构在很多方面存在着不同的需求和问题。因此，在提供数字化服务时，Oinone需要注意与企业的组织能力进行匹配，并根据企业自身的特性来提供在线化的服务能力。这就像在社会主义制度下需要有中国特色一样，Oinone也需要有适合中国企业的特色。
在我们的很多项目中，客户都是有个性化需求的，就像我们不能找到两件一模一样的东西，何况是企业的经营与管理思路，多少都会有差异。常规的方式只能去修改标准产品的逻辑来适配客户的需求。导致后续标品维护非常困难。而在介绍完这节以后是不是让你更加清晰认知到我们2.4.2【oinone独特性之每一个需求都可以是一个模块】一文中所表达的特性带来的好处呢？ 一、继承方式 继承方式可以分为五种： 抽象基类ABSTRACT，只保存不希望为每个子模型重复键入的信息的模型，抽象基类模型不生成数据表存储数据，只供其他模型继承模型可继承域使用，抽象基类可以继承抽象基类。 扩展继承EXTENDS，子模型与父模型的数据表相同，子模型继承父模型的字段与函数。存储模型之间的继承默认为扩展继承。 多表继承MULTI_TABLE，父模型不变，子模型获得父模型的可继承域生成新的模型；父子模型不同表，子模型会建立与父模型的一对一关联关系字段（而不是交叉表），使用主键关联，同时子模型会通过一对一关联关系引用父模型的所有字段。多表继承父模型需要使用@Model.MultiTable来标识，子模型需要使用@Model.MultiTableInherited来标识。 代理继承PROXY，为原始模型创建代理，可以增删改查代理模型的实体数据，就像使用原始（非代理）模型一样。不同之处在于代理继承并不关注更改字段，可以更改代理中的元信息、函数和动作，而无需更改原始内容。一个代理模型必须仅能继承一个非抽象模型类。一个代理模型可以继承任意数量的没有定义任何模型字段的抽象模型类。一个代理模型也可以继承任意数量继承相同父类的代理模型。 临时继承TRANSIENT，将父模型作为传输模型使用，并可以添加传输字段。 二、继承约束 通用约束 对于扩展继承，查询的时候，父模型只能查询到父模型字段的数据，子模型可以查询出父模型及子模型的字段数据（因为派生关系所以子模型复刻了一份父模型的字段到子模型中）。 系统不会为抽象基类创建实际的数据库表，它们也没有默认的数据管理器，不能被实例化也无法直接保存，它们就是用来被继承的。抽象基类完全就是用来保存子模型们共有的内容部分，达到重用的目的。当它们被继承时，它们的字段会全部复制到子模型中。 系统不支持非jar包依赖模型的继承。 多表继承具有阻断效应，子模型无法继承多表继承父模型的存储父模型的字段，需要使用@Model.Advanced注解的inherited属性显示声明继承父模型的父模型。但是可以继承多表继承父模型的抽象父模型的字段。 可以使用@Model.Advanced的unInheritedFields和unInheritedFunctions属性设置不从父类继承的字段和函数。 跨模块继承约束 如果模型间的继承是跨模块继承，应该与模型所属模块建立依赖关系；如果模块间有互斥关系，则不允许建立模块依赖关系，同理模型间也不允许存在继承关系。 跨模块代理继承，对代理模型的非inJvm函数调用将使用远程调用方式；跨模块扩展（同表）继承将使用本地调用方式，如果是数据管理器函数，将直连数据源。 模型类型与继承约束 抽象模型可继承：抽象模型（Abstract） 临时模型可继承：抽象模型（Abstract）、传输模型（Transient） 存储模型可继承：抽象模型（Abstract）、存储模型（Store）、存储模型（多表，Multi-table Store），不可继承多个Store或Multi-table Store 多表存储模型（父）可继承：同扩展继承 多表存储模型（子）在继承单个Multi-table Store后可继承：抽象模型（Abstract）、存储模型（Store），不可继承多个Store 代理模型可继承： 抽象模型（Abstract），须搭配继承Store、Multi-table Store或Proxy 存储模型（Store），不可继承多个Store或Multi-table Store 存储模型（多表，Multi-table Store），不可继承多个Store或Multi-table Store 代理模型（Proxy），可继承多个Proxy，但多个父Proxy须继承自同一个Store或Multi-table Store，且不能再继承其他Store或Multi-table Store 同名字段以模型自身字段为有效配置，若模型自身不存在该字段，继承字段以第一个加载的字段为有效配置，所以在多重继承的情况下，未避免继承同名父模型字段的不确定性，在自身模型配置同名字段来确定生效配置。 三、继承的使用场景 模型的继承可以继承父模型的元信息、字段、数据管理器和函数 抽象基类 解决公用字段问题 扩展继承 解决开放封闭原则、跨模块扩展等问题 多表继承 解决多型派生类字段差异问题和前端多存储模型组合外观问题 代理继承 解决同一模型在不同场景下的多态问题（一表多态） 临时继承 解决使用现有模型进行数据传输问题 举例，前端多存储模型组合外观问题可通过多表继承的子模型，并一对一关联到关联模型，同时使用排除继承字段去掉不需要继承的字段。子模型通过默认模型管理器提供查询功能给前端，默认查询会查询子模型数据列表并在列表行内根据一对一关系查出关联模型数据合并，关联模型数据展现形态在行内是平铺还是折叠，在详情是分组还是选项卡可以自定义view进行配置 扩展继承 父子同表，模型在所有场景都有一致化的表现，意味着原模型被扩展成了新模型，父子模型的表名一致，模型编码不同，可覆盖父模型的模型管理器、数据排序规则、函数 多表继承 父子多表，父子间有隐式一对一关系，即父子模型都增加了一对一关联关系字段，同时父模型的字段被引用到子模型，且引用字段为只读字段，意味着子模型不可以直接更改父模型的字段值，子模型不继承父模型的模型管理器、数据排序规则、函数，子模型拥有自己的默认模型管理器、数据排序规则、函数。多表继承具有阻断效应，子模型无法自动多表继承父模型的存储父模型，需要显式声明多表继承父模型的存储父模型。 代理继承 代理模型继承并可覆盖父模型的模型管理器、数据排序规则、函数，同时可以使用排除继承字段和函数来达到不同场景不同视觉交互的效果。 图3-3-4-1 继承的使用场景 四、抽象基类（举例） 参考前文中3.3.2【模型的类型】一文中关于抽象模型的介绍 五、多表继承（举例） 场景设计如下 图3-3-4-2 多表继承设计场景 Step1 新建宠物品种、宠狗品种和萌猫品种模型 新建宠物品种模型，用@Model.MultiTable(typeField = "kind")，申明为可多表继承父类，typeField指定为kind字段 package pro.shushi.pamirs.demo.api.model; import pro.shushi.pamirs.meta.annotation.Field; import pro.shushi.pamirs.meta.annotation.Model; import pro.shushi.pamirs.meta.base.IdModel; @Model.MultiTable(typeField = "kind") @Model.model(PetType.MODEL_MODEL) @Model(displayName="品种",labelFields = {"name"}) public class PetType extends IdModel { public static final String MODEL_MODEL="demo.PetType"; @Field(displayName = "品种名") private String name; @Field(displayName = "宠物分类") private String kind; } 图3-3-4-3 多表继承示例代码 新建宠狗品种模型，用@Model.MultiTableInherited(type = PetDogType.KIND_DOG)，申明以多表继承模式继承PetType，覆盖kind字段(用defaultValue设置默认值，用invisible = true设置为前端不展示)，更多模块元数据以及模型字段元数据配置详见4.1.6【模型之元数据详解】一文 package pro.shushi.pamirs.demo.api.model; import pro.shushi.pamirs.meta.annotation.Field; import pro.shushi.pamirs.meta.annotation.Model; @Model.MultiTableInherited(type = PetDogType.KIND_DOG) @Model.model(PetDogType.MODEL_MODEL) @Model(displayName="宠狗品种",labelFields = {"name"}) public class PetDogType extends PetType { public static final String MODEL_MODEL="demo.PetDogType"; public static final String KIND_DOG="DOG"; @Field(displayName = "宠物分类",defaultValue = PetDogType.KIND_DOG,invisible = true) private String kind; } 图3-3-4-4 多表继承示例代码 新建萌猫品种模型，用@Model.MultiTableInherited(type = PetCatType.KIND_CAT)，申明以多表继承模式继承PetType，覆盖kind字段(用defaultValue设置默认值，用invisible = true设置为前端不展示)，并新增一个CatShapeEnum枚举类型的字段shape package pro.shushi.pamirs.demo.api.enumeration; import pro.shushi.pamirs.meta.annotation.Dict; import pro.shushi.pamirs.meta.common.enmu.BaseEnum; @Dict(dictionary = CatShapeEnum.DICTIONARY,displayName = "萌猫体型") public class CatShapeEnum extends BaseEnum<CatShapeEnum,Integer>…
界面设计器组件管理页面添加组件 进入组件的元件管理页面 点击“添加元件” 设计元件的属性 这里以是否“显示清除按钮”作为自定义属性从左侧拖入到中间设计区域，然后发布 点击“返回组件” 鼠标悬浮到卡片的更多按钮的图标，弹出下拉弹出“低无一体”的按钮 在弹窗内点击“生成SDK”的按钮 生成完成后，点击“下载模板工程” 解压模板工程kunlun-sdk.zip 解压后先查看README.MD，了解一下工程运行要点，可以先运行 npm i 安装依赖 再看kunlun-plugin目录下已经有生成好的组件对应的ts和vue文件 下面在vue文件内增加自定义代码，可以运行 npm run dev 在开发模式下调试看效果 <template> <div class="my-form-string-input"> <oio-input :value="realValue" @update:value="change" > <template #prepend>MyPrepend</template> </oio-input> </div> </template> <script lang="ts"> import { defineComponent, ref } from 'vue'; import { OioInput } from '@kunlun/vue-ui-antd'; export default defineComponent({ name: 'customField1', components: { OioInput }, props: { value: { type: String }, change: { type: Function }, }, setup(props) { const realValue = ref<string | null | undefined>(props.value); return { realValue }; } }); </script> <style lang="scss"> .my-form-string-input { border: 1px solid red; } </style> 确定改好代码后运行 npm run build，生成上传所需的js和css文件 可以看到 kunlun-plugin目录下多出了dist目录，我们需要的是 kunlun-plugin.umd.js 和 kunlun-plugin.css 这2个文件 再次回到组件的“低无一体”管理弹窗页面，上传上面生成的js和css文件，并点击“确定”保存，到这里我们的组件就新增完成了。 下面我们再到页面设计器的页面中使用上面设计的组件（这里的表单页面是提前准备好的，这里就不介绍如何新建表单页面了） 将左侧组件库拉直最底部，可以看到刚刚新建的组件，将其拖至中间设计区域，我们可以看到自定义组件的展示结果跟刚刚的代码是对应上的（ps: 如果样式未生效，请刷新页面查看，因为刚刚上传的js和css文件在页面初始加载的时候才会导入进来，刚刚上传的动作未导入新上传的代码文件），再次点击设计区域中的自定义组件，可以看到右侧属性设置面板也出现了元件设计时拖入的属性。 最后再去运行时的页面查看效果，与代码逻辑一致！
有工作台权限的用户，默认登录页为工作台，也可以通过APP Finder进入工作台。 1. 快捷处理 右上角消息中会气泡展示未处理或未读的操作，点击展开后可以点过去进行快捷处理。 2. 查看、处理流程 2.1 流程查看 流程管理页面共同点： 1包含选项分类筛选 2包含标签筛选 3包含应用下拉选筛选 4包含根据流程名称搜素 流程管理页面名词解释： 待办：当前登录用户未处理的流程节点 我发起的：当前登录用户人为触发的流程（模型触发） 抄送：抄送给当前登录用户的节点（审批/填写） 我已办结：由当前登录用户完成人工/自动同意、人工拒绝或人工填写的节点 无需办理：当前登录用户转交的任务/被退回、被撤销、被或签、被其他分支任务拒绝的还未办理的任务 站内信：当前登录用户收到的站内信 2.2 流程处理 每条流程数据下方有动作，点击进入流程处理页面，大致分为详情页和操作页。 待办中点击“审批/填写”会进入流程操作页。审批操作页可能包含“同意、拒绝、退回、加签、转交、返回”，填写操作页可能包含“提交、暂存”，审批操作页包含哪些动作由流程设计决定。 我发起的、抄送、我已办结、无需处理点击“查看”会进入流程详情页。 3. 应用快捷入口 应用中心中星标的收藏应用会展示在此处，点击可快捷进入应用。 应用中心中已安装的应用点击星标即可收藏。
