相关推荐

• Oinone 7天入门到精通

  5.8 商业支撑之执行域

  一、基础介绍 执行域包括两个核心一是订单的产生，二是订单的履约。往往品牌商既有自营渠道（包括2c、2b）、又有第三方渠道。那么有两种设计思路： 把第三方渠道的订单当作自有渠道的订单产生一种特殊方式，开放订单创建接口，并统一履约。 好处：简单，在3方渠道不多、且自有渠道单一，并且逻辑相识时系统结构会简单 坏处： 当3方渠道的履约方式、库存分配方式、逆向逻辑等有差异时，会让自有渠道参杂很多不相干的逻辑引入不必要的复杂度 自有渠道不够独立和纯粹，自有渠道多样化时难以支撑 把商家自营渠道假设为特殊的第三方渠道，再建立统一的订单管理系统来对接渠道订单，并完成履约 好处：交易与履约逻辑分离，对未来发展有扩展性 坏处：引入一定复杂度 我们采用的是第二套方案，整体结构简易图如下 图5-8-1 方案整体结构简易图 二、模型介绍 图5-8-2 模型介绍 核心设计逻辑 首先我们看到上图交易域和履约域有很多相同父模型的子模型，交易域和履约域的父模型在CDM的在himalaya-trade里。履约域看oms（libra）对himalaya-trade扩展，交易域看b2c（leo）和b2b（aries）对对himalaya-trade扩展。libra、leo、aries是我们对上层业务产品的命名，取自黄道十二星座 交易域是多商家平台视角设计，有自身渠道必要的履约相关信息，完成自闭环。 履约域是从单一商家对接多渠道视角设计，有渠道交易订单同步后完成履约发货相关设计，完成自闭环。 履约域的合单拆单发货设计，渠道订单只能合单为履约单不可拆，履约单可以拆单发货不可合。用m2o和o2m的组合设计来降低难度，而非采用两个m2m的设计。

  史, 昂

  2024年5月23日

  994000
• Oinone 7天入门到精通

  6.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 重启看效果 修改宠物达人记录对应的字段，然后进入审计模块查看日志

  史, 昂

  2024年5月23日

  938000
• Oinone 7天入门到精通

  1.3 Oinone的生态思考

  以“企业级软件生态”的方式去帮助企业建立“一站式的商业智能软件”。 通过观察信息化到数字化的软件行业发展历程（如下图1-3所示），我们可以发现，企业真正需要的是一站式的软件产品。然而，一站式的软件产品往往都是从单个领域的需求满足开始，这在信息化时代和数字化时代都是如此。在信息化时代，以ERP为终点的一站式趋势逐渐形成；而在数字化时代，中台概念的提出则标志着一站式的趋势重新开始。本文将从企业数字化转型所面临的困境出发，探讨Oinone的生态思考。 图1-3 从信息化到数字化软件行业发展历程 1.3.1 与中台的渊源 中台概念的提出标志着企业数字化改造进入了一个新的时代。随着数字化转型不断深入，企业面临着严重的数据割裂、系统隔离等问题。在这样的背景下，“敏捷响应，低成本地快速创新”成为了推动一站式商业智能软件的内在诉求。需要澄清的是，互联网中台架构只是一种企业解决数据割裂、系统隔离，建立一站式商业智能软件的技术概念之一，并不是技术标准。而且这种方式只适用于企业自建模式。在多供应商环境下，则会适得其反，导致建立更复杂的烟囱系统。 阿里于15年提出中台架构概念，抓住了企业数字化转型的核心诉求，即“敏捷响应，低成本快速创新”。然而，阿里作为一家生态公司，在16年时基本上是带着合作伙伴来给企业交付，但由于伙伴对互联网技术的理解和能力的限制，基本上都做得不好，甚至失败。在2017年，阿里成立了原生交付团队，希望能够树立一些标杆案例。我和公司的核心成员也都来自于这个团队。在做完几个客户后，我发现阿里也做不好，但这次做不好的原因不是技术不行或项目上不了线，而是上线以后预期的效果没有达到，其本质是企业的IT组织能力无法驾驭复杂的互联网中台架构。当无法驾驭的时候，所谓的目标“敏捷响应，快速创新”就无从说起了。结果客户会反馈以下三类问题： 不是说敏捷响应吗？为什么改个需求这么慢，不但时间更长，付出的成本也更高了？是因为中台架构需要一定的技术能力和经验才能有效地应用，就像一个只会骑自行车的人给他一辆汽车或者飞机，他也不能驾驭它们，更不用说是手动挡的。 不是说能力中心吗？当引入新供应商或有新场景开发的时候，为什么前期做的能力中心不能支撑了？是因为能力中心是一种面向业务的能力组织方式，它将不同的业务能力抽象出来，以服务的形式对内提供。然而，由于业务场景的差异，不同的业务需要的能力也会不同，因此能力中心需要不断迭代和升级。对于新引入的供应商或新场景开发，需要根据实际情况对能力中心进行定制化和扩展化，但谁来负责呢？新项目的供应商还是客户自己？ 不是说性能好吗？为什么我投入的物理资源更多了？是因为中台架构采用微服务来解决单点瓶颈问题，提高系统性能和可用性，但是在初始阶段，投入的资源可能会更多。每个模块至少需要两个实例来保障高可用性，因此物理资源的投入量可能会比以前更多。 1.3.2 找解决方案 在考虑解决方案之前，我们需要思考企业数字化软件的最终状态将是什么样子。目前有两种主要的方案（如下图1-4所示）： 第一种是以自建研发团队为核心。中国的大型企业已经开始尝试这种模式，看起来似乎是一个时下比较流行的可行性方案。然而，绝大多数企业由于成本、人才团队等原因而难以坚持下去，只能与供应商合作开发。 第二种是以供应商为核心。由于大多数企业无法选择第一种路径，他们必须接受目前分散的情况，并通过系统集成尽可能拉通各个系统。尽管如此，在数字化时代中，真正意义上的一站式商业智能软件供应商还未出现。 图1-4 企业数字化桎梏和囹圄 对企业来说，这两种方案都非常艰难，但在大规模数字化历程中又不得不做出选择。此外，我们还能清晰看到以下几点： "敏捷响应，低成本地快速创新"成为企业推动一站式商业智能软件的内在诉求 目前没有一家软件供应商能满足企业所有外围商业场景，也不可能有这样的供应商 绝大部分企业需要软件供应商，而不是自建 如何突破这种局面也成为中国软件行业发展的一个机遇。因此，我的思考是： 我们的目标不是依托于提升研发人员的能力，而是降低互联网架构的门槛，让更多企业真正拥有“敏捷响应，低成本快速创新”的能力。 我们的目标不是输出中台方法论，而是提供中台建设的技术平台。 我们的目标不是只服务大企业，而是真正赋能不同IT组织能力的企业，让它们都具备持续创新的能力。 今天，许多中台软件公司告诉企业：“中台是持续演进和快速迭代的过程，因此企业需要组建中台架构团队来实现，而他们则通过中台项目落地将中台建设方法论传授给企业。”这句话的前半部分是正确的，因为我们之前提到企业需要具备敏捷响应业务的能力，即应变能力，因为应变是不断变化的。然而，后半部分是不正确的，因为今天的企业已经有能力组建团队，那么这些中台软件公司到底有什么用呢？企业真的缺少方法论吗？在19年，我就提出了自己的看法：没有低代码能力的中台公司都在收取智商税，都在欺诈，因为很多企业根本找不到足够懂互联网架构的人才。明白流氓在哪里了吗？这些流氓公司赚了很多钱，最后责怪企业无法招到人才，这是企业的责任。因此，仍然认为“最好的赋能是降低门槛，而不是让客户提高技术水平”。 最终，我们得出了一个服务模式的想法：构建企业级的软件生态。企业级软件生态的确切定义是：通过开放的方式，让企业本身以及不同的软件供应商共同参与，遵循相同的技术和数据规范，打造一体化、无需集成的各类企业级软件。如果要打造企业级软件生态，我们列出了六个要点（如下图1-5所示）。 图1-5 打造企业级软件生态需要具备的六大能力 我很幸运地有机会通过“企业级软件生态”的方式，为企业建立“一站式的商业支持平台”提供帮助。我们的Oinone平台结合了低代码开发、通用数据模型和业务产品的优势（如下图1-6所示）。 图1-6 Oinone = 低代码开发平台 + 通用数据模型 + 业务产品 我们对Oinone一站式低代码商业支撑平台展开介绍，它大致分为4部分： 以低代码开发平台为基础，输出具备互联网架构下的软件快速开发标准。这可以帮助企业快速构建符合互联网架构标准的应用程序，从而实现快速响应和低成本创新。 以通用数据模型为基础，满足不同软件基于同一套数据标准的扩展能力。这可以确保不同软件系统之间的数据兼容性和互操作性，避免数据孤岛和信息隔离。 在业务产品层面上，企业和伙伴基于相同的技术标准和数据标准共同提供解决方案。这可以帮助企业和伙伴共同开发出符合标准的商业支撑平台，以提高业务效率和创新能力。 最后是无代码设计器，用于满足项目开展中，超出业务标品范围之外的需求，或者针对标品的临时需求。这可以帮助业务人员在不需要专业软件支持的情况下，自主解决业务需求，并支持部门间的协同工作。 1.3.3 生态建设 Oinone致力于打造全球最大的无需集成的商业应用程序及其生态系统，通过开源内核、汇集数千名开发人员和业务专家，为企业提供成本效益、一体化、模块化的解决方案，解决所有商业需求，让不同技术之间的合作变得简单易行，摆脱烦恼的集成问题。 在客户和场景领域，我们严格限定了自身的专注领域。针对超大型头部企业，我们专注于树立标杆，而对于大、中、小型企业，则交由我们的伙伴来支持。小微企业可以通过我们的开源社区版获得覆盖。在企业数字化转型的核心领域中，我们的解决方案涵盖了数字化交易场景、全渠道订单履约场景、数字化采购场景、数字化营销等产品。在其他领域，我们完全交由伙伴来建设。由于我们自身在企业协同商务领域拥有深厚的背景，因此在该领域提供的产品拥有特别的优势。 企业数字化转型核心领域 图1-7 企业数字化转型核心领域

  史, 昂

  2024年5月23日

  1.7K000
• 产品使用手册

  新版权限操作手册（5.0以上）

  一 整体介绍 1. 角色类型： 为了更好地管理和控制平台中的不同用户，权限系统将对角色进行分类定义。通过角色分类，可以更高效地管理同一类角色，无需单独操作每个角色，实现统一管理。 2. 角色管理： 角色管理是权限系统中的一个基础功能，负责管理具体角色的创建、编辑和禁用，以及对角色的单独操作。 3. 系统权限： 可配置某个应用或其下的某个菜单、某个应用的首页的管理权限和访问权限。 管理权限：赋予某角色后，该角色具备向下分配权限的能力。 访问权限：赋予某角色后，该角色可进行访问。访问权限可配置多个权限组，不同权限组可授权给不同角色。 注： 此处应用下的“首页”菜单是在【应用中心-设置首页-绑定视图】中配置的视图。权限控制是针对这个视图进行的。只有当在设置首页时选择了绑定视图，应用下才会有对应的“首页”菜单；否则，该菜单将不可见。 当【应用中心-设置首页-绑定菜单】只需单独为应用下的某个菜单进行授权即可。 拥有访问权限并不代表拥有管理权限，同理，拥有管理权限也不代表拥有访问权限。这两种权限需要单独授权。二者并无直接关系。 4. 数据权限项和数据权限： 数据权限项：通过为某个模型配置过滤条件来定义特定的数据访问规则，但这些规则不会立即生效。它们需要与数据权限配合使用，以实现精细化的数据访问权限控制。 数据权限：为多个角色应用指定多个数据权限项，类似于系统权限的管理，但其范围更广泛，涵盖了对所有模块的授权。 通过数据权限项定义具体的访问规则，再通过数据权限将这些规则分配给不同的角色，以实现全面的权限控制。 二 操作手册 2.1 创建用户、绑定角色 创建一个名为testName的用户。 2.1.2 用户与角色的绑定（3种方式） 2.1.2.1 创建用户时为其单个或批量绑定角色 在创建用户页面进行添加绑定的角色，勾选完成，点击“确定”，完成角色的添加。 2.1.2.2 修改用户时为其单个或批量绑定角色 在修改用户页面进行添加绑定的角色，勾选完成，点击“确定”，完成角色的添加。 2.1.2.3 选择指定用户为其单个或批量绑定角色 指定用户后点击绑定角色，进行绑定的角色。 2.2 应用的授权–访问权限 访问权限是指将特定应用程序授权给相应的角色，一旦用户被分配到这些角色，他们将获得访问该应用程序的权限。确保了只有经过认证的用户才能访问特定的应用功能或数据。 2.2.1 应用与角色的授权–访问权限 选择系统权限，点击某个想要为其授权的应用。 添加角色，点击“确定”按钮，为应用授权。 授权成功，显示可以访问此应用的角色。 2.2.2 菜单与角色的授权–访问权限 选中系统权限，点击某个想要为其授权的菜单，为其添加权限组。 配置权限组，保存配置。 为权限组授权对应的角色。 授权成功，显示可以访问此菜单的角色。 2.2.3 批量授权–访问权限 我们支持对单个或多个应用程序及其菜单执行批量授权操作，以授予相应的访问权限。 角色权限访问： 角色未被授予应用的访问权限时，即使授予了菜单权限也无法访问。 角色被授予应用访问权限但未被授予菜单权限时，仍然无法访问菜单。 只有当角色同时被授予应用和菜单的权限时，才能访问相关菜单。 批量授权： 该功能仅作为添加角色至应用或菜单配置访问权限的入口。 批量授权： 在批量授权过程中，平台会自动创建一个默认权限组，这个权限组赋予了用户管理所有数据和当前菜单下所有管理权限的能力。这个默认权限组的创建会根据不同的平台版本进行区分处理。 在5.0.4版本之前，平台在创建默认权限组时，并不会自动勾选动作权限。 从5.0.4版本开始，包括5.0.4版本在内，平台会自动勾选所有动作权限，简化了授权流程。 值得注意的是，默认权限组在首次创建时遵循当时的动作权限规则。如果后续进行多次批量授权，平台不会重新创建默认权限组，而是保留之前的设置。因此，即使在后续的批量授权过程中，动作权限也会保持之前的状态。 总结来说，批量授权时，平台会根据版本自动创建带有或不带有动作权限的默认权限组，且该默认权限组在多次授权过程中保持不变，不会随每次授权而更新其动作权限设置。 找到系统权限菜单，点击批量配置。 选择单个或多个应用为其添加访问权限，点击添加角色进行添加操作。 进入添加角色页面。 选择需要添加的角色，点击“确定”按钮，完成角色的授权。 在批量授权过程中，添加角色框中的角色将被视为本次批量授权的角色。 此时完成批量授权，点击取消批量即可。 验证是否批量授权成功：点击已经授权的应用下某一菜单，看到“管理所有数据”下有我们添加的“子管理员”。 2.3 应用的授权–管理权限 管理权限涉及将应用程序的管理功能授权给特定角色，例如“子管理员”。拥有管理权限的角色能够进一步授权其他用户管理权限，可以向下分配。通过这种方式，组织可以实施分级的管理结构，确保各级管理员能够有效地管理和分配资源。 注：如果要为应用授予管理权限，则该应用下的所有菜单也会被授予管理权限。此外，也可以单独为某个应用下的特定菜单授予管理权限。 2.3.1 应用与角色的授权–管理权限 选择系统权限，点击某个想要为其授予管理权限的应用。 进入添加角色页面。 添加可管理此应用的角色，点击“确定”，完成角色的授权。 授权成功，显示可以管理此应用的角色。 2.3.2 菜单与角色的授权–管理权限 选择系统权限，点击某个想要为其授予管理权限的菜单。 进入添加角色页面。 添加可管理此菜单的角色，点击“确定”，完成角色的授权。 授权成功，显示可以管理此菜单的角色。 2.2 实例：向下分配权限–子管理员 子管理员描述 管理权限向下分配能力：子管理员可以向下分配管理权限，包括向其他角色授予或取消某应用、菜单或首页的管理权限。 访问权限：子管理员被授予访问权限，可以访问平台中指定的应用、菜单或首页。 持续的管理权限向下分配：子管理员可以持续地向下分配管理权限，确保权限的适当控制和分配。 子管理员一定要为管理中心应用配置访问和管理权限。 2.2.1 创建一个名字为“子管理员”的角色 2.2.2 角色与用户的绑定 2.2.3 为子管理员分配应用的管理权限 如果要为应用授予管理权限，则该应用下的所有菜单也会被授予管理权限。此外，也可以单独为某个应用下的特定菜单授予管理权限。 应用管理权限的分配 选择系统权限，点击某个想要为其授予管理权限的应用。 进入添加角色页面。 添加可管理此应用的角色，点击“确定”，完成角色的授权。 授权成功，显示可以管理此应用的角色。 2.2.4 登录子管理员继续向下级分配权限 输入账号、密码，点击登录。 在上级角色中我们已经为“子管理员”角色，授权了管理中心的管理、访问权限和具体的某个应用的管理权限。 选择系统权限，点击某个想要为其授权的应用。在此页面“子管理员”这一角色还可以根据所需的业务场景继续向下级分配管理权限和访问权限。 至此，已成功实现子管理员角色所需的管理权限的配置。子管理员随后可依循相同流程，对下属用户进行相应的权限分配。

  萧炎

  2024年7月2日

  5.8K000

• 序篇

  史, 昂

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

  1.9K000