当流程节点需要向用户发送消息或提示时使用站内信这个节点动作。接收人的选取类似审批节点的审批人，通知内容必填，配置完成，保存即可。
节点触发后，接收人会在全渠道运营平台-工作台-我的消息中查看到站内信。
当需要向指定邮箱发送邮件时使用邮件这个节点动作。可直接输入邮箱号，或者按照员工、部门、角色来选择，给接收人登记的邮箱发送邮件，也可以选择模型中的邮箱来发送邮件，若人员重复时只会发送一次邮件。填写主题，填写正文时可以调用当前流程中的一些模型字段的变量。
发送短信需要在工作流-系统设置-短信模板中创建一个短信模板，阿里云模版新增需要一段时间审核，审核通过后就可以正常使用短信节点。短信的接收人与邮件的操作方式一致，之后选择短信模板，并且确定好变量的对应关系即可。
Oinone社区 作者：史, 昂原创文章，如若转载，请注明出处：https://doc.oinone.top/oio4/9417.html
访问Oinone官网:https://www.oinone.top获取数式Oinone低代码应用平台体验
随着数据库技术的发展如分区设计、分布式数据库等，业务层的分库分表的技术终将成老一辈程序员的回忆，谈笑间扯扯蛋既羡慕又自吹地说到“现在的研发真简单，连分库分表都不需要考虑了”。竟然这样为什么要写这篇文章呢？因为现今的数据库虽能解决大部分场景的数据量问题，但涉及核心业务数据真到过亿数据后性能加速降低，能给的方案都还有一定的局限性，或者说性价比不高。相对性价比比较高的分库分表，也会是现阶段一种不错的补充。言归正传oinone的分库分表方案是基于Sharding-JDBC的整合方案，所以大家得先具备一点Sharding-JDBC的知识。 一、分表（举例） 做分库分表前，大家要有一个明确注意的点就是分表字段的选择，它是非常重要的，与业务场景非常相关。在明确了分库分表字段以后，甚至在功能上都要做一些妥协。比如分库分表字段在查询管理中做为查询条件是必须带上的，不然效率只会更低。 Step1 新建ShardingModel模型 ShardingModel模型是用于分表测试的模型，我们选定userId作为分表字段。分表字段不允许更新，所以这里更新策略设置类永不更新，并在设置了在页面修改的时候为readonly package pro.shushi.pamirs.demo.api.model; import pro.shushi.pamirs.boot.base.ux.annotation.field.UxWidget; import pro.shushi.pamirs.boot.base.ux.annotation.view.UxForm; import pro.shushi.pamirs.meta.annotation.Field; import pro.shushi.pamirs.meta.annotation.Model; import pro.shushi.pamirs.meta.enmu.FieldStrategyEnum; @Model.model(ShardingModel.MODEL_MODEL) @Model(displayName = "分表模型",summary="分表模型",labelFields ={"name"} ) public class ShardingModel extends AbstractDemoIdModel { public static final String MODEL_MODEL="demo.ShardingModel"; @Field(displayName = "名称") private String name; @Field(displayName = "用户id",summary = "分表字段",immutable=true/* 不可修改 **/) @UxForm.FieldWidget(@UxWidget(readonly = "scene == 'redirectUpdatePage'"/* 在编辑页面只读 **/ )) @Field.Advanced(updateStrategy = FieldStrategyEnum.NEVER) private Long userId; } 图4-1-24-1 新建ShardingModel模型 Step2 配置分表策略 配置ShardingModel模型走分库分表的数据源pamirsSharding 为pamirsSharding配置数据源以及sharding规则 a. pamirs.sharding.define用于oinone的数据库表创建用 b. pamirs.sharding.rule用于分表规则配置 pamirs: load: sessionMode: true framework: system: system-ds-key: base system-models: – base.WorkerNode data: default-ds-key: pamirs ds-map: base: base modelDsMap: "[demo.ShardingModel]": pamirsSharding #配置模型对应的库 图4-1-24-2 指定模型对应数据源 pamirs: sharding: define: data-sources: ds: pamirs pamirsSharding: pamirs #申明pamirsSharding库对应的pamirs数据源 models: "[trigger.PamirsSchedule]": tables: 0..13 "[demo.ShardingModel]": tables: 0..7 table-separator: _ rule: pamirsSharding: #配置pamirsSharding库的分库分表规则 actual-ds: – pamirs #申明pamirsSharding库对应的pamirs数据源 sharding-rules: # Configure sharding rule ，以下配置跟sharding-jdbc配置一致 – tables: demo_core_sharding_model: #demo_core_sharding_model表规则配置 actualDataNodes: pamirs.demo_core_sharding_model_${0..7} tableStrategy: standard: shardingColumn: user_id shardingAlgorithmName: table_inline shardingAlgorithms: table_inline: type: INLINE props: algorithm-expression: demo_core_sharding_model_${(Long.valueOf(user_id) % 8)} props: sql.show: true 图4-1-24-3 分库分表规则配置 Step3 配置测试入口 修改DemoMenus类增加一行代码，为测试提供入口 @UxMenu("分表模型")@UxRoute(ShardingModel.MODEL_MODEL) class ShardingModelMenu{} 图4-1-24-4 配置测试入口 Step4 重启看效果 自行尝试增删改查 观察数据库表与数据分布 图4-1-24-5 自行尝试增删改查 图4-1-24-6 观察数据库表与数据分布 二、分库分表（举例） Step1 新建ShardingModel2模型 ShardingModel2模型是用于分库分表测试的模型，我们选定userId作为分表字段。分库分表字段不允许更新，所以这里更新策略设置类永不更新，并在设置了在页面修改的时候为readonly package pro.shushi.pamirs.demo.api.model; import pro.shushi.pamirs.boot.base.ux.annotation.field.UxWidget; import pro.shushi.pamirs.boot.base.ux.annotation.view.UxForm; import…
库存的差异会反馈到企业的整个价值链上，所以对库存的设计是至关重要的 一、基础介绍 我们先抛开仓库中对库存的实操管理和整个流通领域的库存，只围绕企业自身一级的采销链路上我们可以从管理和销售两个角度去看。 从管理角度上我们会关心：实物库存、在途库存、在产库存、库存批次等等，也就是企业有多少库存分布在哪里在什么环节。 从销售角度上我们会关心：可售库存、安全库存等等，也就是企业在特定渠道销售中库存分配规则。 在商业场景中库存管理一头对接仓库、生成、采购，另一头对接多个销售渠道。它的挑战在于不同行业不同特征商品都有比较大的差异。比如家具行业卖的是生产能力，家电区域化销售，生鲜拼车销售，服饰一仓销全国。热销的要分配提升体验防止超卖，滞销的要活动拉流量，普通的要渠道共享最大化可售。库存管理的差异会反馈到企业的整个价值链上，所以对库存的设计是至关重要的。 库存设计挑战在于： 技术上：库存类似账户账本的设计，需要能追溯库存变化的过程，且库存操作都能可追溯业务单据。热点数据的并发控制 业务上：在管理角度上游能跟仓库、采购、生产等进行对接、对账、并为其设置可售规则，下游能为各个销售渠道设置库存分配与同步规则 二、模型介绍 图5-7-1 模型介绍 核心设计逻辑： 单据链路：业务单据（外部业务单据+库存业务单据）产生库存指令（库存调整入\出库单），再由库存指令操作库存并记录库存流水。 管理链路：基础数据维护仓库、供应商、服务范围与费用。这些数据是订单履约路由和可售库存同步的基础 库存数据：对外跟商品域，通过库存指令进行操作。不同库存各自维护自身库存与流水记录，确保可追溯。 如果跟销售渠道对接，还需要扩展可售库存逻辑规则以及同步规则。比如oms类似的应用
1. 什么是数据字典 数据字典是一些固定字典项的集合，可作为多选或单选的选项，例如人员性别、员工属相、杭州市下属的行政区等都是数据字典。 选择一个应用/模块下的一个小模块，可以查看其中包含的自定义字典（自建的数据字典）和系统字典。可以通过导入或添加创建自定义字典。 2. 数据字典基本操作 删除：系统字典不支持删除，无法批量删除自定义数据字典，若数据字典已经被字段、页面等引用时，也无法删除这个数据字典。 隐藏/可见：自定义字典、系统字典都可以操作隐藏和可见，隐藏和可见不影响数据字典在字段、页面等处的使用。 查看引用关系：点击查看引用关系，展开弹窗，展示该数据字典和字段、视图的引用关系。 修改：若数据字典已经被引用，无法删除其中的字典项。若无引用关系则可以任意修改。 3. 数据字典导入 点击“导入数据字典”按钮，弹出窗口，可根据图中引导进行数据字典的导入。 在经典模式下，导入数据字典会新建数据字典。 在专家模式下，数据字典导入的模板中包含字段“字典编码”，若导入的字典编码不存在则会新建数据字典，若导入的字典编码已存在则会修改字典编码的设置，新建和修改的动作会校验是否符合规范。 4. 数据字典创建 4.1 专家模式（低代码模式） 字典项类型有“二进制、文本、整数”三种可选，选择二进制时，字典项值需要选择存储在数据库二进制中的第几位。系统根据字典项值去查找字典项名称，因此字典项值不可重复。 数据字典的api名称、代码名称、描述可不填，部分系统会赋默认值。 字典项中字典项名称和字典项值必填，api名称和字典项描述不填系统会赋默认值。 4.2 经典模式（无代码模式） 经典模式下只需要填写字典名称，添加字典项即可。系统会自动将字典项类型设置为“二进制”，并将字典项按照创建的先后顺序设置字典项值的位数。字典项类型、字典项值释义可参照专家模式的解释。
导入导出在一定程度上是企业级软件和效率工具（office工具）的桥梁 文件的上传下载以及业务数据的导入导出是企业级软件一个比较常规的需求，甚至是巨量的需求。业务有管理需要一般都伴随有导入导出需求，导入导出在一定程度上是企业级软件和效率工具（office工具）的桥梁。oinone的文件模块就提供了通用的导入导出实现方案，以简单、一致、可扩展为目标，简单是快速入门，一致是用户操作感知一致、可扩展是满足用户最大化的自定义需求。 下图为文件导入导出的实现示意图，大家可以做一个整体了解 图6-1-1 文件导入导出实现示意图 一、基础能力 准备工作 pamirs-demo-api的pom文件中引入pamirs-file2-api包依赖 <dependency> <groupId>pro.shushi.pamirs.core</groupId> <artifactId>pamirs-file2-api</artifactId> </dependency> 图6-1-2 引入pamirs-file2-api包依赖 DemoModule增加对FileModule的依赖 @Module(dependencies = {FileModule.MODULE_MODULE}) 图6-1-3 DemoModule增加对FileModule的依赖 pamirs-demo-boot的pom文件中引入pamirs-file2-core包依赖 <dependency> <groupId>pro.shushi.pamirs.core</groupId> <artifactId>pamirs-file2-core</artifactId> </dependency> 图6-1-4 启动工程引入pamirs-file2-core包依赖 pamirs-demo-boot的application-dev.yml文件中增加配置pamirs.boot.modules增加file，即在启动模块中增加file模块 pamirs: boot: modules: – file 图6-1-5 pamirs-demo-boot的application-dev.yml文件中增加配置 pamirs-demo-boot的application-dev.yml文件中增加oss的配置。更多有关文件相关配置详见4.1.1【模块之yml文件结构详解】一文 cdn: oss: name: 阿里云 type: OSS bucket: demo uploadUrl: #换成自己的oss上传服务地址 downUrl: #换成自己的oss下载服务地址 accessKeyId: #阿里云oss的accessKeyId accessKeySecret: #阿里云oss的accessKeySecret mairDir: upload/demo #换成自己的目录 validTime: 360000 timeout: 60000 active: true referer: www.shushi.pro 图6-1-6 application-dev.yml文件中增加oss的配置 其他文件系统支持 a. 文件系统类型 类型 服务 OSS 阿里云 UPYUN 又拍云 MINIO Minio HUAWEI_OBS 华为云 LOCAL 本地文件存储 表6-1-1 支持的文件系统类型 b. OSS配置示例 ⅰ. 华为云OBS cdn: oss: name: 华为云 type: HUAWEI_OBS bucket: pamirs #(根据实际情况修改) uploadUrl: obs.cn-east-2.myhuaweicloud.com downloadUrl: obs.cn-east-2.myhuaweicloud.com accessKeyId: 你的accessKeyId accessKeySecret: 你的accessKeySecret # 根据实际情况修改 mainDir: upload/ validTime: 3600000 timeout: 600000 active: true allowedOrigin: http://192.168.95.31:8888,https://xxxx.xxxxx.com referer: 图6-1-7 OBS的配置说明 ⅱ. MINIO cdn: oss: name: minio type: MINIO bucket: pamirs #(根据实际情况修改) uploadUrl: http://192.168.243.6:32190 #(根据实际情况修改) downloadUrl: http://192.168.243.6:9000 #(根据实际情况修改) accessKeyId: 你的accessKeyId accessKeySecret: 你的accessKeySecret # 根据实际情况修改 mainDir: upload/ validTime: 3600000 timeout: 600000 active: true referer: localFolderUrl: 图6-1-8 MINIO的配置说明 ⅲ. 又拍云 cdn: oss: name: 又拍云 type: UPYUN bucket: pamirs #(根据实际情况修改) uploadUrl: v0.api.upyun.com downloadUrl: v0.api.upyun.com accessKeyId: 你的accessKeyId accessKeySecret: 你的accessKeySecret # 根据实际情况修改 mainDir: upload/ validTime: 3600000 timeout: 600000…
