3.2.1 构建第一个Module

所有环境准备就绪,就让我们踏上oinone的奇妙之旅吧。先搞个demo模块【展示名为“oinone的Demo工程”,名称为“demoCore”,编码为“demo_core”】试试看,本节学习目的就是能把它启动起来,有个大概的认知。

一、后端工程脚手架

使用如下命令来利用项目脚手架生成启动工程:

  1. 新建archetype-project-generate.sh脚本,或者直接下载archetype-project-generate.sh
#!/bin/bash

# 项目生成脚手架
# 用于新项目的构建

# 脚手架使用目录
# 本地 local
# 本地脚手架信息存储路径 ~/.m2/repository/archetype-catalog.xml
archetypeCatalog=local

# 以下参数以pamirs-demo为例

# 新项目的groupId
groupId=pro.shushi.pamirs.demo

# 新项目的artifactId
artifactId=pamirs-demo

# 新项目的version
version=1.0.0-SNAPSHOT

# Java包名前缀
packagePrefix=pro.shushi

# Java包名后缀
packageSuffix=pamirs.demo

# 新项目的pamirs platform version
pamirsVersion=4.7.8

# Java类名称前缀
javaClassNamePrefix=Demo

# 项目名称 module.displayName
projectName=OinoneDemo

# 模块 MODULE_MODULE 常量
moduleModule=demo_core

# 模块 MODULE_NAME 常量
moduleName=DemoCore

# spring.application.name
applicationName=pamirs-demo

# tomcat server address
serverAddress=0.0.0.0

# tomcat server port
serverPort=8090

# redis host
redisHost=127.0.0.1

# redis port
redisPort=6379

# 数据库名
db=demo

# zookeeper connect string
zkConnectString=127.0.0.1:2181

# zookeeper rootPath
zkRootPath=/demo

mvn archetype:generate \
  -DinteractiveMode=false \
  -DarchetypeCatalog=${archetypeCatalog} \
  -DarchetypeGroupId=pro.shushi.pamirs.archetype \
  -DarchetypeArtifactId=pamirs-project-archetype \
  -DarchetypeVersion=${pamirsVersion} \
  -DgroupId=${groupId} \
  -DartifactId=${artifactId} \
  -Dversion=${version} \
  -DpamirsVersion=${pamirsVersion} \
  -Dpackage=${packagePrefix}.${packageSuffix} \
  -DpackagePrefix=${packagePrefix} \
  -DpackageSuffix=${packageSuffix} \
  -DjavaClassNamePrefix=${javaClassNamePrefix} \
  -DprojectName="${projectName}" \
  -DmoduleModule=${moduleModule} \
  -DmoduleName=${moduleName} \
  -DapplicationName=${applicationName} \
  -DserverAddress=${serverAddress} \
  -DserverPort=${serverPort} \
  -DredisHost=${redisHost} \
  -DredisPort=${redisPort} \
  -Ddb=${db} \
  -DzkConnectString=${zkConnectString} \
  -DzkRootPath=${zkRootPath}

图3-2-1-1 新建archetype-project-generate.sh脚本

  1. Linux/Unix/Mac 需要执行以下命令添加执行权限
chmod +x archetype-project-generate.sh

图3-2-1-2 添加执行权限

  1. 根据脚本中的注释修改项目变量(demo工程可无需编辑)
  2. 执行脚本
./archetype-project-generate.sh

二、后端工程结构介绍

通过脚手架生成的demo工程是我们2.4.1【oinone独特性之单体与分布式的灵活切换】一文中介绍的单模块工程结构,属于入门级的一种,麻雀虽小五脏俱全,特别适合新手学习。

  1. 结构示意图(如下图3-2-4所示)

3.2.1 构建第一个Module

图3-2-1-4 结构示意图

  1. 工程结构说明
工程名 包名 说明
pamirs-demo-api 对外api包,如果有其他模块需要依赖demo模块,则可以在其pom中引入pamirs-demo-api包
constant 常量的包路径
enumeration 枚举类的包路径
model 该领域核心模型的包路径
service 该领域对外暴露接口api的包路径
tmodel 存放该领域的非存储模型如:用于传输的临时模型
DemoModule 该类是Demo模块的定义
pamirs-demo-boot demo模块的启动类
boot 启动类的包路径
DemoApplication Demo模块的应用启动类,遵循spring boot 规范
resources/config/application-dev.yml 研发环境的yml配置文件,遵循spring boot 规范
resources/bootstrap.yml 启动的yml配置文件,遵循spring boot 规范
pamirs-demo-core
action 模型对外交互的行为的包路径
init 模块初始化工作的包路径
manager manager是 service的一些公共逻辑,不会定义为独立的function的类
service service是对应api工程中service接口的实现类,是模型的function

表3-2-1-1 工程结构说明

三、pom.xml介绍

父pom的依赖管理

  1. 一个是启动包依赖
    a. pamirs-boot里是有我们多种启动模式依赖包。教程只介绍标准启动模式
    b. pamirs-base-standard

3.2.1 构建第一个Module

图3-2-1-5 父pom的依赖管理

pamirs-domo-api

一个标准java工程,可以看出只是依赖了,我们的pamirs-base-standard
3.2.1 构建第一个Module

图3-2-1-6 pamirs-domo-api

pamirs-demo-core

一个标准java工程,可以看出只是依赖了,我们的pamirs-demo-api

3.2.1 构建第一个Module

图3-2-1-7 pamirs-domo-core

pamirs-demo-boot

把启动的时候,需要启动的module(模块)对应的jar,进行依赖引入。这样就可以在我们的yml文件中进行启动module的配置

  1. 所需module(模块)对应的jar(如下图3-2-8所示)

3.2.1 构建第一个Module

图3-2-1-8 所需module(模块)对应的jar包依赖

  1. yml文件基础配置,boot工程的yml配置详见4.1.1【模块之yml文件结构详解】一文

3.2.1 构建第一个Module

图3-2-1-9 yml文件

四、DemoModule的定义

到此我们一个oinone中的一个module对应的工程就介绍完了。到目前为止跟一般的spring boot的工程没有太多区别,就多做了一个DemoModule的定义,oinone的所有Module都继承自PamirsModule。

3.2.1 构建第一个Module

图3-2-1-10 DemoModule的定义

配置注解

通过@Module的name属性配置模块技术名称,前端与后端交互协议使用模块技术名称来定位模块。

通过@Module的displayName属性配置模块展示名称,在产品视觉交互层展现。

通过@Module的version属性配置模块版本,系统会比较版本号来决定模块是否需要进行升级。

通过@Module的priority属性配置模块优先级(数字越小,优先级越高),系统会根据优先级取优先级最高的应用设置的首页来作为整个平台的首页。

通过@Module的dependencies属性和exclusions属性来配置模块间的依赖互斥关系,值为模块编码数组。如果模块继承了另一模块的模型或者与另一模块的模型建立了关联关系,则需要为该模块的依赖模块列表配置另一模块的模块编码。

通过@Module.module配置模块编码,模块编码是模块在系统中的唯一标识。

通过@Module.Advanced的selfBuilt属性配置模块是否为平台自建模块。

通过@Module.Advanced的application属性配置模块是否为应用(具有视觉交互页面的模块)。模块切换组件只能查看到应用。

通过@UxHomepage注解配置首页。@UxHomepage注解的model属性指定跳转页面的模型编码,name属性指定跳转页面的视图动作,默认为列表页。如果配置首页为列表页且未定义ViewAction,系统会根据首页配置自动生成。

更多Module的详细元数据描述,详见4.1.4【模块元数据详解】一文

配置扫描路径

设置扫描模型配置的包路径:

  • 使用packagePrefix方法来配置模块需要扫描模型配置的包路径

  • 使用dependentPackagePrefix方法来配置依赖模块的模型配置的包路径;如果不配置,会默认根据依赖模块的配置扫描模型配置的包路径扫描依赖模型

  • 不同模块包路径包含会导致模型加载模块出问题

命名规范

属性 默认取值规则 命名规范
module 无默认值
开发人员定义规范示例:
{项目名称}_{模块功能示意名称}
使用下划线命名法
仅支持数字、大写或小写字母、下划线
必须以字母开头
不能以下划线结尾
长度必须小于等于128个字符
name 无默认值 使用大驼峰命名法
仅支持数字、字母
必须以字母开头
长度必须小于等于128个字符

表3-2-1-2 命名规范

五、DemoModule的启动

  1. 修改yml文件中数据源配置,数据库地址与密码修改为自己本地

  2. 配置license,否则启动会报错,获取授权文件请找官方客户

3.2.1 构建第一个Module

图3-2-1-11 license未配置

  1. 需要为启动或依赖模块配置扫描路径,配置扫描路径:pmairs是我们的oinone的基础包(必选),himalaya,tanggula是我们的业务模型基础包(可选),pro.shushi.pamirs.demo是我们测试项目包路径(必选,只不过它也在pamirs路径下,不填也不错)

3.2.1 构建第一个Module

图3-2-1-12 扫描逻辑配置

  1. 启动应用,我们会发现会报错。这个错误主要因为Oinone默认的是RELOAD(重启)模式,这种模式下只会从数据库中读取已安装模块并与yml文件中配置需要加载的模块对比。如果数据库中没有则会报没有安装过**模块,而我们是第一次启动,前面必然没有安装过模块,所以我们要把模式变为INSTALL,启动参数详见4.1.2【模块之启动指令】一文。如果整个平台第一次启动则回报 'base_sequence_config' doesn't exist

3.2.1 构建第一个Module

图3-2-1-13 启动应用的报错提示

  1. 把模式变为INSTALL再次启动

3.2.1 构建第一个Module

3.2.1 构建第一个Module

图3-2-1-14 把模式变为INSTALL再次启动

  1. 查看日志,看到对应启动字样才代表启动完成,而非Spring Boot的启动完成日志。我们的oinone的启动是在Spring Boot 启动完以后异步启动的

3.2.1 构建第一个Module

图3-2-1-15 启动成功日志

  1. 打开GraphQL客户端Insomnia看对应服务是否暴露

    a. 创建一个demo项目

3.2.1 构建第一个Module

图3-2-1-16 Insomnia操作示意-创建一个新项目

3.2.1 构建第一个Module

图3-2-1-17 Insomnia操作示意-命名为demo

b. 为demo项目创建一个请求集合

3.2.1 构建第一个Module

图3-2-1-18 Insomnia操作示意-创建一个请求集合(第一步)

3.2.1 构建第一个Module

图3-2-1-19 Insomnia操作示意-创建一个请求集合(第二步)

3.2.1 构建第一个Module

图3-2-1-20 Insomnia操作示意-创建一个请求集合(第三步)

c. 创建一个请求 command+N

3.2.1 构建第一个Module

图3-2-1-21 Insomnia操作示意-创建一个请求

3.2.1 构建第一个Module

图3-2-1-22 Insomnia操作示意-选POST模式

3.2.1 构建第一个Module

图3-2-1-23 Insomnia操作示意-输入服务地址

3.2.1 构建第一个Module

图3-2-1-24 Insomnia操作示意-切换body结构为GQL

d. 检验结果,对应后端提供的服务已经有提示了

3.2.1 构建第一个Module

图3-2-1-25 Insomnia操作示意-检验结果

e. 查看schema 文档

3.2.1 构建第一个Module

图3-2-1-26 Insomnia操作示意-查看API文档

3.2.1 构建第一个Module

图3-2-1-27 Insomnia操作示意-查看API文档

3.2.1 构建第一个Module

图3-2-1-28 Insomnia操作示意-查看API文档

恭喜第一个oinone的模块已经启动完成,在下一文中我们通过页面来看看oinone的系统的庐山真面目。

Oinone社区 作者:史, 昂原创文章,如若转载,请注明出处:https://doc.oinone.top/oio4/9228.html

访问Oinone官网:https://www.oinone.top获取数式Oinone低代码应用平台体验

(0)
史, 昂的头像史, 昂数式管理员
上一篇 2024年5月23日 am9:54
下一篇 2024年5月23日

相关推荐

  • 3.5.6.4 动作的配置

    在3.5.3【Action的类型】一文中,我们介绍Action的几种类型,以及组合动作。 通用配置 配置项 可选值 默认值 作用 name 动作名称 label 显示名称 icon 图标 type primary defaultlink primary 按钮类型样式,支持主要样式、次要样式以及链接样式。 bizStyle defaultsuccesswarningdangerinfo default 按钮业务样式,支持成功(green)、警告(yellow)、危险(red)、信息(grey)四种样式。 invisible truefalse condition false 展示规则,有简单的true/false显隐,也支持复杂的表达式 disabled truefalse condition 根据动作上下文类型进行自动推断 是否禁用自动推断规则:当上下文类型为【单行】时,相当于使用表达式LIST_COUNT(context.activeRecords) != 1当上下文类型为【多行】时,相当于使用表达式LIST_COUNT(context.activeRecords) <= 1当上下文类型为【单行或多行】时,相当于使用表达式LIST_COUNT(context.activeRecords) == 0 disabledTitle string 根据动作上下文类型进行自动推断 禁用悬浮提示 表3-5-6-12 动作通用配置 二次确认配置 二次确认框默认支持两种模式,对话框和气泡框; 对话框 图3-5-6-51 对话框提示 气泡框 图3-5-6-52 气泡框警告 配置项 配置项 可选值 默认值 作用 备注 confirm string 二次确认提示文字 配置后开启二次确认 confirmType POPPER(气泡提示框) MODAL(对话框) POPPER 确认框类型 confirmPosition TM(按钮上方) BM(按钮下方) LM(按钮左侧) RM(按钮右侧) BM 确认框位置 气泡框该配置生效 enterText 确定 确定按钮文字 cancelText 取消 取消按钮文字 表3-5-6-13 配置项 弹出层动作配置(窗口动作ViewAction) 目前平台对于弹出层支持了两种展示形式。弹窗(modal/dialog)和抽屉(drawer) 支持两种配置方式【内嵌视图配置】和【引用已有页面】,内嵌视图配置优先于引用已有页面。 内嵌视图配置 该配置对于弹窗和抽屉均适用。 <action name="窗口动作名称" label="创建"> <view model="模型编码" type="form"> <template slot="form" widget="form"> <field data="id" invisible="true" /> <field data="code" label="编码" widget="Input" /> <field data="name" label="名称" widget="Input" /> </template> <template slot="footer"> <action name="$$internal_DialogCancel" label="关闭" type="default" /> <action name="create" label="确定" /> </template> </view> </action> 图3-5-6-53 内嵌视图配置 引用已有页面配置 该配置对于弹窗和抽屉均适用。 <view model="模型编码" type="form"> <template slot="form" widget="form"> <field data="id" invisible="true" /> <field data="code" label="编码" widget="Input" /> <field data="name" label="名称" widget="Input" /> </template> <template slot="footer"> <action name="$$internal_DialogCancel" label="关闭" type="default" /> <action name="create" label="确定" /> </template> </view> 图3-5-6-54 引用已有页面示例 <action name="窗口动作名称" label="创建" resViewName="$viewName$" /> 图3-5-6-55 引用已有页面 弹窗 当窗口动作的路由方式(target)为dialog时,内嵌视图/引用页面将以弹窗形式展示在页面上。 配置项 配置项 可选值 默认值 作用 title…

    2024年5月23日
    1.1K00
  • 4.2.3 框架之SPI机制

    SPI(Service Provider Interface)服务提供接口,是一套用来被第三方实现或者扩展的API,它可以用来启用框架扩展和替换组件,简单来说就是用来解耦,实现组件的自由插拔,这样我们就能在平台提供的基础组件外扩展新组件或覆盖平台组件。 目前定义SPI组件 ViewWidget 视图组件 FieldWidget 字段组件 ActionWidget 动作组件 表4-2-3-1 目前定义SPI组件 前提知识点 使用 TypeScript 装饰器(注解)装饰你的代码 1. 通过注解定义一种SPI接口(Interface) @SPI.Base<IViewFilterOptions, IView>('View', ['id', 'name', 'type', 'model', 'widget']) export abstract class ViewWidget<ViewData = any> extends DslNodeWidget { } 图4-2-3-1 代码示意 2. 通过注解注册提供View类型接口的一个或多个实现 @SPI.Base<IViewFilterOptions, IView>('View', ['id', 'name', 'type', 'model', 'widget']) export abstract class ViewWidget<ViewData = any> extends DslNodeWidget { } 图4-2-3-2 代码示意 3. 视图的xml内通过配置来调用已定义的一种SPI组件 <view widget="form" model="demo.shop"> <field name="id" /> </view> 图4-2-3-3 代码示意 图4-2-3-4 组件继承示意图 当有多个服务提供方时,按以下规则匹配出最符合条件的服务提供方 SPI匹配规则 SPI组件没有严格的按匹配选项属性限定,而是一个匹配规则 按widget最优先匹配,配置了widget等于是指定了需要调用哪个widget,此时其他属性直接忽略 按最大匹配原则(匹配到的属性越多优先级越高) 按后注册优先原则

    2024年5月23日
    1.5K00
  • 3.5.1 构建第一个Menu

    在前面章节中我们也涉及到菜单,因为菜单我们模块就是地图、导航,没有地图、导航就无法畅游模块并进行相关业务操作。在3.3.4【模块的继承】一文关于多表继承的内容就有涉及到菜单的初始化,本文将展开介绍初始化Menu的两种方式分别是:注解式、数据初始化式。 注解式(举例) Step1 分析现有菜单注解 用@UxMenus声明DemoMenus为菜单初始化入口,同时该类在DemoModule配置扫描路径中,那么通过DemoMenus初始化的菜单都挂在demo_core这个模块上。 如果采用这种模式,建议同一个模块的菜单都只配置在一处 package pro.shushi.pamirs.demo.core.init; import pro.shushi.pamirs.boot.base.constants.ViewActionConstants; import pro.shushi.pamirs.boot.base.ux.annotation.action.UxRoute; import pro.shushi.pamirs.boot.base.ux.annotation.navigator.UxMenu; import pro.shushi.pamirs.boot.base.ux.annotation.navigator.UxMenus; import pro.shushi.pamirs.demo.api.model.*; import pro.shushi.pamirs.demo.api.proxy.PetShopProxy; import pro.shushi.pamirs.demo.api.proxy.PetShopProxyA; import pro.shushi.pamirs.demo.api.proxy.PetShopProxyB; @UxMenus public class DemoMenus implements ViewActionConstants { @UxMenu("商店管理")@UxRoute(PetShopProxy.MODEL_MODEL) class PetShopProxyMenu{} @UxMenu("商店管理A")@UxRoute(PetShopProxyA.MODEL_MODEL) class PetShopProxyAMenu{} @UxMenu("商店管理B")@UxRoute(PetShopProxyB.MODEL_MODEL) class PetShopProxyBMenu{} @UxMenu("商品管理")@UxRoute(PetItem.MODEL_MODEL) class ItemMenu{} @UxMenu("宠狗商品")@UxRoute(PetDogItem.MODEL_MODEL) class DogItemMenu{} @UxMenu("萌猫商品")@UxRoute(PetCatItem.MODEL_MODEL) class CatItemMenu{} @UxMenu("宠物品种")@UxRoute(PetType.MODEL_MODEL) class PetTypeMenu{} @UxMenu("萌猫品种")@UxRoute(PetCatType.MODEL_MODEL) class CatTypeMenu{} @UxMenu("宠狗品种")@UxRoute(PetDogType.MODEL_MODEL) class DogTypeMenu{} @UxMenu("宠物达人")@UxRoute(PetTalent.MODEL_MODEL) class PetTalentMenu{} } 图3-5-1-1 菜单注解 Step2 改造现有菜单注解 菜单的层级关系通过@UxMenu的嵌套进行描述 菜单点击效果有三种分别对应不同的Action的类型,关于Action的类型详见3.5.3【Action的类型】一文。 通过@UxRoute定义一个与菜单绑定的viewAction,@UxMenu("创建商店")@UxRoute(value = PetShop.MODEL_MODEL,viewName = "redirectCreatePage",viewType = ViewTypeEnum.FORM),其中viewName代表视图的name(其默认值为redirectListPage,也就是跳转到列表也),value代码视图所属模型的编码,viewType代表view类型(其默认值为ViewTypeEnum.TABLE) @UxServer定义一个与菜单绑定的serverAction,@UxMenu("UxServer")@UxServer(model = PetCatItem.MODEL_MODEL,name = "uxServer") ,其中name代表serverAction的name,model或value代码serverAction所属模型的编码 @UxLink定义一个与菜单绑定的UrlAction,@UxMenu("Oinone官网")@UxLink(value = "http://www.oinone.top”,openType= ActionTargetEnum.OPEN_WINDOW) ,其中value为跳转url,openType为打开方式默认为ActionTargetEnum.ROUTER,打开方式有以下几种 ROUTER("router", "页面路由", "页面路由") DIALOG("dialog", "页面弹窗", "页面弹窗") DRAWER("drawer", "打开抽屉", "打开抽屉") OPEN_WINDOW("openWindow", "打开新窗口", "打开新窗口") 配合菜单演示,PetCatItemAction增加一个uxServer的ServerAction package pro.shushi.pamirs.demo.core.action; ……包引用 @Model.model(PetCatItem.MODEL_MODEL) @Component public class PetCatItemAction extends DataStatusBehavior<PetCatItem> { ……省略其他代码 @Action(displayName = "uxServer") public PetCatItem uxServer(PetCatItem data){ PamirsSession.getMessageHub().info("uxServer"); return data; } } 图3-5-1-2 示例代码 新的菜单初始化代码如下 package pro.shushi.pamirs.demo.core.init; import pro.shushi.pamirs.boot.base.constants.ViewActionConstants; import pro.shushi.pamirs.boot.base.enmu.ActionTargetEnum; import pro.shushi.pamirs.boot.base.ux.annotation.action.UxLink; import pro.shushi.pamirs.boot.base.ux.annotation.action.UxRoute; import pro.shushi.pamirs.boot.base.ux.annotation.action.UxServer; import pro.shushi.pamirs.boot.base.ux.annotation.navigator.UxMenu; import pro.shushi.pamirs.boot.base.ux.annotation.navigator.UxMenus; import pro.shushi.pamirs.demo.api.model.*; import pro.shushi.pamirs.demo.api.proxy.PetShopProxy; import pro.shushi.pamirs.demo.api.proxy.PetShopProxyA; import pro.shushi.pamirs.demo.api.proxy.PetShopProxyB; import pro.shushi.pamirs.meta.enmu.ViewTypeEnum; @UxMenus public class DemoMenus implements ViewActionConstants { @UxMenu("商店") class ShopMenu{ @UxMenu("UxServer")@UxServer(model = PetCatItem.MODEL_MODEL,name = "uxServer") class ShopSayHelloMenu{ } @UxMenu("创建商店")@UxRoute(value = PetShop.MODEL_MODEL,viewName = "redirectCreatePage",viewType = ViewTypeEnum.FORM) class ShopCreateMenu{ }…

    2024年5月23日
    1.4K00
  • 5.4 基础支撑之商业关系域

    PamirsPartner作为商业关系与商业行为的主体,那么PamirsPartner间的关系如何描述,本文将介绍两种常见的设计思路,从思维和实现两方面进行对比,给出oinone为啥选择关系设计模式的原因。 一、两种设计模式对比 设计模式思路介绍 角色设计模式思路介绍 从产品角度枚举所有商业角色,每个商业角色对应一个派生的商业主体,并把主体间的关系类型进行整理。 图5-4-1 角色设计模式 关系设计模式思路介绍 从产品角度枚举所有商业角色,每个商业角色对应一个派生的主体间商业关系 图5-4-2 关系设计模式 设计模式对应实现介绍 角色设计模式实现介绍 不单商业主体需要扩展,关系也要额外维护,可以是字段或是关系表。一般M2O和O2M字段维护,M2M关系表维护。 创建合同场景中甲方选择【商业主体A】,乙方必须是【商业主体A】有关联的经销商、分销商、零售商、供应商等,则在角色设计模式下就非常麻烦,因为关系都是独立维护的 图5-4-3 角色设计模式实现介绍 关系设计模式实现介绍 只需维护商业关系扩展 同时在设计上收敛了商业关系,统一管理应对不同场景都比较从容 图5-4-4 关系设计模式实现介绍 二、oinone商业关系的默认实现 首先oinone的商业关系选择关系设计模式 其次模型上采用多表继承模式,父模型上维护核心字段,子模型维护个性化字段。

    2024年5月23日
    1.4K00
  • 开放平台

    1. 开放介绍 开放平台是将 Oinone 平台内的能力向外开放,如开放商品信息查询接口、发货单查询接口等。 包括开放接口、三方应用管理。 2. 开放接口 管理开放接口信息,基本操作包括:新增、编辑、停用/启用。 2.1. 新增接口 定义API名称,选择业务域、关联模型,方法支持GET/POST/PUT/DELETE,配置接口参数、响应结果等信息。 2.2. 编辑接口 编辑需要填写的内容同新增,不做赘述。 2.3. 停用/启用 新增后为已启用,停用后,API将无法访问,请慎重使用;针对停用的API进行启用。 3. 应用管理 管理开放接口集成的外部应用,基本操作包括:新增、查看密钥、授权调整、停用/启用。 3.1. 新增应用 新增应用时,输入应用名称,选择数据传输加密算法AES密钥或RSA公钥,勾选授权的API接口。 3.2. 停用/启用 新增后为已启用,停用后,应用将无法访问授权的接口,请慎重使用;针对停用的应用可进行启用。 3.3. 查看密钥 点击【查看密钥】,弹窗展示当前 API Secret,支持复制。 3.4. 授权调整 指调整当前应用的授权的API 范围。

    2024年6月20日
    1.9K00

Leave a Reply

登录后才能评论