一种残膜回收机防缠绕挑膜装置的制 一种秧草收获机用电力驱动行走机构

任务处理方法与流程

2022-11-19 09:57:40 来源:中国专利 TAG:


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.在跨系统的任务分发过程通常由任务处理系统来实现。广义的任务处理系统除包括:消息的发送端(publisher)、接收端(consumer)之外,还包括:消息总线(message bus)、数据库(database)、消息队列(mq)等,侠义的任务处理系统则不包括发送端(publisher)和接收端。后文中的任务处理系统,若无特别说明,均为侠义的系统概念。其中,发送端创建的消息任务经消息总线(message bus)、数据库(database)、消息队列(mq)相互配合处理后(即任务处理系统处理之后),发送至接收端(consumer)进行消费并进行消息的回馈。然而,对于任务状态的记录、更新、反馈、链路等功能有所缺失,且也不利于非开发人员使用。
49.由此,提出了本发明实施例的任务处理方法。如图1所示,图1示出了本发明任务处理方法的第一实施例的流程,该方法由消息总线执行。如图1所示,该方法包括以下步骤:
50.步骤s10:通过设置于发送端的第一消息总线代理接口、设置于接收端的第二消息总线代理接口对应与发送端/接收端建立通信连接;
51.如图2所示,本发明实施例的任务处理方法在具体实现时,在发送端、接收端(发送端和接收端可统称为用户终端,见图2)中均设置有消息总线代理接口(proxy),该消息总线代理接口为一接入接口,用于建立用户终端与消息总线之间的连接并进行通信。该消息总线代理接口例如可以提供springboot starter接入模板、以及消息总线sdk,这样可以实现分布式任务处理系统中各设备之间的简单接入,即使是非开发人员,也可以轻松实现用户终端与处理系统的接入。
52.为清楚描述,后文将设置在发送端的消息总线代理接口命名为第一消息总线代理接口,设置在接收端的总线代理接口命名为第二消息总线代理接口。
53.具体实现过程中,消息总线与发送端/接收端(用户终端)建立通信连接的方式可以是:
54.消息总线接收外部的用户终端通过消息总线代理接口发来的注册请求,该注册请
求中携带有处理系统名称、任务接收端点信息、任务反馈端点信息、任务消息接收端点信息、接收用户组信息、接收任务类型信息等,以用于接收来自分发的任务、通知消息及下游的反馈。若注册成功,则消息总线反馈注册成功的反馈信息至所述接收端/接收端,从而建立用户终端与任务处理系统之间的通信连接,进而实现任务流转。
55.步骤s20:接收来自发送端的流转任务信息;流转任务信息携带有:接收端信息;
56.具体实现任务流转时,消息总线接收来自发送端的流转任务信息,该流转任务信息携带有:接收端信息、推送方式、响应方式、任务详情、优先级、任务时效等信息,若为链式任务,则还会附上当前任务信息,作为父任务。
57.消息总线从发送端接收到流转任务请求,会给与回复给发送端,同时将执行步骤s30。
58.步骤s30:将所述流转任务信息写入消息队列;
59.具体实现中,消息队列mq(message queue)是一种进程间通信或同一进程的不同线程间的通信方式,包括基于内存的消息队列和分布式消息队列,由于分布式消息队列作为任务分发的中间件对于任务状态的记录、更新、反馈、链路等功能有所缺失,因此,本实施例中提供以内存式消息队列来处理来自用户终端的流转任务信息。
60.内存式消息队列为应用中的线程通信方式,通过消息总线配合消息队列,接受用户终端发布的流转任务信息后,消息总线将流转任务信息发布至消息队列或系统内的任务处理器,同时,消费者可获取到消息队列或系统内的任务信息,从而实现系统任务流转、记录、获取等功能。不仅如此,相比于分布式队列处理任务,不仅可以实现多种任务分发、流转模式,以满足用户终端各种任务处理的需求,还方便系统扩容,处理大数量级的任务,减少任务处理过程中的卡顿,使任务处理更加流畅。
61.可选地,在具体实现中可通过rabbitmq、activemq或数据库mysql等作为消息队列。
62.步骤s40:消费所述消息队列中的流转任务信息,根据所述接收端信息的指示,将所述流转任务信息发送至所述接收端,以使得所述接收端根据所述流转任务信息执行对应任务。
63.在具体进行任务消费的过程中,可以由消息总线通过第一消息总线代理接口与发送端建立连接,并与消息总线建立通信连接。消息总线收到流转任务信息后,识别该流转任务信息携带的接收端信息,以将流转任务发送至对应的接收端。
64.可选地,接收端在向消息总线发送流转任务信息时,可通过api接口提供自身信息包括但不限于:系统名称、任务接收端点信息、任务反馈端点信息、任务消息接收端点信息、接收用户终端组信息、接收任务类型信息等信息。
65.可选地,本实施例中的消息总线,通过第一消息总线代理接口与发送端建立通信连接,对于发送端来说,发送端可以通过第一消息总线代理接口直接接入消息队列进行任务流转,而不必预先进行配置,降低接入系统的难度,方便跨系统用户操作,使用户简便、高效的进入任务处理。
66.请参考图2,本实施例中,用户终端可以是发送端也可以是接收端,消息总线与用户终端通信,用户终端的任务处理器实现接收到的任务处理,用户终端可以是一个或多个,从而实现多端之间的任务的流转与处理。通过第一消息总线代理接口与消息队列通信,即
接收端连接第一消息总线后接入消息队列,从而对来自发送端的任务信息进行流转,从而进一步流转该任务或将任务指令发送至对应的接收端执行。
67.当然,接收端可以通过消息总线预先进行注册,即接收端将带有上述一种或几种的自身信息通过消息总线发送至消息总线后并注册成功,成为消息队列的授权用户,同时消息总线将注册成功的信息反馈至接收端,以通知授权用户终端进一步操作,授权接收端连接并与消息队列建立通信,由此实现多端或跨系统之间的任务处理及任务流转,减少用户终端获取数据的难度。
68.可选地,本实施例中,第二消息总线代理接口用于连接消息总线与接收端。第一消息总线代理接口接收来自发送端的流转任务信息后,将流转任务信息通过消息总线写入消息队列,消息队列进一步将流转任务信息通过第二消息总线代理接口和消息总线传送至接收端,以在消息队列获得流转任务信息的同时,发送至接收端以供其根据流转任务信息执行对应任务,由此,实现消息总线消费消息队列中的流转任务信息。
69.其中,通过第二消息总线代理接口将所述流转任务信息发送至接收端的发送方式不做限定,可以通知接收端一对一的主动获取,或者消息队列主动发送。
70.需要说明的是,第一消息总线代理接口与第二消息总线代理接口都用于流转消息队列的任务流转,但是实现消息队列与不同的终端的通信。并且,内存式消息队列对任务信息进行流转记录并保存,经过消息队列流转的任务信息可以供消费者或者获取,对消费者的组成不做限定,可以是发送端或者接收端,以及访问消息队列的浏览者等。通过消息总线将流经的任务信息写入消息队列,不仅对任务信息进行流转分发,还可以对任务信息进行管理与储存,通过访问消息队列,消费者可以获取任务信息。
71.可选地,本实施例中写入消息队列的流转任务信息可以供与消息队列通信的所有消费者获取,或者还可以设定用户终端的权限,对获取任务信息的用户终端进行限制。例如,跟进项目的处理进度以及处理过程,并将该项目的每一任务节点的任务信息写入消息队列后,针对每一节点的任务信息设置对不同用户终端的地址开放权限。
72.可选地,在另一种可行的实施例中,上述的步骤s40中“将所述流转任务信息发送至所述接收端”,具体可以包括:
73.步骤s401:通过点对点发送、点对多或广播方式将所述流转任务信息发送至所述接收端。
74.在具体发送流转任务信息的过程中,本实施例可以通过设置消息总线流转方式实现多种推送路由配置支持,配置方式包括但不限于:点对点发送:发起方推送至单点接收端;点对多发送:发起方推送至多各接收端(由发起方选择);广播:发送方推送至所有接收端。消息队列基于接收端的数量、接收优先等级或者使用者的选择等因素,通过实施不同的推送方式,实现流转任务信息发送至接收端。例如,设定点对点发送接收端,则在流转任务信息具有多个接收端的情况时,可以设定接收端收到的先后顺序,一次发送一个接收端,确保流转的任务信息准确送达。
75.通过接收来自发送端的任务流转信息并通过消息总线将该任务流转信息流转至消息队列,由于任务流转信息带有接收端信息,消息总线可以将任务流转信息写入消息队列,消息队列识别接收端信息,并通过消息总线进一步将任务流转信息通过上述方式的一种或多种结合发送至相应的接收端,从而实现完整的任务流转,写入消息队列的任务流转
信息还可以进一步供各类消费者获取。本实施例提供了一种消息队列的多种任务分发、流转模式,以满足用户终端各种任务处理的需求。
76.可选地,在一种可行的实施例中,上述的接收端包括多个,在上述“将所述流转任务信息发送至所述接收端”的步骤之后,本实施例的任务处理方法还可以包括:
77.步骤s50:若存在任一未接收到所述流转任务信息的接收端,或选定的接收端未接收到所述流转任务信息,则返回执行将所述流转任务信息发送至接收端的步骤。
78.在具体实现过程中,接收端因异常可能存在暂时无法接收到流转任务信息的情况,例如网络中断、接收端未经过授权、接收端没有成功接收任务信息等,因此需要在接收端未接收到流转任务信息时,再次向其发送流转任务信息并进行追踪,直至流转任务完成、终止或关闭。
79.可选地,在一种可行的实施例中,在上述“将所述流转任务信息发送至所述接收端”的步骤之后,本发明任务处理方法还可以包括:
80.步骤s60:检测自身任务状态信息;以及,将所述任务状态信息作为通知消息发送至所述消息队列;和/或,
81.步骤s70:接收来自所述接收端的反馈信息;以及将所述反馈信息发送至所述消息队列和所述接收端。
82.在具体实现过程中,消息总线可以对流转任务信息和任务内容变化进行检测确定是否发生预设条件的变化,例如,对消息总线设置监管者,对任务状态信息对应的时间变化、完成情况、经过地址等信息进行检测,若存发生预设条件下的变化,则将上述内容发送至消息队列,以向接入本系统的用户终端提供该变化情况。
83.和/或者,在向接收端发送流转任务信息时,也可以通过对流转任务信息或接收端或者消息队列设置监管者实现相同效果的检测,以监管流转任务信息的状态变化。例如,在流转任务信息发出时对流转任务信息自身设置监管者,对任务状态的变化进行监管,当检测到流转任务信息状态由正常状态变为异常状态时由监管者进行通报并写入消息队列,进而实现对接收端未接受到的流转任务信息进行通报或者继续监管。
84.可选地,在一种可行的实施例中,本发明任务处理方法还可以包括:
85.消费所述消息队列的任务状态信息或反馈信息;
86.将所述消息队列的任务状态信息或反馈信息发送至所述发送端。
87.可选地,任务状态信息即流转任务信息经过消息队列流转或者接受端处理后发生的状态变化,反馈信息即来自接收端、监管者或自身异常等发出的反馈信息,这些信息经过消息队列的识别与储存,根据接收端或者发送端的需求可以消费消息队列上的任务信息。
88.在具体实现过程中以群组的方式设定用户终端,该群组中的一用户终端发布流转任务信息后并设定对该流转任务信息对应的任务变化情况进行监测,则在该任务的变化情况发布在消息总线后,该群组中的用户都可以获取到该任务的变化情况,从而避免终端用户分别获取,提高用户效率。
89.此外,作为一种可行的实施方式,消息队列可以实现实现对任务处理的时效管理,即可设置任务时效,如设置任务将在时效开始时被投递、在时效临近时还未处理的任务将发送任务时效临近通知等多种情况,例如,在proxy设置监管者,当消息经过时处理过程触发预设告警条件可以包括若消息在时效到期时仍处于未完成状态将触发告警,提示用户终
端或接受者。
90.此外,作为另一种可行的实施方式,消息队列可以实现对任务处理失败后的重试机制,包括但不限于当投递失败时将触发重试机制、多次重试失败后将标记任务为失败状态、失败的消息将会触发相应的告警。
91.可选地,在一种可行的实施例中,本发明任务处理方法还可以包括:
92.若检测到任务追踪指令,判断所述流转任务信息的任务类型;
93.若所述任务类型为链式任务,则以所述任务的当前任务信息作为父任务,追踪所述父任务下各个节点的任务状态;
94.若所述任务类型为普通任务,追踪所述普通任务的一般任务状态;
95.将追踪到的所述各个节点的任务状态或所述一般任务状态作为所述任务追踪指令指向的任务数据。
96.在具体实现过程中,链式任务存在多个任务处理节点,由于各任务节点的任务状态可能不同,因此可通过在任务处理的每个节点设置监管者,或者,设定每个节点的任务状态自发的向消息总线反馈,以通知消息队列,便于需求者获取到各个节点的任务状态。
97.链式任务即一个任务完成后进入该任务的下一阶段的处理,本实施例中应用通过内存式消息队列对链式任务进行处理,可以存储大量的任务返回数据,而且任务先进先出的规则,可以及时反馈任务返回数据、避免任务发生阻塞,减少任务处理过程的异常。
98.可选地,对链式任务的各个节点追踪,还可以通过设置其他方式实现,例如,主动获取各个任务节点任务返回数据并将其关联至该任务,以随时调取、设置存储机制将各个节点的任务返回数据存储并在需要时进行调用等。
99.用户将普通任务发布到消息队列后,消息队列流转或接收端处理后便可完成该任务,不必再通过其他节点。当然,对于任务的类型可通过人为进行分类、或者系统对流转任务信息进行判断,以区分普通任务和链式任务,例如,在任务处理界面设置与用户交互的区域,用户将要发布的流转任务信息标记为一般任务类型,又如,通过流转任务信息流转的节点数量进行判断,以确定流转任务信息对应任务的类型。
100.通过判断类型,确定消息队列是否继续处理该任务以及是否向需求者反馈,从而达到任务状态的及时调整与反馈。将任务数据通过proxy连接的消息总线返回至任务追踪指令的发布者。
101.在本实施例中,消息总线获取到来自用户终端的任务追踪指令,则判断该任务的类型,获取该任务追踪指令对应的任务状态,提取相应的数据,即可向用户反馈或是否需要进入下一个节点继续处理,实现对任务的追踪。进一步地,消息队列接收反馈并转发至发送方,完成一次完整的任务流转。由于任务处理过程已写入消息队列,当用户终端需要跟踪流转任务的链路信息或统计信息时,向消息队列获取,消息队列通过消息总线返回相应信息给用户终端。
102.可选地,在一种可行的实施例中,本发明任务处理方法还可以包括:
103.步骤s80:当接收到所述发送端发来的关于所述流转任务信息的任务监控请求时,将所述任务监控信息发送至所述发送端。
104.在具体实现的过程中,由于任务状态信息和反馈信息都会经过消息队列中转,即任务消息在消息队列进行储存或流转,因此发布消息队列中的任务消息不仅可以供接收端
获取,也可以供发送端消费,用户可以通过消息总线获取到消息队列的任务流转信息。
105.本实施例的任务处理方法提供了一种任务记录完善的方式,使任务信息便于获取,且任务信息的相关内容提供的完整全面。
106.基于前述本发明任务处理方法的各个实施例,提出本发明任务处理方法的另一实施例。在本实施例中,该任务处理方法由用户终端执行。
107.请参考图3,由于用户终端user1、user2和消息队列mq可能处于不同的系统,同时接入后系统无法兼容进行信息流转,或者在传输信息时发生异常,因此本实施例中的消息队列mq基于一种系统服务框架,系统服务框架作为系统基础的支撑架构,以在此基础上构架任务相关应用模块以实现任务处理功能。
108.在本实施例中,提供一种基于spring构建的系统服务框架,其中,spring作为一种开源框架,开发人员易于配置,通过使用springboot工具快速构建和启动spring应用,以简化开发人员配置时间,便于管理。
109.基于此,本发明任务处理方法可以包括:
110.步骤s01:使用消息总线代理接口与消息总线建立连接;
111.步骤s02:创建流转任务信息;所述流转任务信息包括:接收端信息;
112.步骤s03:将所述创建流转任务信息发送至所述消息总线。
113.在具体实现的过程中,基于spring构建的消息队列处理环境,通过消息总线代理接口连接消息总线message bus和用户终端,实现用户终端与消息和其他用户终端通信连接,即用户终端user1和user2进行通信,其中,图示3并不限定user1和user2的接收或发生,本实施例中,user1作为接收端,user2作为发生端,对于不同系统的user1和user2来说,两者可以通过连接消息总线代理接口与消息连接实现接收任务、消息、反馈等,开发人员也便于配置,从而提供一种便捷接入以实现任务流转消息的传输。
114.可选地,消息总线代理接口可以设置在系统服务框架中或者的代码模块内,其中,代码模块由开发人员进行配置,通过对代码模块的程序设定,可以实现任务处理过程的配置。例如,代码模块可以是软硬件中的通信接口、总线,也可以是设定的执行协议、wifi标准、应用程序等,根据数据传输方式、系统配置进一步对代码模块进行设置。对用户终端来说,只需要连接代码模块汇总的消息总线代理接口与消息队列通信即可,相比于传统对不同系统进行配置的方式,可以降低开发接入系统交互的难度,方便跨系统用户终端操作,并且使用户终端简便、高效的进入任务处理。
115.通过在消息总线代理接口与用户终端连接,使用户终端接入基于spring构建的系统服务框架,spring构建的系统服务框架以及消息队列处理任务的方式是预配置在系统内,用户终端通过消息总线代理接口接入时即可通过proxy和消息总线与消息队列通信,使用系统服务框架和消息队列中的配置,并通过消息队列和消息总线实现任务处理功能,减少用户终端下载、配置程序,便于实现接入和任务处理。
116.可选地,代码模块还可根据用户终端需求以及任务实现的功能对其进行配置,以提供便于用户终端接入、任务发布、管理任务的接入方式,例如,设置加密模板、安全验证、用户终端自定义模块、接入成功通知等。
117.可选地,开发人员可对消息队列的功能进行配置,进一步实现消息通知推送,例如任务系统发起消息通知、状态变更通知、任务反馈推送(由接收端发送反馈至发送方)、反馈
投递失败将触发重试机制、任务链支持(将任务由接收端通过链式的方式发送至下一个接收端,形成一个任务链)、优先级支持、多级优先级支持、可设置延迟时间进行延时推送等。还可以对消息总线设置监管者,实现对消息总线上的任务相关请求进行监控,如任务监控请求、任务追踪请求、任务拦截请求等,从而扩展消息队列的功能,使其功能更加丰富,满足用户需求。
118.用户可以在终端创建流转任务信息,在本实施例中,系统服务框架对终端提供软件工具包,即任务处理应用sdk(software developmentkit),通过设置不同的软件工具包,可以实现不同的任务处理功能,例如,设置语音接收应用程序,用于获取用户的语音流转任务信息,在用户终端通过接入程序和应用程序接口api接入后,即可实现用户通过语音发布流转任务信息至本系统。
119.可选地,在一种可行的实施例中,本发明任务处理方法还可以包括:
120.步骤s04:通过任务管理用户界面接收来自用户的任务监控请求;
121.步骤s05:将所述任务监控请求发送至所述消息总线。
122.在具体实现的过程中,可以通过用户终端提供任务管理用户界面,任务管理用户界面与sdk可以一同配置在上述代码模块中,或者在终端配置好而并不通过消息总线传输,以通过任务管理用户界面与用户进行交互。
123.用户终端通过消息总线代理接口接入系统服务框架后,可以通过任务管理用户界面创建流转任务信息并通过任务管理用户界面生成任务监控请求,对消息总线上的任务信息进行监控,消息总线可以将流转任务信息进一步流转或经过消息队列分发,在实现任务的流转同时监控此任务信息,消息队列进一步提供任务信息进行流转和储存,供消费者获取。
124.本实施例中构建了一种已与开发、管理和配置的任务处理框架,便于实现轻便且强大的任务的创建、流转、记录、链路等功能,完全兼容微服务架构极易水平扩展、扩容以处理大数量级的任务,不仅便于开发人员开发配置、实现跨系统应用通信,也便于用户终端接入服务器,实现了任务处理的便捷与高效、任务管理上的简单与易操作。
125.应当理解,除上述实施方式外,本实施例基于前述实施例的全部内容,其他实施方式可以参考前述实施例的全部实施方式,因此不再一一赘述。
126.可选地,在一种可行的实施例中,系统服务框架配置软件工具包,上述的步骤s01具体可以包括:
127.通过应用程序接口与消息总线代理接口建立连接,接收并解析所述软件工具包。
128.在具体实现的过程中,用户终端通过消息总线代理接口连接至系统服务框架,系统服务框架提供软件工具包,用户终端接收并运行该软件程序包,通过设置不同的软件程序包,从而实现多种方式下的任务信息处理,而且通过预设置的软件工具包,提供一种便捷的任务处理方法,可以减少用户终端自行下载安装应用的时间,简化任务处理流程。
129.当然,用户终端创建流转任务信息也可以是终端自带的任务应用,并不通过sdk数据传输,在终端与任务处理建立通信连接后通过网络、wifi、蓝牙传输,例如通过微信、imessage、蓝牙共享等创建流转任务信息。
130.进一步地,接收端信息可以人为的预存在消息队列,或者接收端注册时将接收端信息写入消息队列。
131.可选地,在一种可行的实施例中,在上述的步骤s02之前,本发明任务处理方法还可以包括:
132.发送注册请求;
133.在具体实现的过程中,通终端将注册请求发送至消息队列,消息队列识别发送注册请求时的终端信息,例如mac地址、蓝牙地址等,对此类地址进行解析,可以确定所述注册请求对应的通知端点、反馈端点及授权用户终端等信息。例如,消息总线接收来自已授权用户终端的流转任务信息,并控制消息总线将流转任务信息流转,将授权用户终端的通知端点和反馈端点写入消息队列,控制消息队列将流转任务信息发送至流转任务信息对应的接收端,并接收来自接收端的任务返回数据,并向通知端点或反馈端点发送该任务返回数据,实现对用户终端的管理以及任务接受、交付的精准化。
134.可选地,在一种可行的实施例中,在上述的步骤s01之后,本发明任务处理方法还可以包括:
135.获取任务管理用户界面,当接收到来自用户的操作指令时,调用实施任务管理用户界面,以显示所述任务管理用户界面。
136.在具体实现的过程中,通过在代码模块中提供了任务处理界面,在用户终端通过接入程序连接至本系统后,直接从代码模块获取并运行该软件程序包并在终端显示该任务处理界面,用户终端即可通过任务处理界面与消息队列进行交互,使用户终端无需下载与任务管理相关的ui界面,也避免开发人员对不同系统配置任务处理界面。
137.基于前述本发明任务处理方法的各个实施例,提出本发明任务处理方法的又一实施例。在本实施例中,本发明任务处理方法由任务处理端执行。
138.在本实施例中,本发明任务处理方法可以包括:
139.步骤s100:使用消息总线代理接口与消息总线建立连接;
140.步骤s200:接收来自所述消息总线发来的流转任务信息并执行。
141.在具体实现的过程中,任务处理端用于处理流转任务信息,可以是用户终端的处理器,也可以是配置的独立的任务处理器,使用消息总线代理接口与消息总线建立连接,用户终端通过连接消息总线代理接口与消息总线连接,消息总线连接消息队列,通过消息总线代理接口与消息总线建立连接,可以使用户终端与消息队列连接通信,用户终端发送流转任务信息至消息总线,并经过消息队列的流转。
142.消息总线从用户终端接收流转任务信息,并给与用户终端回复接受成功的提示,并将该流转任务信息写入消息队列,以供消费者获取,消息队列进一步将流转任务信息根据流转任务信息的要求进行流转或发送至对应终端,对应终端的任务处理器进行处理,从而完成任务处理。
143.在一种可行的实施例中,可以通过对接收到流转任务信息设置相应的响应信息,若接收成功或失败,则返回相应的信息至消息总线供消息总线写入消息队列,确保任务状态的更新、流转与采取措施。
144.可选地,流转任务信息携带有接收端信息,或者接收端注册至消息队列所在的系统,经过消息队列流转任务信息后将任务信息发送至对应的任务处理端,任务处理端的实施方式参考前述全部实施例内容,因此不再一一赘述。
145.在一种可行的实施例中,在接受流转任务信息后,通过程序设计还可以实现多种
响应模式支持,以适用不同流转任务需求,包括但不限于:全响应模式:需所有接收端全部响应并进入已发送流转状态,例如若有接收端不响应将触发重试机制;单响应模式:只需任意接收端响应即进入已发送流转状态;选择响应模式:需所有被选择的接收端全部响应进入已发送流转状态,例如若有选择的接收端不响应将触发重试机制。
146.可选地,在一种可行的实施例中,在上述的步骤s200的步骤之后,本发明任务处理方法还可以包括:
147.监控所述流转任务信息对应任务的任务处理过程;
148.若所述处理过程触发预设告警条件,则向相关者提供告警通知。
149.在具体实现的过程中,监控流转任务信息对应的任务处理过程可以通过设置监控条件,例如定时抓取流转任务信息的数据,当然也可以设置监管者,设置监管者的步骤参考前述全部实施例,因此不再赘述。
150.通过监控任务处理端的任务处理过程,可以通过消息总线第一时间向消息总线反馈任务处理过程中的状态变化、异常情况等,以进一步向用户终端等消费者提供相关信息。
151.可选地,监控和告警包括但不限于上述情况,开发人员或用户终端可根据需求设定相应的监控措施和告警措施。
152.此外,本发明还提供一种任务处理装置。请参照图4,图4示出了本发明任务处理装置的实施例的结构示意图。
153.如图4所示,本发明任务处理装置400包括:通信模块410、接收模块420、第一处理模块430和第二处理模块440。
154.通信模块410,用于通过设置于发送端的第一消息总线代理接口、设置于接收端的第二消息总线代理接口对应与发送端/接收端建立通信连接;
155.接收模块420,用于接收来自所述发送端的流转任务信息;所述流转任务信息携带有:接收端信息;
156.第一处理模块430,用于将所述流转任务信息写入消息队列;
157.第二处理模块440:用于消费所述消息队列中的流转任务信息,根据所述接收端信息的指示,将所述流转任务信息发送至所述接收端,以使得所述接收端根据所述流转任务信息执行对应任务。
158.在一种可选的方式中,通信模块410具体用于接收来自所述接收端/发送端的注册请求;若注册成功,则发送注册成功的反馈信息至所述接收端。
159.在一种可选的方式中,第二处理模块440具体用于通过点对点发送、点对多或广播方式将所述流转任务信息发送至所述接收端/发送端。
160.在一种可选的方式中,所述接收端包括多个,第二处理模块440具体用于若存在任一未接收到所述流转任务信息的接收端,或选定的接收端未接收到所述流转任务信息,则返回执行将所述流转任务信息发送至接收端的步骤。。
161.在一种可选的方式中,第二处理模块440具体用于检测自身任务状态信息;以及,将所述任务状态信息作为通知消息发送至所述消息队列;和/或,接收来自所述接收端的反馈信息;以及将所述反馈信息发送至所述消息队列和所述接收端。
162.在一种可选的方式中,第二处理模块440具体当接收到所述发送端发来的关于所述流转任务信息的任务监控请求时,将所述任务监控信息发送至所述发送端。
163.本发明实施例提供的任务处理装置,包括通信模块410、接收模块420、第一处理模块430和第二处理模块440,实现通过第一消息总线代理接口与发送端建立通信连接,对于外部系统或终端用户来说,用户终端可以通过第一消息总线代理接口直接接入消息队列,而不必预先进行配置,降低接入系统的难度,方便跨系统用户终端操作,使用户终端简便、高效的进入任务处理。进一步的,通过接收来自发送端的任务流转信息并识别该任务流转信息的接收端信息,可以将任务流转信息写入消息队列并发送至相应的接收端,用户不仅可以在消息队列消费该任务流转信息,而且发送至对应的接收端执行流转任务信息对应的任务,如此,可以通过消息队列实现多种任务分发、流转模式,以满足用户终端各种任务处理的需求。
164.图5示出了本发明任务处理系统的实施例的结构示意图,本发明具体实施例并不对任务设备的具体实现做限定。
165.如图5所示,该任务处理系统可以包括:第一消息代理总线(图未示出)、消息队列(图未示出)、第二消息代理总线(图未示出)、处理器(processor)502、通信接口(communications interface)504、存储器(memory)506、以及通信总线508。
166.其中:消息队列与通过第一消息代理总线和第二消息总线连接通信,并与处理器502相互通信,处理器502、通信接口504、以及存储器506通过通信总线508完成相互间的通信。通信接口504,用于与其它设备比如客户端或其它服务器等的网元通信。处理器5402,用于执行程序510,具体可以执行上述用于任务处理方法实施例中的相关步骤。
167.具体地,程序510可以包括程序代码,该程序代码包括计算机可执行指令。
168.处理器502可能是中央处理器cpu,或者是特定集成电路asic(application specific integrated circuit),或者是被配置成实施本发明实施例的一个或多个集成电路。任务处理系统包括的一个或多个处理器,可以是同一类型的处理器,如一个或多个cpu;也可以是不同类型的处理器,如一个或多个cpu以及一个或多个asic。
169.存储器506,用于存放程序510。存储器506可能包含高速ram存储器,也可能还包括非易失性存储器(non-volatile memory),例如至少一个磁盘存储器。
170.程序510具体可以被处理器502调取使任务处理系统执行以下操作:
171.通过设置于发送端的第一消息总线代理接口、设置于接收端的第二消息总线代理接口对应与发送端/接收端建立通信连接;
172.接收来自所述发送端的流转任务信息;所述流转任务信息携带有:接收端信息;
173.将所述流转任务信息写入消息队列;
174.消费所述消息队列中的流转任务信息,根据所述接收端信息的指示,将所述流转任务信息发送至所述接收端,以使得所述接收端根据所述流转任务信息执行对应任务。
175.在一种可选的方式中,所述程序510被处理器502调取使任务处理系统执行以下操作:
176.接收来自所述接收端/发送端的注册请求;
177.若注册成功,则发送注册成功的反馈信息至所述接收端/发送端。
178.在一种可选的方式中,所述程序510被处理器502调取使任务处理系统执行以下操作:
179.通过点对点发送、点对多或广播方式将所述流转任务信息发送至所述接收端。
180.在一种可选的方式中,所述程序510被处理器502调取使任务处理系统执行以下操作:
181.若存在任一未接收到所述流转任务信息的接收端,或选定的接收端未接收到所述流转任务信息,则返回执行将所述流转任务信息发送至所述接收端的步骤。
182.在一种可选的方式中,所述程序510被处理器502调取使任务处理系统执行以下操作:
183.检测自身任务状态信息;以及,将所述任务状态信息作为通知消息发送至所述消息队列;和/或,
184.接收来自所述接收端的反馈信息;以及将所述反馈信息发送至所述消息队列和所述接收端。
185.在一种可选的方式中,所述程序510被处理器502调取使任务处理系统执行以下操作:
186.消费所述消息队列的任务状态信息或反馈信息;
187.将所述述消息队列的任务状态信息或反馈信息发送至所述发送端。
188.在一种可选的方式中,所述程序510被处理器502调取使任务处理系统执行以下操作:
189.当接收到所述发送端发来的关于所述流转任务信息的任务监控请求时,将所述任务监控信息发送至所述发送端。
190.在一种可选的方式中,所述程序510被处理器502调取使任务处理系统执行以下操作:
191.使用消息总线代理接口与消息总线建立连接;
192.创建流转任务信息;所述流转任务信息包括:接收端信息;
193.将所述创建流转任务信息发送至所述消息总线。
194.在一种可选的方式中,所述程序510被处理器502调取使任务处理系统执行以下操作:
195.通过任务管理用户界面接收来自用户的任务监控请求;
196.将所述任务监控请求发送至所述消息总线。
197.在一种可选的方式中,所述程序510被处理器502调取使任务处理系统执行以下操作:
198.使用消息总线代理接口与消息总线建立连接;
199.接收来自所述消息总线发来的流转任务信息并执行。
200.在此提供的算法或显示不与任何特定计算机、虚拟系统或者其它设备固有相关。此外,本发明实施例也不针对任何特定编程语言。
201.在此处所提供的说明书中,说明了大量具体细节。然而能够理解,本发明的实施例可以在没有这些具体细节的情况下实践。类似地,为了精简本发明并帮助理解各个发明方面中的一个或多个,在上面对本发明的示例性实施例的描述中,本发明实施例的各个特征有时被一起分组到单个实施例、图、或者对其的描述中。其中,遵循具体实施方式的权利要求书由此明确地并入该具体实施方式,其中每个权利要求本身都作为本发明的单独实施例。
202.本领域技术人员可以理解,可以对实施例中的设备中的模块进行自适应性地改变并且把它们设置在与该实施例不同的一个或多个设备中。可以把实施例中的模块或单元或组件组合成一个模块或单元或组件,以及此外可以把它们分成多个子模块或子单元或子组件。除了这样的特征和/或者过程或者单元中的至少一些是相互排斥之外。
203.应该注意的是上述实施例对本发明进行说明而不是对本发明进行限制,并且本领域技术人员在不脱离所附权利要求的范围的情况下可设计出替换实施例。在权利要求中,不应将位于括号之间的任何参考符号构造成对权利要求的限制。单词“包含”不排除存在未列在权利要求中的元件或步骤。位于元件之前的单词“一”或“一个”不排除存在多个这样的元件。本发明可以借助于包括有若干不同元件的硬件以及借助于适当编程的计算机来实现。在列举了若干装置的单元权利要求中,这些装置中的若干个可以是通过同一个硬件项来具体体现。单词第一、第二、以及第三等的使用不表示任何顺序。可将这些单词解释为名称。上述实施例中的步骤,除有特殊说明外,不应理解为对执行顺序的限定。
再多了解一些

本文用于创业者技术爱好者查询,仅供学习研究,如用于商业用途,请联系技术所有人。

发表评论 共有条评论
用户名: 密码:
验证码: 匿名发表

相关文献