（一）浏览应用
进入 “应用中心” 后，可以浏览应用桌面上的所有应用：
在列表上，可以看到应用的图标、名称、别名，还有授权等级、配置方式以及显示控制。
授权等级是指该应用可以授权给什么类型的用户，如：
我们在这里可以看到，“用户中心” 应用的授权级别是“管理员”，也就是说，这个应用只有管理员属性的用户才能使用，其他普通用户是无权使用的。
“是否显示” 这一列，是 “显示控制”，这一列决定了这个应用是不是会出现在应用桌面上。管理员具备更改这个 “显示控制” 属性的权限，也就是说，如果管理员不希望这里面的某个应用被自己的客户使用，就可以把这个应用的显示控制设置为 “否”，这样，任何用户在应用桌面上就看不到有这个应用。
对这些应用的所有管控，如配置、修改、授权等等，都是通过应用的操作菜单进行的：
操作菜单有四项操作，分别是：查看详情、编辑应用、管理菜单和删除应用。
这里需要特别说明的是，MixIOT 标准发布的应用是不能被删除的，只能删除客户自己创建（开发）的应用。MixIOT 是个开放的平台，客户可以开发自己的东西或者整合自己已有的东西。
在 MixIOT 的不同版本，也许展现形式会有所不同。MixIOT 发布的标准应用，操作菜单中不会出现删除，这种情况会避免删除误操作。
（二）应用详情
我们查看 “AI应用” 的详情：
（1）详情基本信息：
应用的基本信息包括：
a）应用图标
每个应用都有一个图标，图标显示在应用桌面的应用块上。这是一个可以由管理员自己选择的图标。MixIOT提供了一系列图标供选择，同时也接受使用自己创建的其他图标。
b）应用名称和别名
也是显示在应用桌面的应用块上。应用名称和别名也是可以修改的。
c）是否显示
就是显示控制，决定该应用是否显示在应用桌面上。
d）应用类别
应用类型有两种，PC 应用和手机 App。
e）授权等级
该应用面向哪一类角色使用者授权。
f）配置方式
是指该应用的配置形式。MixIOT 是一个由各种服务组成的体系，应用的本质是这些服务引用和交互。应用配置方式，是指形成该应用的方法。 MixIOT 应用有两种应用配置方法， 脚本配置形式或URL形式。
脚本配置形式是用 MixIOT 应用脚本规范来配置的应用；而 URL 是直接通过 URL 引用来配置一个应用，这些后面都有详细的解释。
（2）菜单列表
菜单列表是这个应用的菜单板块、每个菜单板块的菜单项、每个菜单项对应的视图列表，以及每个视图列表所包含的字段（列）、工具栏以及操作菜单。
以 “API管理” 应用为例，从这张图可以看到，这个 “全部授权” 视图列表的别名（标识）是 ApiproxyAuthAll，这个视图列表的列表字段有七个，每个列都有自己的标识。
了解这些，实际上就是在了解 MixIOT 应用构成的规范。如果需要自己去开发创建自己的应用或者去整合已有的应用，就需要对此有非常清晰的理解。
前面说，这个应用是 “脚本配置”，我们看一下这个配置应用的脚本：
这个脚本就是构成应用的配置脚本。换句话说，MixIOT 体系本身就是一个后台的服务系统，遵循一个规范的服务机制。我们把需要的服务内容抽取出来，就跟餐厅点菜一样，选择需要的单项，最后构成一个应用整体。
同时，这也是一个应用扩展的规范，也就是说我们可以自己开发自己的应用，无论用什么方式开发的应用，都可以用这种脚本配置规范来定义这个应用的呈现方式。
（3）编辑应用
我们可以通过编辑功能，修改应用的一些属性：
应用的名称是可以修改的，如果客户有更好的名字，可以替代 MixIOT 标准发布的应用名字。
应用的别名实际上是应用的标识，一般不能修改。
应用的图标可以上传自己设计的，或者 从MixIOT 图标库里选择：
其他的内容，如授权方式、配置方式，都不能直接在编辑中修改，而是要采用其他方式。
我们可以把需要的内容，编写到描述里面：
（4）菜单管理
MixIOT 的应用的构成，是菜单板块、菜单项以及菜单项对应的视图列表。应用的菜单管理，就是对菜单板块、菜单项和视图列表进行管理。
进入菜单管理：
这是我们之前看到过的全部菜单板块、菜单项以及对应的视图列表，这些都是该应用标准的发布内容。
（三）做两件事
如果需要，我们可以做两个事情：
第一件事，创建一个新的菜单板块；
第二件事，在自己创建的菜单板块中，创建新的菜单项。
这里需要说明的是，在 MixIOT 发布的标准应用中，应用的功能和内容是不能改变的，但可以根据使用者需要，创建自己的菜单板块或者菜单项。
MixIOT 的用户授权，是以“菜单项–视图列表”为基础的，这就是通常意义上的“让某个用户能看到哪些内容”，我们就把这些内容都集中放到一个视图列表中。
还是通过一个实例，来讲解菜单管理的方法。
先看一下，现在 “API管理” 这个应用的内容：
在 “API管理” 这一章中，介绍过这些都是 API 的使用授权，非常重要，因为授权里面包括了秘钥（Token）字符串。现在，我们希望让管理 MES的用户，只能看到针对 MES的 API使用授权；让管理 SAP的用户只能看到针对 SAP的API使用授权。
要解决这个问题，可以创建两个新的菜单项，分别把 API-MES 和 API-SAP 塞进去两个不同的菜单项，这样就可以把这两个菜单项授权给两个不同的用户。
（1）添加新视图授权
按 “＋”号进行视图的授权：
可以看到视图授权的配置项：
先 “＋添加菜单”：
菜单的名字是 “分项授权”，别名是 GroupAuth。
父级菜单，就是授权管理，其实就是应用。
排序写100，这是因为我们希望这个 “分项授权” 菜单板块，是在 “全部授权” 这个菜单板块之下的。
最后可以选择一个图标。
完成这个设置后，就可以在这个菜单板块下面，创建一个菜单项。
完成菜单创建后，就可以创建新的视图了：
我们给这个创建的视图，取个名字 “MES接口授权”：
需要注意的是，这只是我们需要创建的视图的名字。
在 “应用总览” 一章中，详细介绍过 MixIOT 应用形式和规范，包括菜单板块（菜单项）、视图和视图列表等等。在这里重新综合梳理一下：
一个应用可以包括多个菜单项（每个菜单项就是一个菜单板块）；每个菜单板块包括一个或多个视图（视图项）。一个视图包括的内容有三个：视图列表（每个列表，包括多个列/字段）、视图工具栏（包括一个或多个功能），以及操作菜单（包括一个或多个操作）。
（2）全视图
MixIOT 发布的标准应用，根据应用本身的需求和设计，有一个或多个菜单项（菜单板块），每个菜单板块至少有一个 “全视图（Full View或All View）”。所谓全视图，就是所有内容都在的视图，一个是数据内容，一个是相关的功能和操作，都是齐全的。
视图（视图项）在 MixIOT 应用中的地位是非常重要，同时也是非常特别的，这是因为 MixIOT 应用的呈现方式和授权，都是基于视图来实现的。我们下面用一个容易理解的例子，对视图进行相关讲解。
下面这张表格是某团队的花名册：
这个花名册就是一个 “全视图”，这是因为团队的所有人的信息都在这个地方了。这里的 “全（All 或 Full）” 是指信息是全的。
如果团队来了个新人（陆大鹏），毫无疑问，这个新人的名字也会在这个全视图里面。如果这个团队的信息可以展现给这个团队的所有人，那就只需要一个这样的全视图就够了，因为团队的所有人，都可以通过这个视图掌握整个团队人员的信息。
但如果这个团队是承担某项秘密工作的团队，按照秘密工作的要求，其中一个规则是只有本部门的人员可以了解本部门人员的信息。
那么，我们可以去创建三个视图，用来分别 “装” 这三个不同部门的人员信息，这三个视图分别是：“研究部视图”、“实验部视图” 和 “工程部视图”。
这三个视图的特点（或者说条件）很清晰，都是把同一个部门的人员信息放到同一个视图里面。有了这三个视图就好办了，只需要把 “研究部视图” 授权给研究部的人员、把 “实验部视图” 授权给实验部的人员，把 “工程部视图” 授权给工程部的人员。
这样，每个人都在这个秘密工作的规则之下，就各得其所。
我们注意这个视图是动态的，而且是维持最新变化的。比如，有了新的成员、有成员的离开，或者有人员部门调动，这些变化在这三个视图上都会体现。无论怎么变化，授权规则是不需要改变的，每个人得到的人员信息都是符合要求的。
再进一步解释，为了攻克难关，这个团队成立了 “突击队”，突击队都是由年龄在 30岁及以下的团队成员组成，他们把苦活儿累活儿都包圆儿了。按规定，突击队的成员才能掌握突击队人员的信息。
这个时候，也是一样的，我们就创建一个新的 “突击队视图”，只不过这个视图的特点是 “年龄不超过30”：
但这个 “突击队视图”，比起 “全视图” 和其他三个部门视图来说，少了一列 “部门” 信息。
这种情况下，我们以 “马九山” 为例。马九山获得的授权有两个，一个是 “实验部视图” ，因为 马九山是实验部的人；另一个是 “突击队视图”，因为马九山年龄没超过30岁。
虽然马九山知道突击队里面都有谁，但除了本部门的人外，他并不知道突击队里的其他人分属哪个部门。
攻克难关的工作是长期的，突击队一直要存在，而且还必须都是风华正茂年富力强的队员。但突击队里并没有冻龄队员，所以一年后，情况会变成这样：
马九山超过30岁了，不得不离开青年突击队，这样他就自动失去“突击队视图”的权限，但还保有“实验部视图”的权限，因为他还在实验部。
从上面这个讲解，应该可以理解：
- 一定存在一个基准，这个基准就是 “全视图”，这是一个 “全集”；
- 其他的视图，都是这个全集的某种条件下的 “子集”；
- 这个 “子集”，可以是 “行” 的，也可以是 “列” 的；
- 视图可以对应某种授权关系。
下一步，完成新视图的创建：
就是定义 “行” 子集的条件。
下—步，是定义 “列” 子集的条件：
接下来，就是分别要完成工具栏和操作菜单的子集：
完成了这个勾选，就可以确定并保存创建的视图：
在这里可以看到，这个应用全部的菜单项（菜单板块）以及它们下面所包含的各个视图。
同理，可以创建 SAP接口视图：
创建完成后，再进入“API管理” 应用去看一下：
这时我们并没有看到刚才创建的菜单板块和其下的两个视图。原因就是没有完成授权。
授权的过程是在 “用户中心” 应用完成的。
打开 “用户中心-角色列表” 菜单板块，进入 “全部角色”，现在要把刚才创建的两个视图授权给 “SERG超级管理员” 这个角色：
这个过程就是对角色的“应用授权”。
首先在列表中找到 “API管理” 这个应用：
然后，再勾选我们新创建的菜单项和视图以及希望授权的功能和操作，最后保存这些操作的结果。
那么，整个菜单视图的授权工作就完成了。
重新打开 “API管理”，可以清晰地看到新创建的菜单项和两个视图：
进入视图：
（四）创建应用
MixIOT 除了可以在已有的应用中创建新的菜单项和视图，还可以创建新的应用。
这里需要说明的是，创建新应用只是把应用集成到 MixIOT 应用桌面，而这些应用必须事先按 MixIOT 的应用规范开发好。MixIOT 应用的开发，不在这里做详细的介绍，有需要可以参考《MixIOT应用开发手册》。
实际上，MixIOT 应用不管用什么方式去开发，最终都需要集成到 MixIOT 应用系统。
集成的方式有两种，一种是 URL链接方式，也就是说，新应用虽然用到 MixIOT API，但本身形式上就是独立存在的，通过一个 URL就可以进入这个应用。这种情况，这个应用相对 MixIOT 而言，实际上是 “体外” 的，我们只需要在 MixIOT 应用桌面上，为这个新应用创建一个统一的图标，这种叫 “URL配置”应用。
下面这个 URL配置，就是把本企业自己开发的 “机组实验管理” 应用集成到 MixIOT 应用桌面：
完成了 MixIOT 应用创建后，还需要授权这个应用给某个角色：
按添加，勾选创建的新应用：
再回到 MixIOT 应用桌面，刷新后就可以看到这个应用：
这样，这个企业自己开发的 “机组实验管理” 就被集成到 MixIOT了。
这是一种相对简单的做法，目的就是把相关的内容，都整合到 MixIOT 应用入口。事实上，MixIOT 标准发布的应用中，也有一些是这种形式的， 比如 “CLI控制台”、“显示板设计”等等。
除了 URL配置方式，还有脚本配置方式：
与URL配置不同，脚本配置的应用是 MixIOT “体内” 应用，也就是说这种应用按 MixIOT 应用的规范开发，打包成一个 MixIOT Block，部署到SERG名下的MixIOT 系统内。
同样，这个应用需要在 “用户中心” 里面给用户角色进行应用授权。但在这个授权之前，我们还需要做一件事，就是通过交互的方式，把这个 Block 变成MixIOT 的应用，这个过程就是去创建菜单项（菜单板块）和视图，以及视图的列表、工具和操作。
这个可以通过应用的 “菜单管理” 进行：
进入菜单管理：
菜单项（菜单板块）和视图，以及视图列表、工具（命令）和操作，每一项命名都必须与 Block 开发的一致，这样才会有效果。
这里就不细说这个应用配置过程了，完成这个配置后，这个应用就算是完成了。
（五）“我的应用”
MixIOT 应用配置规范，提供了一个使用者定制化的极大便利。MixIOT 应用，是一个非常庞大而且复杂的体系，以SERG集团 MixIOT 为例，该集团的任何一个使用者，都不可能把 MixIOT 应用都用个遍，一般来说，一个使用者（用户）的使用范围，是某几个应用，甚至只有这几个应用中的某几个板块。
通常的情况下，使用者需要在不同应用之间来回切换，非常苦恼。而 “应用中心” 的另 一个作用，就是可以根据使用者的实际使用需求，去定制他们专用的应用 。
来看看SERG集团的角色：
SERG集团的电站主管这个角色的工作内容非常分散，涉及到的应用非常多，分散在对象管理（对象）、维保管理（维保任务）、自动报表（班次报表、日报表、月报表）、统计计算（统计、计算）、调度控制等等。
这样，我们就可以帮他们创建一个 “主管的应用”，把这个应用授权给主管这个角色：
进入我们创建的这个应用：
然后，再用 “菜单管理” 操作，把主管需要做的事情整合到一起。
然后，把这个应用授权给电站主管：
这样，就完成了这个专门为电站主管构造的应用：
（六）总结
“应用中心” 是集中管理应用的应用，是 MixIOT 体系的应用中枢。MixIOT 应用形式的核心和关键，就是要规划好应用的菜单板块，设计好每一个视图，包括视图列表、视图工具以及视图操作。
经过这个应用的学习，我们应该建立 “全视图”、“全列表/字段”、“全工具”、“全操作” 的概念，这是构建一个应用的基础。
MixIOT 标准发布的应用版本，也都是仅仅包括了最基础的 All View/Full View，在实际使用中，都需要经过管理员的精细调整，这是平台管理员非常重要的一个工作。
