在线数字商品交易平台逻辑框架分析

导语：在线数字商品交易平台逻辑框架分析一文来源于网友上传，不代表本站观点，若需要原创文章可咨询客服老师，欢迎参考。

摘要：话费、流量等数字商品已成为日常生活中不可或缺的部分，在线购买交易量级不断攀升，对交易系统业务逻辑的高效性、安全性也提出了更高要求，结合“面向对象程序开发实战”教学目标，对系统业务逻辑框架进行了分析与设计，制定开发内容。业务框架主要包括接收上游订单及查询业务、渠道分配业务、渠道发货业务、接收渠道结果通知业务、向渠道查询结果业务、向上游通知结果业务等，业务逻辑完整，确保安全高效。

关键词：数字商品；交易平台；业务框架

随着通信技术的发展以及移动互联网应用软件的大量出现，广大手机用户，特别是年轻用户更倾向于在移动终端进行话费及流量等数字商品的购买消费，传统的营业厅缴费、充值卡缴费等方式逐渐被边缘化，产业结构也逐渐发生调整，新的行业在线交易业务模式出现并呈多样化发展，业务逻辑也不断完善，在确保交易资金安全的基本前提下，不断调整系统模块结构，优化交易业务逻辑，以提高单笔订单的处理效率，缩短交易时间，给用户呈现更好的体验感。通过对话费流量等数字商品交易业务逻辑框架的分析与设计，使学生了解更多与生活息息相关的互联网应用背后的技术细节，提升学习兴趣，并在业务逻辑实现的过程中提升动手能力，实现课程教学目的。

1业务需求分析

在数字商品交易发展的初期，很多业务流程处理都是集成在一个模块中完成的，从接收上游收单到向渠道发货的业务逻辑都在统一模块中顺序执行完成，此种处理在设计上相对简单，所需考虑情况也较少，订单自始至终都是由一个工作线程处理，处理速度相对较慢，在业务发展的初期订单量不足时还可接受，但是当业务量级增长到一定阶段时，此种业务框架模式的弊端就开始显现，表现在系统不能及时接收处理上游订单，或是订单出现网络异常等情形时人工介入的频率增加，这些问题都直接影响到企业盈利。因此结构调整成为必然，将业务模块拆分成多个模块，以订单状态变化驱动业务流转，各模块线程以流水线接力的方式完成订单的消化，这样的结构在效率及安全性上都有大幅提升。业务框架设计主要由接收上游订单及查询业务模块、渠道分配业务模块、渠道发货业务模块、接收渠道结果通知业务模块、向渠道查询结果业务模块、向上游通知结果业务模块等组成。接收上游订单及查询业务模块负责接收上游的订单交易请求以及订单充值情况查询请求，两种请求根据接口协议中的命令字段值进行区分，收单业务经过一定校验处理后在自身数据库中生成对应的订单记录继续充值过程，接收查询业务则负责在本系统查询上游订单的充值结果并按协议返回数据。渠道分配业务模块用于根据生成的订单记录中的交易要素选择最优的下游渠道或下游运营商进行交易，由于所选择的渠道未必都可交易成功，因此该过程可能会重复多次，但是每次执行都会在数据库中生成对应订单流水记录，用于记录当次选择的渠道信息。渠道发货业务模块负责根据选择的渠道信息向该渠道发送交易网络请求，并记录下游响应情况。接收渠道结果通知业务模块用于异步的交易方式，被动接收渠道对交易订单的完成情况。向渠道查询结果业务模块同样用于异步交易方式，主动向下游查询订单完成情况。向上游通知结果业务模块用于将自身数据库接收的上游订单的完成情况主动告知上游，实现订单的完结。

2业务逻辑详细设计

交易系统业务框架模块图如图1所示，主要由6个业务模块构成，下文将从流程图的角度对各个模块的业务逻辑进行设计说明。

2.1接收上游订单及查询业务模块

本业务模块是交易订单进入平台的唯一入口，安全性是首先需要考虑的，因此在收到请求时先提取出命令字、上游编号及上游订单号、上游产品编号、充值号码等信息，根据上游编号在数据库中查找对应上游信息，判断上游状态是否正常，本次请求IP是否在上游请求IP白名单内，对请求数据进行签名校验等安全验证操作，通过后再根据命令字进行后续处理。若是充值命令，首先根据上游编号及上游订单号在数据库订单表中查询是否已存在该笔订单记录，若存在则按照接口协议进行报文回复，不做其他处理，如不存在则进行新订单入库操作。订单入库逻辑为：首先对充值号码进行白名单及当日充值额度上限检查，若不通过则返回报文，流程结束；若通过则根据上游产品编号在平台产品表中查找平台产品编号、运营商、省份等信息，同时生成对应的系统订单号，将这些信息插入系统订单表及订单发货队列表，订单表记录及队列表记录状态置为等待选择渠道。订单表记录保存订单的详细信息，该表属于大表，信息永久保留。订单发货队列表主要记录订单状态，提高搜索速度，记录在订单完结时会删除。收单业务在保证安全的前提下，尽量缩短业务处理逻辑，节省时间，提高收单效率。若是查询命令，则根据上游编号及订单号在订单表中查询记录是否存在，若没有则回复订单不存在，若存在则根据订单结果（充值成功、充值失败、充值中）组织相应报文进行回复，完成业务处理。流程图如图2所示。

2.2渠道分配业务模块

渠道分配业务模块从订单发货队列表中查找状态为等待选择渠道的记录信息集合，通过订单号在渠道发货流水表中查找该笔订单的所有发货流水记录信息。统计发货次数是否超过限制，若超过限制则将订单置为失败，修改相关表状态后不再进行处理；若没有超过限制，则根据订单表记录里的面值、省份、运营商等信息在渠道表里查找有支持对应产品的渠道信息集合，并按照渠道分流比由大到小的顺序对结果进行排序，优先向优质渠道发货以提高成功率。然后逐个取出集合中的记录，判断渠道当前是否可用，不可用则判断下一个，可用则判断当前渠道是否在已尝试发货流水记录中存在，若存在则判断下一个，当集合都遍历后仍无符合条件渠道，则将订单置为失败处理；若不存在则作为本次待发送的渠道，停止判断，立即将队列表记录锁定，判断订单状态是否为等待选择渠道，若不是则将发货队列状态修改为分配渠道中，再根据选择的渠道号在渠道产品表中查找对应渠道产品编号等信息，生成本次渠道发货流水号，将渠道号、订单号、渠道发货流水号、渠道产品编号、流水状态等信息插入渠道发货流水记录表，记录状态为等待发货，同时将订单表及队列表中的记录状态修改为等待发货，以便进行下一步处理。流程图如图3所示。

2.3渠道发货业务模块

渠道发货业务模块从订单发货队列表中查找状态为等待发货的记录信息集合，对集合中的每条记录查询锁定并判断订单记录状态是否为等待发货、流水记录状态是否为等待发货，状态无误则将发货队列状态修改为发货中。再根据流水表中渠道号，查询对应渠道发货地址、签名秘钥等信息，按照接口协议组织报文发送请求，并根据渠道响应的信息修改相关表状态。若发货成功，则将订单表记录、队列表记录、流水表记录状态都修改为等待充值结果，等待渠道异步返回充值结果。若发货失败则将订单表记录及队列表记录状态修改为等待选择渠道，流水表记录状态修改为发货失败，等待再次尝试。若未接收到响应报文，则按发货成功处理。流程图如图4所示。

2.4接收渠道结果通知业务模块

接收渠道结果通知业务模块用于接收渠道发送的订单充值结果，通知的结果情形只有成功和失败。签名校验后，根据接口协议中的订单发货流水号，找到相应的订单发货流水记录、订单记录、订单发货队列记录，判断三个记录的状态是否都为等待充值结果，若不一致则等待人工核实处理，若一致则根据充值结果进行相应处理。若充值成功，则将订单表记录、发货流水记录状态修改为充值成功，若充值失败，则将两个记录状态修改为充值失败，再将订单发货队列记录删除，同时插入订单通知队列记录，状态为等待通知上游，等待将结果通知给上游。流程图如图5所示。

2.5向渠道查询结果业务模块

向渠道查询结果业务模块作为接收渠道结果通知模块的补充，在长时间没有收到渠道结果通知的情况下主动向渠道发起结果查询请求，在订单发货队列表中查找状态为等待充值结果且更新时间超过设定间隔时间的记录进行查询，并根据查询结果及时更新订单相关状态，避免因渠道通知模块异常造成订单未及时完结，导致订单交易耗时延长。查询到结果后的处理和渠道主动通知结果处理相同，只是在异常情况下出现返回查询结果为订单不存在时，就需要人工核对沟通处理。订单状态修改与接收渠道通知业务基本一致，不再赘述，流程图与图5相似，未单独画出。

2.6向上游通知结果业务模块

在系统内订单结果明确后就要将该充值结果通知给上游，在通知队列表中查询状态为等待通知上游且通知次数少于限定次数的记录，分配给工作线程，锁定通知队列记录并将状态修改为通知中，避免被再次筛选出来。同时检查订单表记录及发货流水记录状态是否同为充值成功或充值失败，相同时则按照接口协议将结果组包发送到上游，若上游成功接收并响应则将订单表记录中是否通知上游状态改为是，同时删除通知队列记录，订单逻辑完结；单表记录及发货流水记录状态不同时则将通知队列状态修改为等待通知上游，同时通知次数加1，等待再次通知。流程图如图6所示。

3结论

本文对数字交易平台业务逻辑框架进行了分析与设计，根据高内聚、低耦合的原则设计业务模块，以状态变化驱动业务流转，保证交易安全的同时提高订单处理效率。本案例应用在“面向对象程序开发实战”课程实践中，作为实践内容，在锻炼学生动手能力的同时，培养团队协作精神。

参考文献：

[1]吴杰明，方英兰.软件工程实例教程[M].北京：清华大学出版社，2010.

[2]罗小利，吴清烈.SaaS软件服务基于大规模定制的业务逻辑框架研究[J].电信科学，2011，27（9）：26-31.

[3]陈伟，沈备军，戚正伟.面向SaaS应用的业务逻辑定制框架的研究与实现[J].计算机应用研究，2011，28（1）：155-158.

[4]张荣，孙家泽.电信增值业务框架中业务逻辑的设计[J].西安邮电学院学报，2008（3）：111-113.

[5]吴立春.基于Facade模式的业务逻辑层框架设计[J].微计算机信息，2007（24）：245-246+308.

作者：谢剑 单位：湖南信息职业技术学院