CN106202332A - 一种基于SQLite数据库的离线拣货任务处理方法 - Google Patents

Abstract

本发明公开了一种基于SQLite数据库的离线拣货任务处理方法，本发明主要包括建立离线任务的本地SQLite数据库，执行网络监听、执行数据轮询以及根据执行结果更新离线任务数据库的内容四个主要流程，本发明通过一种新的网络请求方式，将实时的请求做成离线任务，将所有与请求相关的状态用SQLite数据库关联保存起来，通过对网络状态进行监听，对离线任务进行管理和执行，使得用户在操作过程感知不到程序对于网络的依赖，对于电子商务过程中缩短订单的履约时间和提升拣货作业的流畅性尤其具有重要的意义。

Description

一种基于SQLite数据库的离线拣货任务处理方法

技术领域

本发明涉及的是数据处理技术，具体涉及一种基于SQLite数据库的离线数据处理方法。

背景技术

随着电子商务的迅猛发展，网上采购生鲜越来越贴近人们的日常生活，在城市中由于交通出行等时间成本和价格成本越来越高，网上采购生鲜以其临近商超拣货配送，数小时内送达用户手中的特点受到用户推崇，电子商务中一个非常重要的环节就是根据客户的订单快速准确的拣取所需要的商品，并将拣取的商品进行及时的配送，现在物流管理中的拣货模式，一般有两种：

一是采用“人动物静”的方式，即由拣货员携带订单信息，在货场或者商店、超市等场所中不断移动的方式从货架上拣取与订单所需的名称、规格等信息相对应的商品；

二是采用“物动人静”的方式，即拣货员在固定的流水线位置保持不动，商品被放置在流水线上，不断通过持有不同订单的拣货员，由拣货员从中筛选出符合本订单的商品。

以上两种拣货方式各自都存在缺陷，第二种拣货方式流程复杂，需要专门制备流水作业线，占用货场的空间资源，增加了成本的投入，况且流动的作业方式增加了拣货员的精神投入，容易出现错拣、漏拣的情况，从电子商务物流的长远发展来说市场前景并不乐观；第一种拣货方式过程灵活简单，易于操作，能够充分发挥拣货人员的主观能动性，但是由于目前的拣货作业电子化管理已经成为趋势，而大型的货场或者仓库由于货品或者建筑本身的遮挡，存在着网络信号的盲区，往往拣货人员到达准确的储货点却发现本区域内没有网络信号或者信号强度太弱，无法实时将拣货信息回传给后台的任务管理端，于是就需要拣货员携带拣取的货物移动到有网络信号的区域才能完成拣货状态的同步、订单状态同步等拣货管理所需的信息，拣货员到处移动搜寻网络信号，一方面导致作业效率变低，降低拣货员的作业积极性，同时如果是大件、易碎的物品在拖动过程中势必会造成损坏风险的提高，如果让网络请求变成作业流程的关卡，那么对于拣货及后续配送的实时性都会大打折扣。

发明内容

针对现有技术的不足，本发明提供一种基于SQLite数据库的离线拣货任务处理方法，本方法通过在客户端建立一个SQLite的离线任务数据库，将无法实时同步的各类拣货作业信息保存在该数据库中，并由客户端自主对环境中的网络信号进行监听，而不需要人工移动搜寻网络，当客户端监听到网络条件满足数据同步的要求时，则从离线任务数据库中查询出满足执行条件的数据记录向服务端执行数据上传的操作，同时由数据库的程序接口从服务端获取执行的结果状态对离线任务数据库中的记录进行相应的删除或者修改，本发明的具体技术方案如下：

一种基于SQLite数据库的离线拣货任务处理方法，包括以下几个步骤：

S1、根据拣货操作生成SQLite离线任务数据库；

S2、执行网络监听；

S3、网络状态判别；

S4、判别为无网络时继续执行网络监听步骤S2；

S5、判别为有网络时激活数据轮询流程；

S6、查询任务状态，找出符合执行条件的离线任务；

S7、执行离线任务；

S8、根据执行结果更新SQLite离线任务数据库的内容；

S9、数据轮询未找到符合执行条件的离线任务时结束程序。

作为优选方案，所述的本地SQLite数据库包括任务表和数据表，所述任务表记录离线任务的特征数据，所述数据表用以记录离线任务的执行数据。

作为优选方案，所述的任务表和数据表的各条数据记录均包含一个ID作为对应记录的主键约束，其中数据表中的ID同时关联包括在任务表中作为任务表的外键约束，将任务表和数据表联系起来。

作为优选方案，所述轮询流程的触发包括了手动触发和自动触发两种方式，其中手动触发通过调用轮询程序代码完成，自动触发通过注册网络状态监听广播接收器完成。

作为优选方案，所述的修改离线任务数据库内容的步骤S8还包括以下步骤：

S81、执行离线任务成功，修改任务表和数据表中的任务状态和数据状态；

S82、根据修正后的任务表和数据表中的状态数据删除已经执行成功的离线任务记录；

S83、执行离线任务不成功，保持任务表的状态数据不变，修改任务表中的执行次数及执行结果，同时修改数据表中的状态数据为不成功。

本发明的有益效果在于，通过一个本地的SQLite离线任务数据库，将无法及时同步的数据暂时滞后保存在该数据库中，由客户端自主监听环境中的网络信息，网络条件满足时，客户端自主从离线任务数据库中查询需要向服务端上传的信息，整个过程中作业人员自始至终都感知不到客户端对于网络信息的依赖，客户端也不会向作业人员提示任何网络请求的结果干扰作业人员作业，从而保证了作业人员的作业效率，提高了作业人员的积极性，同时也简化了作业流程，节省了人力、物力资源。

附图说明

图1是本发明的流程图；

图2是本发明数据交换的示意图；

图3是本发明执行结果修正的流程图。

具体实施例

为了更加清楚地理解本发明的过程、技术方案及有益效果，下面结合附图对本发明做进一步的说明，但并不将本发明的保护范围限定在以下实施例中，所有在本方法的基本原理下所做的替换、修改均应落入本发明的保护范围。

如图1至图3所示，本发明的技术方案是在客户端建立一个基于SQLite的离线任务数据库，将需要实时同步的数据在网络条件不满足时通过离线任务数据库暂时滞后，由客户端自主完成有关网络状态的检测，并由客户端自主根据网络状态的变化触发对于离线任务数据库中的数据轮询并查询符合执行条件的离线任务，将符合执行条件的离线任务上传给离线任务管理器，或者由拣货人员在完成全部的拣货任务之后手动触发轮询流程对离线任务数据库中的数据进行查询并执行。

本发明基于SQLite的离线任务数据库包括了任务表和关联数据表两种与拣货任务相关的数据信息，其中任务表的建立采用如下命令语句：

sqlite>CREATE TABLE task(id INTEGER PRIMARY KEY autoincrement,typeTEXT NOT NULL,status TEXT NOT NULL,refer_obj_id INTEGER,execute_timesINTEGER,last_error TEXT,user_id TEXT NOT NULL)；

任务表的样表如图表所示(根据不同的拣货任务可以定义不同的数据项目)：

id	type	refer_obj_id	status	user_id	execute_times	last_error
							1	拣货开始	12	NEW	6666	0	last_error
2	拣货完成	23	FINISH	6666	1	last_error
							3	拣货完成	34	SUSPEND	6666	5	last_error

表中各字段的说明如下：

id是离线任务的id：采用“integer primary key autoincrement”约束，由SQLite自主为表中的每一条数据记录自动生成一个整型id，作为自动生成离线任务的唯一标识；

type是任务类型：离线任务请求类型，采用“text not null”约束，因此每一个拣货任务的type根据拣货进程的不同可以是“拣货开始”，“拣货完成”等等不同的类型，但必须是非空的；

refer_obj_id是任务表关联的数据表中数据记录的id：将数据表的id作为外键约束加入到任务表中，由此实现任务表和数据表的关联，通过id之间的关联来查询相关的数据；

Status是任务执行的状态：未执行的任务或者执行后不成功的任务标记为“NEW”，已经成功执行的任务标记为“FINISH”，不需要主动执行的任务标记为“SUSPEND”,SUSPEND状态可以根据实际的执行需要进行状态变更，如果要唤醒任务状态为可执行状态，则将此状态变更为“NEW”。

user_id是拣货员的id：用以标识拣货员的身份信息，这是进行绩效考核、责任落实以及其他人员管理所必须的数据；

execute_times是任务执行次数：记录任务从开始执行到执行成功过程中总共被执行的次数；

last_error是任务执行结果：用以记录任务执行过程中网络请求失败或者其他异常原因导致的执行错误，用于回查任务执行状态，追溯问题。

与任务表对应的是数据表，数据表记录的是需要被执行的具体任务的数据，数据表的建立采用如下的命令语句：

sqlite>CREATE TABLE orders(id INTEGER PRIMARY KEY autoincrement,dataTEXT NOT NULL,data_sync INTEGER NOT NULL)；

数据表的样表如图所示(根据不同的拣货任务定义不同的数据项目)：

id	data	user_id	data_sync
				12	xxx	6666	1
23	xxx	6666	0
				34	xxx	6666	1

表中各字段的说明如下：

id是离线数据的id：采用“integer primary key autoincrement”约束，由SQLite自主为表中的每一条数据记录自动生成一个的整型id，作为离线数据记录的唯一标识；

data是需要具体执行的数据：根据不同的订单信息，所需要执行的数据是各不相同的，商品的条码扫描信息，订单的扫描信息等都可以包含在内，采用“TEXT NOT NULL”作为约束条件，因此每一个任务的data是必须非空的文本数据类型；

user_id是拣货员的id：与任务表中的拣货员id是一致的；

data_sync是数据的执行状态，根据最终的执行结果，定义已经成功执行数据上传的数据执行状态为“0”(int ORDER_UPSUCCESS＝0)；未执行上传或者执行上传不成功的数据执行状态为“1”(int ORDER_UNUPLOAD＝1)。

在具体的任务和数据执行过程中，主要包括以下几个步骤：

S1、根据拣货操作生成SQLite离线任务数据库；

S2、执行网络监听；

S3、网络状态判别；

S4、判别为无网络时继续执行网络监听步骤S2

S5、判别为有网络时激活数据轮询流程；

S6、查询任务状态，找出符合执行条件的离线任务；

S7、执行离线任务；

S8、根据执行结果更新SQLite离线任务数据库的内容；

S9、数据轮询未找到符合执行条件的离线任务时结束程序。

其中，步骤S4涉及的轮询程序的触发包括了手动触发和自动触发两种方式，手动触发是当客户端进入了网路条件满足的环境中后，由拣货人员操作客户端调用任务管理器中的轮询程序代码开启对离线任务数据库中的数据轮询；自动触发是在客户端中注册网络监听广播接收器，由客户端自主检测环境中的网络状态，当客户端检测到网络状态发生变化时，自动触发对于离线任务数据库中的数据轮询。

数据轮询主要是要找出需要执行的离线任务及其对应的数据信息，具体的过程如下：

首先取出任务表中所有任务状态为“NEW”的任务逐条执行；

然后通过任务表中的“refer_obj_id”找到数据表中对应的需要执行的具体数据，向服务端执行上传，具体如下：

按照上述的数据表，经过轮询之后，在任务表中查询到id＝1的任务状态为“NEW”执行次数为“0”，标明该条任务是尚未被执行的离线任务，然后通过refer_obj_id＝12去查询数据表中“id＝12”所对应的具体数据记录(sqlite>SELECT*FROM orders WHERE id＝12)，查询到该数据后执行上传，如果上传成功则将数据表中的“data_sync”修改为“0”(intORDER_UPSUCCESS＝0)，同时修改任务表中的“status”为“FINISH”，“execute_times”为“1”，因为执行过程中未出现错误，因此任务表中的“last_error”为空；如果上传未成功，则将数据表中的“data_sync”修改为“1”(int ORDER_UNUPLOAD＝1)，同时保持任务表中的“status”为“NEW”状态不变，修改“execute_times”为“1”，因为执行过程中出现错误导致任务执行失败，因此任务表中的“last_error”一栏具体写入错误的原因，然后该条任务记录进入下一轮的数据轮询程序进行相同的操作，在执行过程中遇到网络不通的情况时，则将执行线程上锁处于等待唤醒的状态，当监测到网络恢复后释放锁让线程继续执行。

每次执行完后，对数据库中已经被成功执行的数据进行及时删除，以减轻数据库中冗余数据的数量。

在本发明中，除了任务表和数据表中的id以及数据状态data_sync由系统产生外，其余数据都直接通过接口从服务端获取。

Claims (5)

1.一种基于SQLite数据库的离线拣货任务处理方法，其特征在于，包括以下几个步骤：

S1、根据拣货操作生成SQLite离线任务数据库；

S2、执行网络监听；

S3、网络状态判别；

S4、判别为无网络时继续执行网络监听步骤S2；

S5、判别为有网络时激活数据轮询流程；

S6、查询任务状态，找出符合执行条件的离线任务；

S7、执行离线任务；

S8、根据执行结果更新SQLite离线任务数据库的内容；

S9、数据轮询未找到符合执行条件的离线任务时结束程序。

2.根据权利要求1所述的离线任务处理方法，其特征在于，所述的本地SQLite数据库包括任务表和数据表，所述任务表记录离线任务的特征数据，所述数据表用以记录离线任务的执行数据。

3.根据权利要求2所述的离线任务处理方法，其特征在于，所述的任务表和数据表的各条数据记录均包含一个ID作为对应记录的主键约束，其中数据表中的ID同时关联包括在任务表中作为任务表的外键约束，将任务表和数据表联系起来。

4.根据权利要求3所述的离线任务处理方法，其特征在于，所述轮询流程的触发包括了手动触发和自动触发两种方式。

5.根据权利要求4所述的离线任务处理方法，其特征在于，所述的步骤S8还包括以下步骤：

S81、执行离线任务成功，修改任务表和数据表中的任务状态和数据状态；

S82、根据修正后的任务表和数据表中的状态数据删除已经执行成功的离线任务记录；

S83、执行离线任务不成功，保持任务表的状态数据不变，修改任务表中的执行次数及执行结果，同时修改数据表中的状态数据为不成功。