CN116089483A - 基于房地产管理系统的事件查询方法及相关装置 - Google Patents

Abstract

本申请实施例提供了一种基于房地产管理系统的事件查询方法及相关装置，所述应用于房地产管理系统的事件处理服务器，所述房地产管理系统包括用户的用户账号所关联的用户终端、运维账号所关联的运维终端和所述事件处理服务器；所述方法包括：接收来自所述运维终端的登录请求；根据所述登录请求生成运维界面数据包；接收来自所述运维终端的第一查询请求，所述第一查询请求用于查询处理成功事件，所述第一查询请求包括第一业务事件的第一业务事件ID；根据所述第一业务事件ID查询第一业务事件的第一查询结果；向所述运维终端发送所述查询结果。这样，使得业务服务器能够提供可视化的运维界面，提高查询效率。

Description

基于房地产管理系统的事件查询方法及相关装置

技术领域

本申请属于互联网一般数据处理技术领域，具体涉及一种基于房地产管理系统的事件查询方法及相关装置。

背景技术

目前，现有的房地产营销云系统中，在对微服务事件进行处理时，会存在事件处理失败的情况，这时候如果运维人员需要对这些事件进行维护，需要从后台数据库中调取日志，再进行筛选，最后才能够查询到对应的事件数据，处理过程较为麻烦。不利于维护工作的进行，导致系统维护成本较大。

发明内容

本申请实施例提供了一种基于自然语言交互获取剧情信息的方法及相关装置，以期提高人机交互效率，进而提高对业务事件的查询效率。

第一方面，本申请实施例提供了一种基于房地产管理系统的事件查询方法，应用于房地产管理系统的事件处理服务器，所述房地产管理系统包括运维账号所关联的运维终端和所述事件处理服务器；所述方法包括：

接收来自所述运维终端的登录请求；

根据所述登录请求生成运维界面数据包，所述运维界面数据包用于生成第一运维界面，所述第一运维界面包括第一查询区域和第一查询结果区域，所述第一查询区域至少包括第一事件日记ID输入框，第一事件日记ID用于指示对应的业务事件，所述第一查询结果区域用于显示与所述第一事件日记ID对应的第一查询结果；

接收来自所述运维终端的第一查询请求，所述第一查询请求用于查询处理成功事件，所述第一查询请求包括第一业务事件的第一业务事件ID；

根据所述第一业务事件ID查询第一业务事件的第一查询结果，所述第一查询结果包括基础信息和事件投递信息，所述基础信息至少包括事件ID、事件名称、事件源、事件处理成功次数、事件落库时间、事件生成时间和事件原始数据，所述事件投递信息至少包括综合信息和至少一个单次投递信息，所述综合信息至少包括用户ID、处理状态和投递总次数和处理成功时间，每个单次投递信息至少包括当前投递次数、本次投递时间、本次处理状态、本次处理耗时、本次处理结果、本次结果回传时间和本次处理客户端ID；

向所述运维终端发送所述查询结果。

第二方面，本申请实施例提供了一种基于房地产管理系统的事件查询方法，应用于房地产管理系统的运维终端，所述房地产管理系统包括运维账号所关联的所述运维终端和事件处理服务器；所述方法包括：

向所述事件处理服务器发送登录请求；

接收来自所述事件处理服务器的运维界面数据包；

根据所述运维界面数据包在所述运维终端的屏幕上显示运维界面，所述运维界面包括查询区域和查询结果区域，所述查询区域至少包括事件日记ID输入框，事件日记ID用于指示对应的业务事件，所述查询结果区域用于显示与所述事件日记ID对应的查询结果；

获取运维人员输入的事件日记ID，并根据所述事件日记ID生成查询请求；

向所述事件处理服务器发送所述查询请求；

接收来自所述事件处理服务器的所述查询结果，所述查询结果包括基础信息和事件投递信息，所述基础信息至少包括事件ID、事件名称、事件源、事件处理成功次数、事件落库时间、事件生成时间和事件原始数据，所述事件投递信息至少包括综合信息和至少一个单次投递信息，所述综合信息至少包括用户ID、处理状态和投递总次数和处理成功时间，每个单次投递信息至少包括当前投递次数、本次投递时间、本次处理状态、本次处理耗时、本次处理结果、本次结果回传时间和本次处理客户端ID。

第三方面，本申请实施例提供了一种用户设备的用户界面，所述运维终端包括显示屏，所述显示屏上显示有如上述方法中的运维界面，所述运维界面包括由用户通过所述显示屏输入触摸指令对所述用户界面进行控制，或者由所述用户通过输入设备输入控制指令对所述运维界面进行控制；

所述运维界面包括查询区域和查询结果区域，所述查询区域至少包括事件日记ID输入框，事件日记ID用于指示对应的业务事件，所述查询结果区域用于显示与所述事件日记ID对应的查询结果；

所述查询结果包括基础信息和事件投递信息，所述基础信息至少包括事件ID、事件名称、事件源、事件处理成功次数、事件落库时间、事件生成时间和事件原始数据，所述事件投递信息至少包括综合信息和至少一个单次投递信息，所述综合信息至少包括用户ID、处理状态和投递总次数和处理成功时间，每个单次投递信息至少包括当前投递次数、本次投递时间、本次处理状态、本次处理耗时、本次处理结果、本次结果回传时间和本次处理客户端ID。

第四方面，本申请实施例提供了一种电子设备，包括处理器、存储器、通信接口，以及一个或多个程序，所述一个或多个程序被存储在所述存储器中，并且被配置由所述处理器执行，所述程序包括用于执行本申请实施例第一方面和第二方面的步骤的指令。

第五方面，本申请实施例提供了一种计算机存储介质，存储用于电子数据交换的计算机程序，其中，所述计算机程序使得计算机执行如本实施例第一方面和第二方面所描述的部分或全部步骤。

第六方面，本申请实施例提供了一种计算机程序产品，其中，上述计算机程序产品包括存储了计算机程序的非瞬时性计算机可读存储介质，上述计算机程序可操作来使计算机执行如本申请实施例第一方面和第二方面所描述的部分或全部步骤。该计算机程序产品可以为一个软件安装包。

可以看出，本申请实施例中，首先接收来自所述运维终端的登录请求；根据所述登录请求生成运维界面数据包，所述运维界面数据包用于生成第一运维界面；接收来自所述运维终端的第一查询请求，所述第一查询请求用于查询处理成功事件，所述第一查询请求包括第一业务事件的第一业务事件ID；根据所述第一业务事件ID查询第一业务事件的第一查询结果；向所述运维终端发送所述查询结果。这样，使得事件处理服务器向运维终端提供了可视化的运维界面，提高了运维人员与事件处理服务器之间的人机交互效率，进而提高了对业务事件的查询效率。

附图说明

为了更清楚地说明本申请实施例或现有技术中的技术方案，下面将对实施例或现有技术描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本申请的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他的附图。

图1a是本申请实施例提供的一种房地产管理系统的结构示意图；

图1b是本申请实施例提供的一种电子设备的结构示意图；

图2是本申请实施例提供的一种基于房地产管理系统的事件查询方法的流程示意图；

图3a是本申请实施例提供的第一运维界面的示意图；

图3b是本申请实施例提供的第二运维界面一种的示意图；

图3c是本申请实施例提供的第二运维界面另一种的示意图；

图4是本申请实施例提供的一种基于房地产管理系统的事件查询装置的结构示意图。

具体实施方式

为了使本技术领域的人员更好地理解本申请方案，下面将结合本申请实施例中的附图，对本申请实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅仅是本申请一部分实施例，而不是全部的实施例。基于本申请中的实施例，本领域普通技术人员在没有作出创造性劳动前提下所获得的所有其他实施例，都属于本申请保护的范围。

本申请的说明书和权利要求书及上述附图中的术语“第一”、“第二”等是用于区别不同对象，而不是用于描述特定顺序。此外，术语“包括”和“具有”以及它们任何变形，意图在于覆盖不排他的包含。例如包含了一系列步骤或单元的过程、方法、系统、产品或设备没有限定于已列出的步骤或单元，而是可选地还包括没有列出的步骤或单元，或可选地还包括对于这些过程、方法、系统、产品或设备固有的其他步骤或单元。

在本文中提及“实施例”意味着，结合实施例描述的特定特征、结构或特性可以包含在本申请的至少一个实施例中。在说明书中的各个位置出现该短语并不一定均是指相同的实施例，也不是与其它实施例互斥的独立的或备选的实施例。本领域技术人员显式地和隐式地理解的是，本文所描述的实施例可以与其它实施例相结合。

目前，虚拟人物在与用户交互时，只有用户输出了特定的语句，虚拟人物才会反馈对应的与任务相关的线索信息，如果用户使用非特定的自然语言与虚拟人物对话，虚拟人物可能无法给出用户需要的回复，使得在与虚拟人物交互时效率较低。

为解决上述问题，本申请实施例提供了一种基于房地产管理系统的事件查询方法。所述方法可以应用于基于房地产管理系统进行可视化事件查询的场景中。可以通过接收来自所述运维终端的登录请求；根据所述登录请求生成运维界面数据包，所述运维界面数据包用于生成第一运维界面；接收来自所述运维终端的第一查询请求，所述第一查询请求用于查询处理成功事件，所述第一查询请求包括第一业务事件的第一业务事件ID；根据所述第一业务事件ID查询第一业务事件的第一查询结果；向所述运维终端发送所述查询结果。本方案可以适用于多种场景，包括但不限于上述提到的应用场景。

下面介绍本申请实施例涉及的系统架构。

图1a是本申请实施例提供的一种房地产管理系统100的结构示意图。如图1a所示（图中虚线表示可以无线连接或有线连接），所述房地产管理系统100包括用户的用户账号所关联的用户终端110、运维账号所关联的运维终端120和所述事件处理服务器130。

具体的，运维人员通过所述运维终端120上显示的运维界面与所述事件处理服务器130进行交互，进而直接查询处理失败的业务事件。所述用户终端110可以是业务事件的发起端，用户通过所述用户终端110中的微信打开营销云小程序进入用户操作界面→在小程序端操作动作→业务服务器（活动参与服务）根据用户在小程序端的操作动作产生“事件”→将“事件”发送至事件处理服务器130。

图1b是本申请实施例提供的一种电子设备10，如图1b所示，其包括至少一个处理器（processor）11；显示屏12；以及存储器（memory）13，还可以包括通信接口（Communications Interface）15和总线14。其中，处理器11、显示屏12、存储器13和通信接口15可以通过总线14完成相互间的通信。显示屏12设置为显示初始设置模式中预设的用户引导界面。通信接口15可以传输信息。处理器11可以调用存储器13中的逻辑指令，以执行上述实施例中的方法。

可选的，所述电子设备10可以是移动电子设备，也可以是固定电子设备或其他设备，在此不做唯一性限定。

此外，上述的存储器13中的逻辑指令可以通过软件功能单元的形式实现并作为独立的产品销售或使用时，可以存储在一个计算机可读取存储介质中。

存储器13作为一种计算机可读存储介质，可设置为存储软件程序、计算机可执行程序，如本公开实施例中的方法对应的程序指令或模块。处理器11通过运行存储在存储器13中的软件程序、指令或模块，从而执行功能应用以及数据处理，即实现上述实施例中的方法。

存储器13可包括存储程序区和存储数据区，其中，存储程序区可存储操作系统、至少一个功能所需的应用程序；存储数据区可存储根据电子设备10的使用所创建的数据等。此外，存储器13可以包括高速随机存取存储器，还可以包括非易失性存储器。例如，U盘、移动硬盘、只读存储器(Read-Only Memory，ROM)、随机存取存储器(Random Access Memory，RAM)、磁碟或者光盘等多种可以存储程序代码的介质，也可以是暂态存储介质。

下面对具体的方法进行详细的介绍。

请参阅图2，图2是本申请实施例提供的一种基于房地产管理系统的事件查询方法的流程示意图，所述方法应用于房地产管理系统的事件处理服务器，所述房地产管理系统可以包括用户的用户账号所关联的用户终端、运维账号所关联的运维终端和所述事件处理服务器；所述方法包括：

步骤201、接收来自所述运维终端的登录请求。

步骤202、根据所述登录请求生成运维界面数据包。

请一并参阅图3a，图3a是本申请实施例提供的第一运维界面的示意图，所述运维界面数据包用于生成所述第一运维界面，所述第一运维界面包括第一查询区域和第一查询结果区域，所述第一查询区域至少包括第一事件日记ID输入框，第一事件日记ID用于指示对应的业务事件，所述第一查询结果区域用于显示与所述第一事件日记ID对应的第一查询结果。

步骤203、接收来自所述运维终端的第一查询请求。

所述第一查询请求用于查询处理成功事件，所述第一查询请求包括第一业务事件的第一业务事件ID。

步骤204、根据所述第一业务事件ID查询第一业务事件的第一查询结果。

所述第一查询结果包括基础信息和事件投递信息，所述基础信息至少包括事件ID、事件名称、事件源、事件处理成功次数、事件落库时间、事件生成时间和事件原始数据，所述事件投递信息至少包括综合信息和至少一个单次投递信息，所述综合信息至少包括用户ID、处理状态和投递总次数和处理成功时间，每个单次投递信息至少包括当前投递次数、本次投递时间、本次处理状态、本次处理耗时、本次处理结果、本次结果回传时间和本次处理客户端ID。

步骤205、向所述运维终端发送所述查询结果。

具体实现中，运维人员首先在该页面顶部的查询框中输入事件日记ID来定位到目标事件数据，在下方显示“事件接收”和“事件投递”两个具体细分功能页面。

其中，“事件接收”功能页面中包括该目标事件数据的基础信息，例如事件ID、事件名称、事件源（产生该事件的业务服务）、事件处理成功次数、事件落库时间、事件生成时间以及事件原始数据（代码）；其中，“事件投递”功能页面中包括该目标事件数据的多条投递信息，每条投递信息包括用户ID/订阅端ID、处理状态、投递总次数、处理成功时间。其中，每条投递信息下还包括该投递信息的具体投递数据，例如当前投递次数、本次投递时间、本次处理状态、本次处理耗时、本次处理结果、本次结果回传时间、本次处理客户端ID。

此外，所述事件日记ID可以是在事件重推处理之后所记录的ID。事件重推是指：所述事件处理服务器在接收到业务服务器所发送的业务事件时，未能成功处理所述业务事件，因此触发事件重推机制，将所述业务事件重新推送给所述事件处理服务器再次处理，此过程中会生成所述业务事件的事件日记ID。因此，只有经过失败重推的业务事件，才会存在对应的事件日记ID，然后可以基于所述事件日记ID对所述业务事件进行事件追踪。

可以看出，本实施例中，首先接收来自所述运维终端的登录请求；根据所述登录请求生成运维界面数据包，所述运维界面数据包用于生成第一运维界面；接收来自所述运维终端的第一查询请求，所述第一查询请求用于查询处理成功事件，所述第一查询请求包括第一业务事件的第一业务事件ID；根据所述第一业务事件ID查询第一业务事件的第一查询结果；向所述运维终端发送所述查询结果。这样，使得事件处理服务器向运维终端提供了可视化的运维界面，提高了运维人员与事件处理服务器之间的人机交互效率，进而提高了对业务事件的查询效率。

在一个可能的实施例中，所述向所述运维终端发送所述查询结果之后；所述方法还包括：接收来自运维终端的第二查询请求，所述第二查询请求用于查询处理失败事件，所述第二查询请求包括第二业务事件的第二业务事件ID；根据所述第二业务事件ID查询所述第二业务事件的第二查询结果；向所述运维终端发送所述第二查询结果。

具体实现中，上述的界面展示的是消费成功的目标事件数据，因此不包含针对“消费失败”情形的失败原因查询通道。当所述运维人员需要查询消费失败状态时，则可以通过控件、选项等向所述事件处理服务器发送所述第二查询请求，当所述事件处理服务器接收到所述第二查询请求之后，根据所述第二查询请求查询所述第二业务事件的第二查询结果，然后向所述运维终端发送所述第二查询结果。

可以看出，本实施例中，通过设置处理失败查询机制，使得用户能够通过可视化界面直接查询业务事件的处理失败状态，提高了查询效率。

在一个可能的实施例中，所述根据所述第二业务事件ID查询所述第二业务事件的第二查询结果，包括：确定所述运维终端的运维界面上所显示的第三查询结果所对应的第三业务事件ID；确定所述第三业务事件ID与所述第二业务事件ID是否相同；若所述第三业务事件ID与所述第二业务事件ID相同，则生成所述弹窗界面，所述弹窗界面至少包括失败原因、失败总次数、当前失败次数和处理时间；若所述第三业务事件ID与所述第二业务事件ID不相同，生成第二运维界面，所述第二运维界面包括第二查询区域和第二查询结果区域，所述第二查询区域至少包括第二事件日记ID输入框，第二事件日记ID用于指示对应的业务事件，所述第二查询结果区域用于显示与所述第二事件日记ID对应的第二查询结果。

具体实现中，在所述业务处理服务器接收到所述第二查询请求之后，先判断所述运维终端的界面上所显示的第三查询结果对应的第三业务事件与所要查询的第二业务事件是否相同；若是相同，则表示运维人员正在查询所述第二业务事件对应的第一查询结果，因此可以在第一查询结果显示界面的基础上弹窗显示对应的处理失败状态所对应的信息，以便于用户查看，而且弹窗可以由运维人员自由移动，尽量不影响对第一查询结果的查看；若是不相同，则表示运维人员并未在查询所述第二业务事件对应的第一查询结果，因此直接将所述处理失败状态对应的信息以第二查询结果的方式在运维界面上更新所述第二查询结果。

可以看出，本实施例中，能够根据运维端的查询状态自动调整查询结果的显示形式，以提高对不同业务情景的适配效果，提高人机交互效果和查询效率。

在一个可能的实施例中，如图3b和图3c所示，所述第二运维界面包括弹窗界面（如图3b中的“失败状态查询”界面）或隐藏界面（如图3c中加粗部分，可以通过下拉控件展开和隐藏）；所述生成第二运维界面，包括：确定所述第二查询请求是否存在隐藏标识；若存在所述隐藏标识，则在所述第一查询结果区域中生成所述隐藏界面，所述隐藏界面中包括展开控件，所述展开控件用于将所述显示界面中的内容展开；若不存在，则在运维终端的屏幕上生成弹窗界面。

具体实现中，在所述运维终端发送所述第二查询请求之前，可以由所述运维人员先选择所述第二运维界面的显示形式；若所述运维人员选择了隐藏界面，则会生成隐藏标识，在发送所述第二查询请求时则携带所述隐藏标识；若所述运维人员选择了弹窗界面，则生成弹窗标识，在发送所述第二查询请求时则携带所述弹窗标识；此外，在选择所述弹窗界面时，还可以不生成任何标识，若所述事件处理服务器在所述第二查询请中未检测到任何标识，则默认为弹窗界面。

进一步的，还可以由所述运维终端根据所述运维在当前显示界面上所剩余的空白空间是否大于预设阈值，若是，则生成弹窗标识，若否，则生成隐藏标识。

所述事件处理服务器在接收到所述第二查询请求之后，确定所述第二查询请求中是否存在隐藏标识，若存在，则向所述运维终端发送所述隐藏界面。此外，若所述第二查询请求中不存在所述隐藏标识，则向所述运维终端发送所述弹窗界面。

可以看出，本实施例中，通过隐藏标识确定向运维终端发送的第二运维界面的类型，提高了可视化界面显示的智能性。

在一个可能的实施例中，所述根据所述第二业务事件ID查询所述第二业务事件的第二查询结果之后，所述方法还包括：检测到第二业务事件的处理失败状态的更新信息；确定所述运维终端当前是否在查询所述第二业务事件；若所述运维终端当前在查询所述第二业务事件，则根据所述更新信息生成更新数据包；向所述运维终端发送所述更新数据包，所述更新数据包用于指示所述运维终端在所述运维界面上更新所述更新信息。

具体实现中，当所述事件处理服务器对所述第二业务事件处理失败时，会产生处理失败数据，进而生成针对所述第二业务事件的处理失败状态的更新信息。此时，所述事件处理服务器需要先确定所述运维终端当前是否正在查询所述第二业务事件。若是，则表示运维终端上的运维界面当前所述显示不是最新的信息，为了使得用户能够实时查询到最新信息，因此，所述事件处理服务器直接根据所述更新信息生成更新数据包，并向所述运维终端发送所述更新数据包；当所述运维终端接收到所述更新数据包时，可以直接在所述运维界面上更新处理失败状态对应的最新信息，而且在没有数据更新时不刷新运维界面，避免影响运维人员的查看体验。若否，则表示运维终端上未显示第二业务事件对应的信息，因此，不需要进行更新，可以先使用所述更新信息更新存储在数据库中的数据，等待用户下次查询时，将最新的处理失败状态信息发送给运维终端。

可以看出，本实施例中，当用户正在查询对应的业务事件存在更新数据时，实时更新对应的数据，以使得用户能够实时确定事件处理状态，而不需要运维人员再次主动查询，提高了事件处理服务器的智能性，提高了查询效率。

在一个可能的实施例中，所述确定所述运维终端当前是否在查询所述第二业务事件，包括：确定所述第二业务事件对应的运维ID；获取所述运维ID对应的查询日志；若所述查询日志中存在关于所述第二业务事件的查询记录，则确定所述运维终端当前正在查询所述第二业务事件；若所述查询日志中不存在关于所述第二业务事件的查询记录，则确定所述运维终端当前未查询所述第二业务事件。

具体实现中，在所述运维终端向所述事件处理服务器发送查询请求时，所述事件处理服务器会保存该查询请求对应的查询日志。所述事件处理服务器会从所述查询日志中提取对应的查询记录，若存在关于所述第二业务事件的查询记录，则确定用户正在查询所述第二业务事件；若所述查询日志中不存在关于所述第二业务事件的查询记录，则确定所述运维终端当前未查询所述第二业务事件。

可以看出，本实施例中，通过存储运维终端的查询日志，进而确定用户是否正在查询对应的业务事件，提高了事件处理服务器的智能性，提高了查询效率。

本申请还提供了一种基于房地产管理系统的事件查询方法，应用于房地产管理系统的运维终端，所述房地产管理系统可以包括用户的用户账号所关联的用户终端、运维账号所关联的所述运维终端和事件处理服务器；所述方法包括：

向所述事件处理服务器发送登录请求；

接收来自所述事件处理服务器的运维界面数据包；

根据所述运维界面数据包在所述运维终端的屏幕上显示运维界面，所述运维界面包括查询区域和查询结果区域，所述查询区域至少包括事件日记ID输入框，事件日记ID用于指示对应的业务事件，所述查询结果区域用于显示与所述事件日记ID对应的查询结果；

获取运维人员输入的事件日记ID，并根据所述事件日记ID生成查询请求；

向所述事件处理服务器发送所述查询请求；

接收来自所述事件处理服务器的所述查询结果，所述查询结果包括基础信息和事件投递信息，所述基础信息至少包括事件ID、事件名称、事件源、事件处理成功次数、事件落库时间、事件生成时间和事件原始数据，所述事件投递信息至少包括综合信息和至少一个单次投递信息，所述综合信息至少包括用户ID、处理状态和投递总次数和处理成功时间，每个单次投递信息至少包括当前投递次数、本次投递时间、本次处理状态、本次处理耗时、本次处理结果、本次结果回传时间和本次处理客户端ID。

可以看出，本申请实施例中，首先接收来自所述运维终端的登录请求；根据所述登录请求生成运维界面数据包，所述运维界面数据包用于生成第一运维界面；接收来自所述运维终端的第一查询请求，所述第一查询请求用于查询处理成功事件，所述第一查询请求包括第一业务事件的第一业务事件ID；根据所述第一业务事件ID查询第一业务事件的第一查询结果；向所述运维终端发送所述查询结果。这样，使得事件处理服务器向运维终端提供了可视化的运维界面，提高了运维人员与事件处理服务器之间的人机交互效率，进而提高了对业务事件的查询效率。

本申请还提供了一种用户设备的用户界面，所述运维终端包括显示屏，所述显示屏上显示有如上述方法中的运维界面，所述运维界面包括由用户通过所述显示屏输入触摸指令对所述用户界面进行控制，或者由所述用户通过输入设备输入控制指令对所述运维界面进行控制；

所述运维界面包括查询区域和查询结果区域，所述查询区域至少包括事件日记ID输入框，事件日记ID用于指示对应的业务事件，所述查询结果区域用于显示与所述事件日记ID对应的查询结果；

所述查询结果包括基础信息和事件投递信息，所述基础信息至少包括事件ID、事件名称、事件源、事件处理成功次数、事件落库时间、事件生成时间和事件原始数据，所述事件投递信息至少包括综合信息和至少一个单次投递信息，所述综合信息至少包括用户ID、处理状态和投递总次数和处理成功时间，每个单次投递信息至少包括当前投递次数、本次投递时间、本次处理状态、本次处理耗时、本次处理结果、本次结果回传时间和本次处理客户端ID。

上述主要从方法侧执行过程的角度对本申请实施例的方案进行了介绍。可以理解的是，移动电子设备为了实现上述功能，其包含了执行各个功能相应的硬件结构和/或软件模块。本领域技术人员应该很容易意识到，结合本文中所提供的实施例描述的各示例的单元及算法步骤，本申请能够以硬件或硬件和计算机软件的结合形式来实现。某个功能究竟以硬件还是计算机软件驱动硬件的方式来执行，取决于技术方案的特定应用和设计约束条件。专业技术人员可以对每个特定的应用使用不同方法来实现所描述的功能，但是这种实现不应认为超出本申请的范围。

本申请实施例可以根据上述方法示例对电子设备进行功能单元的划分，例如，可以对应各个功能划分各个功能单元，也可以将两个或两个以上的功能集成在一个处理单元中。上述集成的单元既可以采用硬件的形式实现，也可以采用软件功能单元的形式实现。需要说明的是，本申请实施例中对单元的划分是示意性的，仅仅为一种逻辑功能划分，实际实现时可以有另外的划分方式。

请参阅图4，图4是本申请实施例提供的一种基于房地产管理系统的事件查询装置的结构示意图，所述装置应用于房地产管理系统的事件处理服务器，所述房地产管理系统包括用户的用户账号所关联的用户终端、运维账号所关联的运维终端和所述事件处理服务器；所述装置包括：

接收单元31，用于接收来自所述运维终端的登录请求；

生成单元32，用于根据所述登录请求生成运维界面数据包，所述运维界面数据包用于生成第一运维界面，所述第一运维界面包括第一查询区域和第一查询结果区域，所述第一查询区域至少包括第一事件日记ID输入框，第一事件日记ID用于指示对应的业务事件，所述第一查询结果区域用于显示与所述第一事件日记ID对应的第一查询结果；

所述接收单元31，还用于接收来自所述运维终端的第一查询请求，所述第一查询请求用于查询处理成功事件，所述第一查询请求包括第一业务事件的第一业务事件ID；

查询单元34，用于根据所述第一业务事件ID查询第一业务事件的第一查询结果，所述第一查询结果包括基础信息和事件投递信息，所述基础信息至少包括事件ID、事件名称、事件源、事件处理成功次数、事件落库时间、事件生成时间和事件原始数据，所述事件投递信息至少包括综合信息和至少一个单次投递信息，所述综合信息至少包括用户ID、处理状态和投递总次数和处理成功时间，每个单次投递信息至少包括当前投递次数、本次投递时间、本次处理状态、本次处理耗时、本次处理结果、本次结果回传时间和本次处理客户端ID；

发送单元33，用于向所述运维终端发送所述查询结果。

可以看出，本申请实施例中，首先接收来自所述运维终端的登录请求；根据所述登录请求生成运维界面数据包，所述运维界面数据包用于生成第一运维界面；接收来自所述运维终端的第一查询请求，所述第一查询请求用于查询处理成功事件，所述第一查询请求包括第一业务事件的第一业务事件ID；根据所述第一业务事件ID查询第一业务事件的第一查询结果；向所述运维终端发送所述查询结果。这样，使得事件处理服务器向运维终端提供了可视化的运维界面，提高了运维人员与事件处理服务器之间的人机交互效率，进而提高了对业务事件的查询效率。

在一个可能的实施例中，所述向所述运维终端发送所述查询结果的方面之后；所述装置还包括：所述接收单元31还用于接收来自运维终端的第二查询请求，所述第二查询请求用于查询处理失败事件，所述第二查询请求包括第二业务事件的第二业务事件ID；所述查询单元34还用于根据所述第二业务事件ID查询所述第二业务事件的第二查询结果。

在一个可能的实施例中，所述根据所述第二业务事件ID查询所述第二业务事件的第二查询结果的方面，所述查询单元34具体用于：确定所述运维终端的运维界面上所显示的第三查询结果所对应的第三业务事件ID；确定所述第三业务事件ID与所述第二业务事件ID是否相同；若所述第三业务事件ID与所述第二业务事件ID相同，则生成所述弹窗界面，所述弹窗界面至少包括失败原因、失败总次数、当前失败次数和处理时间；若所述第三业务事件ID与所述第二业务事件ID不相同，生成第二运维界面，所述第二运维界面包括第二查询区域和第二查询结果区域，所述第二查询区域至少包括第二事件日记ID输入框，第二事件日记ID用于指示对应的业务事件，所述第二查询结果区域用于显示与所述第二事件日记ID对应的第二查询结果。

在一个可能的实施例中，所述根据所述第二业务事件ID查询所述第二业务事件的第二查询结果的方面之后，所述装置还包括：检测单元，用于检测第二业务事件的处理失败状态的更新信息；确定单元，用于确定所述运维终端当前是否在查询所述第二业务事件；所述生成单元32还用于在所述运维终端当前在查询所述第二业务事件时，根据所述更新信息生成更新数据包；所述发送单元33还用于向所述运维终端发送所述更新数据包，所述更新数据包用于指示所述运维终端在所述运维界面上更新所述更新信息。

在一个可能的实施例中，所述确定所述运维终端当前是否在查询所述第二业务事件的方面，所述确定单元具体用于：确定所述第二业务事件对应的运维ID；获取所述运维ID对应的查询日志；若所述查询日志中存在关于所述第二业务事件的查询记录，则确定所述运维终端当前正在查询所述第二业务事件；若所述查询日志中不存在关于所述第二业务事件的查询记录，则确定所述运维终端当前未查询所述第二业务事件。

上述实施例，可以全部或部分地通过软件、硬件、固件或其他任意组合来实现。当使用软件实现时，上述实施例可以全部或部分地以计算机程序产品的形式实现。所述计算机程序产品包括一个或多个计算机指令或计算机程序。在计算机上加载或执行所述计算机指令或计算机程序时，全部或部分地产生按照本申请实施例所述的流程或功能。所述计算机可以为通用计算机、专用计算机、计算机网络、或者其他可编程装置。所述计算机指令可以存储在计算机可读存储介质中，或者从一个计算机可读存储介质向另一个计算机可读存储介质传输，例如，所述计算机指令可以从一个网站站点、计算机、服务器或数据中心通过有线或无线方式向另一个网站站点、计算机、服务器或数据中心进行传输。所述计算机可读存储介质可以是计算机能够存取的任何可用介质或者是包含一个或多个可用介质集合的服务器、数据中心等数据存储设备。所述可用介质可以是磁性介质（例如，软盘、硬盘、磁带）、光介质（例如，DVD）、或者半导体介质。半导体介质可以是固态硬盘。

本申请实施例还提供一种计算机存储介质，其中，该计算机存储介质存储用于电子数据交换的计算机程序，该计算机程序使得计算机执行如上述方法实施例中记载的任一方法的部分或全部步骤，上述计算机包括电子设备。

本申请实施例还提供一种计算机程序产品，上述计算机程序产品包括存储了计算机程序的非瞬时性计算机可读存储介质，上述计算机程序可操作来使计算机执行如上述方法实施例中记载的任一方法的部分或全部步骤。该计算机程序产品可以为一个软件安装包，上述计算机包括电子设备。

应理解，在本申请的各种实施例中，上述各过程的序号的大小并不意味着执行顺序的先后，各过程的执行顺序应以其功能和内在逻辑确定，而不应对本申请实施例的实施过程构成任何限定。

在本申请所提供的几个实施例中，应该理解到，所揭露的方法、装置和系统，可以通过其它的方式实现。例如，以上所描述的装置实施例仅仅是示意性的；例如，所述单元的划分，仅仅为一种逻辑功能划分，实际实现时可以有另外的划分方式；例如多个单元或组件可以结合或者可以集成到另一个系统，或一些特征可以忽略，或不执行。另一点，所显示或讨论的相互之间的耦合或直接耦合或通信连接可以是通过一些接口，装置或单元的间接耦合或通信连接，可以是电性，机械或其它的形式。

所述作为分离部件说明的单元可以是或者也可以不是物理上分开的，作为单元显示的部件可以是或者也可以不是物理单元，即可以位于一个地方，或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部单元来实现本实施例方案的目的。

另外，在本发明各个实施例中的各功能单元可以集成在一个处理单元中，也可以是各个单元单独物理包括，也可以两个或两个以上单元集成在一个单元中。上述集成的单元既可以采用硬件的形式实现，也可以采用硬件加软件功能单元的形式实现。

上述以软件功能单元的形式实现的集成的单元，可以存储在一个计算机可读取存储介质中。上述软件功能单元存储在一个存储介质中，包括若干指令用以使得一台计算机设备（可以是个人计算机，服务器，或者网络设备等）执行本发明各个实施例所述方法的部分步骤。而前述的存储介质包括：U盘、移动硬盘、磁碟、光盘、易失性存储器或非易失性存储器。其中，非易失性存储器可以是只读存储器（read-only memory，ROM）、可编程只读存储器（programmable ROM，PROM）、可擦除可编程只读存储器（erasable PROM，EPROM）、电可擦除可编程只读存储器（electrically EPROM，EEPROM）或闪存。易失性存储器可以是随机存取存储器（random access memory，RAM），其用作外部高速缓存。通过示例性但不是限制性说明，许多形式的随机存取存储器（random access memory，RAM）可用，例如静态随机存取存储器（static RAM，SRAM）、动态随机存取存储器（DRAM）、同步动态随机存取存储器（synchronous DRAM，SDRAM）、双倍数据速率同步动态随机存取存储器（double data rateSDRAM，DDR SDRAM）、增强型同步动态随机存取存储器（enhanced SDRAM，ESDRAM）、同步连接动态随机存取存储器（synchlink DRAM，SLDRAM）和直接内存总线随机存取存储器（directrambus RAM，DR RAM）。等各种可以存储程序代码的介质。

虽然本发明披露如上，但本发明并非限定于此。任何本领域技术人员，在不脱离本发明的精神和范围内，可轻易想到变化或替换，均可作各种更动与修改，包含上述不同功能、实施步骤的组合，包含软件和硬件的实施方式，均在本发明的保护范围。

Claims (10)

1.一种基于房地产管理系统的事件查询方法，其特征在于，应用于房地产管理系统的事件处理服务器，所述房地产管理系统包括运维账号所关联的运维终端和所述事件处理服务器；所述方法包括：

接收来自所述运维终端的登录请求；

根据所述登录请求生成运维界面数据包，所述运维界面数据包用于生成第一运维界面，所述第一运维界面包括第一查询区域和第一查询结果区域，所述第一查询区域至少包括第一事件日记ID输入框，第一事件日记ID用于指示对应的业务事件，所述第一查询结果区域用于显示与所述第一事件日记ID对应的第一查询结果；

接收来自所述运维终端的第一查询请求，所述第一查询请求用于查询处理成功事件，所述第一查询请求包括第一业务事件的第一业务事件ID；

根据所述第一业务事件ID查询第一业务事件的第一查询结果，所述第一查询结果包括基础信息和事件投递信息，所述基础信息至少包括事件ID、事件名称、事件源、事件处理成功次数、事件落库时间、事件生成时间和事件原始数据，所述事件投递信息至少包括综合信息和至少一个单次投递信息，所述综合信息至少包括用户ID、处理状态和投递总次数和处理成功时间，每个单次投递信息至少包括当前投递次数、本次投递时间、本次处理状态、本次处理耗时、本次处理结果、本次结果回传时间和本次处理客户端ID；

向所述运维终端发送所述查询结果。

2.根据权利要求1所述的方法，其特征在于，所述向所述运维终端发送所述查询结果之后；所述方法还包括：

接收来自运维终端的第二查询请求，所述第二查询请求用于查询处理失败事件，所述第二查询请求包括第二业务事件的第二业务事件ID；

根据所述第二业务事件ID查询所述第二业务事件的第二查询结果；

向所述运维终端发送所述第二查询结果。

3.根据权利要求2所述的方法，其特征在于，所述根据所述第二业务事件ID查询所述第二业务事件的第二查询结果，包括：

确定所述运维终端的运维界面上所显示的第三查询结果所对应的第三业务事件ID；

确定所述第三业务事件ID与所述第二业务事件ID是否相同；

若所述第三业务事件ID与所述第二业务事件ID相同，则生成弹窗界面，所述弹窗界面至少包括失败原因、失败总次数、当前失败次数和处理时间；

若所述第三业务事件ID与所述第二业务事件ID不相同，生成第二运维界面，所述第二运维界面包括第二查询区域和第二查询结果区域，所述第二查询区域至少包括第二事件日记ID输入框，第二事件日记ID用于指示对应的业务事件，所述第二查询结果区域用于显示与所述第二事件日记ID对应的第二查询结果。

4.根据权利要求3所述的方法，其特征在于，所述根据所述第二业务事件ID查询所述第二业务事件的第二查询结果之后，所述方法还包括：

检测到第二业务事件的处理失败状态的更新信息；

确定所述运维终端当前是否在查询所述第二业务事件；

若所述运维终端当前在查询所述第二业务事件，则根据所述更新信息生成更新数据包；向所述运维终端发送所述更新数据包，所述更新数据包用于指示所述运维终端在所述运维界面上更新所述更新信息。

5.根据权利要求1-4任一项所述的方法，其特征在于，所述确定所述运维终端当前是否在查询所述第二业务事件，包括：

确定所述第二业务事件对应的运维ID；

获取所述运维ID对应的查询日志；

若所述查询日志中存在关于所述第二业务事件的查询记录，则确定所述运维终端当前正在查询所述第二业务事件；

若所述查询日志中不存在关于所述第二业务事件的查询记录，则确定所述运维终端当前未查询所述第二业务事件。

6.一种基于房地产管理系统的事件查询方法，其特征在于，应用于房地产管理系统的运维终端，所述房地产管理系统包括运维账号所关联的所述运维终端和事件处理服务器；所述方法包括：

向所述事件处理服务器发送登录请求；

接收来自所述事件处理服务器的运维界面数据包；

根据所述运维界面数据包在所述运维终端的屏幕上显示运维界面，所述运维界面包括查询区域和查询结果区域，所述查询区域至少包括事件日记ID输入框，事件日记ID用于指示对应的业务事件，所述查询结果区域用于显示与所述事件日记ID对应的查询结果；

获取运维人员输入的事件日记ID，并根据所述事件日记ID生成查询请求；

向所述事件处理服务器发送所述查询请求；

接收来自所述事件处理服务器的所述查询结果，所述查询结果包括基础信息和事件投递信息，所述基础信息至少包括事件ID、事件名称、事件源、事件处理成功次数、事件落库时间、事件生成时间和事件原始数据，所述事件投递信息至少包括综合信息和至少一个单次投递信息，所述综合信息至少包括用户ID、处理状态和投递总次数和处理成功时间，每个单次投递信息至少包括当前投递次数、本次投递时间、本次处理状态、本次处理耗时、本次处理结果、本次结果回传时间和本次处理客户端ID。

7.一种用户设备的用户界面，其特征在于，所述运维终端包括显示屏，所述显示屏上显示有如上述方法中的运维界面，所述运维界面包括由用户通过所述显示屏输入触摸指令对所述用户界面进行控制，或者由所述用户通过输入设备输入控制指令对所述运维界面进行控制；

所述运维界面包括查询区域和查询结果区域，所述查询区域至少包括事件日记ID输入框，事件日记ID用于指示对应的业务事件，所述查询结果区域用于显示与所述事件日记ID对应的查询结果；

所述查询结果包括基础信息和事件投递信息，所述基础信息至少包括事件ID、事件名称、事件源、事件处理成功次数、事件落库时间、事件生成时间和事件原始数据，所述事件投递信息至少包括综合信息和至少一个单次投递信息，所述综合信息至少包括用户ID、处理状态和投递总次数和处理成功时间，每个单次投递信息至少包括当前投递次数、本次投递时间、本次处理状态、本次处理耗时、本次处理结果、本次结果回传时间和本次处理客户端ID。

8.一种电子设备，其特征在于，包括处理器、存储器、通信接口，以及一个或多个程序，所述一个或多个程序被存储在所述存储器中，并且被配置由所述处理器执行，所述程序包括用于执行如权利要求1-5任一项所述的方法中的步骤的指令。

9.一种计算机可读存储介质，其特征在于，存储用于电子数据交换的计算机程序，其中，所述计算机程序使得计算机执行如权利要求1-5任一项所述的方法中的步骤的指令。

10.一种计算机程序产品，其特征在于，包括存储了计算机程序的非瞬时性计算机可读存储介质，所述计算机程序可被操作来使计算机执行如权利要求1-5任一项所述的方法中的步骤的指令。

Images