应用中心
一切兼应用
所有的功能都是应用，都会已应用的形式在平台运行。只是应用的属性不一样，有些是基础的应用，有些是业务型应用等等，有些应用需要上架到应用市场，需要在应用市场购买才会有应用的对应功能。有些应用是开通租户的时候就会存在，对应的功能可以直接使用。
什么是应用中心
应用中心是一个集中管理和提供多个SaaS（软件即服务）应用程序的平台。它是一个统一的界面，允许用户通过单点登录来访问和使用各种不同的SaaS应用。
应用中心的主要功能包括：
- 集中管理：SaaS应用中心允许管理员对所有SaaS应用程序进行集中管理。管理员可以在一个地方设置和配置应用程序，管理用户访问权限，并监控应用程序的使用情况。
- 统一访问：SaaS应用中心为用户提供了一个集成的入口点，使他们能够通过单点登录来访问所有已连接的SaaS应用。这意味着用户只需进行一次登录，即可访问他们所需的所有应用程序，无需多次输入凭据或切换到不同的应用程序。
- 应用市场：SaaS应用中心通常还提供一个应用市场或目录，展示了可用的SaaS应用程序。用户可以根据自己的需求和偏好，浏览并选择适合自己的应用程序。这方便了用户发现新的应用，并快速部署它们。
- 应用集成：SaaS应用中心有助于实现不同SaaS应用之间的集成和数据交换。例如，用户可以通过集成将数据从一个应用程序传输到另一个应用程序，实现数据的共享和协同工作。
- 安全和控制：SaaS应用中心提供了安全性和控制功能，以确保用户和组织的数据和访问权受到保护。管理员可以设置用户权限、访问控制策略，并监控应用程序的使用情况，以确保符合安全标准和合规要求。
- 节省成本和资源：使用SaaS应用中心，组织可以更好地管理其SaaS应用程序，减少不必要的重复许可证费用，并更有效地分配IT资源。
作为超级管理员
超级管理员在SaaS应用中心中具有高级管理权限，可以有效地管理各类应用。以下是超级管理员可以采取的一些管理措施：
- 应用设置和配置：超级管理员可以配置应用中心的设置，例如自定义主题、品牌标识、通知偏好等。此外，他们还可以对每个应用的设置进行管理，包括许可证控制、用户权限、数据连接和集成等设置。
- 用户管理：超级管理员可以管理应用中心的用户账户和权限。他们可以创建、编辑和删除用户账户，并分配不同的角色和权限，以控制用户对不同应用的访问和操作。
- 应用发布和撤销：超级管理员负责管理应用中心的应用程序库。他们可以添加新的SaaS应用程序到库中，并确保这些应用符合组织的需求和安全标准。当一个应用程序需要被撤销或替换时，超级管理员也可以移除它并更新应用程序库。
- 安全和合规性：超级管理员有责任确保应用中心的安全性和合规性。他们可以监控应用程序的使用情况，检测潜在的安全风险，并采取必要的安全措施来保护用户数据和系统的安全性。此外，他们也负责确保应用程序的使用符合适用的法规和合规要求。
- 应用集成和数据管理：超级管理员可以管理应用程序的集成配置，确保不同应用之间的数据传输和交换顺利进行。他们可以设置数据连接、API密钥等，并管理数据共享和协作策略，确保数据的安全性和一致性。
- 监控和报告：超级管理员可以通过监控和报告功能来跟踪应用中心的使用情况和性能。他们可以查看用户活动日志、应用程序的运行状态，以及资源利用率等，以便及时发现问题并采取相应的措施。
创建应用
当一个应用要注册进来，我们一般会联系管理员
将应用的信息增加进来
应用新增之后我们会拿到应用的相关信息，比如应用的appKey，加密密匙等
拿到加密的密匙，才有之前所说的和其他应用通信
既然有应用通信，那么该应用到底能访问哪些应用的数据呢？这里我们需要应用授权，只有应用之间授了权的才能相互访问数据。
管理员在应用列表维护好的应用会进入应用市场管理
应用市场管理
应用市场会对应用进行上下架处理
应用市场管理上架的应用可以在应用市场出现，租户就可以进行购买操作
当应用市场下架之后，就不再会出现在应用市场，之前购买了应用的，也会自动取消
应用市场
当应用市场上架应用之后会自动出现在应用市场下，租户可以去安装应用
开通应用之后，对应的菜单就会自动分配给租户
应用能力注册
在应用详情页面我们看到了很多应用相关的东西
- 运行状态
- 应用菜单
- 小组件
- 版本管理
- 接口管理
- 事件管理
- 消息管理
还有其他的一些东西，后续会陆续增加上
那么这些东西怎么来的呢？
在我们应用注册的时候，我们会有一个应用描述文件，这个描述文件就是我们的配置包，描述的就是这个应用提供的能力和需要用到的能力
由于每个版本都不一样，所以我们将上传配置包放到了版本管理
描述文件是什么样的呢？就是一个json描述
{
"menus":[{}], 菜单
"interfaces":[{}], 接口
"events":[{}], 事件
"messages":[{}], 消息源
"components":[{}] 组件
"configs":[{}] 数据字典
}
每个组件都是一个数组对应的json
菜单配置
"menus": [{
"configCmds": [
{
"conditionValue": "查询条件",
"defaultEnum": "是否是默认权限",
"dictValue": ""
}
]
"icon": "图标",
"id": "菜单ID_必填",
"isFrameEnum": "是否为iframe,是：TRUE,否：FALSE",
"menuCode": "菜单编码_必填",
"menuName": "菜单名称_必填",
"menuTypeEnum": "菜单类型，Model:目录、 MENU 菜单、 BUTTON 按钮_必填",
"netUrl": "跳转地址",
"parentId": "父级ID,有就穿没有就不传",
"parentIds": "父菜单IDS(所有父级ID包含自己ID逗号隔开，若没父级则传自身ID)_必填",
"path": "资源路径",
"perms": "权限码key",
"permsStatusEnum": "是否有数据权限，TRUE 是，FALSE 无",
"remarks": "备注"
}]
接口配置
"interfaces": [{
"code": "编码"
"requestType": "请求类型_必填",
"paths": "路劲_必填",
"moduleTag": "模块描述",
"interfaceName": "接口名称_必填",
"requestParams": [{
"in": "body",
"name": "requestData",
"request": true,
"description": "requestData",
"requestData": {
"request": {
"type": "ref(对象类型）",
"引用对象类名(如FindAccountByTargetIdAReq)": {
"targetId（字段名）": {
"type": "integer(类型)",
"format": "int64(类型)",
"description": "字段1描述"
},
"targetType（字段名）": {
"type": "integer(类型)",
"format": "int32(类型)",
"description": "字段2描述"
}
}
}
}
}],
"responseParams": {
"ResponseData«返回对象类名（如：FindManagerAccountPlatAResp）»": {
"data": {
"type": "ref(对象类型)",
"返回对象类名（如：FindManagerAccountPlatAResp）": {
"id（字段名）": {
"type": "integer（类型）",
"format": "int64（类型）",
"description": "id（描述）"
},
"account（字段名）": {
"type": "string（类型）",
"description": "登录名（描述）"
},
"password（字段名）": {
"type": "string（类型）",
"description": "密码（描述）"
}
}
}
}
},
"response": {
"200(状态码)": {
"description(描述)": "OK"
},
"201(状态码)": {
"description(描述)": "Created"
},
"401(状态码)": {
"description(描述)": "Unauthorized"
},
"403(状态码)": {
"description(描述)": "Forbidden"
},
"404(状态码)": {
"description(描述)": "Not Found"
}
},
"consumer": "application/json（请求数据类型）_必填",
"produce": "data（响应数据类型）_必填"
}]
事件中心
"events": [{
"eventCode": "事件编号1_必填",
"eventInfo": "事件描述1_必填"
}]
组件中心
"components": [{
"componentsUrl": "组件地址_必填",
"description": "描述",
"height": "组件高",
"minHeight": "最大组件高度_必填",
"minWidth": "最小组件高度_最小是1_必填",
"name": "名称_必填",
"thumbnailUrl": "组件略缩图",
"typeEnum": "组件分类,WEBSITE_COMPONENTS:官网组件,PORTAL_COMPONENTS:门户组件_必填",
"width": "组件宽_最大是12_必填"
}]
配置中心
"messages":[{
"code": "消息源编号_必填",
"service_name": "消息源名称_必填",
"remarks": "描述"
}]
其他组件
待新增完善，还会扩展应用的依赖关系，应用的编排能力等等
应用接入
为什么要接入
一般情况下是业务要求，往往业务多了之后就会有很多系统，然而各个业务系统都有自己的配置，权限，UI等等。不统一，业务管理起来就不会便利。因为他的记住每个系统是做什么的，每个系统的入口是什么？每个系统的权限功能是什么？每个系统的样式使用都不一致等等繁杂问题，所以统一应用管理是必要的
接入应用带来的好处
- 统一门户风格
- 系统统一管理
- 能使用自定义菜单，实现千人千变
- 能自定义各类工作台
- 能使用底座的组件
- 能使用接口中心，注册能力和使用其他应用能力
- 能使用事件中心，编排服务
- 能统一接入消息中心，发送邮件，短信，站内信，钉钉等
- 能统一接入文件中心，异步上传下载，监控文件进度
- 能统一接入配置中心，可以跨应用使用同一配置
- 能动态配置登录终端
- 能用用户实名中心，自动接入了多种实名方式
- 能编排组件成为新的页面发布网站应用
- 能使用统一支付服务
- 能使用SaaS服务，上架应用到市场
- 等等，持续集成能力
如何接入
独立型应用
一般这个接入方式是老应用，并且老应用不用改造，只是为了统一门户，并且可以访问平台提供的能力。
-
像底座申请接入
入参：
序号 名称 描述 1 应用名称 应用名称 2 应用简介 相关介绍 3 应用介绍 相关介绍 4 应用图标 市场图标 5 访问地址 应用访问的地址 6 心跳监控地址 应用的心跳监控，服务端会定时和该地址进行通信 7 服务商 描述
出参：
| 序号 | 名称 | 描述 |
| -- | ------------ | ----------------------------- |
| 1 | PaaS平台网关通信地址 | 负责和应用交互的网关地址 |
| 2 | PaaS平台公钥 | 和平台通信的密匙 |
| 3 | 应用appKey | 当前应用的appKey，应用的唯一标识，和应用通信时能用到 |
| 4 | 应用私钥 | 应用的私钥，用于和平台通信 |
| 5 | 应用公钥 | 应用的公钥，用于和平台通信 |
-
菜单打开方式修改
独立应用一般的打开方式是外部打开方式，所以我们要修改打开方式为外部
修改好之后就可以去点击菜单了。比如，我们的动态接口平台和开放平台
点击应用之后的效果
-
单点登录集成
当然，如果外部应用能通过平台跳转过去，那么肯定要实现单点登录集成，这个集成方式会在PaaS平台认证中心统一说明，这样跳过去的用户才知道是哪个用户，对应的应用才会根据当前用户做权限
优点：老系统只需要改造单点登录，即可接入，可以访问底座的能力
缺点：体验不好，虽然入口看着像是一个，但是点击之后完全跳到了其他的框架应用
非独立型应用
这个比较简单，如果是这样的应用基本都是按照PaaS平台的规范进行开发，这样的系统是我们推荐的，基本上新应用都可以按照该模式进行开发。因为可以无缝接入到平台，并且能通过内部Rpc调用平台的能力，老应用如果补改造一般是独立应用型接入方式。如果老应用可以做一些改造，那么可以半独立型应用接入方式。
优点：无缝接入平台，直接使用平台的能力，减少重复开发（比如资源，权限等），前后端开发模板都已经共享，gitee.com/application…
缺点：熟悉规范，但是基本每个系统都有规范。新开发都得熟悉。
半独立型应用
该接入方式主要也是用于老应用，老应用需要提供菜单注册到平台，权限可以由平台统一控制，最简单的方式是页面不做改造，将页面的链接直接注册到菜单。这种方式菜单的打开方式就是iframe嵌入，应用需要改造，菜单链接会将该用户的token带进来，菜单能识别到当前用户的信息，复杂点的方式是，按照平台的前端接入规范改造，这些可以直接和平台前端通信，这种就不再是iframe嵌入，而且用到平台的微前端以微应用的形式嵌入。
-
像底座申请接入
入参：
序号 名称 描述 1 应用名称 应用名称 2 应用简介 相关介绍 3 应用介绍 相关介绍 4 应用图标 市场图标 5 访问地址 应用访问的地址 6 心跳监控地址 应用的心跳监控，服务端会定时和该地址进行通信 7 服务商 描述
出参：
| 序号 | 名称 | 描述 |
| -- | ------------ | ----------------------------- |
| 1 | PaaS平台网关通信地址 | 负责和应用交互的网关地址 |
| 2 | PaaS平台公钥 | 和平台通信的密匙 |
| 3 | 应用appKey | 当前应用的appKey，应用的唯一标识，和应用通信时能用到 |
| 4 | 应用私钥 | 应用的私钥，用于和平台通信 |
| 5 | 应用公钥 | 应用的公钥，用于和平台通信 |
-
在平台进行发版操作
应用发版的时候除了填写版本信息，还需要上传一个应用说明文件，该文件描述了应用需要接入的菜单，组件，接口等内容
说明文件内容之前已经介绍过，就是json格式的说明，请参考前面的应用能力注册
3. 单点登录集成
系统需要认识当前的用户信息，在页面切换的时候会传入token
集成完成后就可以在菜单里出现该应用的菜单
就可以进行权限设置了，设置之后用户在主框架登录完成后就会看到已经授权的菜单
优点：老系统只需要改造单点登录，提供应用说明配置，即可接入，可以访问底座的能力，如果按照微应用的方式改造，体验会更好，可以自动切换皮肤，可以调用平台API进行通信，我们建议是前端以微应用方式接入，只是这样的方式可能需要应用进行改造，成本会大一些。
缺点：如果的iframe嵌入，很多没有办法控制应用，比如颜色风格等
备注：如果是iframe方式嵌入，要求对应的应用需要放开iframe权限的拦截
应用开发模式
对于新型应用，那是比较好的，首先他不用再去做用户权限那一套东西，也可以用到基础里面的功能，比如数据字典，文件服务，接口编排等相关功能。
服务集成了gateway，nacos。只需要将服务注册到nacos就可以从gateway转发过去，gateway已经做了权限相关的认证，这样开发起来比较简单。
对于老应用需要采用上面讲的如果先通过注册，完成后下发appkey，再集成单点登录，将菜单，组件等相关的信息注入到平台。即可以使用平台的功能。
云应用
应用类型
-
独立型应用
- 能够独立提供服务，自成体系，不依赖于其他的服务可以提供服务。也可以闭环服务
- 当应用上架的时候能够独立上架到应用市场，提供服务
- 有自己的完整配置，如权限，用户，角色等相关内容
-
非独立型应用
- 应用本身不能独立提供服务，依赖于某个应用，应用不能闭环服务
- 当应用上架的时候需要关联应用才能提供服务
-
半独立型应用
- 能够独立提供服务，自成体系，不完全依赖于其他的服务可以提供服务。也可以闭环服务
- 应用上架的时候能够独立上架到应用市场，提供服务
- 当发现所依赖的应用已经被购买了，可以集成依赖的应用相关的服务，完成更好的服务
什么是云应用
应用可以独立部署，无需将应用部署到PaaS平台，当应用需要注册到PaaS平台时，只要安装接入规范描述文件即可接入
应用部署完成后只要将对应的应用配置，菜单，接口等相关信息按应用的配置格式注册到PaaS平台，应用接入底座的时候需要接入单点登录，当框架跳转到对应应用的菜单的时候，会将系统登录后的token带过去，基座提供token的解析得到相关的用户信息。
云菜单
当应用注册的时候需要将菜单注册进来。系统可以针对这些菜单进行重排，重新编辑等，实现千人千变，PaaS平台还提供了对应的权限管理，会自动在首页展示重新编排后的菜单 往往很多系统本身就有自己的授权，如果要完全接入到底座，那么我们是希望整个权限也接入到平台，但是往往这种推动起来比较麻烦，于是我们支持云菜单。
什么是云菜单
菜单统一管理，菜单可以重排，菜单可以集中授权，菜单还可以各自应用自己授权 当我们在加载权限的时候，如果该应用配置了远程授权地址，并可以从远程授权，那么在加载菜单的同时，还可以同时并发加载各个应用对应权限菜单
云组件
组件可以是一块独立的功能（比如快捷菜单）。也可以是一个公共的功能（比如一些图形组件），我们的云组件就是对应的功能按照我们的组件规范发布的一个组件地址。
- 基座组件
用于基座桌面工作台的渲染
- 门户组件
用于门户装修渲染
云插件（能力）
应用可能是独立的，应用可能会提供相关组件用于门户或者工作台，应用还可以提供插件使其他的应用能使用，插件可以有独立的处理流程，插件也可以注入到其他应用来使用该插件提供的功能
应用开发模式
开发应用的时候，我们首先拿到需求之前个性化开发，定制化开发吗？
当然这种方式也是可以的，只是我们我们不想这么去开发，首先要去抽象产品。抽象工具，用工具打造产品。
什么是工具？
工具其实也可以是应用，他也可以独立服务于客户。这样的工具可以定义为基础应用。 工具也可能不能独立服务。他必须要寄生在他的主体内才能服务，这样的工具一般是公共的，没有任务业务。为了不重复造轮子而存在。
工具型应用如果让别的应用使用？
所以我们定义一个名词 "云插件",当我们的应用想要别的应用能使用他，那么他会提供一些插件，能够嵌入到别的应用，并符合别的应用的业务场景 插件是应用提供的，当应用修改了插件，不影响使用他的应用
后面再通过对应的组件来讲应用编排相关的内容
应用开发模板
