任务监管方法、装置及系统

摘要

本申请公开了一种任务监管方法、装置及系统。该任务监管方法包括基于LNMP系统获取第一客户端发布的任务，其中，任务为数据层中将所有资源整合后生成任务发布模式的任务；将任务发送至邀请任务组用户对应的第二客户端中；当接收到第二客户端返回的任务的完成信息时，更新任务的任务完成情况为完成；当到达任务的截至时间时，停止接收客户端返回的任务的完成信息，并将邀请任务组的任务完成情况反馈至第一客户端和/或第二客户端，以便第一客户端和/或第二客户端查看邀请任务组的任务完成情况。本申请解决了无法对多人小组中的任务完成情况进行查看的技术问题。

说明书

技术领域

本申请涉及通信领域，具体而言，涉及一种任务监管方法、装置及系统。

背景技术

在企业不同部门间进行任务发布时，通常是通过口头或者线下传达任务，但是通过口头或者线下传达任务的时候会出现无法查看任务完成情况的问题。同时，发布者在发布任务时，会将任务发送给任务对应的多人小组，但会存在无法在第一时间将任务发送给多人小组中的每一位用户，而且不论是发布者还是小组用户，都无法对多人小组中的任务完成情况进行查看，如何对发布的任务进行监管成为了亟待解决的问题。

针对相关技术中无法对多人小组中的任务完成情况进行查看的问题，目前尚未提出有效的解决方案。

发明内容

本申请的主要目的在于提供一种任务监管方法，以解决无法对多人小组中的任务完成情况进行查看的问题。

为了实现上述目的，本申请提供了一种任务监管方法、装置及系统。

第一方面，本申请提供了一种任务监管方法。

根据本申请的任务监管方法包括：

基于LNMP系统获取第一客户端发布的任务，其中，所述任务为数据层中将所有资源整合后生成任务发布模式的任务；

将所述任务发送至邀请任务组用户对应的第二客户端中；

当接收到第二客户端返回的任务的完成信息时，更新所述任务的任务完成情况为完成；

当到达任务的截至时间时，停止接收客户端返回的任务的完成信息，并将所述邀请任务组的任务完成情况反馈至第一客户端和/或第二客户端，以便第一客户端和/或第二客户端查看所述邀请任务组的任务完成情况。

进一步的，在所述基于LNMP系统获取第一客户端发送的任务之前，所述方法还包括：

将数据层中存储的所有资源进行整合，生成任务发布模式的任务；

根据所有任务的任务属性，对第一用户端和第二用户端对应的所有用户按照任务属性进行分组，得到邀请任务组，其中，每个用户至少被分到一个邀请任务组中。

进一步的，在所述到达任务的截至时间之前，所述方法还包括：

判断是否到达任务的提醒时间；

若是，则将提示信息发送到所述任务未完成的第二客户端中。

进一步的，在将所述邀请任务组的任务完成情况发送至第一客户端和/或第二客户端之前，所述方法还包括：

若未接收到第二客户端返回的任务完成信息，则所述第二客户端的任务完成情况为未完成。

进一步的，所述方法还包括：

当接收第二客户端发送的资源文件时，将所述资源文件保存在数据层中，以便邀请任务组对应的第二客户端查看。

进一步的，所述方法还包括：

当接收到第一客户端和/或第二客户端发送的任务完成情况的查看指令时；

发送当前任务完成情况至第一客户端和/或第二客户端，以便第一客户端和/或第二客户端查看所述邀请任务组当前的任务完成情况。。

第二方面，本申请提供了一种任务监管装置。

根据本申请的任务监管装置包括：

任务获取单元，用于基于LNMP系统获取第一客户端发布的任务，其中，所述任务为数据层中将所有资源整合后生成任务发布模式的任务；

任务发送单元，用于将所述任务发送至邀请任务组用户对应的第二客户端中；

任务情况更新单元，用于当接收到第二客户端返回的任务的完成信息时，更新所述任务的任务完成情况为完成；

任务情况反馈单元，用于当到达任务的截至时间时，停止接收客户端返回的任务的完成信息，并将所述邀请任务组的任务完成情况反馈至第一客户端和/或第二客户端，以便第一客户端和/或第二客户端查看所述邀请任务组的任务完成情况。

进一步的，所述装置还包括：

任务生成单元，用于将数据层中存储的所有资源进行整合，生成任务发布模式的任务；

任务组分组单元，用于根据所有任务的任务属性，对第一用户端和第二用户端对应的所有用户按照任务属性进行分组，得到邀请任务组，其中，每个用户至少被分到一个邀请任务组中。

进一步的，所述装置还包括：

任务提醒单元，用于判断是否到达任务的提醒时间；若是，则将提示信息发送到所述任务未完成的第二客户端中。

进一步的，所述任务情况反馈单元还包括：

任务情况反馈子单元，用于若未接收到第二客户端返回的任务完成信息，则所述第二客户端的任务完成情况为未完成。

进一步的，所述装置还包括：

资源保存单元，用于当接收第二客户端发送的资源文件时，将所述资源文件保存在数据层中，以便邀请任务组对应的第二客户端查看。

进一步的，所述装置还包括：

任务情况查看单元，用于当接收到第一客户端和/或第二客户端发送的任务完成情况的查看指令时；发送当前任务完成情况至第一客户端和/或第二客户端，以便第一客户端和/或第二客户端查看所述邀请任务组当前的任务完成情况。

第三方面，本申请提供了一种任务监管系统。

根据本申请的任务监管系统包括：

后台端，分别与第一客户端、第二客户端连接，用于实现第一方面提供的任务监管方法的步骤；

第一客户端，用于将发布的任务发送至后台端，接收后台端反馈的邀请任务组中的任务完成情况；

第二客户端，用于接收后台端发送的任务，反馈任务完成情况至后台端，接收后台端反馈的邀请任务组中的任务完成情况。

第四方面，本申请提供一种非暂态计算机可读存储介质，其上存储有计算机程序，该计算机程序被处理器执行时实现第一方面提供的任务监管方法的步骤。

第五方面，本申请提供一种电子设备，包括存储器、处理器及存储在存储器上并可在处理器上运行的计算机程序，所述处理器执行所述程序时实现第一方面提供的任务监管方法的步骤。

在本申请实施例中，采用基于LNMP系统处理信息的方式，后台端通过获取第一客户端发布的任务，并且将其发送给邀请任务组中每个用户对应的第二客户端。接收第二客户端返回的任务完成信息，在到达任务截止时间时统计邀请任务组中每个用户的任务完成情况，并将任务完成情况发送给第一客户端和/或第二客户端，达到了反馈邀请任务组中每个用户的任务完成情况的目的，从而实现了对发布的任务进行监管的技术效果，进而解决了无法对多人小组中的任务完成情况进行查看的技术问题。

附图说明

构成本申请的一部分的附图用来提供对本申请的进一步理解，使得本申请的其它特征、目的和优点变得更明显。本申请的示意性实施例附图及其说明用于解释本申请，并不构成对本申请的不当限定。在附图中：

图1是本申请实施例的任务监管方法的流程示意图；

图2是本申请另一实施例的任务监管方法的流程示意图；

图3是本申请实施例的任务监管装置的结构框图；

图4是本申请实施例的任务监管系统的结构框图；

图5是本申请另一实施例的任务监管系统的结构框图；

图6是本申请实施例的电子设备框图。

具体实施方式

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

需要说明的是，本申请的说明书和权利要求书及上述附图中的术语“第一”、“第二”等是用于区别类似的对象，而不必用于描述特定的顺序或先后次序。应该理解这样使用的数据在适当情况下可以互换，以便这里描述的本申请的实施例。此外，术语“包括”和“具有”以及他们的任何变形，意图在于覆盖不排他的包含，例如，包含了一系列步骤或单元的过程、方法、系统、产品或设备不必限于清楚地列出的那些步骤或单元，而是可包括没有清楚地列出的或对于这些过程、方法、产品或设备固有的其它步骤或单元。

此外，术语“安装”、“设置”、“设有”、“连接”、“相连”、“套接”应做广义理解。例如，可以是固定连接，可拆卸连接，或整体式构造；可以是机械连接，或电连接；可以是直接相连，或者是通过中间媒介间接相连，又或者是两个装置、元件或组成部分之间内部的连通。对于本领域普通技术人员而言，可以根据具体情况理解上述术语在本申请中的具体含义。

需要说明的是，在不冲突的情况下，本申请中的实施例及实施例中的特征可以相互组合。下面将参考附图并结合实施例来详细说明本申请。

首先需要说明的是，本申请实施例中的软件应用环境为基于LNMP系统，LNMP系统具体是指运行在Linux系统中，采用Nginx服务器，数据存储在MySQL数据库，通过PHP语言研发的CGI程序的网站服务系统。并且，LNMP系统包括应用层、服务层、数据层。具体的，应用层包括客户端和后台端，服务层用于为客户端和后台端提供服务(如本申请实施例中提供的任务监管方法)，数据层用于提供数据存储服务。

根据本申请实施例，提供了一种适用于后台端的任务监管方法，如图1所示，该方法包括如下的步骤S101至步骤S104：

S101：基于LNMP系统获取第一客户端发布的任务。

当用户需要发布任务时，会通过第一客户端进行任务的发布，具体的，第一客户端是指发布任务的用户对应的客户端；任务为数据层中将所有资源整合后生成任务发布模式的任务，这样后台端就可以获取第一客户端发布的任务，任务中至少包含任务内容、任务截止时间。

S102：将任务发送至邀请任务组用户对应的第二客户端中。

后台端需要先根据上述任务确定该任务对应的邀请任务组，具体的，邀请任务组的确定可以是根据第一客户端在发布任务时指定的信息确定的，也可以是根据任务内容匹配确定的，在此不进行限制。然后后台端将任务发送给确定的邀请任务组中的每一个用户对应的第二客户端，具体的，第二客户端是指邀请任务组中用户对应的客户端。

S103：当接收到第二客户端返回的任务的完成信息时，更新任务的任务完成情况为完成。

完成信息通常是用户通过第二客户端主动点击提交的，也可以是根据后台端获取到的第二客户端的信息判断后得到的。任务完成情况包括完成和未完成，在本申请实施例中，每个任务初始的任务完成情况均为未完成，只有在接收到第二客户端返回的任务的完成信息时，才会将任务完成情况更新为完成。

S104：当到达任务的截至时间时，停止接收客户端返回的任务的完成信息，并将邀请任务组的任务完成情况反馈至第一客户端和/或第二客户端。

当到达任务的截止时间时，后台端会停止接收上述步骤S103中用户返回的完成信息，若此时还未接收到步骤S103中第二客户端返回的任务完成信息，则没有发送任务完成信息对应的第二客户端的任务完成情况为未完成，同时将邀请任务组中所有用户的任务完成情况进行统计后反馈给第一客户端和/或第二客户端进行展示，后台端具体将任务完成情况为完成和未完成的用户通过2个页面发送给第一客户端和/或第二客户端进行展示，这样，不仅发布任务的用户可以通过第一客户端查看邀请任务组的任务完成情况，邀请任务组中的用户也可以通过第二客户端查看邀请任务组的任务完成情况。

示例的，本申请的一实施例：客服组一用户可以通过第一客户端发布创作文章的任务，并在任务中写明创作的方向及任务截止时间。后台端接收到创作文章的任务时，会根据任务内容进行匹配，得到对应的邀请任务组，并将上述创作文章的任务发送给主编组(即邀请任务组)对应的用户的第二客户端。主编组中的每一位用户可以通过第二客户端查看任务内容(创作文章的创作方向)以及任务截止时间。当主编组中的用户在第二客户端点击“任务完成”按钮时，即该用户上传了任务的完成信息。后台端根据第二客户端上传的任务的完成信息，更新该用户的任务完成情况为完成。当到达任务的截止时间时，后台端停止接收主编组中的用户上传任务的完成信息，并将主编组中所有组员的任务完成情况进行统计后，按照完成和未完成的2个页面反馈给发布任务的客服组用户对应的第一客户端和/或主编组对应的第二用户端，这样发布任务的客户组用户和主编组用户可以对任务完成情况进行查看。

示例的，本申请的另一实施例：宣传组第一用户通过第一客户端发布促活欧洲用户的任务，并在任务中写明截至时间。后台端接收到促活欧洲用户的任务时，根据内容会根据任务内容进行匹配，得到对应的邀请任务组，并将上述促活欧洲用户的任务发送给欧洲宣传组对应的第二客户端。欧洲宣传组(邀请任务组)中的每一位用户就可以通过第二客户端查看任务内容及任务截止时间。邀请任务组中的英国宣传组用户接收到该发布促活欧洲用户的任务后，通过第一用户端发布了促活英国用户的任务，并在任务中写明截止时间，以及指定英国销售组为邀请任务组。客户端接收到英国宣传组用户发布的任务时，根据任务中指定英国销售组为邀请任务组的信息，将促活英国用户的任务发送给英国销售组对应的第二客户端，以便英国销售组用户进行查看。其中，英国销售组包含用户A、B，用户A拥有客户源1、2、3，用户B拥有客户源3、4、5，用户A和用户B均对自己的客户源执行促活任务，最终可以达到促活英国用户的目的，例如，当用户A完成其接收到的促活英国用户的任务时，会在其对应的第二客户端点击“任务完成”按钮，更新用户A的任务完成情况为完成。当到达任务的截止时间时，后台端停止接收主编组中的用户上传任务的完成信息，并将主编组中所有组员的任务完成情况进行统计后，按照完成和未完成的2个页面反馈给发布任务的英国宣传组用户对应的第一客户端和/或英国销售组对应的第二用户端，这样发布任务的英国宣传组用户和英国销售组用户可以对任务完成情况进行查看。英国宣传组用户也就可以通过第二用户端点击促活欧洲用户的任务对应的“任务完成”按钮。并且，宣传部中的用户还会发布促活欧洲其他国家用户的任务，执行任务的方法同理上述促活英国用户的任务。最终可以达到促活欧洲用户的任务。通过上述方法，可以实现任务间的环环相扣，通过执行大任务(促活欧洲用户)间的小任务(促活英国用户)，完成大任务，以达到任务接龙的目的。

从以上的描述中，可以看出，本申请实现了如下技术效果：在本申请实施例中，采用基于LNMP系统处理信息的方式，后台端通过获取第一客户端发布的任务，并且将其发送给邀请任务组中每个用户对应的第二客户端。接收第二客户端返回的任务完成信息，在到达任务截止时间时统计邀请任务组中每个用户的任务完成情况，并将任务完成情况发送给第一客户端和/或第二客户端，达到了反馈邀请任务组中每个用户的任务完成情况的目的，从而实现了对发布的任务进行监管的技术效果。

进一步的，在基于LNMP系统获取第一客户端发送的任务之前，需要将数据层中存储的所有资源进行整合，生成任务发布模式的任务。还需要根据任务属性对数据层中存储的用户进行分组得到邀请任务组，具体是根据所有任务的任务属性，任务属性可以是对任务内容进行语义识别得到的，也可以是用户直接通过第一客户端发布的，对第一用户端和第二用户端对应的所有用户按照任务属性进行分组，得到邀请任务组，每个用户至少被分到一个邀请任务组中，即不同任务组之间可以是交集关系，示例的，用户A既负责客服又负责内容编辑的工作，那么用户A被同时分在客服组和主编组，客服组和主编组的交集就是用户A。

需要说明的是，用户的所有信息是用户通过客户端上传的，后台端将上述信息存储在数据层中，存储的信息中包括用户的账号信息(账号信息主要是指社交账号，例如微信账号、微博账号、网易账号等)，这样用户在登录本申请实施例提供的任务监管系统时，不论使用哪个社交账号登录系统，都可以对应到同一系统用户，即通过不同的账号登录都可以接收到任务，不需要用户通过手动登录不同社交账号进行关联。

进一步的，在到达任务的截至时间之前，还可以对任务截止前提醒未完成的用户完成任务，具体需要先判断是否到达任务的提醒时间，提醒时间通常是系统预设的，也可以是用户自行设定的，示例的，任务的提醒时间可以是截止时间之前一小时；若到达任务的提醒时间，则将提示信息发送到任务未完成的第二客户端中，这样邀请任务组中未完成任务的用户就可以接收到提示信息，减少错误统计任务完成情况的情况发生。

进一步的，邀请任务组在执行任务时，会存在需要将资源共享的情况(如在完成创作文章的任务时，将创作的方向相关的背景资料共享到邀请任务组中；如在完成促活用户的任务时，将客户源共享到邀请任务组中)，当接收第二客户端发送的资源文件时，将资源文件保存在数据层中，这样邀请任务组中的用户都可以通过第二客户端进行查看。另外，还可以在完成任务后进行资源共享，不对资源共享的时间点进行限制。

进一步的，本申请实施例中不仅可以在任务完成时将任务完成情况发送到发布任务的第一客户端和/或执行任务的邀请任务组的第二客户端中，还可以在执行任务期间，按照用户的需求，随时查看任务完成情况，具体的：发布任务的第一客户端、执行任务的邀请任务组的第二客户端都可以查看任务完成情况，当接收到第一客户端和/或第二客户端发送的任务完成情况的查看指令时，后台端将当前时间节点的任务完成情况发送到查看指令对应的客户端，这样客户端就可以查看邀请任务组当前的任务完成情况。

示例的，如图2所示，为本申请另一实施例的任务监管方法，接龙客户端(第一客户端)发布任务，通过https请求发送给Nginx服务器(后台端)，服务器将收集到的任务信息发送到MySQL中进行存储，并且通过在MySQL中以主从同步的方法使用任务信息，即将收集到的任务信息存在MySQL主库，为了保持主库的性能，会将主库中任务信息同步到MySQL从库。当用户需要获取信息时，客户端在从库中进行获取；当用户需要修改任务信息时，客户端在主库中修改任务信息，并将主库中的信息更新到从库中。MySQL主库将任务信息推送给另一Nginx服务器(该Nginx服务器和接收发布任务的Nginx服务器可以是相同的，也可以是不同的)，Nginx服务器将任务通知给第二用户端，第二用户端就可以提交该任务的完成情况，并将完成情况通过https请求返回给Nginx服务器。

需要说明的是，在附图的流程图示出的步骤可以在诸如一组计算机可执行指令的计算机系统中执行，并且，虽然在流程图中示出了逻辑顺序，但是在某些情况下，可以以不同于此处的顺序执行所示出或描述的步骤。

根据本申请实施例，还提供了一种用于实施上述任务监管方法的装置20，如图3所示，该任务监管装置20包括：

任务获取单元201，用于基于LNMP系统获取第一客户端发布的任务，其中，任务为数据层中将所有资源整合后生成任务发布模式的任务；

任务发送单元202，用于将任务发送至邀请任务组用户对应的第二客户端中；

任务情况更新单元203，用于当接收到第二客户端返回的任务的完成信息时，更新任务的任务完成情况为完成；

任务情况反馈单元204，用于当到达任务的截至时间时，停止接收客户端返回的任务的完成信息，并将邀请任务组的任务完成情况反馈至第一客户端和/或第二客户端，以便第一客户端和/或第二客户端查看邀请任务组的任务完成情况。

进一步的，装置20还包括：

任务生成单元，用于将数据层中存储的所有资源进行整合，生成任务发布模式的任务；

任务组分组单元，用于根据所有任务的任务属性，对第一用户端和第二用户端对应的所有用户按照任务属性进行分组，得到邀请任务组，其中，每个用户至少被分到一个邀请任务组中。

进一步的，装置20还包括：

任务提醒单元，用于判断是否到达任务的提醒时间；若是，则将提示信息发送到任务未完成的第二客户端中。

进一步的，任务情况反馈单元204还包括：

任务情况反馈子单元，用于若未接收到第二客户端返回的任务完成信息，则第二客户端的任务完成情况为未完成。

进一步的，装置20还包括：

资源保存单元，用于当接收第二客户端发送的资源文件时，将资源文件保存在数据层中，以便邀请任务组对应的第二客户端查看。

进一步的，装置20还包括：

任务情况查看单元，用于当接收到第一客户端和/或第二客户端发送的任务完成情况的查看指令时；发送当前任务完成情况至第一客户端和/或第二客户端，以便第一客户端和/或第二客户端查看邀请任务组当前的任务完成情况。

具体的，本实施例中各模块的实现可以参考方法实施例中的相关实现，不再赘述。

从以上的描述中，可以看出，本申请实现了如下技术效果：在本申请实施例中，采用基于LNMP系统处理信息的方式，后台端通过获取第一客户端发布的任务，并且将其发送给邀请任务组中每个用户对应的第二客户端。接收第二客户端返回的任务完成信息，在到达任务截止时间时统计邀请任务组中每个用户的任务完成情况，并将任务完成情况发送给第一客户端和/或第二客户端，达到了反馈邀请任务组中每个用户的任务完成情况的目的，从而实现了对发布的任务进行监管的技术效果。

根据本申请实施例，还提供了一种用于实施上述任务监管方法的任务监管系统30，如图4所示，该任务监管系统30包括：

后台端301，分别与第一客户端302、第二客户端303连接，用于执行任务监管方法；

第一客户端302，用于将发布的任务发送至后台端301，接收后台端301反馈的邀请任务组中的任务完成情况；

第二客户端303，用于接收后台端301发送的任务，反馈任务完成情况至后台端301，接收后台端301反馈的邀请任务组中的任务完成情况。

如图5所示，为本申请另一实施例的任务监管系统的结构框图，具体包括：应用层、服务层、数据层。应用层中包括接龙客户端(即上述第一客户端302、第二客户端303)，接龙管理后台(即上述后台端301)。服务层包括用户信息收集服务、接龙任务发布服务(即上述任务发送单元202)、登录服务、用户分组服务(即上述任务组分组单元)、执行结果反馈服务(即上述任务情况反馈单元204)。数据层包括MySql数据存储和Memcache数据存储。

本发明实施例提供一种非暂态计算机可读存储介质，其上存储有计算机程序，该计算机程序被处理器执行时实现任务监管方法的步骤。例如包括：基于LNMP系统获取第一客户端发布的任务，其中，任务为数据层中将所有资源整合后生成任务发布模式的任务；将任务发送至邀请任务组用户对应的第二客户端中；当接收到第二客户端返回的任务的完成信息时，更新任务的任务完成情况为完成；当到达任务的截至时间时，停止接收客户端返回的任务的完成信息，并将邀请任务组的任务完成情况反馈至第一客户端和/或第二客户端，以便第一客户端和/或第二客户端查看邀请任务组的任务完成情况。

图6为本发明实施例提供的电子设备框图，如图6所示，该设备包括：处理器401、存储器402和总线403；

其中，处理器401及存储器402分别通过总线403完成相互间的通信；处理器401用于调用存储器402中的程序指令，以执行上述实施例所提供的任务监管方法，例如包括：基于LNMP系统获取第一客户端发布的任务，其中，任务为数据层中将所有资源整合后生成任务发布模式的任务；将任务发送至邀请任务组用户对应的第二客户端中；当接收到第二客户端返回的任务的完成信息时，更新任务的任务完成情况为完成；当到达任务的截至时间时，停止接收客户端返回的任务的完成信息，并将邀请任务组的任务完成情况反馈至第一客户端和/或第二客户端，以便第一客户端和/或第二客户端查看邀请任务组的任务完成情况。

显然，本领域的技术人员应该明白，上述的本申请的各模块或各步骤可以用通用的计算装置来实现，它们可以集中在单个的计算装置上，或者分布在多个计算装置所组成的网络上，可选地，它们可以用计算装置可执行的程序代码来实现，从而，可以将它们存储在存储装置中由计算装置来执行，或者将它们分别制作成各个集成电路模块，或者将它们中的多个模块或步骤制作成单个集成电路模块来实现。这样，本申请不限制于任何特定的硬件和软件结合。

以上所述仅为本申请的优选实施例而已，并不用于限制本申请，对于本领域的技术人员来说，本申请可以有各种更改和变化。凡在本申请的精神和原则之内，所作的任何修改、等同替换、改进等，均应包含在本申请的保护范围之内。