分销管理中的支付应用本文是指分销商代理产品销售，向供货商付费结算的流程。以正在开发的某智能旅游平台为例，景区通过平台发布旅游产品，各分销商获得代理权，营销获取客源后在线下单。下单处理中就会涉及向景区如何支付的问题。景区方为了避免未来应收款管理问题，要求在下单交易时即能结清款项，同时交易明细如金额、时间、事项存入本地日志中。根据这一需求，我们设计了支付逻辑模型。景区可与第三方支付平台（本项目为易宝）合作，本地平台开发与易宝的支付接口，分销商通过易宝支付接口进行结算。
①分销商提前通过易宝接口支付充值，款项进入景区在易宝的账户，同时平台交易日志记录此次“充值”明细，增加分销商在景区账户的余额。②分销商通过平台下单，平台从分销商账户余额中扣除订单额，平台交易日志中记录此次“下单”明细。③如果执行②操作时，分销商账户余额少于订单额，自动转入①操作，待充值额度满足后，自动完成②的操作。④若景区只使用传统支付方式（如银行转账），当景区收到分销商线下转账后，由景区在平台为分销商执行授信操作，在平台输入金额数，平台交易日志记录此次“授信”明细，增加分销商在景区账户的余额。上面需求分析概括了景区和其分销商之间的结算互动关系和流程，包括充值、授信、下单三种账户增减不同的业务流程，要求既可利用第三方支付平台，也要保留传统线下支付手段。这些需求在电子分销管理中具有典型意义，需要统一考虑。
在系统架构设计时，确定以下原则，利用系统的分层架构（struts2+spring+mybatis），不仅实现技术分层，还实现逻辑抽象分层，越往下层，逻辑意义越少，尽量达到以“不变应万变”的设计效应。要把充值、授信和下单三种逻辑目标不同的流程集成到一个实现体系中来，各种安全，事务性处理统一设计。本架构设计分层从上到下分为表示层，控制层，业务层、数据映射层。表示层由jsp页面文件组成，控制层由structs2的Action类文件组成，spring负责业务层逻辑并整合管理控制层和数据访问层的类对象，数据映射层由mybatis配置实现。
表示层是用户直接界面交互的部分，由jsp页面推送至客户端展现，这一层次仅包括表单数据收集、基础格式验证和提交路径，不包含任何业务处理逻辑或数据库操作。在线支付过程中本地系统表单主要为：在线支付发起表单，它由分销商填写、提交支付金额，启动支付流程；本地系统按易宝系统接口定义生成提交的支付数据表单和验证回复表单。其他支付操作过程中的功能页面是界面定向到易宝接口后由其推送显示的。
控制层负责接收表示层表单提交的数据，综合调用业务逻辑层的功能对象去处理。并根据处理结果，选择处理流程的后续转向。控制层通过structs2组件实现设计目标，在structs2的Action类定义中，将在线支付处理的实体类设为属性对象，如充值日志记录实体对象。然后将从表单接收的用户定义数据整合业务状态数据，为实体对象赋值。这样，以实体对象为处理单元，传递至业务逻辑层，有利用数据封装，逻辑意义也更加明晰。支付应用控制层主要包括2个Action方法。一是accountAction的rechargeAccount()方法，它从用户发起的支付表单获取支付数据。通过调用业务逻辑层的服务，生成易宝需要的接口数据包，并创建相应的充值日志记录，然后控制流程定向到易宝用户支付操作接口。使本地事务处理与外部接口操作都进入待完成状态。另一个是accountAction的rechargecallback()，它是易宝通知本地系统用户支付完成状况而回调的接口。通过易宝回调时传回的状态值，本地系统可相应同步推进事务处理的进度。完成一次在线支付事务的远程和本地的原子操作。
业务逻辑层由若干具有业务处理语义的执行单元组成，在控制层的指挥协调下，协同完成整个业务流程，业务逻辑层作用可以类比为一个企业中各职能部门，大家各司其职，相对独立但又承上启下得合作完成一个事务流程的处理。在本项目框架上，由spring组件充当业务逻辑对象。业务逻辑层主要包括的类及其服务定义。accountService的createRechargeLog ( )负责在本地支付事务发起阶段，生成本地充值记录，并使充值记录处于待完成状态。此服务通过参数标识，区分“授信”和“充值”性质不同但操作细节大部分相同的事务。当用户在易宝支付操作成功回调本地接口，控制层利用accountService的commitRecharge( )提交处于待完成的充值日志记录。当支付事务完全成功，accountService的updateAccount()负责更新本地系统的分销商账户数据。通过这三个业务逻辑服务划分，保证了彼此不破坏不侵入其他业务区域，又方便与远程支付状态同步节奏。
数据映射层负责将直接数据库访问包装成实体对象（集）管理形式，既可实现数据库实现物理无关性，对象集合的操作形式也更反映逻辑概念本身，无论是查询和修改都比在代码中直接混合sql语句更易维护。本项目的数据映射采用的mybatis开源框架，该框架的优势是既能约束以实体对象（集）的形式与数据库互操作，又能充分发挥自定义sql语句的灵活性和执行效率。无论是逻辑语义环境，数据库操作最终体现的就是sql语句的查增改删操作，因此，最大化sql语句的通用性，在查询条件和字段上尽量灵活组合。而把逻辑意义的区分设置在业务逻辑层生成实体对象属性值阶段，达到高内聚的设计效果。为此，在数据映射层的sql设计时把充值日志记录的插入、查询和修改都利用mybatis的标签功能作了通用化设计，满足不同支付性质、状态实体对象的数据交互。
分销商确认产品下单后，转入支付确认交互界面。用户填写确认支付金额，和下单明细一起提交至控制层accountAction的re charge ()接收处理。①创建本地支付日志。recharge()首先调用业务逻辑组件accountService的createRechargeLog(accountLog)服务，参数accountLog实体对象主要包括记录编号，分销商，订购产品，时间、金额、交易类型类型（充值、授信、下单），完成状态（创建、提交）等属性，映射数据库表acount_log表结构。createRechargeLog()服务通用于充值、授信、下单三种业务。首先创建一条本地账户日志记录，完成状态为“创建”，如果后续的支付操作顺利完成，未来本记录可进入“完成”状态。如果交易类型为授信或下单，无需后续支付操作，则忽略“完成状态”。createRechargeLog()为accountLog实体对象赋值后，调用数据映射层的insertSelective(AccountLog record)方法生成数据库日志记录。②准备易宝接口数据。本地日志记录生成后，控制层recharge()继续生成易宝接口数据。接口数据主要包括在易宝注册的商户编号、分配的商户密钥、交易类型、交易名称、金额、回调本地地址、利用易宝本地组件生成的签名(hmac)。这些数据封装成实体对象，传送至易宝。③重定向到易宝应用端。recharge()任务完成后，根据action配置转到RechargeReqpayForm.jsp表单页面，易宝接口数据实体对象自动映射成易宝所需的表单字段，页面自动提交到易宝，用户进入易宝页面进行在线支付操作。
用户在易宝完成支付操作后，易宝将以http方式回调本地系统url接口call，将交易数据回传，以便本地系统作后续处理。交易安全性验证。回传接口为控制层对象accountAction的rechargeCallback()方法。易宝回传数据的结构和内容与本地提交时数据大部分相同。这些回传的数据首先要通过易宝本地组件PaymentForOnlineService.verifyCallback( )的安全性验证，当提交和回传的hmac 码一致时表示安全。hmac是一种秘密的密钥验证算法，hmac提供的数据完整性和源身份验证完全取决于秘密密钥分配的范围。如果只有发起者和接收者知道hmac 密钥，那么这就对两者间发送的数据提供了源身份验证和完整性。完成支付事务本地提交。安全性验证完成后，表明远程支付操作成功，因此本地的在线支付日志记录也要同步更新成“完成”状态，分销商账户余额也要累加本次充值额度。这些任务都设计为业务逻辑层的处理过程，由rechargeCallback()调用执行。提交日志的是amountLogService.commitRecharge(accountLog)服务，参数accountLog实体对象传入前只在控制层根据接收的回调数据解析设置了ID属性值，确认了对应的支付日志记录。传入后由业务对象负责为状态属性赋“完成”值，在设计上严格区分各层职责。在业务逻辑层内进一步调用数据映射层对象accountLogMapper.updateByPrimaryKey (accountLog)，修改数据库中支付日志记录的状态值。从接口命名和实现设计上，数据映射层已完全屏蔽了逻辑意义，本方法只是根据accountLog业务对象的属性值按主键查找和修改记录，可以适用于同质的各类数据修改处理。与此思路一致，更新分销商账户余额也采取同样设计架构。本地反馈成功信息。当完成本地事务的同步处理。按照易宝数据格式要求，格式化成功信息反馈至易宝服务端。易宝确认后也推送交易成功消息至本地客户端。整个交易流程完成。
本应用模型中，远程支付操作和对应本地数据和状态变更是同进同退的原子事务。要么都成功，要么都失败，失败也仍需保留事务痕迹以便核查。所以设计了两段段日志提交模式。当启动支付事务，创建支付日志记录时，日志记录处于未完成状态，而且分销商账户余额不变。后续远程支付操作可能发生意外情况有2种一是用户在完成前中止支付操作。则易宝不会对本地接口产生回调，后续事务不触发。因此本地支付日志记录恒为未完成状态，不会被纳入实际计算统计中，但仍可见，用户可选择该记录后再次发起支付操作。二是用户实际支付完成，但易宝回调本地接口时失败。这种情况其实是由易宝负责后续处理，根据其官方文档，它会定时发起回调直至成功为止，这样整个事务也会最终完成。
本网站始终秉持着简洁高效的特色进行设计，让用户更加简洁快速地了解网站提供的招聘与求职信息。由于毕业设计时间较短，本网站仅仅实现了一些基本功能，此后将更加完善、增强网站的功能。总的来说，此次毕业设计在学习Java语言等内容的基础上，进一步学习并实践了网页制作、Web服务器安装、网络数据库操作、JSP程序设计等多种实用技术，如期设计出了一个功能基本齐全的Web人才交流网站。
