具体实施方式
为使本公开的目的、特征、优点能够更加的明显和易懂,下面将结合本公开实施例中的附图,对本公开实施例中的技术方案进行清楚、完整地描述,显然,所描述的实施例仅仅是本公开一部分实施例,而非全部实施例。基于本公开中的实施例,本领域技术人员在没有做出创造性劳动前提下所获得的所有其他实施例,都属于本公开保护的范围。
为了简化通过网络消息通道群发信息的流程,本公开提供了一种消息的发送方法,该方法适用于图1所示的网络架构,包括:第三方应用客户端、第三方应用服务端、消息服务端和消息客户端。
其中,消息服务端部署在终端设备厂商侧,消息客户端部署在终端设备侧,一个消息服务端可管理多个消息客户端。消息服务端和其管理的消息客户端之间的消息传输通道即为网络消息通道。
信息的发送者(即客户)可通过第三方应用客户端编辑信息进行发送;第三方应用服务端可维护多个消息服务端(即终端设备厂商)的信息,以及每个消息服务端管理的多个消息客户端(即终端设备)的信息,将来自第三方应用客户端的信息转发给对应的消息服务端,由消息服务端将该消息分发给多个消息客户端。
基于该网络架构,消息发送者可通过其对应的第三方应用客户端将消息群发给多个消息客户端,无需与各个终端设备厂商进行对接。
下面通过具体的示例对本公开的消息发送方法进行说明,该方法应用于图1所示的第三方应用服务端,该方法的实现过程如图2所示,包括:
步骤101:接收来自第三方应用客户端的目标信息的第一发送请求消息。
本公开中,目标信息的大小不受限制,可以是传统的SMS短信大小(例如160个英文或数字字符,或者70个中文字符),也可以是消息发送者编辑的任意大小的信息。其中,目标信息的内容可包括文本、图片、网址链接等等。
在一个示例中,在接收到第三方应用客户端的第一发送请求信息时,可为该目标信息分配唯一的标识,以便于后续流程中通过该标识调取和识别该目标信息。
步骤102:查询支持网络消息的MDN,并生成第二发送请求消息,其中携带目标信息和MDN。
消息客户端授权接收网络消息后,将携带移动用户号码簿号码(MobileDirectory Number,MDN)的授权指令发送至消息服务端,消息服务端接收该授权指令并记录该消息客户端的MDN。如此,消息服务端可集合所有接收网络消息的消息客户端对应的MDN,并提交至第三方应用服务端。则第三方应用服务端可维护一个号码池来记录这些MDN。
在第三方应用服务端在该号码池中进行查询时,这些MDN被分成两类。
一类是支持网络消息的MDN,这类MDN对应的消息客户端在第三方应用服务端进行查询时,不仅开启接收网络消息的权限,并且处于连接网络的状态,第三方应用服务端将目标信息和MDN提交至该MDN对应的消息服务端,以使消息服务端将目标信息通过与消息客户端之间的网络消息通道发送至该MDN对应的消息客户端。另一类则是不支持网络消息的MDN,在第三方应用服务端进行查询时,确认这类MDN的消息客户端关闭了接收网络消息的权限和/或未处于连接网络的状态。
当第三方应用服务端接收到第一发送请求消息,可在本地查询到支持网络消息的MDN,为每一个MDN生成一个第二发送请求消息,其中携带目标信息和该MDN,以便消息服务端向该MDN对应的消息客户端发送目标信息。第三方应用服务端也可以根据属于同一个消息服务端的多个MDN生成一个第二发送请求信息,其中携带该目标信息和这些MDN,以便消息服务端向这些MDN各自对应的消息客户端发送目标信息。
此外,还需注意的是,号码池中的MDN会每隔一段时间进行一次更新,优选的更新频率为一天。
步骤103:向MDN对应的消息服务端发送第二发送请求消息,以使消息服务端通过网络消息通道将目标信息发送至MDN对应的消息客户端。
由第三方应用服务端维护了多个消息服务端的信息,以及每个消息服务端管理的多个消息客户端的信息,因此,根据MDN可查询到其对应的消息服务端。将第二发送请求消息发送给消息服务端,消息服务端可将其中的目标信息通过网络消息通道发送至MDN对应的消息客户端。
通过本公开提供的一种消息的发送方法,应用于第三方应用服务端。第三方应用服务端能够接入多个消息服务端,并在接收来自第三方应用客户端的目标信息的第一发送请求信息时,筛选出支持网络消息的MDN,并将第三方应用客户端提供的目标信息与MDN提交至对应的消息服务端,以使消息服务端通过网络消息通道将目标信息发送至MDN对应的消息客户端。如此,简化了客户(即第三方应用客户端用户)向终端设备用户(即消息客户端用户)进行网络信息通知的流程,减少了客户与多个终端设备厂商对接产生的成本。
在一个示例中,上述步骤103,在将第二发送请求消息发送至MDN对应的消息服务端之前,如图3所示,该方法还包括:
步骤201:获取MDN对应的消息服务端的消息格式,根据消息格式对目标信息进行格式转换;相应的,第二发送请求消息携带格式转换后的目标信息。每个消息服务端与其协同的消息客户端之间所使用的网络消息服务对于消息发送的格式均有不同的要求。因此,第三方应用服务端根据每个消息服务端的网络消息服务的消息格式,将目标信息进行格式转换后再发送至相应的消息服务端,以提高目标信息的发送效率。
除此之外,需要注意的是,由于不同端口使用的协议不同,因此,在发送第二发送请求信息前,还需要获取MDN对应的消息服务端的端口号,根据该端口号对应的协议,将第二发送请求信息转换成消息服务端可识别的请求信息。因此,先将目标信息进行格式转换,再将第二发送请求信息按照端口号对应的协议进行转换后,发送至消息服务端。
在一个示例中,上述步骤103,发送第二发送请求消息时,如图4所示,该方法还包括:
步骤301:生成第二发送请求消息的发送记录,发送记录包括:目标信息、MDN和第二发送请求消息的发送时间。
步骤302:根据消息服务端的响应,确定第二发送请求消息发送成功时,将发送记录的状态设置为第二发送请求消息发送成功,并启动计时器。
在发送第二发送请求消息的同时,生成第二发送请求信息的发送记录,并根据来自消息服务端成功接收第二发送请求信息的响应,将该发送记录的状态设置为第二发送请求信息发送成功,同时启动计时器进行计时。
步骤303:在计时器到时前接收到消息服务端针对第二发送请求消息发送的回执信息,若发送记录的状态为第二发送请求消息发送成功,且回执信息指示消息客户端通过网络消息通道成功接收目标信息时,将回执信息反馈至第三方应用客户端,并将发送记录的状态设置为已回执。
计时器的计时时长优选为5s或10s,可根据实际需求调整计时时长,本公开对此不做限制。在计时器到时前,接收到消息服务端针对于第二发送请求消息发送的回执信息时,首先需要确认发送记录的状态为第二发送请求消息发送成功。
在出现消息服务端向第三应用服务端重复发送该第二发送请求信息的回执信息的情况时,第三方应用服务端往往会对该第二发送请求信息进行第二次回执处理。因此,为了避免第三方应用服务端出现重复处理的情况,为第二发送请求信息设置了发送记录状态,以记录第三方应用服务端处理第二发送请求信息的阶段。第三方应用服务端在接收到回执信息后,首先确认发送记录的状态为第二发送请求消息发送成功,即表示该第二发送请求信息处于发送成功且未回执处理的阶段,再进行后续的回执处理。如此,第三方应用服务端既可避免进行重复处理造成算力资源的浪费,同时也防止向第三方应用客户端重复发送回执信息。
随后,第三方应用服务端解析该回执信息,在确认消息客户端通过网络消息通道成功接收目标信息时,将该回执信息反馈至第三方应用客户端,同时将发送记录的状态设置为已回执。第三方应用服务端能够顺利地执行以上步骤,则表示该目标信息以网络信息的方式成功发送至消息客户端。
在一个示例中,根据消息服务端的响应,确定第二发送请求消息发送失败时,如图5所示,方法还包括:
步骤401:将发送记录的状态设置为第二发送请求消息发送失败。
步骤402:将目标信息通过短信通道发送至MDN对应的消息客户端,并将发送记录的状态设置为已回执。
根据来自消息服务端对第二发送请求信息的接收失败的响应,将发送记录的状态设置为第二发送请求消息发送失败。同时,从发送记录中获取目标信息和MDN,将目标信息和MDN提交至运营商服务端,以使运营商服务端将目标信息通过短信通道发送至与MDN对应的消息客户端,并将发送记录的状态设置为已回执。
其中,短信通道(SMS channel)是由中国移动、联通、电信等运营商直接提供的短信发送接口,能够实现将短信息批量发送或自定义发送至指定的MDN。
在一个示例中,上述步骤303,在计时器到时时未接收到回执信息,该方法还包括:确定发送记录的状态为第二发送请求消息发送成功,则获取对MDN对应的消息客户端发送消息的操作权限,将目标信息通过短信通道发送至消息客户端,并将发送记录的状态设置为已回执。
当第三方应用服务端在计时器到时时未接收到回执信息,首先,确认发送记录的状态为第二发送请求消息发送成功,在确保第三方应用服务端没有重复处理该第二发送请求消息的情况下再进行后续处理。
对于第三方应用服务端在计时器到时时未接收到回执信息的原因,例如消息客户端出现网络延迟等等。消息客户端未成功接收目标信息,也无法通过消息服务端向第三方应用服务端发送回执消息。此时的第三方应用服务端由于无法确定消息客户端成功接收目标信息的状态,因此,为了避免消息服务端与第三方应用服务端重复发送同一目标信息,同时也为了消息客户端能够尽快接收到目标信息,第三方应用服务端需要重新获取对该MDN对应的消息客户端发送信息的操作权限,相当于告知消息服务端暂停向该MDN对应的消息客户端通过网络消息通道发送目标信息的进程。随后,第三方应用服务端将目标信息通过短信通道发送至该消息客户端,并将发送记录修改为已回执。
在一个示例中,在计时器到时前接收到消息服务端针对第二发送请求消息发送的回执信息,若发送记录的状态为第二发送请求消息发送成功、且回执信息指示消息客户端未成功接收目标信息,如图6所示,方法还包括:
步骤501:确定目标信息通过网络消息通道发送失败,将发送记录的状态设置为已回执,并将回执信息反馈至第三方应用客户端。
对于目标信息通过网络消息通道发送失败的原因,例如消息客户端接收的目标信息格式错误、乱码等等;或者在消息客户端在发送目标信息时,消息客户端关闭接收网络消息的权限或者断开网络连接等等。因此,第三方应用服务端解析消息客户端反馈至消息服务端的回执信息中确认该目标信息通过网络通信通道发送失败时,将发送记录设置为已回执,并将该回执信息反馈至第三方应用客户端。
步骤502:将目标信息通过短信通道发送至MDN对应的消息客户端。。
随后通过短信通道将目标信息发送至MDN对应的消息客户端,确保消息客户端能够尽快接收到目标信息。
在一个示例中,该方法还包括:查询不支持网络消息的MDN,将目标信息通过短信通道发送至不支持网络消息的MDN对应的消息客户端。
本示例即为上述步骤102的示例中,第三方应用服务端在号码池中查询到的MDN不支持网络消息的情况。此时,第三方应用服务端则将目标信息通过短信通道发送至该MDN对应的消息客户端。如此,即便是关闭了接收网络消息的权限和/或未连接网络的消息客户端也能及时接收到目标信息。
在一个示例中,对于第三方应用客户端确定需要通过短信通道向MDN对应的消息客户端发送目标信息的情况,第三方应用服务端还可将目标信息和该MDN提交至第三方应用客户端。
由于有些第三方应用客户端开通了短信服务,因此,这部分第三方应用客户端从第三方应用服务端获取该MDN与目标信息,并通过短信通道发送目标信息至MDN对应的消息客户端。
本公开还提供了一种消息的发送装置,该装置应用于第三方应用服务端,如图7所示,该装置包括:
接收模块601,用于接收来自第三方应用客户端的目标信息的第一发送请求消息;
查询模块602,用于查询支持网络消息的移动用户号码簿号码MDN;
生成模块603,用于在查询的MDN支持网络消息时,生成第二发送请求消息,其中携带目标信息和MDN;
发送模块604,用于向MDN对应的消息服务端发送第二发送请求消息,以使消息服务端通过网络消息通道将目标信息发送至MDN对应的消息客户端。
在一个示例中,如图8所示,该装置还包括:
格式转换模块605,用于在将第二发送请求消息发送至MDN对应的消息服务端之前,获取MDN对应的消息服务端的消息格式,根据消息格式对目标信息进行格式转换;相应的,第二发送请求消息携带格式转换后的目标信息。
在一个示例中,如图8所示,该装置还包括:
记录模块606,用于生成第二发送请求消息的发送记录,发送记录包括:目标信息、MDN和第二发送请求消息的发送时间;
根据消息服务端的响应,确定第二发送请求消息发送成功时,记录模块606,还用于将发送记录的状态设置为第二发送请求消息发送成功;同时,计时模块607,用于启动计时器;
在计时器到时前接收到消息服务端针对第二发送请求消息发送的回执信息时,回执处理模块608,用于确定发送记录的状态为第二发送请求消息发送成功,且回执信息指示消息客户端通过网络消息通道成功接收目标信息时,回执处理模块608还用于将回执信息反馈至第三方应用客户端;同时,记录模块606还用于将发送记录的状态设置为已回执。
在一个示例中,根据消息服务端的响应,确定第二发送请求消息发送失败时,记录模块606,还用于将发送记录的状态设置为第二发送请求消息发送失败;回执处理模块608,还用于在确定第二发送请求消息发送失败时,将目标信息通过短信通道发送至MDN对应的消息客户端;记录模块606还用于将发送记录的状态设置为已回执。
在一个示例中,在计时器到时时未接收到回执信息,回执处理模块608还用于确定发送记录的状态为第二发送请求消息发送成功,则获取对MDN对应的消息客户端发送消息的操作权限,将目标信息通过短信通道发送至消息客户端;同时,记录模块606还用于将发送记录的状态设置为已回执。
在一个示例中,在计时器到时前接收到消息服务端针对第二发送请求消息发送的回执信息,若发送记录的状态为第二发送请求消息发送成功、且回执信息指示消息客户端未成功接收目标信息时,回执处理模块608还用于确定目标信息通过网络消息通道发送失败;记录模块606还用于将发送记录的状态设置为已回执;回执处理模块608还用于将回执信息反馈至第三方应用客户端,并将目标信息通过短信通道发送至MDN对应的消息客户端。
在一个示例中,查询不支持网络消息的MDN时,回执处理模块608还用于将目标信息通过短信通道发送至不支持网络消息的MDN对应的消息客户端。
通过本公开提供的一种消息的发送装置,应用于第三方应用服务端。第三方应用服务端能够接入多个消息服务端,并在接收来自第三方应用客户端的目标信息的第一发送请求信息时,筛选出支持网络消息的MDN,并将第三方应用客户端提供的目标信息与MDN提交至对应的消息服务端,以使消息服务端通过网络消息通道将目标信息发送至MDN对应的消息客户端。如此,简化了客户(即第三方应用客户端用户)向终端设备用户(即消息客户端用户)进行网络信息通知的流程,减少了客户与多个终端设备厂商对接产生的成本。
根据本公开的实施例,本公开还提供了一种电子设备和一种可读存储介质。
图9示出了可以用来实施本公开的实施例的示例电子设备800的示意性框图。电子设备旨在表示各种形式的数字计算机,诸如,膝上型计算机、台式计算机、工作台、个人数字助理、服务器、刀片式服务器、大型计算机、和其它适合的计算机。电子设备还可以表示各种形式的移动装置,诸如,个人数字处理、蜂窝电话、智能电话、可穿戴设备和其它类似的计算装置。本文所示的部件、它们的连接和关系、以及它们的功能仅仅作为示例,并且不意在限制本文中描述的和/或者要求的本公开的实现。
如图9所示,设备800包括计算单元801,其可以根据存储在只读存储器(ROM)802中的计算机程序或者从存储单元808加载到随机访问存储器(RAM)803中的计算机程序,来执行各种适当的动作和处理。在RAM 803中,还可存储设备800操作所需的各种程序和数据。计算单元801、ROM 802以及RAM 803通过总线804彼此相连。输入/输出(I/O)接口805也连接至总线804。
设备800中的多个部件连接至I/O接口805,包括:输入单元806,例如键盘、鼠标等;输出单元807,例如各种类型的显示器、扬声器等;存储单元808,例如磁盘、光盘等;以及通信单元809,例如网卡、调制解调器、无线通信收发机等。通信单元809允许设备800通过诸如因特网的计算机网络和/或各种电信网络与其他设备交换信息/数据。
计算单元801可以是各种具有处理和计算能力的通用和/或专用处理组件。计算单元801的一些示例包括但不限于中央处理单元(CPU)、图形处理单元(GPU)、各种专用的人工智能(AI)计算芯片、各种运行机器学习模型算法的计算单元、数字信号处理器(DSP)、以及任何适当的处理器、控制器、微控制器等。计算单元801执行上文所描述的各个方法和处理,例如消息的发送方法。例如,在一些实施例中,消息的发送方法可被实现为计算机软件程序,其被有形地包含于机器可读介质,例如存储单元808。在一些实施例中,计算机程序的部分或者全部可以经由ROM 802和/或通信单元809而被载入和/或安装到设备800上。当计算机程序加载到RAM 803并由计算单元801执行时,可以执行上文描述的消息的发送方法的一个或多个步骤。备选地,在其他实施例中,计算单元801可以通过其他任何适当的方式(例如,借助于固件)而被配置为执行消息的发送方法。
本文中以上描述的系统和技术的各种实施方式可以在数字电子电路系统、集成电路系统、场可编程门阵列(FPGA)、专用集成电路(ASIC)、专用标准产品(ASSP)、芯片上系统的系统(SOC)、负载可编程逻辑设备(CPLD)、计算机硬件、固件、软件、和/或它们的组合中实现。这些各种实施方式可以包括:实施在一个或者多个计算机程序中,该一个或者多个计算机程序可在包括至少一个可编程处理器的可编程系统上执行和/或解释,该可编程处理器可以是专用或者通用可编程处理器,可以从存储系统、至少一个输入装置、和至少一个输出装置接收数据和指令,并且将数据和指令传输至该存储系统、该至少一个输入装置、和该至少一个输出装置。
用于实施本公开的方法的程序代码可以采用一个或多个编程语言的任何组合来编写。这些程序代码可以提供给通用计算机、专用计算机或其他可编程数据处理装置的处理器或控制器,使得程序代码当由处理器或控制器执行时使流程图和/或框图中所规定的功能/操作被实施。程序代码可以完全在机器上执行、部分地在机器上执行,作为独立软件包部分地在机器上执行且部分地在远程机器上执行或完全在远程机器或服务器上执行。
在本公开的上下文中,机器可读介质可以是有形的介质,其可以包含或存储以供指令执行系统、装置或设备使用或与指令执行系统、装置或设备结合地使用的程序。机器可读介质可以是机器可读信号介质或机器可读储存介质。机器可读介质可以包括但不限于电子的、磁性的、光学的、电磁的、红外的、或半导体系统、装置或设备,或者上述内容的任何合适组合。机器可读存储介质的更具体示例会包括基于一个或多个线的电气连接、便携式计算机盘、硬盘、随机存取存储器(RAM)、只读存储器(ROM)、可擦除可编程只读存储器(EPROM或快闪存储器)、光纤、便捷式紧凑盘只读存储器(CD-ROM)、光学储存设备、磁储存设备、或上述内容的任何合适组合。
为了提供与用户的交互,可以在计算机上实施此处描述的系统和技术,该计算机具有:用于向用户显示信息的显示装置(例如,CRT(阴极射线管)或者LCD(液晶显示器)监视器);以及键盘和指向装置(例如,鼠标或者轨迹球),用户可以通过该键盘和该指向装置来将输入提供给计算机。其它种类的装置还可以用于提供与用户的交互;例如,提供给用户的反馈可以是任何形式的传感反馈(例如,视觉反馈、听觉反馈、或者触觉反馈);并且可以用任何形式(包括声输入、语音输入或者、触觉输入)来接收来自用户的输入。
可以将此处描述的系统和技术实施在包括后台部件的计算系统(例如,作为数据服务器)、或者包括中间件部件的计算系统(例如,应用服务器)、或者包括前端部件的计算系统(例如,具有图形用户界面或者网络浏览器的用户计算机,用户可以通过该图形用户界面或者该网络浏览器来与此处描述的系统和技术的实施方式交互)、或者包括这种后台部件、中间件部件、或者前端部件的任何组合的计算系统中。可以通过任何形式或者介质的数字数据通信(例如,通信网络)来将系统的部件相互连接。通信网络的示例包括:局域网(LAN)、广域网(WAN)和互联网。
计算机系统可以包括客户端和服务器。客户端和服务器一般远离彼此并且通常通过通信网络进行交互。通过在相应的计算机上运行并且彼此具有客户端-服务器关系的计算机程序来产生客户端和服务器的关系。服务器可以是云服务器,也可以为分布式系统的服务器,或者是结合了区块链的服务器。
应该理解,可以使用上面所示的各种形式的流程,重新排序、增加或删除步骤。例如,本发公开中记载的各步骤可以并行地执行也可以顺序地执行也可以不同的次序执行,只要能够实现本公开公开的技术方案所期望的结果,本文在此不进行限制。
此外,术语“第一”、“第二”仅用于描述目的,而不能理解为指示或暗示相对重要性或者隐含指明所指示的技术特征的数量。由此,限定有“第一”、“第二”的特征可以明示或隐含地包括至少一个该特征。在本公开的描述中,“多个”的含义是两个或两个以上,除非另有明确具体的限定。
以上所述,仅为本公开的具体实施方式,但本公开的保护范围并不局限于此,任何熟悉本技术领域的技术人员在本公开揭露的技术范围内,可轻易想到变化或替换,都应涵盖在本公开的保护范围之内。因此,本公开的保护范围应以所述权利要求的保护范围为准。