1.应用上架须知

1.1 开发商条件

1. 能保证应用功能的持续优化、迭代，产品需求细节的交流、沟通，以及用户问题的高效处理；
2. 上架的应用需要有相应的开发、运维等服务作为保障支撑；
3. 具有独立承担民事责任的能力；
4. 单位具有良好的商业信誉和健全的财务会计制度；
5. 具有依法缴纳税收和社会保障资金的良好记录；
6. 在经营活动中没有违法或违规记录。

1.2 应用规范

平台主要面向组织用户，因此上架平台的应用应以组织为颗粒度设计多租户。用户从属于组织，组织可设置内设机构和岗位，用户可以加入多组织，组织之间可以组合成集团。

传统SaaS应用提供服务，组织或用户需要登陆服务地址，注册账号，提供相关用户认证信息。云原生应用平台要求面向组织和用户聚合服务。SaaS应用必须注册到平台，用户登陆平台，即可获取和使用SaaS服务。（即登录平台后使用应用不需要二次登陆）

为满足面向用户聚合服务的需要，应用需要遵守平台相关的规范。

1.2.1 强制性规范

• 对接平台组织体系 查看
• 对接平台待办中心 查看
• 注册应用入口，菜单和图标及角色对应关系。
• 遵守平台数据规范（暂时可视为参考规范，未来会转化至强制规范）、技术规范和安全规范。

1.2.2 可选性规范

• 遵守平台的 UI 设计规范 查看
• 集成部署规范 查看（平台支持去中心和分布式部署，也可以提供集成部署环境）

1.3 申请上架流程

当完成上述应用规范对接后，服务商应根据以下规则要求完成自检：

1. 用户同步：订阅应用后、分配权限后，用户是否同步
2. 应用菜单：应用中出现的菜单，是否与平台规范相符
3. 应用内容：应用描述是否存在非法内容、敏感内容
4. 用户逻辑：应用是否需要重新登陆，单点登录是否实现
5. 数据对接：如果与资产相关的应用，数据是否对接上
6. 页面风格：页面上的整体风格是否与资产云的保持一致
7. 待办对接：应用中的待办是否与系统中的同步
8. 核心数据：应用中的核心数据是否建立相应的元数据和枚举字典
9. 业务流程：主要业务流程是否可以走通，是否存在重大bug导致闪退、卡顿、报错等
10. 数据请求：嵌套 iframe 相关页面和网络请求是否正常

测试前请发送申请邮件 42225@hdu.edu.cn 开通权限

邮件内容包括：

租户名称 主管部门 统一社会信用代码 管理员姓名 手机号 行政区划代码 行政区划名称 实/虚单位

完成自检后，服务商可以在云原生应用平台测试环境中申请应用上架，通知云原生应用平台运维团队进行初步测试的相关审核，并在测试环境中完成灰度测试。

平台会对运行在测试环境应用进行定期清理，释放出被无效占用的资源。

1.4 环境说明

1.4.1 测试环境（灰度环境）

用于开发商上架测试应用的环境

地址：http://platform.assetcloud.org.cn/

1.4.2 正式环境（生产环境）

经测试后，正式发布应用的环境 地址：http://online.assetcloud.org.cn/

1.5 灰度测试

在云原生应用平台测试环境中，根据应用上架流程上架应用并完成灰度测试：

1. 灰度上架：验收通过的应用，将被灰度上架到云原生应用市场提供给一部分特定企业试用。当授权企业达到约定数量后，灰度上架结束；
2. 灰度运营：在约定周期内，服务商对授权企业维护运营；
3. 灰度测试时长不超过6个月；
4. 灰度测试报告：根据相关规则为准。出具灰度测试报告。

1.6 正式上架

1.6.1 进入开发者中心

步骤： 点击「应用市场」，之后点击「开发者中心」具体步骤参见下图：

1.6.2 注册应用

1.6.2.1 操作流程

步骤一： 进入开发者中心后，点击「注册」，见图示

步骤二： 填写应用信息

注册应用需按照平台要求填写正确信息并经平台审核后即可进入开发流程，具体需要提供的信息见下图：

1.6.2.2 查看应用key和secret

填写应用基本信息，审核通过后可查看应用 key 和 secret （用于调用平台接口，请勿外泄）

步骤： 进入开发者中心后，找到对应应用后点击「运维」，见下图1和2：

1.6.3 部署应用

目前集中部署功能已在青云集群上实现，请选择集中部署之后根据平台提供的部署文档进行操作；

独立部署具体方式各开放商根据自身情况进行即可。

1.6.4 上架应用

填写应用角色和角色对应的菜单信息

步骤一： 设置应用的角色，用于应用权限分配

步骤二： 为每个角色设置对应的菜单。菜单 URL：用于点击菜单时显示对应界面，需填写完整路径，如：http://www.assetcloud.org.cn (或者为ip+端口号)

完成角色菜单设计后，提交申请，等待平台管理员审核，具体各个按钮功能见下图：

1.6.5 发布应用

步骤一： 在开发者中心，选择应用，点击「发布」

步骤二： 发布后即可在应用市场获取应用

1.6.6 获取应用

应用通过审核后，上架到应用中心并可在应用中心获取，具体获取步骤见下图：

注册时设为面向单位或个人版的应用，上架后可以在 单位管理->应用中心，具体见下图：

注册时设为面向集团的应用，上架后可以在 集团管理（需先创建集团）->应用中心，具体见下图：

1.6.7 重新发布

在应用已经发布上架后，如需修改角色菜单的内容，在下架后可进行重新发布操作。

步骤一： 在开发者中心，选择应用，点击「下架」，如下图所示：

步骤二： 下架之后，点击「重新发布」，如下图所示：

步骤三： 等待平台管理员重新审核

1.7 开发流程

1.7.1 应用开发流程关键说明

1.7.1.1 应用开发

关键接入项

以下为应用接入到云原生应用平台体系中，开发必须接入环节包含用户身份验证、用户应用权限获取，此外，平台提供其他支持接口方便开发商更好地服务平台客户。

- 用户身份验证

必选项，在应用开发过程中需要主动进行用户身份验证并且保证在登录平台后不需要二次登录，可利用平台提供的消息传输SDK包或自主开发实现

- 获取用户应用权限

非必选项，适配在应用端设置的不同用户的数据权限范围，如：企业文员就没有企业资产管理权限

参照开发手册：用户身份验证

- 其他接入项

非必选项，详细参照开发手册，整体 API 列表：

已支持：

• 身份验证
• 组织架构
• 工单接口
• 消息接口
• 标准数据字典

1.7.1.2 应用调试

步骤一：

• 在测试环境发布应用，配置相应的菜单与权限，并提交审核；（在此请注意至少要设置一名角色）

步骤二：平台应用要满足以下几点，

• 账户逻辑：接收平台消息，同步租户、用户及权限。测试资产云账户是否可以正常免登应用，以及是否符合菜单测试权限。
• 业务逻辑：业务逻辑是否正常操作
• 数据请求：嵌套 iframe 相关页面和网络请求是否正常

1.7.1.3 应用部署

当前平台试运行期间，在 2022 年 6 月 30 号前为试运行阶段
开发商入驻以平台导入为主，开发商可以自行部署，请联系96116-1

平台支持两种应用部署方式：

• 「集中部署」：是指平台统一提供资源，统一部署。集中部署的应用，应填写应用部署相关信息，上传应用 helm 包，提交后等待平台管理员审核。
• 「独立部署」：是指在自有资源部署应用，注册到平台管理的应用。独立部署应用跳过这一步直接进入下一环节。

详细部署文档参见： 应用部署

1.7.2 应用审核上架

开发商完成自我调试和开发后，提交应用上架申请。审核通过后可上架。应用在本租户的单位应用中心可见。

1.7.3 应用发布应用市场

完成用户测试，达到发布条件的，可以申请提交发布应用市场，审核通过后，应用全局可见。

1.7.4 申请迁移生产环境

云原生应用平台支持kubernetes容器环境上私有化部署。当应用在官网测试环境 (opens new window)发布并已经通过用户生产测试，可以提交生产环境部署申请，平台运维方负责将应用部署到生产环境，返回应用部署参数，并开通生产环境租户账号。租户登陆生产环境注册应用，完成上架和发布审核流程，将应用发布生产环境应用市场。应用上架单位，默认为应用所有权人，可以查看订阅本应用的租户情况，并拥有暂停或中止某个租户使用的权利。具体可参考部署文档。

1.8 应用审核标准

1.8.1 应用内容规范

1. 应用名称要言简意赅，精炼、准确、专业的概括应用的核心用户价值以及应用具体解决方案；
2. 应用名称不能含有特殊符号，不能包含关联业务、产品相关的文字；
3. 应用内容描述要遵守国家的相关法律法规、道德规范，遵守云原生应用平台应用开发者相关协议，不能出现反政治、反科学以及色情暴力等内容；
4. 应用名称、图标、内容等不能侵犯他人合法权利如著作权、商业秘密、商标权等；
5. 应用正式上架后不允许自行改名，若需要修改应用名称则要提交平台重新审核；
6. 应用名称与应用图标、应用介绍等内容相互要有关联；
7. 应用图标不能包含未经特殊授权的角标，图标统一圆角、描边、视觉尺寸、角度、渐变方式以及统一扁平化风格（参考UI规范）；
8. 应用功能要求高效、专业、稳定、可用，符合用户正常使用交互习惯；
9. 应用基础体验要符合主流体验设计，加载数据快、流畅度高；
10. 不能出现恶意广告，类似活动推广内容需严格保证不影响、不干扰用户正常使用；
11. 不允许在应用中向用户推送各类广告信息，也不允许推送其他与应用无关内容。
12. 应用不得使用与资产云、资产云开放协同创新中心相同或相似的logo等标识，或其他足以使用户混淆两者关系的行为。

1.8.2 用户对接规范

1. 申请上架云原生应用平台的应用要统一使用云原生应用平台账号体系，不能出现任何有关账号注册，登录的界面；
2. 必须完成用户数据的统一，有相关用户信息的更改需要及时完成同步；
3. 应用需要包含用户的引导或者帮助页面，简要说明应用的核心特性、用户场景等；
4. 应用需要包含客户服务的联系方式。

1.8.3 安全规范

1. 应用开发者要在管理和技术上构建安全管理体系，充分保障企业用户数据安全；
2. 应用要遵守业界主流的安全体验通用规范，保证没有病毒、木马等恶意程序，确保不会带来相关安全漏洞等问题；
3. 应用不能非法窃取、盗用企业、用户信息；
4. 应用需要具有完备的应急事件响应预案（生产环境需达到2小时响应，24小时出解决方案），并定期对该预案进行更新。

1.8.4 数据规范

1. 每个应用上架前需要检查是否有同类型业务应用，分为以下两种情况：

   1.1 首个业务应用：需要将业务主要数据定义到平台中，对接元数据与字典信息，在平台中提供接口标准和信息化数据标准；

   1.2 若有同类型的业务应用：必须遵守首个应用在平台中提供的接口标准和信息化数据标准，在这个基础上，可以增加或参与共同讨论制定新的业务标准。

2. 如该应用是资产相关业务类应用或者资产业务类应用，分以下两种情况：

   2.1 如该应用是资产相关业务类应用，则必须保证定义的主信息项中有与资产业务关联的外键（gs1），确定该业务实体是与那个具体资产进行相对应的。

   2.2 如该应用是资产业务类应用，资产卡片数据都必须基于平台统一卡片库（mongodb），访问平台统一卡片库均通过平台提供的方法进行访问，上架前

要做系统切换的测试报告，确保系统之间能随意切换使用。

3. 具体见数据规范一文

1.8.5 应用体验优化建议

优雅的UI交互

1. 统一页面的交互体验和视觉元素，包含但不限于：页面结构、元素样式、字体、图标、颜色等；
2. 节省空间避免干扰，控制各模块所占的空间比例，减少使用动画效果、背景图等元素，避免对用户造成干扰；
3. 重点突出，正确引导。利用对比，从视觉上强调主操作弱化次要操作，帮助用户理解区分并做出选择；
4. 应用在产品层面要增强用户自引导设计，能让用户自主体验、快速上手等。

清晰的产品逻辑

逻辑清晰路径明确，产品交互及页面结构要有规律可循，让用户能轻易地找到所需信息及操作入口，提高工作效率。

简明易懂的文案

含义明确，文案传达的信息要跟实际效果或操作场景相符合，避免出现词不达意的情况； 通俗易懂，减少使用专业术语、英文缩写或是自己创造的新词汇，避免信息的无效传达；精简扼要，切中场景，避免冗余。

技术层面优化

在4G或WIFI网络条件下，应用页面加载时间要求小于3秒，操作响应时间小于5秒；资源较多的页面建议按需加载或分屏加载，禁止出现404或业务逻辑提示外的其他错误信息提示。

应用客服、运维人员配置

服务商必须为上架应用配置专职的客服、运维人员和联系方式，以便及时有效地沟通、解决可能会发生的问题，问题或故障发生后，要求服务商客服能快速响应并联系协调运维、开发人员解决问题。

1.9 监管规则

省财政厅负责对云原生应用平台市场的监管，对不满足财政部统一业务规范、省数字化改革要求以及云原生应用平台上架审核规范的应用不允许上架，运行中不符合要求的应用采取冻结应用、限制上新应用或下架应用处理。同时，为了使更加优秀、高价值的应用能够在云原生应用市场中获得更多的曝光机会，云原生应用平台每三个月会对平台应用做检查，对于评价较差的应用作下架处理，下架具体规则如下：

1.9.1 冻结应用

1. 无用户使用行为，用户数在< 5（用户个性化定制的应用除外，须提供合同证明）。
2. 应用在使用过程有重大功能缺陷，经用户反应后在5日内未解决。

满足以上两个规则的应用将由平台运维人员结合平台运维数据判断并发送警告消息，若服务商未对当前应用存在的问题及时进行针对性的优化或处理，在通知相应应用服务商的15日后 ，将冻结应用（即不允许新用户购买分发）。

应用被冻结后，服务商需分析总结应用质量下降的原因并针对性的优化解决问题，并汇总具体的优化方案。在优化过程中，服务商需要记录优化过程中的相应记录以及测试结果，在应用优化后，可向云原生应用平台运维团队提交总结后的相关优化报告（包括优化方案、优化记录和用户灰度测试结果）和解冻申请，在平台运维团队审核通过后解冻重启应用。

1.9.2 限制上新应用

不遵守应用规范拒不整改，大量用户反映差的服务商可以采取一定期限内限制上架新应用处罚措施。

1.9.3 下架应用

出现重大安全漏洞，2小时内无法解决的，将下架应用。

应用下架之后，将无法在云原生应用市场中搜索到，且无法被任何单位或集团获取。

1.9.4 重新上架

应用被自动下架之后，服务商需分析总结应用质量下降的原因并针对性的优化解决问题，并汇总具体的优化方案。在优化过程中，服务商需要记录优化过程中的相应记录以及测试结果，在应用优化后，可向云原生应用平台运维团队提交总结后的相关优化报告（包括优化方案、优化记录和用户灰度测试结果）和重新上架申请，在平台运维团队审核通过后重新上架。