业务数据处理方法、装置、电子设备及存储介质与流程

计算;推算;计数设备的制造及其应用技术1.本发明涉及消息推送技术领域，尤其涉及一种业务数据处理方法、装置、电 子设备及存储介质。背景技术：2.现有技术中，在业务系统内部的各业务平台之间大多采用消息中间件的方 式发送消息，若两个业务平台之间不是基于消息中间件传递消息，则需要专门为 其创建并维护一个消息发送装置，消息传递效率低，维护成本高，并且，业务系 统内部的业务平台无法与第三方业务平台传递消息。技术实现要素：3.本发明的目的在于提供一种业务数据处理方法、装置、电子设备及存储介质， 以解决现有技术中消息传递可扩展性不高的技术问题。4.本发明的技术方案如下：提供一种业务数据处理方法，包括：5.获取发送方的消息发送请求，根据所述消息发送请求生成对应的消息数据， 其中，所述消息数据包括发送方标识、接收方标识以及消息内容；6.根据所述发送方标识和所述调用方标识确定发送链路，根据所述发送链路 从预先存储的第一映射表获取对应的消息发送策略，其中，所述第一映射表用于 记录所述发送链路和所述消息发送策略的关联关系，所述消息发送策略用于表 征消息发送方式；7.根据所述消息发送策略从预先建立的多个消息投递组件中选择对应的目标 消息投递组件，其中，所述多个消息投递组件采用不同的传输协议传输数据；8.根据所述目标消息投递组件对应的所述传输协议将所述消息数据封装为消 息数据包，调用所述目标消息投递组件向接收方发送所述消息数据包。9.可选地，所述根据所述发送方标识和所述调用方标识确定发送链路，根据所 述发送链路从预先存储的第一映射表获取对应的消息发送策略之前，还包括：10.获取业务系统的所有业务端，其中，所述业务端包括业务平台和服务器端；11.针对每个所述业务端，以所述业务系统内的其他业务端以及第三方业务端 为所述接收方分别获取以所述业务端为所述发送方的所述发送链路；12.获取每个所述发送链路的消息发送策略，创建用于记录所述发送链路和所 述消息发送策略之间关联关系的第一映射表。13.可选地，所述根据所述目标消息投递组件对应的所述传输协议将所述消息 数据封装为消息数据包，调用所述目标消息投递组件向接收方发送所述消息数 据包之前，还包括：14.根据所述消息发送策略对所述消息数据进行加密处理或认证处理。15.可选地，所述根据所述消息发送策略对所述消息数据进行加密处理或认证 处理，包括：16.若所述接收方为第三方业务平台，则获取所述发送方的元数据信息，根据所 述元数据信息判断所述发送方是否具有数据外发权限；17.若所述发送方具有数据外发权限，则认证通过；18.若接收方为业务系统的业务平台，则判断所述接收方对所述消息内容是否 具有访问权限；19.若判断结果为是，则执行所述根据所述目标消息投递组件对应的所述传输 协议将所述消息数据封装为消息数据包的步骤；20.若判断结果为否，则对所述消息内容进行加密处理，执行所述根据所述目标 消息投递组件对应的所述传输协议将所述消息数据封装为消息数据包的步骤。21.可选地，所述调用所述目标消息投递组件向接收方发送所述消息数据包之 后，还包括：22.若所述消息数据包发送失败，则为所述消息数据包添加发送失败状态标签；23.获取携带有所述发送失败状态标签的所述消息数据包，将所述消息数据包 的调用次数累加一，调用所述目标消息投递组件向接收方发送所述消息数据包；24.若所述调用次数大于预设次数阈值，则为所述消息数据包添加告警标签；25.若所述消息数据包发送成功，则为对应的所述消息数据添加发送成功状态 标签。26.可选地，所述调用所述目标消息投递组件向接收方发送所述消息数据包之 后，还包括：27.接收维护指令，其中，所述维护指令包括待维护的业务平台标识以及修改后 的传输协议；28.获取以所述待维护的业务平台为接收方的所述发送链路，根据所述修改后 的传输协议确定修改后的消息发送策略；29.将获取的所述发送链路关联的所述消息发送策略更新为所述修改后的消息 发送策略，获取更新后的第一映射表。30.可选地，所述消息数据还包括业务类型；31.所述调用所述目标消息投递组件向接收方发送所述消息数据包之后，还包 括：32.针对每个所述业务类型，获取携带有所述发送成功状态标签的消息数据对 应的发送链路；33.根据所述发送链路获取所述业务类型的调用链路。34.本发明的另一技术方案如下：提供一种业务数据处理装置，包括：35.接收模块，用于获取发送方的消息发送请求，根据所述消息发送请求生成对 应的消息数据，其中，所述消息数据包括发送方标识、接收方标识以及消息内容；36.策略确定模块，用于根据所述发送方标识和所述调用方标识确定发送链路， 根据所述发送链路从预先存储的第一映射表获取对应的消息发送策略，其中，所 述第一映射表用于记录所述发送链路和所述消息发送策略的关联关系，所述消 息发送策略用于表征消息发送方式；37.选择模块，用于根据所述消息发送策略从预先建立的多个消息投递组件中 选择对应的目标消息投递组件，其中，所述多个消息投递组件采用不同的传输协 议传输数据；38.发送模块，用于根据所述目标消息投递组件对应的所述传输协议将所述消 息数据封装为消息数据包，调用所述目标消息投递组件向接收方发送所述消息 数据包。39.本发明的另一技术方案如下：提供一种电子设备，所述电子设备包括处理器、 以及与所述处理器耦接的存储器，所述存储器存储有可被所述处理器执行的程 序指令；所述处理器执行所述存储器存储的所述程序指令时实现上述的业务数 据处理方法。40.本发明的另一技术方案如下：提供一种存储介质，所述存储介质内存储有程 序指令，所述程序指令被处理器执行时实现上述的业务数据处理方法。41.本发明的业务数据处理方法、装置、电子设备及存储介质，获取发送方的消 息发送请求，根据所述消息发送请求生成对应的消息数据，其中，所述消息数据 包括发送方标识、接收方标识以及消息内容；根据所述发送方标识和所述调用方 标识确定发送链路，根据所述发送链路从预先存储的第一映射表获取对应的消 息发送策略，其中，所述第一映射表用于记录所述发送链路和所述消息发送策略 的关联关系，所述消息发送策略用于表征消息发送方式；根据所述消息发送策略 从预先建立的多个消息投递组件中选择对应的目标消息投递组件，其中，所述多 个消息投递组件采用不同的传输协议传输数据；根据所述目标消息投递组件对 应的所述传输协议将所述消息数据封装为消息数据包，调用所述目标消息投递 组件向接收方发送所述消息数据包；通过上述方式，可以根据业务扩展增加新的 消息投递组件，当业务系统增加了新的业务平台后，可以针对该业务平台作为发 送方和接收方增加新的发送链路，为新的发送链路选择原有的消息投递组件或 建立新的消息投递组件，提高了业务系统的可维护性和可扩展性。附图说明42.图1为本发明第一实施例的业务数据处理方法的流程示意图；43.图2为本发明第二实施例的业务数据处理方法的流程示意图；44.图3为本发明第三实施例的业务数据处理装置的结构示意图；45.图4为本发明第四实施例的电子设备的结构示意图；46.图5为本发明第五实施例的存储介质的结构示意图。具体实施方式47.下面将结合本发明实施例中的附图，对本发明实施例中的技术方案进行清 楚、完整地描述，显然，所描述的实施例仅是本发明的一部分实施例，而不是全 部的实施例。基于本发明中的实施例，本领域普通技术人员在没有做出创造性劳 动前提下所获得的所有其他实施例，都属于本发明保护的范围。48.本发明中的术语“第一”、“第二”、“第三”仅用于描述目的，而不能理解为 指示或暗示相对重要性或者隐含指明所指示的技术特征的数量。由此，限定有ꢀ“第一”、“第二”、“第三”的特征可以明示或者隐含地包括至少一个该特征。本 发明的描述中，“多个”的含义是至少两个，例如两个，三个等，除非另有明确 具体的限定。本发明实施例中所有方向性指示(诸如上、下、左、右、前、后……) 仅用于解释在某一特定姿态(如附图所示)下各部件之间的相对位置关系、运动情 况等，如果该特定姿态发生改变时，则该方向性指示也相应地随之改变。此外， 术语“包括”和“具有”以及它们任何变形，意图在于覆盖不排他的包含。例如 包含了一系列步骤或单元的过程、方法、系统、产品或设备没有限定于已列出的 步骤或单元，而是可选地还包括没有列出的步骤或单元，或可选地还包括对于这 些过程、方法、产品或设备固有的其它步骤或单元。49.在本文中提及“实施例”意味着，结合实施例描述的特定特征、结构或特性 可以包含在本发明的至少一个实施例中。在说明书中的各个位置出现该短语并 不一定均是指相同的实施例，也不是与其它实施例互斥的独立的或备选的实施 例。本领域技术人员显式地和隐式地理解的是，本文所描述的实施例可以与其它 实施例相结合。50.图1是本发明第一实施例的业务数据处理方法的流程示意图。需注意的是， 若有实质上相同的结果，本发明的方法并不以图1所示的流程顺序为限。如图1 所示，该业务数据处理方法包括步骤：51.s101，获取发送方的消息发送请求，根据所述消息发送请求生成对应的消 息数据，其中，所述消息数据包括发送方标识、接收方标识以及消息内容。52.其中，发送方和接收方可以分别为业务系统内部的业务平台(应用平台)， 业务平台可以包括但不限于第一管理平台、x型保险应用平台、y型保险应用平 台、查询工具、数据挖掘工具、a分析平台、b展示平台等，例如，在反馈查询 数据的场景下，发送方为查询工具，接收方为a分析平台，查询工具(发送方) 查询到对应数据后向a分析平台(接收方)反馈所得数据；在发送数据查询请 求的场景下，发送方为b分析平台，接收方为查询工具，b分析平台(发送方) 将待查询的目标发送至查询工具(接收方)。其中，接收方还可以为服务器，发 送方可以为业务平台，业务平台(发送方)向对应的业务服务器(接收方)发送 消息。也就是说，在本实施例中，执行主体为一个消息通知服务器，用于将发送 方的消息发送给接收方，一个消息的发送方可以是另一个消息的接收方。其中， 接收方还可以是第三方系统的业务平台或服务器，发送方为业务系统内部的业 务平台或业务服务器。53.其中，获取发送方的消息发送请求之后，提取消息发送请求中的消息内容、 发送方和接收方，获取所述发送方的对应发送方标识以及所述接收方的接收方 标识，并为该消息内容配置一个唯一识别的消息识别码，再将消息识别码、发送 方标识、接收方标识和消息内容生成为一个消息数据进行存储。具体地，发送方 标识用于表征发送方，接收方标识用于表征接收方，消息识别码可以是日期和编 号生成的，消息识别码用于表征该消息发送请求，便于后续查询回溯。54.s102，根据所述发送方标识和所述调用方标识确定发送链路，根据所述发 送链路从预先存储的第一映射表获取对应的消息发送策略，其中，所述第一映射 表用于记录所述发送链路和所述消息发送策略的关联关系，所述消息发送策略 用于表征消息发送方式。55.其中，可以针对同一个发送方，分别与不同的接收方形成发送链路，发送 链路由发送方标识和接收方标识确定，将发送链路和对应的消息发送策略记录 在第一映射表中。56.其中，所述消息发送策略用于表征消息发送方式，进一步地，所述消息发 送策略还用于表征消息发送加密处理方式、消息发送认证处理方式以及消息发 送失败处理方式。具体地，消息发送方式包括消息中间件发送方式、tcp/ip (transmission control protocol/internet protocol，传输控制协议/网际)发送方式、 http(hyper text transfer protocol，超文本传输)发送方式、短信发送方式以 及业务系统内部的自定义发送方式，另外，消息中间件可以进一步包括但不限于 kafka、active mq、rabbit mq、sofa mq、rocket mq和tencentmq等。在消息发送服务器中，分别建立不同消息发送方式对应的发送模块，通 过对应的发送模块发送消息数据。57.在一个可选的实施方式中，在步骤s102之前还包括如下步骤：58.s201，获取业务系统的所有业务端，其中，所述业务端包括业务平台和服 务器端；59.s202，针对每个所述业务端，以所述业务系统内的其他业务端以及第三方 业务端为所述接收方分别获取以所述业务端为所述发送方的所述发送链路；60.s203，获取每个所述发送链路的消息发送策略，创建用于记录所述发送链 路和所述消息发送策略之间关联关系的第一映射表。61.具体地，当发送方和接收方确定时，它们之间的消息发送方式是确定的， 消息发送策略也是确定的，在实际使用过程中，业务系统内部的各业务端会相互 传输消息，业务系统内部的一些业务端也会与特定的第三方业务端传输消息，一 般情况下，消息发送策略中的消息发送方式是由接收方确定的，消息发送策略中 的消息发送加密处理方式、消息发送认证处理方式以及消息发送失败处理是由 发送方和接收方共同确定的，同一个业务端作为接收方时，对于不同的发送方， 加密处理方式、认证方式及发送失败处理方式可能不同。62.s103，根据所述消息发送策略从预先建立的多个消息投递组件中选择对应 的目标消息投递组件，其中，所述多个消息投递组件采用不同的传输协议传输数 据。63.其中，消息投递组件可以是一个多线程消息发送组件，可以同时处理发送 多条该消息数据包，满足海量消息数据包的批量打包发送。具体地，消息发送策 略中的消息发送方式对应不同的传输协议，需要通过不同的消息投递组件发送， 例如，消息发送方式可以分别对应消息队列遥测传输(message queuing telemetrytransport，mqtt)协议、传输控制协议/网际(transmission controlprotocol/internet protocol，tcp/ip)协议、超文本传输(hyper text transfer protocol， http)协议、短信协议(short message protocol，smp)、自定义协议等。64.s104，根据所述目标消息投递组件对应的所述传输协议将所述消息数据封 装为消息数据包，调用所述目标消息投递组件向接收方发送所述消息数据包。65.其中，不同的传输协议可以对应不同的数据格式，按照对应的数据格式将 消息数据打包封装成消息数据包。不同的传输协议也可以对应相同的数据格式， 例如，为了增加api接口的复用性，可以将接收方为业务系统内部各业务平台 的消息数据封装为json格式的消息数据包，该消息投递组件将从多个发送方 获取的消息数据包通过调用同一个内部推送服务api接口发送至不同的接收方， 通过上述方式，相同类型的接收方可以共用一个消息投递组件。为第三方业务平 台设置专门的消息投递组件，例如，移动、联通、电信服务器，传输协议为短信 协议，将消息数据打包封装为pdu格式的消息数据包再进行发送。66.本实施例中消息发送服务器采用可扩展消息通知框架，可以根据业务扩展 增加新的消息投递组件，当业务系统增加了新的业务平台后，可以针对该业务平 台作为发送方和接收方增加新的发送链路，为新的发送链路选择原有的消息投 递组件或建立新的消息投递组件，提高了业务系统的可维护性和可扩展性。67.在一个可选的实施方式中，所述消息发送策略还用于表征消息发送失败处 理方式，步骤s104之后还包括：68.s301，若所述消息数据包发送失败，则为所述消息数据包添加发送失败状 态标签；69.s302，获取携带有所述发送失败状态标签的所述消息数据包，将所述消息 数据包的调用次数累加一，调用所述目标消息投递组件向接收方发送所述消息 数据包；70.s303，若所述调用次数大于预设次数阈值，则为所述消息数据包添加告警 标签；71.s304，若所述消息数据包发送成功，则为对应的所述消息数据添加发送成 功状态标签。72.在本实施方式中，对发送失败的消息数据包进行标记并重新发送，并对重 新发送的次数进行累加，若重新发送的次数过多，则为其添加告警标签，便于后 续触发告警规则。对发送成功的消息数据包，在其对应的消息数据中添加发送成 功标签。73.在一个可选的实施方式中，当业务系统内某个业务平台作为接收方的传输 协议变化，可直接在第一映射表中修改对应的消息发送策略，具体地，步骤s104 之后还包括如下步骤：74.s401，接收维护指令，其中，所述维护指令包括待维护的业务平台标识以 及修改后的传输协议；75.s402，获取以所述待维护的业务平台为接收方的所述发送链路，根据所述 修改后的传输协议确定修改后的消息发送策略；76.s403，将获取的所述发送链路关联的所述消息发送策略更新为所述修改后 的消息发送策略，获取更新后的第一映射表。77.在本实施方式中，根据修改后的传输协议确定修改后的消息发送方式，根 据该修改后的消息发送方式确定修改后的消息发送策略，以对第一映射表中所 有涉及待维护的业务平台的发送链路相关联的消息发送策略统一进行更新。78.在一个可选的实施方式中，在步骤s401至s404的基础上，由于消息发送 服务器中存储了消息数据，可以通过消息数据的发送链路呈现各业务平台之间 的调用链路，该消息数据进一步包括业务类型，步骤s104之后还包括如下步骤：79.s501，针对每个所述业务类型，获取携带有所述发送成功状态标签的消息 数据对应的发送链路；80.s502，根据所述发送链路获取所述业务类型的调用链路。81.其中，对于两个发送链路，若其中一个发送链路的接收方与另一个发送链 路的发送方，则将该两个发送链路进行连接，形成该业务类型的调用链路，通过 消息数据展现该业务类型相关的各业务平台的关系。82.进一步地，上述的业务数据处理流程可以基于人工智能进行构建，基于人 工智能技术对相关的消息进行发送链路的识别和发送，实现无人值守的人工智 能消息推送。其中，人工智能(artificial intelligence，ai)是利用数字计算机或 者数字计算机控制的机器模拟、延伸和扩展人的智能，感知环境、获取知识并使 用知识获得最佳结果的理论、方法、技术及应用系统。83.人工智能基础技术一般包括如传感器、专用人工智能芯片、云计算、分布 式存储、大数据处理技术、操作/交互系统、机电一体化等技术。人工智能软件 技术主要包括计算机视觉技术、机器人技术、生物识别技术、语音处理技术、自 然语言处理技术以及机器学习/深度学习等几大方向。84.图2是本发明第二实施例的业务数据处理方法的流程示意图。需注意的是， 若有实质上相同的结果，本发明的方法并不以图2所示的流程顺序为限。如图2 所示，该业务数据处理方法包括步骤：85.s601，获取发送方的消息发送请求，根据所述消息发送请求生成对应的消息 数据，其中，所述消息数据包括发送方标识、接收方标识以及消息内容。86.s602，根据所述发送方标识和所述调用方标识确定发送链路，根据所述发送 链路从预先存储的第一映射表获取对应的消息发送策略，其中，所述第一映射表 用于记录所述发送链路和所述消息发送策略的关联关系，所述消息发送策略用 于表征消息发送方式。87.s603，根据所述消息发送策略从预先建立的多个消息投递组件中选择对应 的目标消息投递组件，其中，所述多个消息投递组件采用不同的传输协议传输数 据。88.s604，根据所述消息发送策略对所述消息数据进行加密处理或认证处理。89.在本实施例中，所述消息发送策略还用于表征消息发送加密处理方式、消 息发送认证处理方式以及消息发送失败处理方式。其中，根据消息发送策略中记 载的加密处理方式或认证处理方式对消息数据进行处理，例如，接收方为第三方 业务平台时，针对消息数据中可能涉及的敏感数据需要进行加密处理，针对发送 方是否有外发权限需要进行认证处理，在加密处理完成后或认证处理通过后才 能将消息数据进行封装及发送。又如，不同的业务平台对于数据的访问权限不同， 消息数据中的消息内容可能来源于业务系统中存储于数据库中的数据表，数据 表包括多个字段，字段可能涉及客户身份信息或隐私信息的数据(证件号码、是 否患有某疾病、通信地址等)等敏感数据，第一管理平台对数据表中每个字段均 具有访问权限，数据挖掘工具对数据表中敏感数据对应的字段没有访问权限、对 非敏感数据对应的字段有访问权限，若第一管理平台为接收方，则无需进行加密 处理；若数据挖掘工具为接收方，则需要判断消息数据的消息内容是否涉及敏感 字段的数据，若消息内容包括敏感字段的数据，则需要对敏感数据进行加密处理。 具体地，在步骤s604中，若所述接收方为第三方业务平台，则获取所述发送方 的元数据信息，根据所述元数据信息判断所述发送方是否具有数据外发权限；若 所述发送方具有数据外发权限，则认证通过；若接收方为业务系统的业务平台， 则判断所述接收方对所述消息内容是否具有访问权限；若判断结果为是，则直接 执行步骤s104；若判断结果为否，则对所述消息内容进行加密处理，再执行步 骤s104。在实际应用中，对于发送至第三方业务平台的消息，在发送至消息发 送服务器之前会进行严格的验证处理，在消息发送服务器中只对发送方的外发 权限进行认证，无需对消息数据进行处理。90.s605，根据所述目标消息投递组件对应的所述传输协议将所述消息数据封 装为消息数据包，调用所述目标消息投递组件向接收方发送所述消息数据包。91.本实施例中，步骤s601至步骤s603以及步骤s605具体参见第一实施例中 步骤s101至步骤s104的记载。92.在本实施例中，基于可扩展消息通知框架，着重于解决如何在业务系统中降 低复杂多样的消息通知带来的复杂度，提高系统开发效率和可扩展性。通过抽象 应用信息，负责统一维护各应用接口的基础信息、通知方式、通知地址、异常处 理规则、告警规则等信息。通过抽象消息信息，譬如：消息编号、消息类型、发 送方、接收方、消息体、调用次数、投递状态等，实现对消息进行统一维护管理。 异步消息通知框架自动加载服务方元信息，根据消息元信息找到需要投递的服 务方信息，根据规则自动判断应该使用何种方式来进行消息投递，系统内置了常 用的消息投递方式，也支持快速自定义投递方式。消息投递失败自动触发策略， 譬如：重试、告警等策略在异步消息通知框架中，消息中间件只是消息投递了一 种渠道，降低了对单个消息中间件的依赖性。框架内置了多种消息投递渠道，丰 富了消息通知方式，并支持依赖框架公共服务快速扩展个性化的消息投递方式， 使用灵活，可扩展性高，提高开发效率，降低开发成本。93.本实施例的业务数据处理方法能够提供更加灵活可控的消息投递方式，不 仅可以集成现有的消息中间件，还内置了常用的通知方式，也可以根据不同的场 景需求，集成自定义的通知功能，提高了系统的可维护性和可扩展性。94.图3是本发明第三实施例的业务数据处理装置的结构示意图。如图3所示， 该业务数据处理装置30包括：接收模块31、策略确定模块32、选择模块33以 及发送模块34，其中，接收模块31，用于获取发送方的消息发送请求，根据所 述消息发送请求生成对应的消息数据，其中，所述消息数据包括发送方标识、接 收方标识以及消息内容；策略确定模块32，用于根据所述发送方标识和所述调 用方标识确定发送链路，根据所述发送链路从预先存储的第一映射表获取对应 的消息发送策略，其中，所述第一映射表用于记录所述发送链路和所述消息发送 策略的关联关系，所述消息发送策略用于表征消息发送方式；选择模块33，用 于根据所述消息发送策略从预先建立的多个消息投递组件中选择对应的目标消 息投递组件，其中，所述多个消息投递组件采用不同的传输协议传输数据；发送 模块34，用于根据所述目标消息投递组件对应的所述传输协议将所述消息数据 封装为消息数据包，调用所述目标消息投递组件向接收方发送所述消息数据包。95.进一步地，该策略确定模块32还用于：获取业务系统的所有业务端，其中， 所述业务端包括业务平台和服务器端；针对每个所述业务端，以所述业务系统内 的其他业务端以及第三方业务端为所述接收方分别获取以所述业务端为所述发 送方的所述发送链路；获取每个所述发送链路的消息发送策略，创建用于记录所 述发送链路和所述消息发送策略之间关联关系的第一映射表。96.进一步地，该发送模块34还用于：根据所述消息发送策略对所述消息数据 进行加密处理或认证处理。97.进一步地，该发送模块34还用于：若所述接收方为第三方业务平台，则获 取所述发送方的元数据信息，根据所述元数据信息判断所述发送方是否具有数 据外发权限；若所述发送方具有数据外发权限，则认证通过；若接收方为业务系 统的业务平台，则判断所述接收方对所述消息内容是否具有访问权限；若判断结 果为是，则执行所述根据所述目标消息投递组件对应的所述传输协议将所述消 息数据封装为消息数据包的步骤；若判断结果为否，则对所述消息内容进行加密 处理，执行所述根据所述目标消息投递组件对应的所述传输协议将所述消息数 据封装为消息数据包的步骤。98.进一步地，该发送模块34还用于：若所述消息数据包发送失败，则为所述 消息数据包添加发送失败状态标签；获取携带有所述发送失败状态标签的所述 消息数据包，将所述消息数据包的调用次数累加一，调用所述目标消息投递组件 向接收方发送所述消息数据包；若所述调用次数大于预设次数阈值，则为所述消 息数据包添加告警标签；若所述消息数据包发送成功，则为对应的所述消息数据 添加发送成功状态标签。99.进一步地，该发送模块34还用于：接收维护指令，其中，所述维护指令包 括待维护的业务平台标识以及修改后的传输协议；获取以所述待维护的业务平 台为接收方的所述发送链路，根据所述修改后的传输协议确定修改后的消息发 送策略；将获取的所述发送链路关联的所述消息发送策略更新为所述修改后的 消息发送策略，获取更新后的第一映射表。100.所述消息数据还包括业务类型；进一步地，该发送模块34还用于：针对每 个所述业务类型，获取携带有所述发送成功状态标签的消息数据对应的发送链 路；根据所述发送链路获取所述业务类型的调用链路。101.图4是本发明第四实施例的电子设备的结构示意图。如图4所示，该电子 设备40包括处理器41及和处理器41耦接的存储器42。102.存储器42存储有用于实现上述任一实施例的所述业务数据处理方法的程 序指令。103.处理器41用于执行存储器42存储的程序指令以进行配件外修订单调度。104.其中，处理器41还可以称为cpu(central processing unit，中央处理单元)。 处理器41可能是一种集成电路芯片，具有信号的处理能力。处理器41还可以 是通用处理器、数字信号处理器(dsp)、专用集成电路(asic)、现场可编程门阵 列(fpga)或者其他可编程逻辑器件、分立门或者晶体管逻辑器件、分立硬件组 件。通用处理器可以是微处理器或者该处理器也可以是任何常规的处理器等。105.参阅图5，图5为本发明第五实施例的存储介质的结构示意图。本发明实施 例的存储介质存储有能够实现上述所有方法的程序指令51，所述存储介质可以 是非易失性，也可以是易失性。其中，该程序指令51可以以软件产品的形式存 储在上述存储介质中，包括若干指令用以使得一台计算机设备(可以是个人计算 机，服务器，或者网络设备等)或处理器(processor)执行本发明各个实施方式所述 方法的全部或部分步骤。而前述的存储介质包括：u盘、移动硬盘、只读存储器 (rom，read-only memory)、随机存取存储器(ram，random access memory)、 磁碟或者光盘等各种可以存储程序代码的介质，或者是计算机、服务器、手机、 平板等终端设备。106.在本发明所提供的几个实施例中，应该理解到，所揭露的系统，装置和方 法，可以通过其它的方式实现。例如，以上所描述的装置实施例仅仅是示意性的， 例如，单元的划分，仅仅为一种逻辑功能划分，实际实现时可以有另外的划分方 式，例如多个单元或组件可以结合或者可以集成到另一个系统，或一些特征可以 忽略，或不执行。另一点，所显示或讨论的相互之间的耦合或直接耦合或通信连 接可以是通过一些接口，装置或单元的间接耦合或通信连接，可以是电性，机械 或其它的形式。107.另外，在本发明各个实施例中的各功能单元可以集成在一个处理单元中， 也可以是各个单元单独物理存在，也可以两个或两个以上单元集成在一个单元 中。上述集成的单元既可以采用硬件的形式实现，也可以采用软件功能单元的形 式实现。以上仅为本发明的实施方式，并非因此限制本发明的专利范围，凡是利 用本发明说明书及附图内容所作的等效结构或等效流程变换，或直接或间接运 用在其他相关的技术领域，均同理包括在本发明的专利保护范围。108.以上所述的仅是本发明的实施方式，在此应当指出，对于本领域的普通技 术人员来说，在不脱离本发明创造构思的前提下，还可以做出改进，但这些均属 于本发明的保护范围。









图片声明：本站部分配图来自人工智能系统AI生成,觅知网授权图片,PxHere摄影无版权图库。本站只作为美观性配图使用,无任何非法侵犯第三方意图,一切解释权归图片著作权方,本站不承担任何责任。如有恶意碰瓷者,必当奉陪到底严惩不贷!




内容声明：本文中引用的各种信息及资料（包括但不限于文字、数据、图表及超链接等）均来源于该信息及资料的相关主体（包括但不限于公司、媒体、协会等机构）的官方网站或公开发表的信息。部分内容参考包括:(百度百科,百度知道,头条百科,中国民法典,刑法,牛津词典,新华词典,汉语词典,国家院校,科普平台)等数据,内容仅供参考使用,不准确地方联系删除处理！本站为非盈利性质站点,发布内容不收取任何费用也不接任何广告!




免责声明：我们致力于保护作者版权，注重分享，被刊用文章因无法核实真实出处，未能及时与作者取得联系，或有版权异议的，请联系管理员，我们会立即处理，本文部分文字与图片资源来自于网络，部分文章是来自自研大数据AI进行生成,内容摘自(百度百科,百度知道,头条百科,中国民法典,刑法,牛津词典,新华词典,汉语词典,国家院校,科普平台)等数据,内容仅供学习参考,不准确地方联系删除处理!的,若有来源标注错误或侵犯了您的合法权益，请立即通知我们，情况属实，我们会第一时间予以删除，并同时向您表示歉意,谢谢!