函数（Function）：是oinone可管理的执行逻辑单元，跟模型绑定则对应模型的方法
描述满足数学领域函数定义，含有三个要素：定义域A、值域C{f（x），x属于A}和对应法则f。其中核心是对应法则f，它是函数关系的本质特征
满足面向对象原则，可设置不同开放级别，本地与远程智能切换。
本章会带大家更加详细地了解Function的方方面面，主要以几下几个维度
构建第一个Function
函数的开放级别与类型
函数的相关特性
函数元数据详解
Oinone社区 作者：史, 昂原创文章，如若转载，请注明出处：https://doc.oinone.top/oio4/9242.html
访问Oinone官网:https://www.oinone.top获取数式Oinone低代码应用平台体验
一、事务管理介绍 函数Function支持事务字段为isTransaction（默认为false），事务传播行为propagationBehavior（默认PROPAGATION_SUPPORTS），事务隔离级别isolationLevel（默认使用数据库默认的事务隔离级别），所以不会默认为函数添加事务。另外事务配置提供全局配置。 平台事务管理兼容Spring声明式与编程式事务，支持多数据源事务管理。事务管理中多数据源嵌套独立事务，不会造成死锁风险。使用多数据源或分表操作，不会导致脏读。如果需要多数据源分布式事务，请使用PamirsTransational分布式事务管理方案（@PamirsTransational(enableXa=true)）。分布式事务一般用于量小的跨模块配置管理场景 使用方式 声明式事务，使用@PamirsTransactional注解在需要事务管理的类或方法上标注。在非无代码场景下，与@Transactional注解功能一致。 编程式事务，使用PamirsTransactionTemplate即可。在非无代码场景下，与TransactionTemplate功能一致。 配置式事务，使用TxConfig模型在模块安装时初始化存储事务配置数据。 事务特性 原子性 （atomicity）:强调事务的不可分割. 一致性 （consistency）:事务的执行的前后数据的完整性保持一致. 隔离性 （isolation）:一个事务执行的过程中,不应该受到其他事务的干扰 持久性（durability） :事务一旦结束,数据就持久到数据库 事务隔离级别 事务隔离级别指的是一个事务对数据的修改与另一个并行的事务的隔离程度，当多个事务同时访问相同数据时，如果没有采取必要的隔离机制，就可能发生以下问题： 问题 描述 脏读 一个事务读到另一个事务未提交的更新数据，所谓脏读，就是指事务A读到了事务B还没有提交的数据，比如银行取钱，事务A开启事务，此时切换到事务B，事务B开启事务–>取走100元，此时切换回事务A，事务A读取的肯定是数据库里面的原始数据，因为事务B取走了100块钱，并没有提交，数据库里面的账务余额肯定还是原始余额，这就是脏读 不可重复读 在一个事务里面的操作中发现了未被操作的数据 比方说在同一个事务中先后执行两条一模一样的select语句，期间在此次事务中没有执行过任何DDL语句，但先后得到的结果不一致，这就是不可重复读 幻读 是指当事务不是独立执行时发生的一种现象，例如第一个事务对一个表中的数据进行了修改，这种修改涉及到表中的全部数据行。 同时，第二个事务也修改这个表中的数据，这种修改是向表中插入一行新数据。那么，以后就会发生操作第一个事务的用户发现表中还有没有修改的数据行，就好象 发生了幻觉一样。 表4-1-8-1 事务隔离级别 Pamirs（Spring）支持的隔离级别 隔离级别 描述 DEFAULT 使用数据库本身使用的隔离级别 ORACLE（读已提交） MySQL（可重复读） READ_UNCOMITTED 读未提交（脏读）最低的隔离级别，一切皆有可能。 READ_COMMITED 读已提交，ORACLE默认隔离级别，有不可重复读以及幻读风险。 REPEATABLE_READ 可重复读，解决不可重复读的隔离级别，但还是有幻读风险。 SERLALIZABLE 串行化，最高的事务隔离级别，不管多少事务，挨个运行完一个事务的所有子事务之后才可以执行另外一个事务里面的所有子事务，这样就解决了脏读、不可重复读和幻读的问题了 表4-1-8-2 隔离级别与描述 隔离级别 脏读可能性 不可重复读可能性 幻读可能性 加锁度 READ_UNCOMITTED 是 是 是 否 READ_COMMITED 否 是 是 否 REPEATABLE_READ 否 否 是 否 SERLALIZABLE 否 否 否 是 表4-1-8-3 隔离级别说明表 事务的传播行为 保证同一个事务中 PROPAGATION_REQUIRED 支持当前事务，如果不存在 就新建一个(默认) PROPAGATION_SUPPORTS 支持当前事务，如果不存在，就不使用事务 PROPAGATION_MANDATORY 支持当前事务，如果不存在，抛出异常 保证没有在同一个事务中 PROPAGATION_REQUIRES_NEW 如果有事务存在，挂起当前事务，创建一个新的事务 PROPAGATION_NOT_SUPPORTED 以非事务方式运行，如果有事务存在，挂起当前事务 PROPAGATION_NEVER 以非事务方式运行，如果有事务存在，抛出异常 PROPAGATION_NESTED 如果当前事务存在，则嵌套事务执行 A中嵌套B事务，嵌套PROPAGATION_REQUIRES_NEW方法勿与A在同类中。 异常状态 PROPAGATION_REQUIRES_NEW （两个独立事务） PROPAGATION_NESTED (B的事务嵌套在A的事务中) PROPAGATION_REQUIRED (同一个事务) A抛异常 B正常 A回滚，B正常提交 A与B一起回滚 A与B一起回滚 A正常 B抛异常 1.如果A中捕获B的异常，并没有继续向上抛异常，则B先回滚，A再正常提交； 2.如果A未捕获B的异常，默认则会将B的异常向上抛，则B先回滚，A再回滚 B先回滚，A再正常提交 A与B一起回滚 A抛异常B抛异常 B先回滚，A再回滚 A与B一起回滚 A与B一起回滚 A正常 B正常 B先提交，A再提交 A与B一起提交 A与B一起提交 表4-1-8-4 事务传播行为 二、声明式事务（举例） Step1 修改PetShopBatchUpdateAction 用@PamirsTransactional或者@Transactional注解来声明事务，PamirsTransactional跟Spring的Transactional区别在于PamirsTransactional支持多库事务，但此多库事务为非严格的分布式多库事务，之所以选择这个方案，原因如下 a. 不损害任何性能。 b. 事务保障率超过4个9 c. 经过阿里的大厂验证，特别是在阿里的结算平台中得到了很好的验证 @PamirsTransactional更多配置项请详见4.1.7【函数之元数据详解】一文，自己多试试。同时@PamirsTransactional百分百兼容@Transactional @Action(displayName = "确定",bindingType = ViewTypeEnum.FORM,contextType = ActionContextTypeEnum.SINGLE) @PamirsTransactional //@Transactional public PetShopBatchUpdate conform(PetShopBatchUpdate data){ if(data.getPetShopList() == null || data.getPetShopList().size()==0){ throw PamirsException.construct(DemoExpEnumerate.PET_SHOP_BATCH_UPDATE_SHOPLIST_IS_NULL).errThrow(); } List<PetShopProxy> proxyList = data.getPetShopList(); for(PetShopProxy petShopProxy:proxyList){ petShopProxy.setDataStatus(data.getDataStatus()); } new PetShopProxy().updateBatch(proxyList); throw PamirsException.construct(DemoExpEnumerate.SYSTEM_ERROR).errThrow(); // return data; } 图4-1-8-1 修改PetShopBatchUpdateAction Step2 重启看效果 进入店铺管理列表页，选择记录点击【批量更新数据状态】按钮，修改记录的数据状态为【未启用】，提交看效果。期望效果为：提示系统异常，数据修改失败 图4-1-8-2 数据状态显示已启用 图4-1-8-3 批量更新数据状态…
在业务应用中我们经常需要为一些核心数据的变更做审计追踪，记录字段的前后变化、操作IP、操作人、操作地址等等。数据审计模块为此提供了支撑和统一管理。它在成熟的企业的核心业务系统中，需求是比较旺盛的。接下来我们开始学习下数据审计模块 准备工作 pamirs-demo-core的pom文件中引入pamirs-data-audit-api包依赖 <dependency> <groupId>pro.shushi.pamirs.core</groupId> <artifactId>pamirs-data-audit-api</artifactId> </dependency> pamirs-demo-boot的pom文件中引入pamirs-data-audit-core和pamirs-third-party-map-core包依赖，数据审计会记录操作人的地址信息，所以也依赖了pamirs-third-party-map-core <dependency> <groupId>pro.shushi.pamirs.core</groupId> <artifactId>pamirs-data-audit-core</artifactId> </dependency> <dependency> <groupId>pro.shushi.pamirs.core.map</groupId> <artifactId>pamirs-third-party-map-core</artifactId> </dependency> pamirs-demo-boot的application-dev.yml文件中增加配置pamirs.boot.modules增加data_audit 和third_party_map，即在启动模块中增加data_audit和third_party_map模块 pamirs: boot: modules: – data_audit – tp_map 为third_party_map模块增加高德接口api，下面e439dda234467b07709f28b57f0a9bd5换成自己的key pamirs: eip: map: gd: key: e439dda234467b07709f28b57f0a9bd5 数据审计 注解式（举例） Step1 新增PetTalentDataAudit数据审计定义类 package pro.shushi.pamirs.demo.core.init.audit; import pro.shushi.pamirs.data.audit.api.annotation.DataAudit; import pro.shushi.pamirs.demo.api.model.PetTalent; @DataAudit( model = PetTalent.MODEL_MODEL,//需要审计的模型 modelName = "宠物达人" ,//模型名称，默认模型对应的displayName //操作名称 optTypes = {PetTalentDataAudit.PETTALENT_CREATE,PetTalentDataAudit.PETTALENT_UDPATE}, fields={"nick","picList.id","picList.url","petShops.id","petShops.shopName"}//需要审计的字段,关系字段用"."连结 ) public class PetTalentDataAudit { public static final String PETTALENT_CREATE ="宠物达人创建"; public static final String PETTALENT_UDPATE ="宠物达人修改"; Step2 修改PetTalentAction的update方法 做审计日志埋点:手工调用 OperationLogBuilder.newInstance().record()方法。需要注意的是这里需要把原有记录的数据值先查出来做对比 @Function.Advanced(type= FunctionTypeEnum.UPDATE) @Function.fun(FunctionConstants.update) @Function(openLevel = {FunctionOpenEnum.API}) public PetTalent update(PetTalent data){ //记录日志 OperationLogBuilder.newInstance(PetTalent.MODEL_MODEL, PetTalentDataAudit.PETTALENT_UDPATE).record(data.queryById().fieldQuery(PetTalent::getPicList).fieldQuery(PetTalent::getPetShops),data); PetTalent existPetTalent = new PetTalent().queryById(data.getId()); if(existPetTalent !=null){ existPetTalent.fieldQuery(PetTalent::getPicList); existPetTalent.fieldQuery(PetTalent::getPetShops); existPetTalent.relationDelete(PetTalent::getPicList); existPetTalent.relationDelete(PetTalent::getPetShops); } data.updateById(); data.fieldSave(PetTalent::getPicList); data.fieldSave(PetTalent::getPetShops); return data; } Step3 重启看效果 修改宠物达人记录对应的字段，然后进入审计模块查看日志
本节为小伙伴们介绍，Function的面向对象的特性：继承与多态； 一、继承 我们在3.4.1【构建第一个Function】一文中伴随模型新增函数和独立类新增函数绑定到模型部分都是在父模型PetShop新增了sayHello的Function，同样其子模型都具备sayHello的Function。因为我们是通过Function的namespace来做依据的，子模型在继承父模型的sayHello函数后会以子模型的编码为namespace，名称则同样为sayHello。 二、多态（举例） oinone的多态，我们只提供覆盖功能，不提供重载，因为oinone相同name和fun的情况下不会去识别参数个数和类型。 Step1 为PetShop新增hello函数 package pro.shushi.pamirs.demo.api.model; …… //import @Model.model(PetShop.MODEL_MODEL) @Model(displayName = "宠物店铺",summary="宠物店铺",labelFields ={"shopName"} ) @Model.Code(sequence = "DATE_ORDERLY_SEQ",prefix = "P",size=6,step=1,initial = 10000,format = "yyyyMMdd") public class PetShop extends AbstractDemoIdModel { public static final String MODEL_MODEL="demo.PetShop"; …… //省略其他代码 @Function(openLevel = FunctionOpenEnum.API) @Function.Advanced(type= FunctionTypeEnum.QUERY) public PetShop sayHello(PetShop shop){ PamirsSession.getMessageHub().info("Hello:"+shop.getShopName()); return shop; } @Function(name = "sayHello2",openLevel = FunctionOpenEnum.API) @Function.Advanced(type= FunctionTypeEnum.QUERY) @Function.fun("sayHello2") public PetShop sayHello(PetShop shop, String s) { PamirsSession.getMessageHub().info("Hello:"+shop.getShopName()+",s:"+s); return shop; } @Function(openLevel = FunctionOpenEnum.API) @Function.Advanced(type= FunctionTypeEnum.QUERY) public PetShop hello(PetShop shop){ PamirsSession.getMessageHub().info("Hello:"+shop.getShopName()); return shop; } } 图3-4-3-1 为PetShop新增hello函数 Step2 为PetShopProxyB新增对应的三个函数 其中PetShopProxyB新增的hello函数，在java中是重载了hello，在代码中new PetShopProxyB()是可以调用父类的sayHello单参方法，也可以调用本类的双参方法。但在oinone的体系中对于PetShopProxyB只有一个可识别的Function就是双参的sayHello package pro.shushi.pamirs.demo.api.proxy; import pro.shushi.pamirs.demo.api.model.PetCatItem; import pro.shushi.pamirs.demo.api.model.PetShop; import pro.shushi.pamirs.meta.annotation.Field; import pro.shushi.pamirs.meta.annotation.Function; import pro.shushi.pamirs.meta.annotation.Model; import pro.shushi.pamirs.meta.api.session.PamirsSession; import pro.shushi.pamirs.meta.enmu.FunctionOpenEnum; import pro.shushi.pamirs.meta.enmu.FunctionTypeEnum; import pro.shushi.pamirs.meta.enmu.ModelTypeEnum; import java.util.List; @Model.model(PetShopProxyB.MODEL_MODEL) @Model.Advanced(type = ModelTypeEnum.PROXY,inherited ={PetShopProxy.MODEL_MODEL,PetShopProxyA.MODEL_MODEL} ) @Model(displayName = "宠物店铺代理模型B",summary="宠物店铺代理模型B") public class PetShopProxyB extends PetShop { public static final String MODEL_MODEL="demo.PetShopProxyB"; @Field.one2many @Field(displayName = "萌猫商品列表") @Field.Relation(relationFields = {"id"},referenceFields = {"shopId"}) private List<PetCatItem> catItems; @Function(openLevel = FunctionOpenEnum.API) @Function.Advanced(type= FunctionTypeEnum.QUERY) public PetShop sayHello(PetShop shop){ PamirsSession.getMessageHub().info("PetShopProxyB Hello:"+shop.getShopName()); return shop; } @Function(name = "sayHello2",openLevel = FunctionOpenEnum.API) @Function.Advanced(type= FunctionTypeEnum.QUERY) @Function.fun("sayHello2") public PetShop sayHello(PetShop shop,String hello){ PamirsSession.getMessageHub().info("PetShopProxyB say:"+hello+","+shop.getShopName()); return shop; } @Function(openLevel = FunctionOpenEnum.API)…
两种工程模式介绍 oinone推荐的两种工程模式都保留互联网特性，如跟业务无关的基础平台还是采用平台化思路建设。二种侧重点差异如下 第一种：比较适合企业采用多供应商联合开发场景，先以业务区分，各个业务线有独立的领域平台，最大限度保持不同业务线的独立性，有利于各个业务线独立发展（目前oinone上层星空系列产品采用这种工程模式，因为我们期望的时候帮助企业构建软件生态，必然要考虑不同供应商联合开发场景） 第二种：比较接近传统互联网架构，先按平台领域区分，如商品领域：商品平台做总工程，但里面按业务区分模块分子工程来保持业务相互独立，相对于第一种把领域的代码放一起，带来好处强化大家思考模型通用性。但不适用于跨公司主体间配合。 图5-2-1 Oinone-CDM的两种工程模式 注意事项： oinone兼容传统互联网架构 不管哪种模式，都需要解决CDM的维护问题 CDM维护的常见问题： Q：CDM层缺少模型怎么办？ A：CDM层模型是逐步完善和丰富的。如果是特定业务自己需要的模型，这类模型无通用性。则加到自己的工程中；如果是通用的，则架构组确定是否需要纳入到CDM。 Q：CDM层已有的模型缺少字段怎么办？ A：CDM层模型的字段也是逐步完善和丰富的，通用的字段在架构组确定后也会被吸收进来 Q：CDM层不同业务线相互影响怎么办？ A：扩展字段最好带上自有前缀标志，如果觉得通用则提交架构组走模型缺少字段加入 Q：CDM层某模型新增加了的字段，但原先业务线已经加了相同含义字段 A：业务线可以把自己的字段related到CDM增加的新字段，并做数据迁移
1. 查看、处理流程 1.1 流程查看 流程管理页面共同点： 选项分类筛选 标签筛选 应用下拉选筛选 根据流程名称搜索 流程管理页面名词解释： 任务待办：当前登录用户未处理的流程节点 我发起的：当前登录用户人为触发的流程（模型触发） 抄送：抄送给当前登录用户的节点（审批/填写） 我已办结：由当前登录用户完成人工/自动同意、人工拒绝或人工填写的节点 无需办理：当前登录用户转交的任务/被退回、被撤销、被或签、被其他分支任务拒绝的还未办理的任务 1.2 流程处理 1.2.1 任务待办 任务待办中点击“审批/填写”会进入流程详情处理页面，主要展示 1. 操作区 2. 流程发起人及状态 3. 模型视图内容 4. 流程时间线及其他记录。 审批代办操作区可能包含“分享、同意、拒绝、退回、加签、转交、返回”，填写代办操作区可能包含“分享、转交、提交、暂存、返回”，审批/填写操作区包含哪些动作由流程设计决定。 1.2.2 我发起的 我发起的流程列表中主要分为进行中和已完成的流程。进行中的流程可以进行查看、催办、撤销的操作，已完成的流程可以进行查看操作。 查看我发起的流程，进入流程详情页面，也是根据流程状态展示对应操作功能，进行中的流程有分享、催办、撤销、返回按钮，已完成的流程有分享、返回按钮。 1.2.3 抄送 抄送列表中每条抄送只可以进行查看操作，查看进入流程的详情页面，有分享和返回的操作。 1.2.4 我已办结 我已办结列表中可以进行查看操作，查看进入代办的详情页面，可以进行分享和返回的操作。 1.2.5 无需办理 无需办理列表中可以进行查看操作，查看进入代办的详情页面，可以进行分享和返回的操作。 2. 流程运行记录查看 所有运行流程都会记录在流程运行记录中，可以根据流程的所属应用，流程名称，触发方式和状态进行搜索，流程运行记录详情中展示流程运行的具体节点，运行时间，当前运行节点，异常信息等。
