【技术实现步骤摘要】
本申请涉及订单处理，尤其涉及一种多渠道订单处理方法、装置及设备。
技术介绍
1、随着移动互联网的发展，企业往往通过多个线上渠道(如：自营网站、电商平台、社交媒体、线下门店、第三方服务商等)进行商品销售。然而，每个销售渠道生成的订单号通常具有其特定的编码规则和格式，使得企业在处理跨渠道订单时面临诸多挑战，包括但不限于订单追踪困难、数据统计分析复杂、客户查询服务不便、订单号重复、订单号长度长短不一等。对此，亟需设计一种订单号规则，对多渠道订单数据进行统一。
2、目前，一种常见的方法就是修改交互报文格式，并通知相关合作方进行修改，实现订单的统一管理，使得订单号格式统一。
3、然而，这种方式需要合作方配合，对相关系统进行升级改造，当涉及众多合作方系统时，难度比较大，改造进度依赖于合作方，难以把握。因此，现有技术无法高效、便捷地实现订单的统一管理。
技术实现思路
1、本申请提供一种多渠道订单处理方法、装置及设备，用以解决现有技术无法高效、便捷地实现订单的统一管理的问题。
2、第一方面，本申请提供一种多渠道订单处理方法，包括：
3、接收多渠道中至少一个渠道发送的原始订单信息；针对任一渠道的原始订单信息，对所述原始订单信息进行解析，识别得到订单的业务类型和订单的渠道特征；对解析后的原始订单信息进行校验；若校验通过，根据所述解析后的原始订单信息中的目标业务参数，生成所述多渠道对应的统一格式的订单号；其中，所述多渠道对应的统一格式中包括：时间、业务类型
4、在一种可能的设计中，所述目标业务参数包括：客户联系方式、客户id、金额、数量、商家、商品、库存；所述对解析后的原始订单信息进行校验，包括下述至少一项：对所述原始订单信息进行解密后，对解密后的签名进行验证，确认所述原始订单信息对应的请求报文是否真实有效，若确认所述请求报文真实有效，则确认所述请求报文的真实内容与所述请求报文的发送方，所述发送方为所述多渠道中的渠道；根据所述目标业务参数，检查所述请求报文的字段是否完整，若不完整，则对缺失的关键交易要素的请求进行拒绝；其中，所述关键交易要素为所述目标业务参数对应的要素；检查所述请求报文的字段的有效性，若字段无效，则对字段无效的请求进行拒绝；对所述请求报文的时间戳校验，若时间戳校验失败，则对时间戳校验失败的请求进行拒绝；检查所述客户是否登录，若所述客户未登录，则对未登录的客户对应的渠道的请求进行拒绝；检查所述客户是否为异常客户和/或异常ip，若为异常客户和/或异常ip，对所述异常客户和/或异常ip对应的渠道的请求进行拒绝。
5、在一种可能的设计中，所述检查所述请求报文的字段的有效性，包括：检查所述请求报文的字段的取值是否在预设范围内；若在预设范围内，则确定所述请求报文的字段有效；若不在预设范围内，则确定所述请求报文的字段无效。
6、在一种可能的设计中，所述方法还包括：根据所述业务类型和所述渠道特征，确定所述原始订单信息对应的目标业务参数。
7、在一种可能的设计中，所述根据所述解析后的原始订单信息中的目标业务参数，生成所述多渠道对应的统一格式的订单号，包括：根据所述解析后的原始订单信息中的目标业务参数，利用统一发号器，生成所述多渠道对应的统一格式的订单号；其中，所述统一发号器是由redis存储系统和lua脚本构建，所述统一发号器为用于对所述多渠道的订单进行格式统一，生成统一格式的订单号的应用系统；若所述统一发号器不可用时，通过统一订单号生成策略，确定订单格式，并根据所述订单格式，生成所述多渠道对应的统一格式的订单号，所述订单格式为所述多渠道对应的统一格式。
8、在一种可能的设计中，所述统一格式中包含的所述自增数为多位，且用于支持每秒生成批量的订单号，所述统一格式中包含的所述客户id用于搜索或查询所述原始订单信息；所述生成所述多渠道对应的统一格式的订单号，包括：根据所述目标业务参数，确定所述统一格式中包含的时间、业务类型、机器码、渠道号、自增数、客户id分别对应的取值；将各个取值，按照所述统一格式，生成所述统一格式的订单号。
9、在一种可能的设计中，所述方法还包括：保留所述渠道发送的订单号，并将所述渠道发送的订单号作为第三方订单号；存储并维护所述统一格式的订单号与所述第三方订单号的映射关系。
10、在一种可能的设计中，所述方法还包括：根据所述统一格式的订单号中的客户id的目标位，将所述统一格式的订单号的数据进行分表，用以平均到多张表中；其中，所述客户id的目标位作为用于搜索或查询的索引。
11、在一种可能的设计中，所述方法还包括：在历史数据表中新增第三方订单号的字段，所述第三方订单号的字段用于保存各个渠道发送的订单号，所述历史数据表中包含订单号的字段，所述订单号的字段上记录有相应渠道发送的订单号；对新增的第三方订单号的字段进行初始化，用以根据历史订单相关信息和目标业务参数，通过所述统一格式，生成相应的新订单号并保存所述新订单号；将所述新增的第三方订单号的字段与所述订单号的字段进行互换，并更新所述历史数据表的索引。
12、第二方面，本申请提供一种多渠道订单处理装置，包括：接收模块，用于接收多渠道中至少一个渠道发送的原始订单信息；解析模块，用于针对任一渠道的原始订单信息，对所述原始订单信息进行解析，识别得到订单的业务类型和订单的渠道特征；校验模块，用于对解析后的原始订单信息进行校验；订单号生成模块，用于在校验通过时，根据所述解析后的原始订单信息中的目标业务参数，生成所述多渠道对应的统一格式的订单号；其中，所述多渠道对应的统一格式中包括：时间、业务类型、机器码、渠道号、自增数、客户id的目标位，所述机器码为用于生成统一格式的订单号的应用系统标识，所述渠道特征与所述渠道号存在对应关系。
13、第三方面，本申请实施例提供一种电子设备，包括：至少一个处理器和存储器；所述存储器存储计算机执行指令；所述至少一个处理器执行所述存储器存储的计算机执行指令，使得所述至少一个处理器执行如上第一方面以及第一方面各种可能的设计所述的多渠道订单处理方法。
14、第四方面，本申请实施例提供一种计算机可读存储介质，所述计算机可读存储介质中存储有计算机执行指令，所述计算机执行指令被处理器执行时用于实现如如上第一方面以及第一方面各种可能的设计所述的多渠道订单处理方法。
15、第五方面，本申请实施例提供一种计算机程序产品，包括计算机程序，所述计算机程序被处理器执行时，实现如上第一方面以及第一方面各种可能的设计所述的多渠道订单处理方法。
16、本申请提供的多渠道订单处理方法、装置及设备，通过接收多渠道中至少一个渠道发送的原始订单信息；针对任一渠道的原始订单信息，对所述原始订单信息进行解析，识别得到订单的业务类型和订单的渠道特征；
17本文档来自技高网...
【技术保护点】
1.一种多渠道订单处理方法，其特征在于，包括：
2.根据权利要求1所述的方法，其特征在于，所述目标业务参数包括：客户联系方式、客户ID、金额、数量、商家、商品、库存；所述对解析后的原始订单信息进行校验，包括下述至少一项：
3.根据权利要求2所述的方法，其特征在于，所述检查所述请求报文的字段的有效性，包括：
4.根据权利要求1所述的方法，其特征在于，所述方法还包括：
5.根据权利要求1所述的方法，其特征在于，所述根据所述解析后的原始订单信息中的目标业务参数，生成所述多渠道对应的统一格式的订单号，包括：
6.根据权利要求1-5任一项所述的方法，其特征在于，所述统一格式中包含的所述自增数为多位，且用于支持每秒生成批量的订单号，所述统一格式中包含的所述客户ID用于搜索或查询所述原始订单信息；所述生成所述多渠道对应的统一格式的订单号，包括：
7.根据权利要求1-5任一项所述的方法，其特征在于，所述方法还包括：
8.根据权利要求1-5任一项所述的方法，其特征在于，所述方法还包括：
9.根据权利要求
10.一种多渠道订单处理装置，其特征在于，包括：
11.一种电子设备，其特征在于，包括：处理器，以及与所述处理器通信连接的存储器；
12.一种计算机可读存储介质，其特征在于，所述计算机可读存储介质中存储有计算机执行指令，所述计算机执行指令被处理器执行时用于实现如权利要求1-9中任一项所述的方法。
13.一种计算机程序产品，其特征在于，包括计算机程序，该计算机程序被处理器执行时实现权利要求1-9中任一项所述的方法。
...【技术特征摘要】
1.一种多渠道订单处理方法，其特征在于，包括：
2.根据权利要求1所述的方法，其特征在于，所述目标业务参数包括：客户联系方式、客户id、金额、数量、商家、商品、库存；所述对解析后的原始订单信息进行校验，包括下述至少一项：
3.根据权利要求2所述的方法，其特征在于，所述检查所述请求报文的字段的有效性，包括：
4.根据权利要求1所述的方法，其特征在于，所述方法还包括：
5.根据权利要求1所述的方法，其特征在于，所述根据所述解析后的原始订单信息中的目标业务参数，生成所述多渠道对应的统一格式的订单号，包括：
6.根据权利要求1-5任一项所述的方法，其特征在于，所述统一格式中包含的所述自增数为多位，且用于支持每秒生成批量的订单号，所述统一格式中包含的所述客户id用于搜索或查询所述原始订单信息；所述...
【专利技术属性】
技术研发人员：杨倾生，苏健，李晶，李尚真，江魁栋，
申请(专利权)人：中国建设银行股份有限公司，
类型：发明
国别省市：
还没有人留言评论。发表了对其他浏览者有用的留言会获得科技券。