一种消息管理方法和装置与流程

本发明涉及计算机技术领域，尤其涉及一种消息管理方法和装置。

背景技术：

现有b端消息开放平台具有消息接入、消息路由、消息管理等服务，目前仅支持商家pc端/移动端的消息中心，商家可通过在线提醒或离线推送两种方式快速查看消息，以及通过重要消息提醒快速处理业务，以此提高工作效率，例如订单、售后、触发预警等消息。

在实现本发明的过程中，发明人发现现有技术至少存在如下问题：

1)商家后台、营销中心等平台端均有各自的建设需求，但若在各平台端单独建设消息管理中心存在成本高、效率低等问题；

2)同一平台端存在多业务域、多角色的情况，所需的消息触达场景也较为复杂多样，而现有平台端无法根据租户所在业务域、角色等差异化展示消息，导致租户看到的冗余的消息类型过多，进而影响消息触达效率以及租户的业务处理效率；

3)各平台端之间对于消息分类、层级关系、数据、状态(已读/未读)没有进行统一管理，导致租户在不同平台端查看到的消息较为混乱，同一消息的状态不同步，导致租户阅读消息体验差的问题。

技术实现要素：

有鉴于此，本发明实施例提供一种消息管理方法和装置，至少能够解决现有平台端的消息中心需单独建立的问题。

为实现上述目的，根据本发明实施例的一个方面，提供了一种消息管理方法，应用于消息服务系统中的多个平台端，且每个平台端对应于至少一个租户，包括：

确定与平台端对应的租户，基于所述租户的租户标识，从消息租户组件中获取与所述租户对应的消息类型；

从消息平台端获取与所述消息类型对应的业务数据消息，对所述业务数据消息进行打包处理；

基于所述平台端的标识，将打包后的业务数据信息发送至所述平台端，以通过所述平台端解析所述业务数据信息并推送至所述租户进行显示。

可选的，在所述确定与平台端对应的租户之前，还包括：接收所述平台端传输的创建标识请求，若存在与所述平台端对应的租户，则基于所述平台端的信息进行标识创建。

可选的，在所述确定与平台端对应的租户之前，还包括：

所述消息租户组件接收所述平台端传输的创建租户请求，将所述创建租户请求中的业务需求描述传输至审核服务端；

若所述审核服务端反馈的审核结果为通过，则基于所述业务需求描述进行租户标识创建。

可选的，所述基于所述租户的租户标识，从消息租户组件中获取与所述租户对应的消息类型，包括：所述消息租户组件基于所述租户标识，从所述消息平台端获取与所述租户对应的所述消息类型；其中，所述消息类型与预先赋予所述租户的角色对应。

可选的，还包括：所述消息租户组件获取所述租户的数据存储需求，确定与所述数据存储需求对应的存储配置信息；基于所述存储配置信息为所述租户创建数据存储单元，以将所述消息类型存储至所述数据存储单元。

为实现上述目的，根据本发明实施例的另一方面，提供了一种消息管理装置，应用于消息服务系统中的多个平台端，且每个平台端对应于至少一个租户，包括：

消息类型获取模块，用于确定与平台端对应的租户，基于所述租户的租户标识，从消息租户组件中获取与所述租户对应的消息类型；

业务数据获取模块，用于从消息平台端获取与所述消息类型对应的业务数据消息，对所述业务数据消息进行打包处理；

业务数据推送模块，用于基于所述平台端的标识，将打包后的业务数据信息发送至所述平台端，以通过所述平台端解析所述业务数据信息并推送至所述租户进行显示。

可选的，还包括标识创建模块，用于：接收所述平台端传输的创建标识请求，若存在与所述平台端对应的租户，则基于所述平台端的信息进行标识创建。

可选的，还包括租户标识创建模块，用于：

所述消息租户组件接收所述平台端传输的创建租户请求，将所述创建租户请求中的业务需求描述传输至审核服务端；

若所述审核服务端反馈的审核结果为通过，则基于所述业务需求描述进行租户标识创建。

可选的，所述消息类型获取模块，用于：所述消息租户组件基于所述租户标识，从所述消息平台端获取与所述租户对应的所述消息类型；其中，所述消息类型与预先赋予所述租户的角色对应。

可选的，还包括存储单元创建模块，用于：所述消息租户组件获取所述租户的数据存储需求，确定与所述数据存储需求对应的存储配置信息；基于所述存储配置信息为所述租户创建数据存储单元，以将所述消息类型存储至所述数据存储单元。

为实现上述目的，根据本发明实施例的再一方面，提供了一种消息管理电子设备。

本发明实施例的电子设备包括：一个或多个处理器；存储装置，用于存储一个或多个程序，当所述一个或多个程序被所述一个或多个处理器执行，使得所述一个或多个处理器实现上述任一所述的消息管理方法。

为实现上述目的，根据本发明实施例的再一方面，提供了一种计算机可读介质，其上存储有计算机程序，所述程序被处理器执行时实现上述任一所述的消息管理方法。

根据本发明所述提供的方案，上述发明中的一个实施例具有如下优点或有益效果：平台端可直接接入消息中心组件形成各端消息中心，无需重新研发，从而减少各平台端的研发成本，同时保证多端消息分类、层级关系、数据、状态的统一管理。

上述的非惯用的可选方式所具有的进一步效果将在下文中结合具体实施方式加以说明。

附图说明

附图用于更好地理解本发明，不构成对本发明的不当限定。其中：

图1是根据本发明实施例的一种消息管理方法的主要流程示意图；

图2为单个平台端显示业务数据消息的示意图；

图3是根据本发明实施例的一种可选的消息管理方法的流程示意图；

图4是根据本发明实施例的一种具体地消息管理方法的流程示意图；

图5是根据本发明实施例的一种消息管理装置的主要模块示意图；

图6是本发明实施例可以应用于其中的示例性系统架构图；

图7是适于用来实现本发明实施例的移动设备或服务器的计算机系统的结构示意图。

具体实施方式

以下结合附图对本发明的示范性实施例做出说明，其中包括本发明实施例的各种细节以助于理解，应当将它们认为仅仅是示范性的。因此，本领域普通技术人员应当认识到，可以对这里描述的实施例做出各种改变和修改，而不会背离本发明的范围和精神。同样，为了清楚和简明，以下的描述中省略了对公知功能和结构的描述。

参见图1，示出的是本发明实施例提供的一种消息管理方法的主要流程图，包括如下步骤：

s101：确定与平台端对应的租户，基于所述租户的租户标识，从消息租户组件中获取与所述租户对应的消息类型；

s102：从消息平台端获取与所述消息类型对应的业务数据消息，对所述业务数据消息进行打包处理；

s103：基于所述平台端的标识，将打包后的业务数据信息发送至所述平台端，以通过所述平台端解析所述业务数据信息并推送至所述租户进行显示。

上述实施方式中，对于步骤s101和s102，本发明可适用于电商、第三方服务商等消息开放平台，所涉及的平台端代表需求方的不同端，例如商家后台、营销中心、营销中心、宙斯平台端等，数量为多个，且一个平台端可以关联有至少一个租户。

为支撑多端、多域、多角色的消息显示管理，本发明在消息开放平台中设置有前端消息中心组件(jssdk)和后端消息租户组件；其中，消息中心组件用于支撑各平台多端消息中心，消息租户组件用于支持多业务域、多角色业务场景，对于消息租户组件的使用具体参见后续图3所示描述。

消息中心组件在接收到平台端传输的创建app_id(即标识)请求后，可以直接基于该平台端的信息进行app_id创建。进一步的，为避免平台端申请app_id但不使用的情况(即无租户)，在创建app_id之前，可以首先判断是否存在与该平台端对应的租户tenant_id(即租户标识)：

1)若存在，消息中心组件审核通过后基于平台端信息完成app_id创建，以将app_id作为区分各个平台端的唯一标识；其中，app_id可以为平台端的名称或与数字、字母等的叠加；

2)若不存在，则不进行app_id创建，降低资源占用情况。

一个平台端可以关联有多个租户tenant_id，例如商家后台关联有商家、供应商、开发者等。平台端可视为是消息传输的中间者，最终消息仍是推送至租户处进行显示。

消息类型type作为从消息平台端获取业务数据消息的依据，存储于消息平台端，后经由消息租户组件传输至消息中心组件中，具体参见图2所示：

1)消息中心组件根据平台端下租户的标识tenant_id，从消息租户组件中获取该租户下自行创建、管理的消息类型type；

2)消息中心组件根据各消息类型type，从消息平台端获取相应的业务数据消息，例如消息内容、标题、数据、状态(已读/未读)等。

3)消息中心组件通过打包工具webpack对业务数据消息进行构建打包，且支持window变量、amd、es6等多种接入方式的包文件。

其中，webpack是一个开源的前端打包工具。webpack提供了前端开发缺乏的模块化开发方式，将各种静态资源视为模块，并重新生成优化过的代码。

对于步骤s103，消息中心组件通过消息-订阅模式，将开放的接口暴露给平台端，如订阅消息未读数更新、消息已读事件，从而满足多段在消息展示细节上的差异化需求。

平台端可以选择静态资源引入或npm(nodepackagemanager，一个node.js包管理和分发工具)安装方式接入jssdk前端消息组件，形成自身平台的消息中心，参见图2所示示例，为平台端显示同一业务数据消息的示意图；其中，静态资源为客户端发送请求到web服务器，web服务器从内存取到相应的文件返回给客户端，客户端解析并渲染显示。

进一步的，上述两种接入方式可以通过typescript+scss+webpack技术栈实现。通过使用javascript标准ecmascript6的模块和类将消息中心组件拆分成多个小组件模块：消息中心、消息订阅、动画过渡列表、分页、单条消息组件等，便于后续的开发维护；在组件开发中使用强类型语言typescript，通过显示定义变量和参数类型，使项目更加容易阅读，而且可以在编译阶段自动发现大部分类型错误。样式文件通过使用scss和bem规范进行编写，加强代码可读性和单元化，同时通过scss变量接入方可以自定义主题，以满足多端系统设计风格多异的需求。

平台端在接收到业务数据消息并解析后，会基于业务数据消息中的tenant_id将其推送至相应租户。另外，还可以根据租户登录状态精准的进行在线或离线通知，例如，租户在线，则将消息推送至租户对话框中；若离线，则在消息图标/文字右上角进行消息数量显示。

另外，前后端的通信通过短轮询的方式不断更新消息中心组件中消息的未读数，后端通过接口告知前端未读数接口请求的时间，在消息访问量过大时将刷新时间加长，以减少后端接口的压力从而达到消息量降级的目的。

上述实施例所提供的方法，平台端可直接接入消息中心组件形成各端消息中心，无需重新研发且组件可快速复用，达到降本提效的目的，同时对于同一消息可以同步至多个平台端进行显示，以保证多端消息分类、层级关系、数据、状态的统一管理。

参见图3，示出了根据本发明实施例的一种可选的消息管理方法流程示意图，包括如下步骤：

s301：消息租户组件接收平台端传输的创建租户请求，将所述创建租户请求中的业务需求描述传输至审核服务端；

s302：若所述审核服务端反馈的审核结果为通过，则基于所述业务需求描述进行租户标识创建；

s303：基于所述租户标识，从所述消息平台端获取与所述租户对应的所述消息类型；其中，所述消息类型与预先赋予所述租户的角色对应；

s304：消息中心组件接收所述平台端传输的创建标识请求，若存在与所述平台端对应的租户，则基于所述平台端的信息进行标识创建；

s305：基于所述租户的租户标识，从消息租户组件中获取与所述租户对应的消息类型；

s306：从消息平台端获取与所述消息类型对应的业务数据消息，对所述业务数据消息进行打包处理；

s307：基于所述标识，将打包后的业务数据信息发送至所述平台端，以通过所述平台端解析所述业务数据信息并推送至所述租户进行显示。

上述实施方式中，对于步骤s304～s307可参见图1所示步骤s61～s63的描述，在此不再赘述。

上述实施方式中，对于步骤s301和s302，消息开放平台提供消息租户组件，主要复用消息开放平台能力，以在消息开放平台中独立管理租户的消息分类、标题、触达渠道、模板、跳转协议等信息。

平台端若有租户需求时，在消息租户组件中提交“创建租户”请求，消息租户组件对平台端提交的brd(businessrequirementdocument，业务需求描述)进行审批，审批通过后创建租户标识tenant_id；其中，tenant_id代表一个租户的唯一标识。

其中，brd是基于商业目标或价值所描述的产品需求内容文档(报告)，用于产品在投入研发之前，由企业高层作为决策评估的重要依据。

进一步的，对于brd的审核，可以是消息租户组件的自行审核，也可以是以递交、邮件等方式，将该brd发送至审核服务端，以通过审核服务端的工作人员(可以是人或机器)进行审核，之后将审核结果反馈至消息租户组件。

若审核结果为通过，消息租户组件会基于brd建立tenant_id；否则，传输审核失败信息至平台端，告知创建tenant_id失败。

对于步骤s303，消息类型与租户之间存在映射关系，租户可以单独持有一种消息类型type，也可以同一种消息类型type同时触达多个租户。

对于租户的消息类型：

1)可以由租户自行指定，例如根据自身实际需求进行消息类型创建，之后与该租户的tenant_id进行绑定；

2)租户在创建时，直接根据角色模板创建相应的角色，因此租户的消息类型即为与其角色对应的消息类型；其中，角色可以为店长、客服、运营、财务、仓储、美工等。

进一步的，每种角色对于不同消息类型可以具有不同的访问权限，因此可以通过访问权限进行消息类型确定。

更进一步的，还可以根据租户所处业务域进行角色确定，一个业务域可以对应于多个角色，需要租户自主选择，例如物流-仓储、店铺-店长、供应商-客服、金融-财务等，以此形成业务域-角色-消息类型的对应关系。

消息类型对应于等级划分，例如可以分为一级分类和二级分类，每个租户tenant_id绑定一组唯一的一级分类和二级分类；其中：

1)一级分类：为消息中心的第一层分类，例如，交易、商品、营销；

2)二级分类：为消息中心根据一级分类进行的二级分类划分，形成一对多或一对一的对应关系；例如，图2交易消息分类下的新订单、买家已付款、订单完成、中差评提醒等。

租户获取消息一级分类时根据对应的二级分类进行过滤，并根据消息二级分类对应的存储参数动态选择数据源搜索数据，通过数据库和多级缓存相结合方式，保证高并发请求下的影响速度。

另外，考虑到不同租户对消息存储需求的不同，例如对消息存储时间长短、安全性要求、消息使用的场景(多读少或者读多写少)，消息租户组件提供了mysql、redis持久化、elasticsearch、hbase多种存储方，基于不同存储需求支持配置不同的存储方案，极大满足了租户存储需求的多样性，并且可以灵活的扩展。

上述实施例所提供的方法，消息开放平台通过租户组件管理，针对不同租户的业务域、角色进行不同的消息类型划分，从而实现租户差异化管理，结合前端消息中心组件，用以支撑多端、多域、多角色消息数据、状态的统一管理。

参见图4，示出了根据本发明实施例的一具体地消息管理方法流程示意图，包括如下步骤：

1)平台端向消息租户组件申请创建租户；

2)消息租户组件将申请中的brd传输至审核服务端进行审核；

3)若审核服务端的审核结果为通过，则生成租户tenant_id；

4)平台端在接收到租户tenant_id后，向消息中心组件申请创建app_id；

5)消息中心组件判断是否存在与该平台端对应的租户；

6)审核通过后，创建app_id；

7)消息租户组件根据tenant_id，从消息平台端获取该租户的消息类型；

8)消息平台端根据预先赋予租户的角色，将与该角色对应的消息类型作为与该tenant_id对应的消息类型；

9)消息平台端返回该租户的消息类型至消息租户组件；

10)消息中心组件从消息租户组件中获取到该租户的消息类型；

11)消息中心组件根据该消息类型，从消息平台端获取业务数据消息，包括消息内容、标题、数据、状态等；

12)消息平台端返回业务数据信息至消息中心组件；

13)通过静态资源引入或npm安装方式接入消息中心组件至平台端，以在平台端形成自身的消息中心。

另外，还包括：

14)业务人员创建并维护消息平台端中的消息分类、标题、模板、跳转协议、触达渠道等信息。

由上可知，本实施方式系统中包含平台端、消息租户组件、消息中心组件以及消息平台端，其中，消息中心组件用以创建app_id，消息租户组件用以创建tenant_id。

上述实施例所提供的方法，提供了一种支撑多端、多域、多角色的消息开放平台，根据租户的实际业务域、所处角色以及处理不同业务所需的平台端，建立租户组件并提供统一的前端消息中心(jssdk)，以此形成各平台端独立的消息中心；同时可以根据租户的业务域、角色、平台等多方面因素，差异化展示该租户所需的消息类型、数据等信息。

参见图5，示出了本发明实施例提供的一种消息管理装置500的主要模块示意图，应用于消息服务系统中的多个平台端，且每个平台端对应于至少一个租户，包括：

消息类型获取模块501，用于确定与平台端对应的租户，基于所述租户的租户标识，从消息租户组件中获取与所述租户对应的消息类型；

业务数据获取模块502，用于从消息平台端获取与所述消息类型对应的业务数据消息，对所述业务数据消息进行打包处理；

业务数据推送模块503，用于基于所述平台端的标识，将打包后的业务数据信息发送至所述平台端，以通过所述平台端解析所述业务数据信息并推送至所述租户进行显示。

本发明实施装置还包括标识创建模块504(图中未标出)，用于：

接收所述平台端传输的创建标识请求，若存在与所述平台端对应的租户，则基于所述平台端的信息进行标识创建。

本发明实施装置还包括租户标识创建模块505(图中未标出)，用于：

所述消息租户组件接收所述平台端传输的创建租户请求，将所述创建租户请求中的业务需求描述传输至审核服务端；

若所述审核服务端反馈的审核结果为通过，则基于所述业务需求描述进行租户标识创建。

本发明实施装置中，所述消息类型获取模块501，用于：

所述消息租户组件基于所述租户标识，从所述消息平台端获取与所述租户对应的所述消息类型；其中，所述消息类型与预先赋予所述租户的角色对应。

本发明实施装置还包括存储单元创建模块506(图中未标出)，用于：

所述消息租户组件获取所述租户的数据存储需求，确定与所述数据存储需求对应的存储配置信息；

基于所述存储配置信息为所述租户创建数据存储单元，以将所述消息类型存储至所述数据存储单元。

需要说明的是，消息管理装置的实施方为消息中心组件，与该消息中心组件相关联的还包括有消息租户组件和消息平台端，其中，租户标识创建模块可以存储于消息租户组件中。

另外，在本发明实施例中所述装置的具体实施内容，在上面所述方法中已经详细说明了，故在此重复内容不再说明。

图6示出了可以应用本发明实施例的示例性系统架构600。

如图6所示，系统架构600可以包括终端设备601、602、603，网络604和服务器605(仅仅是示例)。网络604用以在终端设备601、602、603和服务器605之间提供通信链路的介质。网络604可以包括各种连接类型，例如有线、无线通信链路或者光纤电缆等等。

用户可以使用终端设备601、602、603通过网络604与服务器605交互，以接收或发送消息等。终端设备601、602、603上可以安装有各种通讯客户端应用。

终端设备601、602、603可以是具有显示屏并且支持网页浏览的各种电子设备，包括但不限于智能手机、平板电脑、膝上型便携计算机和台式计算机等等。

服务器605可以是提供各种服务的服务器，例如对用户利用终端设备601、602、603所浏览的购物类网站提供支持的后台管理服务器(仅为示例)。

需要说明的是，本发明实施例所提供的方法一般由服务器605执行，相应地，装置一般设置于服务器605中。

应该理解，图6中的终端设备、网络和服务器的数目仅仅是示意性的。根据实现需要，可以具有任意数目的终端设备、网络和服务器。

下面参考图7，其示出了适于用来实现本发明实施例的终端设备的计算机系统700的结构示意图。图7示出的终端设备仅仅是一个示例，不应对本发明实施例的功能和使用范围带来任何限制。

如图7所示，计算机系统700包括中央处理单元(cpu)701，其可以根据存储在只读存储器(rom)702中的程序或者从存储部分708加载到随机访问存储器(ram)703中的程序而执行各种适当的动作和处理。在ram703中，还存储有系统700操作所需的各种程序和数据。cpu701、rom702以及ram703通过总线704彼此相连。输入/输出(i/o)接口705也连接至总线704。

以下部件连接至i/o接口705：包括键盘、鼠标等的输入部分706；包括诸如阴极射线管(crt)、液晶显示器(lcd)等以及扬声器等的输出部分707；包括硬盘等的存储部分708；以及包括诸如lan卡、调制解调器等的网络接口卡的通信部分709。通信部分709经由诸如因特网的网络执行通信处理。驱动器710也根据需要连接至i/o接口705。可拆卸介质711，诸如磁盘、光盘、磁光盘、半导体存储器等等，根据需要安装在驱动器710上，以便于从其上读出的计算机程序根据需要被安装入存储部分708。

特别地，根据本发明公开的实施例，上文参考流程图描述的过程可以被实现为计算机软件程序。例如，本发明公开的实施例包括一种计算机程序产品，其包括承载在计算机可读介质上的计算机程序，该计算机程序包含用于执行流程图所示的方法的程序代码。在这样的实施例中，该计算机程序可以通过通信部分709从网络上被下载和安装，和/或从可拆卸介质711被安装。在该计算机程序被中央处理单元(cpu)701执行时，执行本发明的系统中限定的上述功能。

需要说明的是，本发明所示的计算机可读介质可以是计算机可读信号介质或者计算机可读存储介质或者是上述两者的任意组合。计算机可读存储介质例如可以是——但不限于——电、磁、光、电磁、红外线、或半导体的系统、装置或器件，或者任意以上的组合。计算机可读存储介质的更具体的例子可以包括但不限于：具有一个或多个导线的电连接、便携式计算机磁盘、硬盘、随机访问存储器(ram)、只读存储器(rom)、可擦式可编程只读存储器(eprom或闪存)、光纤、便携式紧凑磁盘只读存储器(cd-rom)、光存储器件、磁存储器件、或者上述的任意合适的组合。在本发明中，计算机可读存储介质可以是任何包含或存储程序的有形介质，该程序可以被指令执行系统、装置或者器件使用或者与其结合使用。而在本发明中，计算机可读的信号介质可以包括在基带中或者作为载波一部分传播的数据信号，其中承载了计算机可读的程序代码。这种传播的数据信号可以采用多种形式，包括但不限于电磁信号、光信号或上述的任意合适的组合。计算机可读的信号介质还可以是计算机可读存储介质以外的任何计算机可读介质，该计算机可读介质可以发送、传播或者传输用于由指令执行系统、装置或者器件使用或者与其结合使用的程序。计算机可读介质上包含的程序代码可以用任何适当的介质传输，包括但不限于：无线、电线、光缆、rf等等，或者上述的任意合适的组合。

附图中的流程图和框图，图示了按照本发明各种实施例的系统、方法和计算机程序产品的可能实现的体系架构、功能和操作。在这点上，流程图或框图中的每个方框可以代表一个模块、程序段、或代码的一部分，上述模块、程序段、或代码的一部分包含一个或多个用于实现规定的逻辑功能的可执行指令。也应当注意，在有些作为替换的实现中，方框中所标注的功能也可以以不同于附图中所标注的顺序发生。例如，两个接连地表示的方框实际上可以基本并行地执行，它们有时也可以按相反的顺序执行，这依所涉及的功能而定。也要注意的是，框图或流程图中的每个方框、以及框图或流程图中的方框的组合，可以用执行规定的功能或操作的专用的基于硬件的系统来实现，或者可以用专用硬件与计算机指令的组合来实现。

描述于本发明实施例中所涉及到的模块可以通过软件的方式实现，也可以通过硬件的方式来实现。所描述的模块也可以设置在处理器中，例如，可以描述为：一种处理器包括消息类型获取模块、业务数据获取模块、业务数据推送模块。其中，这些模块的名称在某种情况下并不构成对该模块本身的限定，例如，业务数据推送模块还可以被描述为“业务数据推送至租户的模块”。

作为另一方面，本发明还提供了一种计算机可读介质，该计算机可读介质可以是上述实施例中描述的设备中所包含的；也可以是单独存在，而未装配入该设备中。上述计算机可读介质承载有一个或者多个程序，当上述一个或者多个程序被一个该设备执行时，使得该设备包括：

确定与平台端对应的租户，基于所述租户的租户标识，从消息租户组件中获取与所述租户对应的消息类型；

从消息平台端获取与所述消息类型对应的业务数据消息，对所述业务数据消息进行打包处理；

基于所述平台端的标识，将打包后的业务数据信息发送至所述平台端，以通过所述平台端解析所述业务数据信息并推送至所述租户进行显示。

根据本发明实施例的技术方案，提供了一种支撑多端、多域、多角色的消息开放平台，根据租户的实际业务域、所处角色以及处理不同业务所需的平台端，建立租户组件并提供统一的前端消息中心(jssdk)，以此形成各平台端独立的消息中心；同时可以根据租户的业务域、角色、平台等多方面因素，差异化展示该租户所需的消息类型、数据等信息。

上述具体实施方式，并不构成对本发明保护范围的限制。本领域技术人员应该明白的是，取决于设计要求和其他因素，可以发生各种各样的修改、组合、子组合和替代。任何在本发明的精神和原则之内所作的修改、等同替换和改进等，均应包含在本发明保护范围之内。