在App Finder 中点击应用中心可以进入oinone的应用中心，可以看到oinone平台所有应用列表、应用大屏、以及技术可视化。
标准版本不支持在线安装，只能通过boot工程的yml文件来配置安装模块。在 www.oinone.top 官方SaaS平台客户可以在线管理应用生命周期如：安装、升级、卸载。同时针对已安装应用可以进行无代码设计（前提安装了设计器），针对应用类的模块则可进行收藏，收藏后会在App Finder中的我收藏的应用中出现。在应用列表中可以看到我们已经安装的应用以及模块，我们oinoneDemo工程也在其中。
但我们的测试应用没有设置应用类目，则无法在应用大屏中呈现。
在技术可视化页面，出展示已经安装模块的元数据，并进行分类呈现
Oinone社区 作者：史, 昂原创文章，如若转载，请注明出处：https://doc.oinone.top/oio4/9230.html
访问Oinone官网:https://www.oinone.top获取数式Oinone低代码应用平台体验
欢迎来到Oinone生态，我们为您提供了一站式低代码商业支撑平台，数式科技已经用其服务了如中烟、得力、上海电气、中航金网、雾芯科技等多个知名企业，我们的技术实力在商业场景得到了很好的验证。我们希望通过开源Oinone项目，为中国软件行业带来变革，提升整体工程化水平，与广大软件工程师一起为客户创造价值！《Oinone 7天从入门到精通》一书是Oinone开源项目的配套书籍，系统化地介绍了如何基于Oinone开源项目，快速开发高质量的软件系统。此外，如果您开发的项目是用于商业化而非企业自用，我们还为您提供了一种可选的商业化变现途径：申请成为Oinone的合作伙伴，并提交相关产品，详情请访问 www.oinone.top 网站。 书籍纲领 本书的章节安排如下： 第一章至第二章：【揭开面纱，理解Oinone】和【Oinone的技术独特性】。这两个章节可以帮助您更好地理解我们设计Oinone的初衷以及特性的由来。 第三章：面向研发人员的【Oinone的基础入门】。如果您是专业的研发人员，本章可以帮助您快速上手并做出业务系统。只要按着里面的case一步步操作下来就可以。 第四章至第六章：面向研发人员的【Oinone的高级特性】、【Oinone的CDM】、【Oinone的通用能力】。这三篇章节重点介绍了Oinone的高级技术特性、提供的通用数据模型和通用基础能力。它们能够帮助我们更快地进行业务开发，从容应对业务的特殊场景要求，比较适合进阶的研发人员。 第七章：面向非研发人员的【Oinone的设计器们】和【Oinone的低无一体】。如果您并不是专业的研发人员，本章可以帮助您通过使用Oinone的无代码可视化设计器轻松自主解决业务需求，并且当可视化设计器满足不了的时候，您还可以在【Oinone的低无一体】中找到方式，并寻求研发帮助
自2017年中国推进数字建设以来，数字经济规模持续增长，“十四五”规划和2035远景目标纲要中明确强调企业和政府需大力推动数字化转型，中国正在迈进一个崭新的数字经济时代。 在这个过程中，软件已经从工具变成信息化的基础设施，如何有效应对该变化所带来的一系列新的核心技术挑战，是整个软件行业发展遇到的另一难题。我认为，开源创新是解决这些难题的有效手段之一，也是未来软件发展的重要方向。如果说，数字化转型是时代趋势，那么开源创新也已成为时代主流。十四五规划纲要首提开源，2021年11月工信部印发《十四五软件和信息技术服务业发展规划》中提到开源重塑软件发展新生态，并将开源重塑软件发展新生态作为十四五期间我国软件产业的四大发展形势之一进行重点阐述。支持国产化开源创新体系发展，建设自己的开源社区和开源平台，其所具有的大众协同、开放共享、持续创新等特点，可有效推动各行业自主可控的数字化转型。 Oinone所倡导的开源理念和生态共建，与国家开源战略不谋而合：将开源作为一种合作手段，通过完善社区注重开源治理，吸引更多的企业和个体参与其中。湖南大学作为首批国家示范性软件学院的双一流建设高校，一直致力于推进和引导国产化开源软件体系的建设，并为此开展多种形式的产学研研究和实践。基于Oinone微服务分布式的设计理念和面向生态的开源特性，湖南大学结合自身在大数据分布式存储、多元异构数据汇聚融合和大数据智能分析等方面的研究成果，与Oinone展开了深度的技术创新合作，并在多个大中型企业数字化应用和数字政府应用中取得了良好的效果。 随着Oinone的开源，相信能激发更多的开发者参与到国产软件建设中，通过开源模式实现更广泛参与方的共享、共创、共生、共赢，构建价值驱动的数字创新生态平台，为我国数字经济发展贡献科技力量。 湖南大学教授：陈浩
一、基础介绍 执行域包括两个核心一是订单的产生，二是订单的履约。往往品牌商既有自营渠道（包括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的设计。
我们在应用开发过程有一种特殊情况在后端逻辑编写的时候需要知道请求的发起入口，平台利用GQL协议中的Variables属性来传递信息，本文就介绍如何获取。 一、前端附带额外变量 属性名 类型 说明 scene String 菜单入口 表4-1-18-1 前端附带额外变量 图4-1-18-1 variables信息中的scene 二、后端如何接收variables信息 通过PamirsSession.getRequestVariables()可以得到PamirsRequestVariables对象。 三、第一个variable（举例） Step1 修改PetTalentAction，获取得到前端传递的Variables package pro.shushi.pamirs.demo.core.action; ……类引用 @Model.model(PetTalent.MODEL_MODEL) @Component public class PetTalentAction { ……其他代码 @Function.Advanced(type= FunctionTypeEnum.QUERY) @Function.fun(FunctionConstants.queryPage) @Function(openLevel = {FunctionOpenEnum.API}) public Pagination<PetTalent> queryPage(Pagination<PetTalent> page, IWrapper<PetTalent> queryWrapper){ String scene = (String)PamirsSession.getRequestVariables().getVariables().get("scene"); System.out.println("scene: "+ scene); ……其他代码 } ……其他代码 } 图4-1-18-2 修改PetTalentAction Step2 重启验证 点击宠物达人不同菜单入口，查看效果 图4-1-18-3 示例效果（一） 图4-1-18-4 示例效果（二）
