当流程节点需要向用户发送消息或提示时使用站内信这个节点动作。接收人的选取类似审批节点的审批人，通知内容必填，配置完成，保存即可。
节点触发后，接收人会在全渠道运营平台-工作台-我的消息中查看到站内信。
当需要向指定邮箱发送邮件时使用邮件这个节点动作。可直接输入邮箱号，或者按照员工、部门、角色来选择，给接收人登记的邮箱发送邮件，也可以选择模型中的邮箱来发送邮件，若人员重复时只会发送一次邮件。填写主题，填写正文时可以调用当前流程中的一些模型字段的变量。
发送短信需要在工作流-系统设置-短信模板中创建一个短信模板，阿里云模版新增需要一段时间审核，审核通过后就可以正常使用短信节点。短信的接收人与邮件的操作方式一致，之后选择短信模板，并且确定好变量的对应关系即可。
Oinone社区 作者：史, 昂原创文章，如若转载，请注明出处：https://doc.oinone.top/oio4/9417.html
访问Oinone官网:https://www.oinone.top获取数式Oinone低代码应用平台体验
如果把互联网架构比作社会主义，Oinone就是也要做有中国特色的社会主义，才能符合国情。 随着业务和生态的发展，企业对效率、性能、体验和智能化等方面的要求越来越高，但很多企业的系统面临着严重的系统架构落后和系统间割裂等问题，这些问题导致原有系统在业务发展下面临着效率和性能的双重挑战。与此同时，互联网平台的技术水平远远领先于传统企业系统，但是是否可以直接将互联网架构照搬到企业数字化转型中呢？显然，这是不合适的，因为互联网架构在企业数字化转型中面临着许多水土不服的问题。本章节将结合互联网中台架构的发展，分析这些问题的原因。 借鉴互联网中台理念 我们要先看互联网架构的发展，是如何一步步到今天提的中台架构概念的，每一步又解决了什么具体问题，我们以阿里架构变迁史为例来看下（如下图2-2所示）： 图2-2 阿里架构变迁史 在2009年，淘宝上线了五彩石项目，这标志着淘宝从单体应用向服务化应用的时代迈出了一步。那么，淘宝为什么要开发五彩石项目呢？因为当时淘宝面临两个非常严峻的问题，一个是性能问题，数据库连接不足，数据库成为了瓶颈；另一个是效率问题，当时淘宝有百余个研发人员，但核心系统只有一套测试、预发、线上环境，导致研发需求排队等待。在开始五彩石项目之前，淘宝还做了千岛湖项目，用来验证服务化架构的可行性，将用户中心独立出来。随后，淘宝开启了五彩石项目，目标是通过增加人力来提升效率，通过增加机器来提升性能。 随着淘宝的业务发展，他们又面临了一个问题：各个服务之间有很多重复的建设，效率低下。为了解决这个问题，淘宝开始从服务化转向平台化，并创立了“共享业务事业部”，将重复建设的公共业务分配给这个事业部，以避免成本浪费。这些公共业务包括商品平台、交易平台和结算平台等。平台化的目标是规避服务化没有规划导致的重复建设问题。 但是随着业务的快速发展，淘宝变成了一个拥有几十个事业部的巨型企业，而这带来了新的问题：效率问题。例如，如果需要在一个业务线上做出改动，需要与十几个平台进行沟通，这是非常低效的。同时，对于一个平台来说，需要面对来自不同事业部的需求，这需要平台研发人员具备理解和抽象所有业务线需求的能力，这让平台研发人员感觉回到了单体应用时代，所有的需求都要排队，即使增加人力也无法提高效率。这个问题主要表现在交易平台上。 为了解决这个问题，淘宝提出了中台的概念，中台是在一套规范下建立的，让具有专业技能的团队自主决策业务系统发展的平台。中台的目标是弱化平台的业务特性，提供通用能力。简而言之，就是将“共享业务”中的“业务”两个字去掉，只提供通用能力的平台 我们将每个阶段的核心目标总结为一句话： 从单体到服务：通过增加人员和机器来提高效率和性能； 从服务化到平台化：解决服务化阶段因缺乏规划而导致的重复建设问题； 平台化到中台化：在一套规范下，让各业务团队自行决定业务系统发展，适用于多个业务线或多个场景应用的独立发展。 类似地，在企业数字化转型过程中，也面临着类似的问题： 随着企业业务在线化，对系统性能和稳定性提出了更高的要求，但由于内部系统之间的割裂，导致很多重复建设。因此，我们需要进行服务化和平台化； 没有一个供应商能够解决企业所有的商业场景问题，所以需要多个供应商共同参与。我们可以将供应商类比为各业务线，在一套规范下让供应商或业务线自行决定业务系统的发展。 然而，阿里的中台架构方案并不能直接照搬到企业中。因为阿里的中台架构采用了平台共建模式，即让业务线基于平台设计的规范共同开发。这本质上还是平台主导模式，对企业来说历史包袱较大。在企业中，让不同背景的研发一起共建交易或商品平台是非常复杂的事情。平台化已经足够复杂，再加上共建会导致企业架构的负载过重，这对企业来说就不再是赋能，而是“内耗”。 互联网中台架构在企业实践中遇到的问题 在1.3《Oinone的生态思考》一文中，《与中台的渊源》部分提到，在阿里云为企业提供数字化项目时，客户经常会对以下三个问题提出质疑，这些问题非常突出： 1我们听说你们具备敏捷响应能力，但为什么改动需求如此缓慢？不仅所需时间更长，而且成本更高？ 2我们听说你们有能力中心，但为什么当我们引入新供应商或开发新场景时，前期建立的能力中心无法支持我们？ 3我们听说你们的性能很好，但为什么我们需要投入更多的物理资源来支持项目？ 在探讨互联网架构的适用性时，我想提出以下两个问题： 1企业应用程序的性能问题是否与互联网平台公司遇到的性能问题相同？ 2企业应用程序的开发效率问题是否与互联网平台公司遇到的效率问题相同？ 通过比较企业和互联网之间的差异，我们可以了解水土不服的核心原因。 企业 互联网 企业IT组织能力无法与数字化转型的速度匹配，缺乏足够的人才支持。为了提高开发效率，企业需要寻找工具和技术来降低开发难度，同时提高个人开发效率 互联网企业拥有众多优秀的人才，需要解决团队协作和知识共享的问题，即协同开发的效率。 企业无法制定并主导技术规范，这导致了能力复用的不足。为了提高效率和减少开发成本，企业需要建立统一的技术规范和标准，以便能力复用和组织协同。 互联网企业可以自定义技术规范，因此能力复用更易于保障。 企业往往当前业务量相对小，期望数字化建设能打动业务发展，对业务发展的预期比较高，所以企业的诉求是即满足当下成本效应又能兼顾未来对发展预期 互联网企业起步时的系统目标负载就高，通常会忽略资源起步门槛的问题，当然也可以通过自动扩容、云计算等方式来解决初期的负载问题。 表2-1从企业与互联网的对比，看水土不服的核心原因 我们可以看到企业和互联网架构在很多方面存在着不同的需求和问题。因此，在提供数字化服务时，Oinone需要注意与企业的组织能力进行匹配，并根据企业自身的特性来提供在线化的服务能力。这就像在社会主义制度下需要有中国特色一样，Oinone也需要有适合中国企业的特色。
PamirsPartner作为商业关系与商业行为的主体，那么PamirsPartner间的关系如何描述，本文将介绍两种常见的设计思路，从思维和实现两方面进行对比，给出oinone为啥选择关系设计模式的原因。 一、两种设计模式对比 设计模式思路介绍 角色设计模式思路介绍 从产品角度枚举所有商业角色，每个商业角色对应一个派生的商业主体，并把主体间的关系类型进行整理。 图5-4-1 角色设计模式 关系设计模式思路介绍 从产品角度枚举所有商业角色，每个商业角色对应一个派生的主体间商业关系 图5-4-2 关系设计模式 设计模式对应实现介绍 角色设计模式实现介绍 不单商业主体需要扩展，关系也要额外维护，可以是字段或是关系表。一般M2O和O2M字段维护，M2M关系表维护。 创建合同场景中甲方选择【商业主体A】，乙方必须是【商业主体A】有关联的经销商、分销商、零售商、供应商等，则在角色设计模式下就非常麻烦，因为关系都是独立维护的 图5-4-3 角色设计模式实现介绍 关系设计模式实现介绍 只需维护商业关系扩展 同时在设计上收敛了商业关系，统一管理应对不同场景都比较从容 图5-4-4 关系设计模式实现介绍 二、oinone商业关系的默认实现 首先oinone的商业关系选择关系设计模式 其次模型上采用多表继承模式，父模型上维护核心字段，子模型维护个性化字段。
枚举是大家在系统开发中经常用的一种类型，在oinone中也对枚举类型进行了支持，同时也做了相应的加强。希望通过本文能让大家对枚举的使用，有更全面的认知 一、枚举系统与数据字典 枚举是列举出一个有穷序列集的所有成员的程序。在元数据中，我们使用数据字典进行描述。 协议约定 枚举需要实现IEnum接口和使用@Dict注解进行配置，通过配置@Dict注解的dictionary属性来设置数据字典的唯一编码。前端使用枚举的displayName来展示，枚举的name来进行交互；后端使用枚举的value来进行交互（包括默认值设置也使用枚举的value）。 枚举会存储在元数据的数据字典表中。枚举分为两类：1.异常类；2.业务类。异常类枚举用于定义程序中的错误提示，业务类枚举用于定义业务中某个字段值的有穷有序集。 编程式用法 图3-3-6-1 编程式用法 如果一个字段的类型被定义为枚举，则该字段就可以使用该枚举来进行可选项约束（options）。该字段的可选项为枚举所对应数据字典的子集。 可继承枚举 继承BaseEnum可以实现java不支持的继承枚举。同时可继承枚举也可以用编程式动态创建枚举项。 可继承枚举也可以兼容无代码枚举。 图3-3-6-2 可继承枚举 二进制枚举 可以通过@Dict注解设置数据字典的bit属性或者实现BitEnum接口来标识该枚举值为2的次幂。 二、enum不可继承枚举（举例） 我们在介绍抽象基类中AbstractDemoCodeModel和AbstractDemoIdModel就引入了数据状态(DataStatusEnum)字段，并设置了必填和默认值为DISABLED。DataStatusEnum实现了IEnum接口,并用@Dict(dictionary = DataStatusEnum.dictionary, displayName = "数据状态")进行了注解。为什么不能继承呢？因为JAVA语言的限制导致enum是不可继承的 package pro.shushi.pamirs.core.common.enmu; import pro.shushi.pamirs.meta.annotation.Dict; import pro.shushi.pamirs.meta.common.enmu.IEnum; @Dict(dictionary = DataStatusEnum.dictionary, displayName = "数据状态") public enum DataStatusEnum implements IEnum<String> { DRAFT("DRAFT", "草稿", "草稿"), NOT_ENABLED("NOT_ENABLED", "未启用", "未启用"), ENABLED("ENABLED", "已启用", "已启用"), DISABLED("DISABLED", "已禁用", "已禁用"); public static final String dictionary = "partner.DataStatusEnum"; private String value; private String displayName; private String help; DataStatusEnum(String value, String displayName, String help) { this.value = value; this.displayName = displayName; this.help = help; } public String getValue() { return value; } public String getDisplayName() { return displayName; } public String getHelp() { return help; } } 图3-3-6-3 不可继承枚举 三、BaseEnum可继承枚举（举例） Step1 新增CatShapeExEnum继承CatShapeEnum枚举 package pro.shushi.pamirs.demo.api.enumeration; import pro.shushi.pamirs.meta.annotation.Dict; @Dict(dictionary = CatShapeExEnum.DICTIONARY,displayName = "萌猫体型Ex") public class CatShapeExEnum extends CatShapeEnum { public static final String DICTIONARY ="demo.CatShapeExEnum"; public final static CatShapeExEnum MID =create("MID",3,"中","中"); } 图3-3-6-4 新增CatShapeExEnum继承CatShapeEnum枚举 Step2 修改PetCatType的shape字段类型为CatShapeExEnum package pro.shushi.pamirs.demo.api.model; import pro.shushi.pamirs.demo.api.enumeration.CatShapeExEnum; import pro.shushi.pamirs.meta.annotation.Field; import pro.shushi.pamirs.meta.annotation.Model; @Model.MultiTableInherited(type = PetCatType.KIND_CAT) @Model.model(PetCatType.MODEL_MODEL) @Model(displayName="萌猫品种",labelFields = {"name"}) public class PetCatType extends PetType { public static final String MODEL_MODEL="demo.PetCatType"; public static final String KIND_CAT="CAT"; @Field(displayName = "宠物分类",defaultValue…
1. 创建用户 进入用户中心应用，在用户列表中点击创建。 填写表单中的必填信息。 若未设置昵称，则右上角头像右侧展示名称。若设置了昵称，则右上角头像右侧展示昵称。 是否激活账号选择是，选择否时用户登录会显示“未找到首页”。 角色分组中，选择创建的用户的角色，默认选择了超级管理员（包含所有权限）。 点击确定，用户创建完成。 用户登录时可用登录账号/邮箱/手机号登录。 2. 用户相关操作 表格页中包含常规的搜索、批量删除功能。 冻结：当将“是否有效”状态为“是”时展示，将用户“是否有效”修改为“否”。 解冻：当将“是否有效”状态为“否”时展示，将用户“是否有效”修改为“是”。 修改：进入用户信息修改页面，“编码、登录账号、注册时间”只读。 重置密码：点击后在弹窗“账号确认”中输入账号，点击重置密码后，展示新密码。
