CN117931472A - 消息中心数据管理方法、装置、设备及介质 - Google Patents

Abstract

本公开提供了一种消息中心数据管理方法、装置、设备及介质，涉及计算机技术领域，该方法包括：通过服务端接口接收用户端发送的消息列表请求，其中包括用户标识，根据用户标识，配置各个业务方的业务方标识和业务方调用接口，并以此获取各个业务方的消息列表数据，其中包括业务消息类型和组件标识，根据业务消息类型、组件标识和业务方标识，构建第一消息中心列表。通过上述方式，新的业务方接入时，服务端通过新的业务方的业务方标识和业务方调用接口，就可以将其加入消息中心中，无需用户端调用新的接口，也不需要进行特定开发和渲染，便于后期业务拓展，依据服务端的业务方标识、业务消息类型和组件标识，业务管理更加快捷高效。

Description

消息中心数据管理方法、装置、设备及介质

技术领域

本公开涉及计算机技术领域，尤其涉及一种消息中心数据管理方法、装置、设备及介质。

背景技术

随着移动互联网技术的发展和电子设备智能化的普及，用户可以通过诸如手机、平板电脑、掌上电脑等电子设备使用各类基于互联网技术的应用程序(例如各种手机应用、手机游戏等)，极大地丰富了用户体验。

相关技术中，用户可以通过用户端的应用程序获取消息中心列表，其中包括不同业务方的数据，用户端通过请求调用服务端消息列表接口，再将获取的消息中心列表展示。

但是，上述相关技术存在如下缺点：

1、每当有新的业务方接入消息中心时，都需要用户端向服务端调用新的接口，并且，新的业务方下发的数据接口与之前的不统一时，用户端还需要特定开发进行对接和渲染，不仅数据获取的效率低，工作量还大，不利于使用，业务拓展不方便。

2、消息中心列表是唯一列表，需要汇总每个业务方的列表数据，用户端请求次数多，处理逻辑复杂，数据不灵活，不利于运营。

需要说明的是，在上述背景技术部分公开的信息仅用于加强对本公开的背景的理解，因此可以包括不构成对本领域普通技术人员已知的现有技术的信息。

发明内容

本公开的目的在于提供一种消息中心数据管理方法、装置、设备及介质，至少在一定程度上解决现有技术中业务拓展过程复杂，效率低的问题。

本公开的其他特性和优点将通过下面的详细描述变得显然，或部分地通过本公开的实践而习得。

根据本公开的第一方面，提供一种消息中心数据管理方法，所述方法包括：

通过服务端接口，接收用户端发送的消息列表请求；所述消息列表请求包括用户标识；

根据所述用户标识，配置各个业务方的业务方数据集；所述业务方数据集包括各个业务方的业务方标识和业务方调用接口；

通过所述业务方调用接口，获取各个业务方的消息列表数据；所述消息列表数据包括业务消息类型和组件标识；

根据所述业务消息类型、组件标识和所述业务方标识，构建所述用户标识对应的第一消息中心列表，并通过所述服务端接口返回至用户端。

在一种可能的实施例中，所述消息列表请求中还包括：应用程序标识、用户端类型和用户端版本。

在一种可能的实施例中，所述通过所述业务方调用接口，获取各个业务方的消息列表数据，包括：

通过各个业务方的业务方调用接口，并发向所述各个业务方请求消息列表数据；

接收所述各个业务方返回的消息列表数据。

在一种可能的实施例中，消息列表数据中还包括最新消息时间；所述方法还包括：

根据最新消息时间对消息列表数据进行排序。

在一种可能的实施例中，所述根据所述业务消息类型、组件标识和所述业务方标识，构建第一消息中心列表，包括：

在所述各个业务方的消息列表数据上拓展所述业务方标识，得到拓展消息列表数据；

根据所述业务消息类型、组件标识和所述业务方标识，合成每条消息列表数据的唯一索引；

根据所述唯一索引和所述拓展消息列表数据，构建所述第一消息中心列表。

在一种可能的实施例中，在所述各个业务方的消息列表数据上拓展所述业务方标识，得到拓展消息列表数据；

根据所述应用程序标识、业务消息类型、组件标识和所述业务方标识，合成每条消息列表数据的唯一索引；

根据所述唯一索引和所述拓展消息列表数据，构建所述第一消息中心列表。

在一种可能的实施例中，所述根据所述业务消息类型、组件标识和所述业务方标识，构建第一消息中心列表，并返回至用户端之后，所述方法还包括：

通过所述用户标识，向数据库中查询用户设置数据；所述用户设置数据为对消息列表数据进行处理的数据；

接收根据所述唯一索引生成的用户设置数据；

根据所述用户设置数据，处理所述第一消息中心列表，生成第二消息中心列表，并返回至所述用户端。

在一种可能的实施例中，所述用户设置数据至少包括对消息列表数据进行排序、删除、置顶、设置免打扰标识和会话折叠处理中的任意一种或多种。

在一种可能的实施例中，所述方法还包括：

根据每条消息列表数据累加，获取消息中心列表中总的未读数数据。

在一种可能的实施例中，所述方法还包括：

将消息中心列表中相同类型的消息列表数据进行聚合显示。

在一种可能的实施例中，所述方法还包括：

接收到新的业务方接入所述第一消息中心列表的接入请求；

配置所述新的业务方的业务方数据集；所述业务方数据集包括所述新的业务方的业务方调用接口和业务方标识；

根据所述新的业务方的业务方调用接口和业务方标识，将所述新的业务方加入消息中心；

根据所述新的业务方，构建第三消息中心列表，并通过所述服务端接口返回至用户端。

根据本公开的另一方面，提供一种消息中心数据管理装置，包括：

接收单元，用于通过服务端接口，接收用户端发送的消息列表请求；所述消息列表请求包括用户标识；

配置单元，用于根据所述用户标识，配置各个业务方的业务方数据集；所述业务方数据集包括各个业务方的业务方标识和业务方调用接口；

业务数据获取单元，用于通过所述业务方调用接口，获取各个业务方的消息列表数据；所述消息列表数据包括业务消息类型和组件标识；

构建单元，用于根据所述业务消息类型、组件标识和所述业务方标识，构建所述用户标识对应的第一消息中心列表，并通过所述服务端接口返回至用户端。

根据本公开的再一方面，提供一种电子设备，包括：处理器；以及存储器，用于存储所述处理器的可执行指令；其中，所述处理器配置为经由执行所述可执行指令来执行第一方面中任意一项的方法。

根据本公开的再一方面，提供一种计算机可读存储介质，其上存储有计算机程序，所述计算机程序被处理器执行时实现第一方面中任意一项的方法。

本公开的实施例所提供的一种消息中心数据管理方法、装置、设备及介质，该方法包括：通过服务端接口接收用户端发送的消息列表请求，其中包括用户标识，根据用户标识，服务端获取服务端配置各个业务方的业务方数据集，其中包括业务方标识和业务方调用接口，并根据业务方标识和业务方调用接口，获取各个业务方的消息列表数据，其中包括业务消息类型和组件标识，根据业务消息类型、组件标识和业务方标识，对消息列表数据进行汇总，构建第一消息中心列表。通过上述方式，新的业务方接入时，服务端通过新的业务方的业务方标识和业务方调用接口，就可以将其加入消息中心中，无需用户端调用新的接口，也不需要进行特定开发和渲染，便于后期业务拓展，依据服务端的业务方标识、业务消息类型和组件标识，业务管理更加快捷高效。

并且，正常情况下，新的业务方接入到消息中心时，也需要配置各种参数，通过本方法，在新的业务方有需求接入到消息中心时，新的业务方需要配置特定的参数用来接入，即业务消息类型和组件标识，也没有对业务方产生更多复杂的需求，但是更便于整体管理，以及节省用户端大量时间，提高用户端获取消息中心列表中数据的效率。

应当理解的是，以上的一般描述和后文的细节描述仅是示例性和解释性的，并不能限制本公开。

附图说明

此处的附图被并入说明书中并构成本说明书的一部分，示出了符合本公开的实施例，并与说明书一起用于解释本公开的原理。显而易见地，下面描述中的附图仅仅是本公开的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他的附图。

图1示出本公开实施例中一种消息中心数据管理方法的流程图之一；

图2示出本公开实施例中一种消息中心数据管理方法的流程图之二；

图3示出本公开实施例中一种消息中心数据管理方法的流程图之三；

图4示出本公开实施例中一种新的业务方接入消息中心的流程图；

图5示出本公开实施例中一种消息中心数据管理方法的流程图之四；

图6示出本公开实施例中一种消息中心数据管理方法的交互示意图；

图7示出本公开实施例中一种消息中心数据管理装置的结构示意图；

图8示出本公开实施例中一种电子设备的结构示意图。

具体实施方式

现在将参考附图更全面地描述示例实施方式。然而，示例实施方式能够以多种形式实施，且不应被理解为限于在此阐述的范例；相反，提供这些实施方式使得本公开将更加全面和完整，并将示例实施方式的构思全面地传达给本领域的技术人员。所描述的特征、结构或特性可以以任何合适的方式结合在一个或更多实施方式中。

此外，附图仅为本公开的示意性图解，并非一定是按比例绘制。图中相同的附图标记表示相同或类似的部分，因而将省略对它们的重复描述。附图中所示的一些方框图是功能实体，不一定必须与物理或逻辑上独立的实体相对应。可以采用软件形式来实现这些功能实体，或在一个或多个硬件模块或集成电路中实现这些功能实体，或在不同网络和/或处理器装置和/或微控制器装置中实现这些功能实体。

相关技术中，用户可以通过用户端的应用程序获取消息中心列表，其中包括不同业务方的数据，用户端通过服务端接口请求调用消息列表，再将获取的消息中心列表展示。

但是，上述相关技术存在如下缺点：

1、每当有新的业务方接入消息中心时，都需要用户端向服务端调用新的接口，并且，新的业务方下发的数据接口与之前的不统一时，用户端还需要特定开发进行对接和渲染，不仅数据获取的效率低，工作量还大，不利于使用，业务拓展不方便。

2、消息中心列表是唯一列表，需要汇总每个业务方的列表数据，用户端请求次数多，处理逻辑复杂，数据不灵活，不利于运营。

基于上述问题，发明人考虑到了一种消息中心数据管理方法，该方法包括：通过服务端接口接收用户端发送的消息列表请求，其中包括用户标识，根据用户标识，配置各个业务方的业务方标识和业务方调用接口，并以此获取各个业务方的消息列表数据，其中包括业务消息类型和组件标识，根据业务消息类型、组件标识和业务方标识，构建第一消息中心列表。通过上述方式，新的业务方接入时，服务端通过新的业务方的业务方标识和业务方调用接口，就可以将其加入消息中心中，无需用户端调用新的接口，也不需要进行特定开发和渲染，便于后期业务拓展，依据服务端的业务方标识、业务消息类型和组件标识，业务管理更加快捷高效。

本申请实施例提供的方案涉及对于消息中心数据管理方法等技术，具体通过如下实施例进行说明：

图1示出本公开实施例中一种消息中心数据管理方法的流程图。本公开实施例提供的方法可以由服务器执行，在此不进行具体限定。图1所示，包括步骤S102～S108：

S102：通过服务端接口，接收用户端发送的消息列表请求，消息列表请求包括用户标识。

在一种可能的实施例中，服务端接收用户端建立连接的请求，建立服务端接口，通过服务端接口接收用户端发送的消息列表请求。消息列表请求用于请求各个业务方的消息列表数据。各个业务方的消息列表数据通过服务端进行汇总，可以得到消息中心列表。

用户标识具体可以是用户的手机号，也可以是UID(User ID)等。

在一种可能的实施例中，消息列表请求中还包括：应用程序标识(ApplicationIdentity Document，APPID)、用户端类型(clientType)和用户端版本(clenetVersion)等信息。

根据用户端类型和用户端版本，可以使得服务端更准确的得到用户端的信息，有一些业务在旧版本中是没有的，在新的版本中是需要加入到消息中心中的，或者，有一些业务在旧版本中是有的，在新的版本中是没有的。

进一步地，可以根据用户端类型和用户端版本，为用户端请求的消息中心列表填充更加详细的其他数据信息。

需要说明的是，若服务端只能获取到某一个应用程序的消息中心列表，则在获取消息中心列表的过程中，用户端可以不发送应用程序标识，若服务端中可以获取到10个应用程序对应的消息中心列表，则在用户端获取消息中心列表时，则需要将应用程序标识发送至服务端，以保证消息列表请求中的参数完整。

示例性地，如果用户是通过不同的应用程序发送的消息列表请求，则消息列表请求的请求参数可以包括APPID，用于标识不同的应用程序，然后服务端通过APPID和用户标识，获取配置在该APPID下各业务方标识和业务方调用接口的业务方数据集，再进行上述后续消息列表逻辑处理。

S104：根据用户标识，配置各个业务方的业务方数据集，业务方数据集包括各个业务方的业务方标识和业务方调用接口。

在一种可能的实施例中，服务端可以根据用户标识，确定存在业务联系的一个或者多个业务方，一般为多个，本公开中以多个为例进行说明。

服务端根据用户标识，确定对应的多个业务方之后，可以根据用户标识，配置业务方数据集，业务方数据集是服务端为各个业务方配置的，是用于标识不同业务方身份，以及调用各个业务方的数据集。其中包括各个业务方的业务方标识和业务方调用接口。其中，业务方标识可以为businessId；业务方调用接口可以是远程过程调用(Remote ProcedureCall，RPC)接口。

可以理解为，服务端为各个业务方分配businessId，服务端可以根据businessId直接确定一共有多少个业务方，以及每个业务方的序号，配置对应的RPC参数，即业务方消息接口相关信息，可以称为rpcData。

示例性地，若存在10个业务方，则建立10个businessId，并为10个业务方进行分配，配置10个调用业务方的rpcData。

S106：通过业务方调用接口，获取各个业务方的消息列表数据，消息列表数据包括业务消息类型和组件标识。

在一种可能的实施例中，通过各个业务方的业务方调用接口，以并发的方式分别向各个业务方请求消息列表数据，接收各个业务方返回的消息列表数据。消息列表数据是各个业务方与用户端存在业务关系的数据，通过消息列表数据构建消息中心列表在用户端展示，其中，消息列表数据中包括业务消息类型和组件标识。

业务消息类型可以是bizType，可以理解为消息中心列表中业务方的消息列表数据的消息类型；组件标识可以是sid，每个消息列表数据的组件ID。

S108：根据业务消息类型、组件标识和业务方标识，构建用户标识对应的第一消息中心列表，并通过服务端接口返回至用户端。

在一种可能的实施例中，将各个业务方返回的消息列表数据汇总，通过业务消息类型、组件标识和业务方标识进行回填，对消息列表数据进行汇总，构建第一消息中心列表。可以将得到的第一消息中心列表返回到用户端，以使用户端展示。

需要说明的是，本公开中的第一消息中心列表、第二消息中心列表和第三消息中心列表，是为了区分对消息中心列表进行处理之后的不同之处。

在一种可能的实施例中，根据每条消息列表数据累加，获取消息中心列表中总的未读数数据。

以第一消息中心列表为例，最终返回用户端并展示的数据可以是各个业务方的汇总数据，并且可以展示出未读数的数据。

针对不同业务方的数据，展示在消息中心列表中之后，用户端若没有针对业务方的数据进行任何操作，例如，没有对其进行读取或者查询等操作，则在消息中心列表中这类数据可以理解为未读数数据，在展示第一消息中心列表时，会对全部业务方的未读的消息列表数据进行汇总，并生成总数，以供用户端查询，查看还有多少数据没有查询过。

在一种可能的实施例中，服务端还可以将消息中心列表中相同类型的消息列表数据进行聚合显示。

通过此方式可以使得用户在查看消息中心列表时，更方便。例如，针对某个应用程序A，可以获取到应用程序A对应的消息中心列表，消息中心列表中包括应用程序A对应的某些业务方的电商数据，则可以将电商数据进行聚合，进行展示，方便用户查看。

通过本公开实施例提供的消息中心数据管理方法，可以看出，用户端和服务端之间的接口只需要一个即可，就是本公开中的服务端接口，调用服务端接口之后，服务端会配置用户端对应的各个业务方的远程过程调用接口，即配置RPC参数，若存在新的业务方需要接入到消息中心，服务端可以直接为新的业务方配置新的业务方标识和新的业务方调用接口，并将心的业务方接入到消息中心，后续可以将新的业务方的消息列表数据加入到消息中心列表中，无需用户端再去调用新的接口，并且，因为不需要调用新的接口，新的业务方也是通过服务端接口接入的，消息中心列表依旧是通过原有的方式渲染和展示，用户端也不需要再进行新的渲染方式了，利于用户端拓展新的业务，方便新的业务方接入消息中心。

在服务端配置了各个业务方的businessId和rpcData，businessId再配合消息列表数据的业务消息类型和组件标识，可以方便的管理每个业务方的消息中心列表，服务端根据businessId，就可以确定是哪个业务方，根据业务消息类型可以明确消息的类型等等，管理数据时逻辑清晰，利于运营。

在一种可能的实施例中，步骤S108在构建第一消息中心列表过程中，各个业务方的消息列表数据中还可以包括数据的最新消息时间(lastMsgTime)。可以根据最新消息时间对消息列表数据进行排序。

在一种可能的实施例中，步骤S108中，可以提供一种构建消息中心列表之后，对于管理消息中心列表更加便利的方式，如图2所示，具体可以包括如下步骤：

S202：在各个业务方的消息列表数据上拓展业务方标识，得到拓展消息列表数据。

在一种可能的实施例中，在各个业务方返回的消息数据上，拓展上businessId数据，得到拓展消息列表数据。

S204：根据业务消息类型、组件标识和业务方标识，合成每条消息列表数据的唯一索引。

在一种可能的实施例中，可以根据businessId、bizType、sid三者进行合成索引，用于标识各个业务方的消息列表数据，唯一索引可以通过skey表示。

在一种可能的实施例中，还可以根据businessId、bizType、sid三者两两组合，并基于组后后得到的三个合成标识，生成唯一索引，用于标识各个业务方的消息列表数据。

S206：根据唯一索引和拓展消息列表数据，构建第一消息中心列表。

在一种可能的实施例中，通过每个业务方的消息列表数据的唯一索引，和拓展消息列表数据，构建第一消息中心列表，可以直接通过唯一索引查询业务方的数据，并且进行一系列管理。

在另一种可能的实施例中，步骤S108中，针对生成唯一索引，若用户端发送的消息列表请求中包括应用程序标识，则每条消息列表数据的唯一索引需要根据APPID、业务消息类型、组件标识和业务方标识四个参数生成。

示例性地，在各个业务方的消息列表数据上拓展业务方标识，得到拓展消息列表数据，根据应用程序标识、业务消息类型、组件标识和业务方标识，合成每条消息列表数据的唯一索引，根据唯一索引和拓展消息列表数据，构建第一消息中心列表。

进一步地，对于消息中心列表，可以根据唯一索引进行管理，如图3所示，具体可以包括以下步骤：

S302：通过用户标识，向数据库中查询用户设置数据，用户设置数据为对消息列表数据进行处理的数据。

在一种可能的实施例中，在获取到第一消息中心列表之后，可以通过用户标识，向数据库中查询用户设置数据的集合。具体地，用户设置数据至少包括对消息列表数据进行排序、删除、置顶、设置免打扰标识和会话折叠处理中的任意一种或多种。

S304：接收根据唯一索引生成的用户设置数据。

在一种可能的实施例中，数据库可以通过唯一索引返回消息列表数据的用户设置数据，每条用户设置数据通过skey为每条数据的索引，设置对应的删除、置顶及免打扰标识等。

S306：根据用户设置数据，处理第一消息中心列表，生成第二消息中心列表，并返回至用户端。

在一种可能的实施例中，将第一消息中心列表中的汇总的数据结合用户设置数据，依次执行删除、置顶、免打扰等功能逻辑，并进行新的排序，生成第二消息中心列表，并返回至用户端。

进一步地，在一种可能的实施方式中，对于新的业务方接入到消息中心中，服务端可以执行如下操作，如图4所示，具体包括下述步骤：

S402：接收到新的业务方接入消息中心列表的接入请求。

在一种可能的实施例中，新的业务方需要接入的用户端，可以向服务端发送接入请求。

S404：配置新的业务方的业务方数据集，业务方数据集包括新的业务方的业务方调用接口和业务方标识。

S406：根据新的业务方的业务方调用接口和业务方标识，将新的业务方加入消息中心列表。

S408：根据新的业务方，构建第三消息中心列表，并通过服务端接口返回至用户端。

用户端基本无感知，刷新消息中心列表之类的，就可以获取到新的业务方的消息列表数据。

进一步地，在一种可能的实施方式中，本公开实施例提供了另一种消息中心数据管理方法，如图5所示，包括以下步骤：

S502：通过服务端接口，接收用户端发送的消息列表请求，消息列表请求包括用户标识、应用程序标识、用户端类型和用户端版本。

S504：根据用户标识、应用程序标识、用户端类型和用户端版本，配置各个业务方的业务方数据集，业务方数据集包括各个业务方的业务方标识和业务方调用接口。

S506：通过业务方调用接口，获取各个业务方的消息列表数据，消息列表数据包括业务消息类型、组件标识和最新消息时间。

S508：在各个业务方的消息列表数据上拓展业务方标识，得到拓展消息列表数据。

S510：根据业务消息类型、应用程序标识、组件标识和业务方标识，合成每条消息列表数据的唯一索引。

S512：根据唯一索引和拓展消息列表数据，汇总各个业务方的消息列表数据，生成会话列表。

S514：根据最新消息时间对会话列表中的消息列表数据进行排序，构建第一消息中心列表。

S516：通过用户标识，向数据库中查询用户设置数据，用户设置数据为对消息列表数据进行处理的数据。

S518：接收根据唯一索引生成的用户设置数据。

S520：根据用户设置数据，处理第一消息中心列表，生成第二消息中心列表。

S522：根据每条消息列表数据累加，获取消息中心列表中总的未读数数据。

S524：向用户端返回第二消息中心列表和未读数数据。

通过服务端与用户端，以及服务端与各个业务方之间的交互，可以与用户端预先约定，用户端请求消息中心列表需要的参数，即可以称为入参，例如，用户标识。服务端也可以与预先与各个业务方约定，各个业务方想要接入到消息中心，需要的参数，即可以称为出参，例如，业务消息类型和组件标识。

通过约定的入参和出参，指定与各个业务方通用的消息中心接口(ApplicationProgramming Interface，API)，即使更多的业务方需要拓展，也可以通过服务端处理，直接加入到消息中心，无需用户端调用新的接口，并且依旧是通过服务端接口，展示在用户端，不存在不适配的问题，也无需进行新的开发和渲染处理，节省大量的用户端应用程序的开发时间，用户端拓展业务方也更加方便，快捷，效率更高。

发明人设计方案的思路主要还是由于用户端拓展业务不方便，通过本公开的方法可以提供一种用户端和服务端之间，对于各个业务方都通用的接口，实现与业务方数据解耦，功能逻辑统一管理，便于后期维护与运营。数据方案设计充分考虑不同业务方数据碰撞问题，并在服务端保证数据唯一，灵活且可用性强。

在一种可能的实施例中，本公开实施例提供了一种用户端、服务端和各个业务方之间的消息中心数据管理方法的交互示意图，如图6所示，包括以下步骤：

S602：用户端通过服务端接口，向服务端发送消息列表请求。

其中，消息列表请求包括用户标识、应用程序标识、用户端类型和用户端版本。

S604：服务端根据用户标识、应用程序标识、用户端类型和用户端版本，配置各个业务方的业务方数据集，业务方数据集包括各个业务方的业务方标识和业务方调用接口。

S606：服务端通过业务方调用接口，并发向各个业务方请求消息列表数据。

S608：各个业务方返回消息列表数据，消息列表数据包括业务消息类型、组件标识和最新消息时间。

S610：服务端在各个业务方的消息列表数据上拓展业务方标识，得到拓展消息列表数据。

S612：服务端根据应用程序标识、业务消息类型、组件标识和业务方标识，合成每条消息列表数据的唯一索引。

S614：服务端根据唯一索引和拓展消息列表数据，汇总各个业务方的消息列表数据，生成会话列表。

S616：服务端根据最新消息时间对会话列表中的消息列表数据进行排序，构建第一消息中心列表。

S618：服务端通过用户标识，向数据库中查询用户设置数据，用户设置数据为对消息列表数据进行处理的数据。

S620：数据库返回根据唯一索引生成的用户设置数据。

S622：服务端根据用户设置数据，处理第一消息中心列表，生成第二消息中心列表。

S624：服务端根据每条消息列表数据累加，获取消息中心列表中总的未读数数据。

S626：服务端向用户端返回第二消息中心列表和未读数数据。

与上述方法实施例基于同一发明构思，本申请实施例还提供一种消息中心数据管理装置。图7示出了本申请实施例提供的一种消息中心数据管理装置的结构示意图，该装置包括：接收单元701，用于通过服务端接口，接收用户端发送的消息列表请求；消息列表请求包括用户标识；配置单元702，用于根据用户标识，配置各个业务方的业务方数据集；业务方数据集包括各个业务方的业务方标识和业务方调用接口；业务数据获取单元703，用于通过业务方调用接口，获取各个业务方的消息列表数据；消息列表数据包括业务消息类型和组件标识；构建单元704，用于根据业务消息类型、组件标识和业务方标识，构建用户标识对应的第一消息中心列表，并通过服务端接口返回至用户端。

所属技术领域的技术人员能够理解，本发明的各个方面可以实现为系统、方法或程序产品。因此，本发明的各个方面可以具体实现为以下形式，即：完全的硬件实施方式、完全的软件实施方式(包括固件、微代码等)，或硬件和软件方面结合的实施方式，这里可以统称为“电路”、“模块”或“系统”。

下面参照图8来描述根据本发明的这种实施方式的电子设备800。图8显示的电子设备800仅仅是一个示例，不应对本发明实施例的功能和使用范围带来任何限制。

如图8所示，电子设备800以通用计算设备的形式表现。电子设备800的组件可以包括但不限于：上述至少一个处理单元810、上述至少一个存储单元820、连接不同系统组件(包括存储单元820和处理单元810)的总线830。

其中，所述存储单元存储有程序代码，所述程序代码可以被所述处理单元810执行，使得所述处理单元810执行本说明书上述“示例性方法”部分中描述的根据本发明各种示例性实施方式的步骤。

存储单元820可以包括易失性存储单元形式的可读介质，例如随机存取存储单元(RAM)8201和/或高速缓存存储单元8202，还可以进一步包括只读存储单元(ROM)8203。

存储单元820还可以包括具有一组(至少一个)程序模块8205的程序/实用工具8204，这样的程序模块8205包括但不限于：操作系统、一个或者多个应用程序、其它程序模块以及程序数据，这些示例中的每一个或某种组合中可能包括网络环境的实现。

总线830可以为表示几类总线结构中的一种或多种，包括存储单元总线或者存储单元控制器、外围总线、图形加速端口、处理单元或者使用多种总线结构中的任意总线结构的局域总线。

电子设备800也可以与一个或多个外部设备840(例如键盘、指向设备、蓝牙设备等)通信，还可与一个或者多个使得用户能与该电子设备800交互的设备通信，和/或与使得该电子设备800能与一个或多个其它计算设备进行通信的任何设备(例如路由器、调制解调器等等)通信。这种通信可以通过输入/输出(I/O)接口850进行。并且，电子设备800还可以通过网络适配器860与一个或者多个网络(例如局域网(LAN)，广域网(WAN)和/或公共网络，例如因特网)通信。如图所示，网络适配器860通过总线830与电子设备800的其它模块通信。应当明白，尽管图中未示出，可以结合电子设备800使用其它硬件和/或软件模块，包括但不限于：微代码、设备驱动器、冗余处理单元、外部磁盘驱动阵列、RAID系统、磁带驱动器以及数据备份存储系统等。

通过以上的实施方式的描述，本领域的技术人员易于理解，这里描述的示例实施方式可以通过软件实现，也可以通过软件结合必要的硬件的方式来实现。因此，根据本公开实施方式的技术方案可以以软件产品的形式体现出来，该软件产品可以存储在一个非易失性存储介质(可以是CD-ROM，U盘，移动硬盘等)中或网络上，包括若干指令以使得一台计算设备(可以是个人计算机、服务器、终端装置、或者网络设备等)执行根据本公开实施方式的方法。

在本公开的示例性实施例中，还提供了一种计算机可读存储介质，其上存储有能够实现本说明书上述方法的程序产品。在一些可能的实施方式中，本发明的各个方面还可以实现为一种程序产品的形式，其包括程序代码，当所述程序产品在终端设备上运行时，所述程序代码用于使所述终端设备执行本说明书上述“示例性方法”部分中描述的根据本发明各种示例性实施方式的步骤。

描述了根据本发明的实施方式的用于实现上述方法的程序产品，其可以采用便携式紧凑盘只读存储器(CD-ROM)并包括程序代码，并可以在终端设备，例如个人电脑上运行。然而，本发明的程序产品不限于此，在本文件中，可读存储介质可以是任何包含或存储程序的有形介质，该程序可以被指令执行系统、装置或者器件使用或者与其结合使用。

所述程序产品可以采用一个或多个可读介质的任意组合。可读介质可以是可读信号介质或者可读存储介质。可读存储介质例如可以为但不限于电、磁、光、电磁、红外线、或半导体的系统、装置或器件，或者任意以上的组合。可读存储介质的更具体的例子(非穷举的列表)包括：具有一个或多个导线的电连接、便携式盘、硬盘、随机存取存储器(RAM)、只读存储器(ROM)、可擦式可编程只读存储器(EPROM或闪存)、光纤、便携式紧凑盘只读存储器(CD-ROM)、光存储器件、磁存储器件、或者上述的任意合适的组合。

计算机可读信号介质可以包括在基带中或者作为载波一部分传播的数据信号，其中承载了可读程序代码。这种传播的数据信号可以采用多种形式，包括但不限于电磁信号、光信号或上述的任意合适的组合。可读信号介质还可以是可读存储介质以外的任何可读介质，该可读介质可以发送、传播或者传输用于由指令执行系统、装置或者器件使用或者与其结合使用的程序。

可读介质上包含的程序代码可以用任何适当的介质传输，包括但不限于无线、有线、光缆、RF等等，或者上述的任意合适的组合。

可以以一种或多种程序设计语言的任意组合来编写用于执行本发明操作的程序代码，所述程序设计语言包括面向对象的程序设计语言—诸如Java、C++等，还包括常规的过程式程序设计语言—诸如“C”语言或类似的程序设计语言。程序代码可以完全地在用户计算设备上执行、部分地在用户设备上执行、作为一个独立的软件包执行、部分在用户计算设备上部分在远程计算设备上执行、或者完全在远程计算设备或服务器上执行。在涉及远程计算设备的情形中，远程计算设备可以通过任意种类的网络，包括局域网(LAN)或广域网(WAN)，连接到用户计算设备，或者，可以连接到外部计算设备(例如利用因特网服务提供商来通过因特网连接)。

应当注意，尽管在上文详细描述中提及了用于动作执行的设备的若干模块或者单元，但是这种划分并非强制性的。实际上，根据本公开的实施方式，上文描述的两个或更多模块或者单元的特征和功能可以在一个模块或者单元中具体化。反之，上文描述的一个模块或者单元的特征和功能可以进一步划分为由多个模块或者单元来具体化。

此外，尽管在附图中以特定顺序描述了本公开中方法的各个步骤，但是，这并非要求或者暗示必须按照该特定顺序来执行这些步骤，或是必须执行全部所示的步骤才能实现期望的结果。附加的或备选的，可以省略某些步骤，将多个步骤合并为一个步骤执行，以及/或者将一个步骤分解为多个步骤执行等。

通过以上的实施方式的描述，本领域的技术人员易于理解，这里描述的示例实施方式可以通过软件实现，也可以通过软件结合必要的硬件的方式来实现。因此，根据本公开实施方式的技术方案可以以软件产品的形式体现出来，该软件产品可以存储在一个非易失性存储介质(可以是CD-ROM，U盘，移动硬盘等)中或网络上，包括若干指令以使得一台计算设备(可以是个人计算机、服务器、移动终端、或者网络设备等)执行根据本公开实施方式的方法。

本领域技术人员在考虑说明书及实践这里公开的发明后，将容易想到本公开的其它实施方案。本申请旨在涵盖本公开的任何变型、用途或者适应性变化，这些变型、用途或者适应性变化遵循本公开的一般性原理并包括本公开未公开的本技术领域中的公知常识或惯用技术手段。说明书和实施例仅被视为示例性的，本公开的真正范围和精神由所附的权利要求指出。

Claims (14)

1.一种消息中心数据管理方法，其特征在于，所述方法包括：

通过服务端接口，接收用户端发送的消息列表请求；所述消息列表请求包括用户标识；

根据所述用户标识，配置各个业务方的业务方数据集；所述业务方数据集包括各个业务方的业务方标识和业务方调用接口；

通过所述业务方调用接口，获取各个业务方的消息列表数据；所述消息列表数据包括业务消息类型和组件标识；

根据所述业务消息类型、组件标识和所述业务方标识，构建所述用户标识对应的第一消息中心列表，并通过所述服务端接口返回至用户端。

2.根据权利要求1所述的方法，其特征在于，所述消息列表请求中还包括：应用程序标识、用户端类型和用户端版本。

3.根据权利要求1所述的方法，其特征在于，所述通过所述业务方调用接口，获取各个业务方的消息列表数据，包括：

通过各个业务方的业务方调用接口，并发向所述各个业务方请求消息列表数据；

接收所述各个业务方返回的消息列表数据。

4.根据权利要求1所述的方法，其特征在于，消息列表数据中还包括最新消息时间；所述方法还包括：

根据最新消息时间对消息列表数据进行排序。

5.根据权利要求1所述的方法，其特征在于，所述根据所述业务消息类型、组件标识和所述业务方标识，构建第一消息中心列表，包括：

在所述各个业务方的消息列表数据上拓展所述业务方标识，得到拓展消息列表数据；

根据所述业务消息类型、组件标识和所述业务方标识，合成每条消息列表数据的唯一索引；

根据所述唯一索引和所述拓展消息列表数据，构建所述第一消息中心列表。

6.根据权利要求2所述的方法，其特征在于，所述根据所述业务消息类型、组件标识和所述业务方标识，构建第一消息中心列表，包括：

在所述各个业务方的消息列表数据上拓展所述业务方标识，得到拓展消息列表数据；

根据所述应用程序标识、业务消息类型、组件标识和所述业务方标识，合成每条消息列表数据的唯一索引；

根据所述唯一索引和所述拓展消息列表数据，构建所述第一消息中心列表。

7.根据权利要求5或6任一项所述的方法，其特征在于，所述根据所述业务消息类型、组件标识和所述业务方标识，构建第一消息中心列表，并返回至用户端之后，所述方法还包括：

通过所述用户标识，向数据库中查询用户设置数据；所述用户设置数据为对消息列表数据进行处理的数据；

接收根据所述唯一索引生成的用户设置数据；

根据所述用户设置数据，处理所述第一消息中心列表，生成第二消息中心列表，并返回至所述用户端。

8.根据权利要求7所述的方法，其特征在于，所述用户设置数据至少包括对消息列表数据进行排序、删除、置顶、设置免打扰标识和会话折叠处理中的任意一种或多种。

9.根据权利要求1所述的方法，其特征在于，所述方法还包括：

根据每条消息列表数据累加，获取消息中心列表中总的未读数数据。

10.根据权利要求1所述的方法，其特征在于，所述方法还包括：

将消息中心列表中相同类型的消息列表数据进行聚合显示。

11.根据权利要求1所述的方法，其特征在于，所述方法还包括：

接收到新的业务方接入消息中心列表的接入请求；

配置所述新的业务方的业务方数据集；所述业务方数据集包括所述新的业务方的业务方调用接口和业务方标识；

根据所述新的业务方的业务方调用接口和业务方标识，将所述新的业务方加入消息中心列表；

根据所述新的业务方，构建第三消息中心列表，并通过所述服务端接口返回至用户端。

12.一种消息中心数据管理装置，其特征在于，包括：

接收单元，用于通过服务端接口，接收用户端发送的消息列表请求；所述消息列表请求包括用户标识；

配置单元，用于根据所述用户标识，配置各个业务方的业务方数据集；所述业务方数据集包括各个业务方的业务方标识和业务方调用接口；

业务数据获取单元，用于通过所述业务方调用接口，获取各个业务方的消息列表数据；所述消息列表数据包括业务消息类型和组件标识；

构建单元，用于根据所述业务消息类型、组件标识和所述业务方标识，构建所述用户标识对应的第一消息中心列表，并通过所述服务端接口返回至用户端。

13.一种电子设备，其特征在于，包括：

处理器；以及

存储器，用于存储所述处理器的可执行指令；

其中，所述处理器配置为经由执行所述可执行指令来执行权利要求1～11中任意一项所述的方法。

14.一种计算机可读存储介质，其上存储有计算机程序，其特征在于，所述计算机程序被处理器执行时实现权利要求1～11中任意一项所述的方法。