CN117032655A - 一种业务通知组件设计方法、装置、设备及其存储介质 - Google Patents

Abstract

本申请实施例属于数字医疗技术领域，应用于跨多平台的数字化医疗系统进行业务通知过程中，涉及一种业务通知组件设计方法、装置、设备及其存储介质，包括根据业务接触项的在后通知程序所属的业务通知类别是否需要回复，在基础设施层对通知业务进行领域设计，实现了对业务通知组件的设计，在原有的分层设计中，对基础设施层之内的通知提醒服务进行聚合和整理，使得将多个独立的通知提醒整理为最小提醒次数的通知提醒，提升用户的业务体验度，避免了形成通知服务孤岛与数据孤岛，降低通知服务的混乱度和复杂度，使得通知服务更加科学化和规范化，对数字医疗平台或者医疗机构平台的通知提醒服务进行整合，以提高患者接收通知提醒的体验。

Description

一种业务通知组件设计方法、装置、设备及其存储介质

技术领域

本申请涉及数字医疗技术领域，应用于跨多平台的数字化医疗系统进行业务通知过程中，尤其涉及一种业务通知组件设计方法、装置、设备及其存储介质。

背景技术

随着数字医疗行业的发展，越来越多的医疗相关数据需要进行以短信、邮件或者文件的形式发送给目标患者端，目标患者端的接触通知服务在跨多平台的医疗系统中极其重要，由于通知领域信息种类繁多、数量大、各业务系统各自实现触达功能导致业务通知功能混乱，另外这种“烟囱式”垂直型架构，各系统间服务与数据不共享，容易形成服务孤岛与数据孤岛，难以适应复杂和快速变化的业务。由于场景不灵活，通道单一且代码侵入性太高每次都需要重复造轮子，系统间集成成本较高，不利于业务沉淀与持续发展。

由于数字医疗技术的发展，在辅助患者获得检查报告结果或者在向医生咨询患病情况时，往往涉及到多个独立或者关联的通知提醒，现有通知提醒较多，易造成患者混淆。上述通知服务领域存在的问题，易给患者接收端带来较差的通知服务体验。

发明内容

本申请实施例的目的在于提出一种业务通知组件设计方法、装置、设备及其存储介质，以解决现有技术中通知服务领域中通知服务架构不科学，易给患者接收端带来较差的通知服务体验的问题。

为了解决上述技术问题，本申请实施例提供一种业务通知组件设计方法，采用了如下所述的技术方案：

一种业务通知组件设计方法，包括下述步骤：

通过预设的业务接入接口，接收测试用户请求的业务处理事件；

基于所述业务处理事件确定对应的程序执行代码，并根据所述业务处理事件执行所述程序执行代码，获取所述业务处理事件对应的执行日志；

通过解析所述执行日志获取所述测试用户对应的业务接触项；

根据预设的识别规则，判断所述业务接触项的在后通知程序所属的业务通知类别，其中，所述业务通知类别包括第一通知类别和第二通知类别，所述第一通知类别为无需回复型通知类别，所述第二通知类别为需回复型通知类别；

若所述业务接触项的在后通知程序所属的业务通知类别为第一通知类别，则将所述业务接触项的通知接口连接到预设的第一通知服务领域；

若所述业务接触项的在后通知程序所属的业务通知类别为第二通知类别，则将所述业务接触项的通知接口连接到预设的第二通知服务领域。

进一步的，所述基于所述业务处理事件确定对应的程序执行代码的步骤，具体包括：

获取所述业务处理事件对应的事件对象名称；

根据预设的目标执行系统的源代码和所述事件对象名称，确定所述事件对象名称对应的程序执行代码；

所述根据所述业务处理事件执行所述程序执行代码，获取所述业务处理事件对应的执行日志的步骤，具体包括：

通过预设的配置文件，获取所述业务处理事件对应的执行参数信息；

根据所述执行参数信息执行所述程序执行代码，获取所述业务处理事件对应的执行日志。

进一步的，在执行所述根据预设的识别规则，判断所述业务接触项的在后通知程序所属的业务通知类别的步骤之前，所述方法还包括：

预先根据不同业务接触项的在后通知程序所发送的通知是否需要回复，在所述基础设施层对业务通知类别进行领域划分，具体地，

根据不同业务接触项的在后通知程序所发送的通知是否需要回复，在所述基础设施层划分出第一通知服务领域和第二通知服务领域，其中，所述第一通知服务领域对应无需回复的业务接触项，所述第二通知服务领域对应需回复的业务接触项。

进一步的，所述根据不同业务接触项的在后通知程序所发送的通知是否需要回复，在所述基础设施层划分出第一通知服务领域和第二通知服务领域的步骤，具体包括：

为所述第一通知服务领域和所述第二通知服务领域设置区别域名，获取所述第一通知服务领域和所述第二通知服务领域分别对应的域名信息；

在执行所述根据不同业务接触项的在后通知程序所发送的通知是否需要回复，在所述基础设施层划分出第一通知服务领域和第二通知服务领域的步骤之后，所述方法还包括：

分别在所述第一通知服务领域和所述第二通知服务领域内聚合整理相同通知类别的业务接触项的通知处理中间件；

根据所述第一通知服务领域和所述第二通知服务领域分别对应的域名信息，设置所述第一通知服务领域和所述第二通知服务领域的通知输出接口，其中，所述第一通知服务领域的通知输出接口一端与所述第一通知服务领域内的通知处理中间件相连接，另一端与预设的通知接收端相连接，同理，所述第二通知服务领域的通知输出接口一端与所述第二通知服务领域内的通知处理中间件相连接，另一端与预设的通知接收端相连接。

进一步的，在执行所述若所述业务接触项的在后通知程序所属的业务通知类别为第一通知类别，则将所述业务接触项的通知接口连接到预设的第一通知服务领域的步骤之前，所述方法还包括：

预先根据所述第一通知服务领域的域名信息设置第一连接接口；

获取与所述第一通知服务领域建立通知接口连接关系的所有业务接触项；

将所述第一连接接口设置为与所述第一通知服务领域建立通知接口连接关系的所有业务接触项的目标接入接口；

所述若所述业务接触项的在后通知程序所属的业务通知类别为第一通知类别，则将所述业务接触项的通知接口连接到预设的第一通知服务领域的步骤，具体包括：

获取所述目标接入接口的连接地址；

通过所述目标接入接口的连接地址，将所述业务接触项的通知接口连接到所述第一通知服务领域。

进一步的，在执行所述若所述业务接触项的在后通知程序所属的业务通知类别为第二通知类别，则将所述业务接触项的通知接口连接到预设的第二通知服务领域的步骤之前，所述方法还包括：

预先根据所述第二通知服务领域的域名信息设置第二连接接口；

获取与所述第二通知服务领域建立通知接口连接关系的所有业务接触项；

将所述第二连接接口设置为与所述第二通知服务领域建立通知接口连接关系的所有业务接触项的目标接入接口；

所述若所述业务接触项的在后通知程序所属的业务通知类别为第二通知类别，则将所述业务接触项的通知接口连接到预设的第二通知服务领域的步骤，具体包括：

获取所述目标接入接口的连接地址；

通过所述目标接入接口的连接地址，将所述业务接触项的通知接口连接到所述第二通知服务领域。

进一步的，所述根据预设的识别规则，判断所述业务接触项的在后通知程序所属的业务通知类别的步骤，具体包括：

预先根据所述业务接触项的在后通知程序所属的业务通知类别是否需要回复在所述执行日志中设置区别标识字符，其中，所述区别标识字符包括需回复的标识字符和无需回复的标识字符；

根据解析所述执行日志所获取的区别标识字符，判断所述业务接触项的在后通知程序所属的业务通知类别。

为了解决上述技术问题，本申请实施例还提供一种业务通知组件设计装置，采用了如下所述的技术方案：

一种业务通知组件设计装置，包括：

业务处理接入模块，用于通过预设的业务接入接口，接收测试用户请求的业务处理事件；

执行日志获取模块，用于基于所述业务处理事件确定对应的程序执行代码，并根据所述业务处理事件执行所述程序执行代码，获取所述业务处理事件对应的执行日志；

业务接触项获取模块，用于通过解析所述执行日志获取所述测试用户对应的业务接触项；

业务通知类别判断模块，用于根据预设的识别规则，判断所述业务接触项的在后通知程序所属的业务通知类别，其中，所述业务通知类别包括第一通知类别和第二通知类别，所述第一通知类别为无需回复型通知类别，所述第二通知类别为需回复型通知类别；

第一处理选择模块，用于若所述业务接触项的在后通知程序所属的业务通知类别为第一通知类别，则将所述业务接触项的通知接口连接到预设的第一通知服务领域；

第二处理选择模块，用于若所述业务接触项的在后通知程序所属的业务通知类别为第二通知类别，则将所述业务接触项的通知接口连接到预设的第二通知服务领域。

为了解决上述技术问题，本申请实施例还提供一种计算机设备，采用了如下所述的技术方案：

一种计算机设备，包括存储器和处理器，所述存储器中存储有计算机可读指令，所述处理器执行所述计算机可读指令时实现上述所述的业务通知组件设计方法的步骤。

为了解决上述技术问题，本申请实施例还提供一种计算机可读存储介质，采用了如下所述的技术方案：

一种计算机可读存储介质，所述计算机可读存储介质上存储有计算机可读指令，所述计算机可读指令被处理器执行时实现如上述所述的业务通知组件设计方法的步骤。

与现有技术相比，本申请实施例主要有以下有益效果：

本申请实施例所述业务通知组件设计方法，通过预设的业务接入接口，接收测试用户请求的业务处理事件；基于业务处理事件确定对应的程序执行代码，并根据业务处理事件执行程序执行代码，获取业务处理事件对应的执行日志；通过解析执行日志获取测试用户对应的业务接触项；根据预设的识别规则，判断业务接触项的在后通知程序所属的业务通知类别；若业务接触项的在后通知程序所属的业务通知类别为第一通知类别，则将业务接触项的通知接口连接到预设的第一通知服务领域；若业务接触项的在后通知程序所属的业务通知类别为第二通知类别，则将业务接触项的通知接口连接到预设的第二通知服务领域。在原有的分层设计中，对基础设施层之内的通知提醒服务进行聚合和整理，使得将多个独立的通知提醒整理为最小提醒次数的通知提醒，提升用户的业务体验度，避免了形成通知服务孤岛与数据孤岛，降低通知服务的混乱度和复杂度，使得通知服务更加科学化和规范化，对数字医疗平台或者医疗机构平台的通知提醒服务进行整合，以提高患者接收通知提醒的体验。

附图说明

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

图1是本申请可以应用于其中的示例性系统架构图；

图2根据本申请的业务通知组件设计方法的一个实施例的流程图；

图3示出了根据本申请的业务通知组件设计方法所对应的业务系统的整体架构图；

图4根据本申请的业务通知组件设计装置的一个实施例的结构示意图；

图5根据本申请的计算机设备的一个实施例的结构示意图。

具体实施方式

除非另有定义，本文所使用的所有的技术和科学术语与属于本申请的技术领域的技术人员通常理解的含义相同；本文中在申请的说明书中所使用的术语只是为了描述具体的实施例的目的，不是旨在于限制本申请；本申请的说明书和权利要求书及上述附图说明中的术语“包括”和“具有”以及它们的任何变形，意图在于覆盖不排他的包含。本申请的说明书和权利要求书或上述附图中的术语“第一”、“第二”等是用于区别不同对象，而不是用于描述特定顺序。

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

为了使本技术领域的人员更好地理解本申请方案，下面将结合附图，对本申请实施例中的技术方案进行清楚、完整地描述。

如图1所示，系统架构100可以包括终端设备101、102、103，网络104和服务器105。网络104用以在终端设备101、102、103和服务器105之间提供通信链路的介质。网络104可以包括各种连接类型，例如有线、无线通信链路或者光纤电缆等等。

用户可以使用终端设备101、102、103通过网络104与服务器105交互，以接收或发送消息等。终端设备101、102、103上可以安装有各种通讯客户端应用，例如网页浏览器应用、购物类应用、搜索类应用、即时通信工具、邮箱客户端、社交平台软件等。

终端设备101、102、103可以是具有显示屏并且支持网页浏览的各种电子设备，包括但不限于智能手机、平板电脑、电子书阅读器、MP3播放器(Moving PictureExpertsGroup Audio Layer III，动态影像专家压缩标准音频层面3)、MP4(MovingPictureExperts Group Audio Layer IV，动态影像专家压缩标准音频层面4)播放器、膝上型便携计算机和台式计算机等等。

服务器105可以是提供各种服务的服务器，例如对终端设备101、102、103上显示的页面提供支持的后台服务器。

需要说明的是，本申请实施例所提供的业务通知组件设计方法一般由服务器/终端设备执行，相应地，业务通知组件设计装置一般设置于服务器/终端设备中。

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

继续参考图2，示出了根据本申请的业务通知组件设计方法的一个实施例的流程图。所述的业务通知组件设计方法，包括以下步骤：

步骤201，通过预设的业务接入接口，接收测试用户请求的业务处理事件。

本实施例中，所述预设的业务接入接口设置于网络应用系统分层体系中的业务接入层，其中，所述业务接入层由用户界面层、表示层和网关层共同构成。

本实施例中，所述网络应用系统包括跨多平台的数字化医疗系统。

本实施例中，所述测试用户包括在所述跨多平台的数字化医疗系统上进行人机交互操作的软件运维测试人员。

本实施例中，所述测试用户请求的业务处理事件包括由所述软件运维测试人员通过人机交互方式输入的业务测试请求，所述业务测试请求包括申请执行挂号预约业务、问诊咨询业务、缴费请求业务、科室选择业务、药品购买业务、检查报告下载上传业务、复诊快捷通道业务分别对应的请求等。每一个业务处理事件对应一个唯一事件名称，即程序执行代码中事件对象名称。

本实施例中，所述跨多平台的数字化医疗系统为经过分层设计的的网络应用系统，具体分层方式包括业务接入层、应用服务层、领域服务层和基础设施层。

通过对所述跨多平台的数字化医疗系统进行分层设计，使得不同分层内分别执行业务处理事件的目标逻辑代码，做到程序间的分层设计，便于后期对程序的维护。

步骤202，基于所述业务处理事件确定对应的程序执行代码，并根据所述业务处理事件执行所述程序执行代码，获取所述业务处理事件对应的执行日志。

本实施例中，所述基于所述业务处理事件确定对应的程序执行代码的步骤，具体包括：获取所述业务处理事件对应的事件对象名称；根据预设的目标执行系统的源代码和所述事件对象名称，确定所述事件对象名称对应的程序执行代码。

本实施例中，所述根据所述业务处理事件执行所述程序执行代码，获取所述业务处理事件对应的执行日志的步骤，具体包括：通过预设的配置文件，获取所述业务处理事件对应的执行参数信息；根据所述执行参数信息执行所述程序执行代码，获取所述业务处理事件对应的执行日志。

本实施例中，所述预设的目标执行系统指所述跨多平台的数字化医疗系统。

本实施例中，所述目标执行系统的源代码指所述跨多平台的数字化医疗系统的程序运行源码。

本实施例中，所述事件对象名称对应的程序执行代码分别存储于所述目标执行系统的应用服务层、领域服务层和基础设施层内，其中，所述应用服务层内存储的程序执行代码部分包括所述业务处理事件对应事件对象的生成和调用关系，所述领域服务层内存储的程序执行代码部分包括所述业务处理事件进行具体业务处理时实例化数据的预处理、计算和流转过程，所述基础设施层内存储的程序执行代码部分包括所述业务处理事件处理结果的输出过程，其中，所述输出过程包括直接输出过程和间接输出过程，所述直接输出过程即直接通过所述目标执行系统的预设界面展示给目标用户，所述间接输出过程包括通过第三方平台转发方式发送处理结果给目标用户，例如：微信小程序、短信、邮箱等第三方平台。

通过应用服务层内存储的程序执行代码部分包括所述业务处理事件对应事件对象的生成和调用关系，所述领域服务层内存储的程序执行代码部分包括所述业务处理事件进行具体业务处理时实例化数据的预处理、计算和流转过程，所述基础设施层内存储的程序执行代码部分包括所述业务处理事件处理结果的输出过程，做到对所述跨多平台的数字化医疗系统的程序运行源码进行分层设计，每一层只关注自身层的执行逻辑，保证了程序执行时的松散耦合性。

步骤203，通过解析所述执行日志获取所述测试用户对应的业务接触项。

本实施例中，所述业务接触项表示所述测试用户通过界面点击方式经所述业务接入层所引入的业务处理功能需求，例如挂号预约需求、问诊咨询需求、缴费请求需求、科室选择需求、药品购买需求、检查报告下载上传需求、复诊快捷通道需求等。

本实施例中，所述业务接触项根据是否能够执行成功，还包括有效业务接触项和无效业务接触项。

本实施例中，还包括业务接触项效力判断规则，用于判断所述业务接触项是属于有效业务接触项或者无效业务接触项，尤其是在界面上经测试用户可选择的逻辑按钮，例如，当前测试界面展示了三个可选择的业务处理事件，若测试用户选择了第二个业务处理事件，则所述第二个业务处理事件即为本次测试用户选择时的有效业务接触项，其他两个业务处理事件，即为本次测试用户选择时的无效业务接触项。

通过将所述测试用户通过界面点击方式经所述业务接入层所引入的业务处理功能需求整体作为所述业务接触项，便于以整体需求的方式对分层之后的系统进行重新优化。

步骤204，根据预设的识别规则，判断所述业务接触项的在后通知程序所属的业务通知类别。

本实施例中，所述业务通知类别包括第一通知类别和第二通知类别，所述第一通知类别为无需回复型通知类别，所述第二通知类别为需回复型通知类别，例如：问诊咨询需求这一业务接触项所对应的业务通知类型，显然为所述第二通知类别，需要医生和患者间进行问答回复；再者，检查报告下载上传需求、缴费请求需求、科室选择需求、挂号预约需求，此类业务接触项所对应的业务通知类型，显然为所述第一通知类别，只需在业务事件处理后，返回给操作者一个操作成功或者操作失败的状态即可，无需医生和患者间进行问答回复。

本实施例中，在执行所述根据预设的识别规则，判断所述业务接触项的在后通知程序所属的业务通知类别的步骤之前，所述方法还包括：预先根据不同业务接触项的在后通知程序所发送的通知是否需要回复，在所述基础设施层对业务通知类别进行领域划分，具体地，根据不同业务接触项的在后通知程序所发送的通知是否需要回复，在所述基础设施层划分出第一通知服务领域和第二通知服务领域，其中，所述第一通知服务领域对应无需回复的业务接触项，所述第二通知服务领域对应需回复的业务接触项。

本实施例中，所述根据不同业务接触项的在后通知程序所发送的通知是否需要回复，在所述基础设施层划分出第一通知服务领域和第二通知服务领域的步骤，具体包括：为所述第一通知服务领域和所述第二通知服务领域设置区别域名，获取所述第一通知服务领域和所述第二通知服务领域分别对应的域名信息。

本实施例中，在执行所述根据不同业务接触项的在后通知程序所发送的通知是否需要回复，在所述基础设施层划分出第一通知服务领域和第二通知服务领域的步骤之后，所述方法还包括：分别在所述第一通知服务领域和所述第二通知服务领域内聚合整理相同通知类别的业务接触项的通知处理中间件；根据所述第一通知服务领域和所述第二通知服务领域分别对应的域名信息，设置所述第一通知服务领域和所述第二通知服务领域的通知输出接口，其中，所述第一通知服务领域的通知输出接口一端与所述第一通知服务领域内的通知处理中间件相连接，另一端与预设的通知接收端相连接，同理，所述第二通知服务领域的通知输出接口一端与所述第二通知服务领域内的通知处理中间件相连接，另一端与预设的通知接收端相连接。

本实施例中，所述根据预设的识别规则，判断所述业务接触项的在后通知程序所属的业务通知类别的步骤，具体包括：预先根据所述业务接触项的在后通知程序所属的业务通知类别是否需要回复在所述执行日志中设置区别标识字符，其中，所述区别标识字符包括需回复的标识字符和无需回复的标识字符；根据解析所述执行日志所获取的区别标识字符，判断所述业务接触项的在后通知程序所属的业务通知类别。

本实施例中，判断业务通知类别的识别规则，可以采用执行日志区别标识字符的方式，也可以预先设置区别日志模板，例如第一通知类别的业务接触项的执行日志输出到第一日志模板，第二通知类别的业务接触项的执行日志输出到第二日志模板，后续只需判断日志模板类别即可识别当前业务接触项对应的业务通知类别。

本实施例中，所述业务通知组件设置在所述基础设施层，其根据业务接触项的在后通知程序所属的业务通知类别是否需要回复包括两个通知服务领域，分别为第一通知服务领域和第二通知服务领域，而且，所述第一通知服务领域和第二通知服务领域分别都设置有相应的域名信息、目标接入接口、通知处理中间件和通知输出接口。

继续参考图3，图3示出了根据本申请的业务通知组件设计方法所对应的业务系统的整体架构图，其中，图中301表示所述业务接入层，其由用户界面层301a、表示层301b和网关层301c共同构成，图中302表示所述应用服务层，用于存储的程序执行代码部分包括所述业务处理事件对应事件对象的生成和调用关系，图中303示出了所述领域服务层，用于存储的程序执行代码部分包括所述业务处理事件进行具体业务处理时实例化数据的预处理、计算和流转过程，图中304示出了所述基础设施层，用于存储的程序执行代码部分包括所述业务处理事件处理结果的输出过程，所述基础设施层304内至少包括经分领域设计的所述第一通知服务领域304a和第二通知服务领域304b。

根据业务接触项的在后通知程序所属的业务通知类别是否需要回复，在基础设施层对通知业务进行领域设计，并分别为不同通知服务领域设置相应的域名信息、目标接入接口、通知处理中间件和通知输出接口，便于对通知服务进行聚合优化，统一接入接口、通知处理中间件和通知输出接口，避免了形成通知服务孤岛与数据孤岛，降低通知服务的混乱度和复杂度，使得通知服务更加科学化和规范化。

步骤205，若所述业务接触项的在后通知程序所属的业务通知类别为第一通知类别，则将所述业务接触项的通知接口连接到预设的第一通知服务领域。

本实施例中，在执行所述若所述业务接触项的在后通知程序所属的业务通知类别为第一通知类别，则将所述业务接触项的通知接口连接到预设的第一通知服务领域的步骤之前，所述方法还包括：预先根据所述第一通知服务领域的域名信息设置第一连接接口；获取与所述第一通知服务领域建立通知接口连接关系的所有业务接触项；将所述第一连接接口设置为与所述第一通知服务领域建立通知接口连接关系的所有业务接触项的目标接入接口。

本实施例中，所述若所述业务接触项的在后通知程序所属的业务通知类别为第一通知类别，则将所述业务接触项的通知接口连接到预设的第一通知服务领域的步骤，具体包括：获取所述目标接入接口的连接地址；通过所述目标接入接口的连接地址，将所述业务接触项的通知接口连接到所述第一通知服务领域。

步骤206，若所述业务接触项的在后通知程序所属的业务通知类别为第二通知类别，则将所述业务接触项的通知接口连接到预设的第二通知服务领域。

本实施例中，在执行所述若所述业务接触项的在后通知程序所属的业务通知类别为第二通知类别，则将所述业务接触项的通知接口连接到预设的第二通知服务领域的步骤之前，所述方法还包括：预先根据所述第二通知服务领域的域名信息设置第二连接接口；获取与所述第二通知服务领域建立通知接口连接关系的所有业务接触项；将所述第二连接接口设置为与所述第二通知服务领域建立通知接口连接关系的所有业务接触项的目标接入接口。

本实施例中，所述若所述业务接触项的在后通知程序所属的业务通知类别为第二通知类别，则将所述业务接触项的通知接口连接到预设的第二通知服务领域的步骤，具体包括：获取所述目标接入接口的连接地址；通过所述目标接入接口的连接地址，将所述业务接触项的通知接口连接到所述第二通知服务领域。

通过根据业务接触项的在后通知程序所属的业务通知类别是否需要回复，在基础设施层对通知业务进行领域设计，并分别为不同通知服务领域设置相应的域名信息、目标接入接口、通知处理中间件和通知输出接口，实现了对业务通知组件的设计，在原有的微服务体系中的分层设计和领域划分中，对基础设施层之内的通知提醒服务进行聚合和整理，使得将多个独立的通知提醒整理为最小提醒次数的通知提醒，提升用户的业务体验度，考虑对数字医疗平台或者医疗机构平台的通知提醒服务进行整合，以提高患者接收通知提醒的体验。

本申请通过预设的业务接入接口，接收测试用户请求的业务处理事件；基于业务处理事件确定对应的程序执行代码，并根据业务处理事件执行程序执行代码，获取业务处理事件对应的执行日志；通过解析执行日志获取测试用户对应的业务接触项；根据预设的识别规则，判断业务接触项的在后通知程序所属的业务通知类别；若业务接触项的在后通知程序所属的业务通知类别为第一通知类别，则将业务接触项的通知接口连接到预设的第一通知服务领域；若业务接触项的在后通知程序所属的业务通知类别为第二通知类别，则将业务接触项的通知接口连接到预设的第二通知服务领域。在原有的分层设计中，对基础设施层之内的通知提醒服务进行聚合和整理，使得将多个独立的通知提醒整理为最小提醒次数的通知提醒，提升用户的业务体验度，避免了形成通知服务孤岛与数据孤岛，降低通知服务的混乱度和复杂度，使得通知服务更加科学化和规范化，对数字医疗平台或者医疗机构平台的通知提醒服务进行整合，以提高患者接收通知提醒的体验。

本申请实施例可以基于人工智能技术对相关的数据进行获取和处理。其中，人工智能(Artificial Intelligence，AI)是利用数字计算机或者数字计算机控制的机器模拟、延伸和扩展人的智能，感知环境、获取知识并使用知识获得最佳结果的理论、方法、技术及应用系统。

人工智能基础技术一般包括如传感器、专用人工智能芯片、云计算、分布式存储、大数据处理技术、操作/交互系统、机电一体化等技术。人工智能软件技术主要包括计算机视觉技术、机器人技术、生物识别技术、语音处理技术、自然语言处理技术以及机器学习/深度学习等几大方向。

本申请实施例中，通过在原有的分层设计中，对基础设施层之内的通知提醒服务进行聚合和整理，使得将多个独立的通知提醒整理为最小提醒次数的通知提醒，提升用户的业务体验度，避免了形成通知服务孤岛与数据孤岛，降低通知服务的混乱度和复杂度，使得通知服务更加科学化和规范化，对数字医疗平台或者医疗机构平台的通知提醒服务进行整合，以提高患者接收通知提醒的体验。

进一步参考图4，作为对上述图2所示方法的实现，本申请提供了一种业务通知组件设计装置的一个实施例，该装置实施例与图2所示的方法实施例相对应，该装置具体可以应用于各种电子设备中。

如图4所示，本实施例所述的业务通知组件设计装置400包括：业务处理接入模块401、执行日志获取模块402、业务接触项获取模块403、业务通知类别判断模块404、第一处理选择模块405和第二处理选择模块406。其中：

业务处理接入模块401，用于通过预设的业务接入接口，接收测试用户请求的业务处理事件；

执行日志获取模块402，用于基于所述业务处理事件确定对应的程序执行代码，并根据所述业务处理事件执行所述程序执行代码，获取所述业务处理事件对应的执行日志；

业务接触项获取模块403，用于通过解析所述执行日志获取所述测试用户对应的业务接触项；

业务通知类别判断模块404，用于根据预设的识别规则，判断所述业务接触项的在后通知程序所属的业务通知类别，其中，所述业务通知类别包括第一通知类别和第二通知类别，所述第一通知类别为无需回复型通知类别，所述第二通知类别为需回复型通知类别；

第一处理选择模块405，用于若所述业务接触项的在后通知程序所属的业务通知类别为第一通知类别，则将所述业务接触项的通知接口连接到预设的第一通知服务领域；

第二处理选择模块406，用于若所述业务接触项的在后通知程序所属的业务通知类别为第二通知类别，则将所述业务接触项的通知接口连接到预设的第二通知服务领域。

本实施例的一些具体实施方式中，所述的业务通知组件设计装置400还包括通知服务领域设计模块，所述通知服务领域设计模块用于预先根据不同业务接触项的在后通知程序所发送的通知是否需要回复，在所述基础设施层对业务通知类别进行领域划分，具体地，根据不同业务接触项的在后通知程序所发送的通知是否需要回复，在所述基础设施层划分出第一通知服务领域和第二通知服务领域，其中，所述第一通知服务领域对应无需回复的业务接触项，所述第二通知服务领域对应需回复的业务接触项。

本实施例的一些具体实施方式中，所述的业务通知组件设计装置400还包括领域设计结果命名模块，所述领域设计结果命名模块用于为所述第一通知服务领域和所述第二通知服务领域设置区别域名，获取所述第一通知服务领域和所述第二通知服务领域分别对应的域名信息。

本实施例的一些具体实施方式中，所述的业务通知组件设计装置400还包括通知处理中间件聚合模块，所述通知处理中间件聚合模块用于分别在所述第一通知服务领域和所述第二通知服务领域内聚合整理相同通知类别的业务接触项的通知处理中间件。

本实施例的一些具体实施方式中，所述的业务通知组件设计装置400还包括通知输出接口设置模块，所述通知输出接口设置模块用于根据所述第一通知服务领域和所述第二通知服务领域分别对应的域名信息，设置所述第一通知服务领域和所述第二通知服务领域的通知输出接口。

本实施例的一些具体实施方式中，所述的业务通知组件设计装置400还包括通知输出接口连接模块，所述通知输出接口连接模块用于将所述第一通知服务领域的通知输出接口一端与所述第一通知服务领域内的通知处理中间件相连接，另一端与预设的通知接收端相连接，还用于将所述第二通知服务领域的通知输出接口一端与所述第二通知服务领域内的通知处理中间件相连接，另一端与预设的通知接收端相连接。

本实施例的一些具体实施方式中，所述的业务通知组件设计装置400还包括通知输入接口设置模块，所述通知输入接口设置模块用于预先根据所述第一通知服务领域的域名信息设置第一连接接口，还用于预先根据所述第二通知服务领域的域名信息设置第二连接接口。

本实施例的一些具体实施方式中，所述的业务通知组件设计装置400还包括通知输入接口连接模块，所述通知输入接口连接模块用于将所述第一连接接口设置为与所述第一通知服务领域建立通知接口连接关系的所有业务接触项的目标接入接口，获取所述目标接入接口的连接地址，通过所述目标接入接口的连接地址，将所述业务接触项的通知接口连接到所述第一通知服务领域，还用于将所述第二连接接口设置为与所述第二通知服务领域建立通知接口连接关系的所有业务接触项的目标接入接口，获取所述目标接入接口的连接地址，通过所述目标接入接口的连接地址，将所述业务接触项的通知接口连接到所述第二通知服务领域。

本申请通过预设的业务接入接口，接收测试用户请求的业务处理事件；基于业务处理事件确定对应的程序执行代码，并根据业务处理事件执行程序执行代码，获取业务处理事件对应的执行日志；通过解析执行日志获取测试用户对应的业务接触项；根据预设的识别规则，判断业务接触项的在后通知程序所属的业务通知类别；若业务接触项的在后通知程序所属的业务通知类别为第一通知类别，则将业务接触项的通知接口连接到预设的第一通知服务领域；若业务接触项的在后通知程序所属的业务通知类别为第二通知类别，则将业务接触项的通知接口连接到预设的第二通知服务领域。在原有的分层设计中，对基础设施层之内的通知提醒服务进行聚合和整理，使得将多个独立的通知提醒整理为最小提醒次数的通知提醒，提升用户的业务体验度，避免了形成通知服务孤岛与数据孤岛，降低通知服务的混乱度和复杂度，使得通知服务更加科学化和规范化，对数字医疗平台或者医疗机构平台的通知提醒服务进行整合，以提高患者接收通知提醒的体验。

本领域普通技术人员可以理解实现上述实施例方法中的全部或部分流程，是可以通过计算机可读指令来指令相关的硬件来完成，该计算机可读指令可存储于计算机可读取存储介质中，该程序在执行时，可包括如上述各方法的实施例的流程。其中，前述的存储介质可为磁碟、光盘、只读存储记忆体(Read-Only Memory，ROM)等非易失性存储介质，或随机存储记忆体(Random Access Memory，RAM)等。

应该理解的是，虽然附图的流程图中的各个步骤按照箭头的指示依次显示，但是这些步骤并不是必然按照箭头指示的顺序依次执行。除非本文中有明确的说明，这些步骤的执行并没有严格的顺序限制，其可以以其他的顺序执行。而且，附图的流程图中的至少一部分步骤可以包括多个子步骤或者多个阶段，这些子步骤或者阶段并不必然是在同一时刻执行完成，而是可以在不同的时刻执行，其执行顺序也不必然是依次进行，而是可以与其他步骤或者其他步骤的子步骤或者阶段的至少一部分轮流或者交替地执行。

为解决上述技术问题，本申请实施例还提供计算机设备。具体请参阅图5，图5为本实施例计算机设备基本结构框图。

所述计算机设备5包括通过系统总线相互通信连接存储器5a、处理器5b、网络接口5c。需要指出的是，图中仅示出了具有组件5a-5c的计算机设备5，但是应理解的是，并不要求实施所有示出的组件，可以替代的实施更多或者更少的组件。其中，本技术领域技术人员可以理解，这里的计算机设备是一种能够按照事先设定或存储的指令，自动进行数值计算和/或信息处理的设备，其硬件包括但不限于微处理器、专用集成电路(ApplicationSpecific Integrated Circuit，ASIC)、可编程门阵列(Field－Programmable GateArray，FPGA)、数字处理器(Digital Signal Processor，DSP)、嵌入式设备等。

所述计算机设备可以是桌上型计算机、笔记本、掌上电脑及云端服务器等计算设备。所述计算机设备可以与用户通过键盘、鼠标、遥控器、触摸板或声控设备等方式进行人机交互。

所述存储器5a至少包括一种类型的可读存储介质，所述可读存储介质包括闪存、硬盘、多媒体卡、卡型存储器(例如，SD或DX存储器等)、随机访问存储器(RAM)、静态随机访问存储器(SRAM)、只读存储器(ROM)、电可擦除可编程只读存储器(EEPROM)、可编程只读存储器(PROM)、磁性存储器、磁盘、光盘等。在一些实施例中，所述存储器5a可以是所述计算机设备5的内部存储单元，例如该计算机设备5的硬盘或内存。在另一些实施例中，所述存储器5a也可以是所述计算机设备5的外部存储设备，例如该计算机设备5上配备的插接式硬盘，智能存储卡(Smart Media Card,SMC)，安全数字(Secure Digital,SD)卡，闪存卡(FlashCard)等。当然，所述存储器5a还可以既包括所述计算机设备5的内部存储单元也包括其外部存储设备。本实施例中，所述存储器5a通常用于存储安装于所述计算机设备5的操作系统和各类应用软件，例如业务通知组件设计方法的计算机可读指令等。此外，所述存储器5a还可以用于暂时地存储已经输出或者将要输出的各类数据。

所述处理器5b在一些实施例中可以是中央处理器(Central Processing Unit，CPU)、控制器、微控制器、微处理器、或其他数据处理芯片。该处理器5b通常用于控制所述计算机设备5的总体操作。本实施例中，所述处理器5b用于运行所述存储器5a中存储的计算机可读指令或者处理数据，例如运行所述业务通知组件设计方法的计算机可读指令。

所述网络接口5c可包括无线网络接口或有线网络接口，该网络接口5c通常用于在所述计算机设备5与其他电子设备之间建立通信连接。

本实施例提出的计算机设备，属于数字医疗技术领域，应用于跨多平台的数字化医疗系统进行业务通知过程中。本申请通过预设的业务接入接口，接收测试用户请求的业务处理事件；基于业务处理事件确定对应的程序执行代码，并根据业务处理事件执行程序执行代码，获取业务处理事件对应的执行日志；通过解析执行日志获取测试用户对应的业务接触项；根据预设的识别规则，判断业务接触项的在后通知程序所属的业务通知类别；若业务接触项的在后通知程序所属的业务通知类别为第一通知类别，则将业务接触项的通知接口连接到预设的第一通知服务领域；若业务接触项的在后通知程序所属的业务通知类别为第二通知类别，则将业务接触项的通知接口连接到预设的第二通知服务领域。在原有的分层设计中，对基础设施层之内的通知提醒服务进行聚合和整理，使得将多个独立的通知提醒整理为最小提醒次数的通知提醒，提升用户的业务体验度，避免了形成通知服务孤岛与数据孤岛，降低通知服务的混乱度和复杂度，使得通知服务更加科学化和规范化，对数字医疗平台或者医疗机构平台的通知提醒服务进行整合，以提高患者接收通知提醒的体验。

本申请还提供了另一种实施方式，即提供一种计算机可读存储介质，所述计算机可读存储介质存储有计算机可读指令，所述计算机可读指令可被处理器执行，以使所述处理器执行如上述的业务通知组件设计方法的步骤。

本实施例提出的计算机可读存储介质，属于数字医疗技术领域，应用于跨多平台的数字化医疗系统进行业务通知过程中。本申请通过预设的业务接入接口，接收测试用户请求的业务处理事件；基于业务处理事件确定对应的程序执行代码，并根据业务处理事件执行程序执行代码，获取业务处理事件对应的执行日志；通过解析执行日志获取测试用户对应的业务接触项；根据预设的识别规则，判断业务接触项的在后通知程序所属的业务通知类别；若业务接触项的在后通知程序所属的业务通知类别为第一通知类别，则将业务接触项的通知接口连接到预设的第一通知服务领域；若业务接触项的在后通知程序所属的业务通知类别为第二通知类别，则将业务接触项的通知接口连接到预设的第二通知服务领域。在原有的分层设计中，对基础设施层之内的通知提醒服务进行聚合和整理，使得将多个独立的通知提醒整理为最小提醒次数的通知提醒，提升用户的业务体验度，避免了形成通知服务孤岛与数据孤岛，降低通知服务的混乱度和复杂度，使得通知服务更加科学化和规范化，对数字医疗平台或者医疗机构平台的通知提醒服务进行整合，以提高患者接收通知提醒的体验。

通过以上的实施方式的描述，本领域的技术人员可以清楚地了解到上述实施例方法可借助软件加必需的通用硬件平台的方式来实现，当然也可以通过硬件，但很多情况下前者是更佳的实施方式。基于这样的理解，本申请的技术方案本质上或者说对现有技术做出贡献的部分可以以软件产品的形式体现出来，该计算机软件产品存储在一个存储介质(如ROM/RAM、磁碟、光盘)中，包括若干指令用以使得一台终端设备(可以是手机，计算机，服务器，空调器，或者网络设备等)执行本申请各个实施例所述的方法。

显然，以上所描述的实施例仅仅是本申请一部分实施例，而不是全部的实施例，附图中给出了本申请的较佳实施例，但并不限制本申请的专利范围。本申请可以以许多不同的形式来实现，相反地，提供这些实施例的目的是使对本申请的公开内容的理解更加透彻全面。尽管参照前述实施例对本申请进行了详细的说明，对于本领域的技术人员来而言，其依然可以对前述各具体实施方式所记载的技术方案进行修改，或者对其中部分技术特征进行等效替换。凡是利用本申请说明书及附图内容所做的等效结构，直接或间接运用在其他相关的技术领域，均同理在本申请专利保护范围之内。

Claims (10)

1.一种业务通知组件设计方法，其特征在于，包括下述步骤：

通过预设的业务接入接口，接收测试用户请求的业务处理事件；

基于所述业务处理事件确定对应的程序执行代码，并根据所述业务处理事件执行所述程序执行代码，获取所述业务处理事件对应的执行日志；

通过解析所述执行日志获取所述测试用户对应的业务接触项；

根据预设的识别规则，判断所述业务接触项的在后通知程序所属的业务通知类别，其中，所述业务通知类别包括第一通知类别和第二通知类别，所述第一通知类别为无需回复型通知类别，所述第二通知类别为需回复型通知类别；

若所述业务接触项的在后通知程序所属的业务通知类别为第一通知类别，则将所述业务接触项的通知接口连接到预设的第一通知服务领域；

若所述业务接触项的在后通知程序所属的业务通知类别为第二通知类别，则将所述业务接触项的通知接口连接到预设的第二通知服务领域。

2.根据权利要求1所述的业务通知组件设计方法，其特征在于，所述基于所述业务处理事件确定对应的程序执行代码的步骤，具体包括：

获取所述业务处理事件对应的事件对象名称；

根据预设的目标执行系统的源代码和所述事件对象名称，确定所述事件对象名称对应的程序执行代码；

所述根据所述业务处理事件执行所述程序执行代码，获取所述业务处理事件对应的执行日志的步骤，具体包括：

通过预设的配置文件，获取所述业务处理事件对应的执行参数信息；

根据所述执行参数信息执行所述程序执行代码，获取所述业务处理事件对应的执行日志。

3.根据权利要求1所述的业务通知组件设计方法，其特征在于，在执行所述根据预设的识别规则，判断所述业务接触项的在后通知程序所属的业务通知类别的步骤之前，所述方法还包括：

预先根据不同业务接触项的在后通知程序所发送的通知是否需要回复，在所述基础设施层对业务通知类别进行领域划分，具体地，

根据不同业务接触项的在后通知程序所发送的通知是否需要回复，在所述基础设施层划分出第一通知服务领域和第二通知服务领域，其中，所述第一通知服务领域对应无需回复的业务接触项，所述第二通知服务领域对应需回复的业务接触项。

4.根据权利要求3所述的业务通知组件设计方法，其特征在于，所述根据不同业务接触项的在后通知程序所发送的通知是否需要回复，在所述基础设施层划分出第一通知服务领域和第二通知服务领域的步骤，具体包括：

为所述第一通知服务领域和所述第二通知服务领域设置区别域名，获取所述第一通知服务领域和所述第二通知服务领域分别对应的域名信息；

在执行所述根据不同业务接触项的在后通知程序所发送的通知是否需要回复，在所述基础设施层划分出第一通知服务领域和第二通知服务领域的步骤之后，所述方法还包括：

分别在所述第一通知服务领域和所述第二通知服务领域内聚合整理相同通知类别的业务接触项的通知处理中间件；

根据所述第一通知服务领域和所述第二通知服务领域分别对应的域名信息，设置所述第一通知服务领域和所述第二通知服务领域的通知输出接口，其中，所述第一通知服务领域的通知输出接口一端与所述第一通知服务领域内的通知处理中间件相连接，另一端与预设的通知接收端相连接，同理，所述第二通知服务领域的通知输出接口一端与所述第二通知服务领域内的通知处理中间件相连接，另一端与预设的通知接收端相连接。

5.根据权利要求4所述的业务通知组件设计方法，其特征在于，在执行所述若所述业务接触项的在后通知程序所属的业务通知类别为第一通知类别，则将所述业务接触项的通知接口连接到预设的第一通知服务领域的步骤之前，所述方法还包括：

预先根据所述第一通知服务领域的域名信息设置第一连接接口；

获取与所述第一通知服务领域建立通知接口连接关系的所有业务接触项；

将所述第一连接接口设置为与所述第一通知服务领域建立通知接口连接关系的所有业务接触项的目标接入接口；

所述若所述业务接触项的在后通知程序所属的业务通知类别为第一通知类别，则将所述业务接触项的通知接口连接到预设的第一通知服务领域的步骤，具体包括：

获取所述目标接入接口的连接地址；

通过所述目标接入接口的连接地址，将所述业务接触项的通知接口连接到所述第一通知服务领域。

6.根据权利要求4所述的业务通知组件设计方法，其特征在于，在执行所述若所述业务接触项的在后通知程序所属的业务通知类别为第二通知类别，则将所述业务接触项的通知接口连接到预设的第二通知服务领域的步骤之前，所述方法还包括：

预先根据所述第二通知服务领域的域名信息设置第二连接接口；

获取与所述第二通知服务领域建立通知接口连接关系的所有业务接触项；

将所述第二连接接口设置为与所述第二通知服务领域建立通知接口连接关系的所有业务接触项的目标接入接口；

所述若所述业务接触项的在后通知程序所属的业务通知类别为第二通知类别，则将所述业务接触项的通知接口连接到预设的第二通知服务领域的步骤，具体包括：

获取所述目标接入接口的连接地址；

通过所述目标接入接口的连接地址，将所述业务接触项的通知接口连接到所述第二通知服务领域。

7.根据权利要求1至6任一项所述的业务通知组件设计方法，其特征在于，所述根据预设的识别规则，判断所述业务接触项的在后通知程序所属的业务通知类别的步骤，具体包括：

预先根据所述业务接触项的在后通知程序所属的业务通知类别是否需要回复在所述执行日志中设置区别标识字符，其中，所述区别标识字符包括需回复的标识字符和无需回复的标识字符；

根据解析所述执行日志所获取的区别标识字符，判断所述业务接触项的在后通知程序所属的业务通知类别。

8.一种业务通知组件设计装置，其特征在于，包括：

业务处理接入模块，用于通过预设的业务接入接口，接收测试用户请求的业务处理事件；

执行日志获取模块，用于基于所述业务处理事件确定对应的程序执行代码，并根据所述业务处理事件执行所述程序执行代码，获取所述业务处理事件对应的执行日志；

业务接触项获取模块，用于通过解析所述执行日志获取所述测试用户对应的业务接触项；

业务通知类别判断模块，用于根据预设的识别规则，判断所述业务接触项的在后通知程序所属的业务通知类别，其中，所述业务通知类别包括第一通知类别和第二通知类别，所述第一通知类别为无需回复型通知类别，所述第二通知类别为需回复型通知类别；

第一处理选择模块，用于若所述业务接触项的在后通知程序所属的业务通知类别为第一通知类别，则将所述业务接触项的通知接口连接到预设的第一通知服务领域；

第二处理选择模块，用于若所述业务接触项的在后通知程序所属的业务通知类别为第二通知类别，则将所述业务接触项的通知接口连接到预设的第二通知服务领域。

9.一种计算机设备，包括存储器和处理器，所述存储器中存储有计算机可读指令，所述处理器执行所述计算机可读指令时实现如权利要求1至7中任一项所述的业务通知组件设计方法的步骤。

10.一种计算机可读存储介质，其特征在于，所述计算机可读存储介质上存储有计算机可读指令，所述计算机可读指令被处理器执行时实现如权利要求1至7中任一项所述的业务通知组件设计方法的步骤。